- The conference client maintains a cache of credentials it has seen in E2EE secure online conference (as discussed above);
- When the conference client joins an E2EE secure online conference:
  - The conference server provides a list of hashes of user credentials that are being used in the online conference (i.e., for participants in the online conference);
  - For each hash of each user credential contained in the list obtained from the conference server, the conference client checks/compares each hash contained in the list against each of a corresponding hash of each user credential stored in its cached user credentials in order to determine whether it has a stored/cached user credential that matches a particular hash contained in the list obtained from the conference server:
    - If the conference client determines that it does have a stored/cached credential matching a particular hash of the list obtained from the conference server, the conference client uses the stored credential in the meeting; or
    - If the conference client determines that it does not have a stored/cached credential for a particular hash of the list, the conference client downloads the user credential corresponding to the unmatched hash, validates the user credential, and adds the user credential to its cached list of user credentials in order to complete joining the E2EE secure online conference.

For the hash and fetch variant, fetching user credentials of unmatched hashes can be performed differently, depending on implementation. In at least one embodiment, each user credential for each unmatched hash can be fetched individually or can be fetched in a batch from the conference server or from another server. For example, user credentials may be downloaded from the main MLS conference server or from a different server.

In at least one embodiment, a Uniform Resource Locator (URL) or other identifying information can be included for one or more of the hashes of each user credential contained in the list obtained from the conference server. In at least one embodiment, credentials may be requested by hash or using a link (e.g., URL) provided by the conference server.

Generally, credential validation can involve querying an authentication service (AS) (not shown), to determine where a credential is valid. For example, for X.509 certificates, the AS can include a certificate chain per RFC 5280 that can be used to determine credential validity. Such validation can be used by a client to confirm the authenticity of a credential that is downloaded, before using the credential for MLS negotiations/operations.

Another approach or variant for joining an MLS E2EE secure online conference may be referred to herein as the ‘compression dictionary’ variant in which a conference client and the conference server can operate, as follows:

- The conference client maintains a cache of credentials it has seen in E2EE secure online conference (as discussed above);
- When the conference client joins an E2EE secure online conference:
  - The conference client includes in a request to the conference server an expression of the set of user credentials it has stored in its cache of user credentials. In at least one embodiment, the expression sent to the conference server may include a list of hashes of the user credentials stored/cached by the conference client;
  - The conference server compresses the list of user credentials in the meeting using the client's list of user credentials as a compression dictionary; and
  - The conference server returns to the client a list of user credentials in the meeting, replacing the user credentials the conference client already knows (i.e., stored in its cached user credentials) with indices into the compression dictionary and providing any user credentials to the conference client that it does not already know (i.e., that are not stored in its cached user credentials.

Thus, as shown in FIG. 2 generally at 222, each conference client 204A, 204B, 204C, and 204D involved in the first online conference can request tree data/user credentials using either the hash and fetch interactions or the compression dictionary interactions, as discussed above. As generally shown at 230, the conference server 210 can provide/respond to a request with ratchet tree data including user credentials (potentially compressed as hashes of user credentials for the hash and fetch variant) to each conference client. Thus, the conference server 210 can store a ratchet tree/user credentials for each of one or more online conferences hosted by the conference server and can provide the ratchet tree/user credentials (optionally in a compressed form) to conference clients seeking to join an online conference. In the hash and fetch variant, a conference client can separately obtain any user credentials not already stored thereat, while in the compression dictionary variant, any user credentials not already stored thereat can be directly included in the ratchet tree data (along with indices of user credentials known by the conference client) sent to the conference client.

For example, for the first online conference, conference client 204A already has user credentials stored thereat for each of users 201B, 201C, and 201D and thus does not need to obtain any additional user credentials from the conference server. In contrast, conference client 204B is to obtain the user credential for user 201A (e.g., from the conference server 210 or from another server).

Similar operations may be performed by conference clients 204C, 204D, 204E, and 204F using either the hash and fetch or the compression dictionary operations/interactions with the conference server 210 for a second online conference (online conference 2) involving a ratchet tree 214-2 stored by the conference server 210.

In general, the hash and fetch variant may provide advantages in terms of reduced time to join an E2EE online conference and/or the amount of data uploaded/downloaded by each conference client when a majority of participants in a given online conference are already known to each conference participant (i.e., the user credentials of each participant are already cached by each conference client; whereas, the compression dictionary may provide advantages in terms of reduced time to join an E2EE online conference when the overlap of already known participants/user credentials is smaller.

Consider various examples that may illustrate how embodiments herein may reduce the amount of data that a conference client may need to download for joining/entering a given E2EE online conference. By reducing the amount of data that is to be downloaded, the speed of joining a given E2EE online conference that includes some overlap with participants of previous online conference(s) in which a given conference client/user has participated may thus be improved (take less time).

In one example, consider that a user, Alice, and 20 other users join a meeting. Alice's conference client can download all user credentials for the other 20 participants and can store/cache the 20 downloaded user credentials in a cached list of user credentials. Thereafter, the meeting can end, yet Alice's conference client can maintain the cached list of user credentials for use in one or more subsequent meetings. For example, one day later, consider that Alice joins another meeting with 10 of the participants from the previous call. For an implementation involving the hash and fetch embodiment, the conference server can provide Alice's conference client with a list of the 10 user credential hashes. In such an embodiment, Alice's conference client can recognize that all 10 hashes correspond to user credentials contained in the cached list of user credentials, so the conference client does not have to download any credentials.

In another example, consider that a user, Bob, and 20 other users join a meeting. Bob's conference client can download all user credentials for the other 20 participants and can store/cache the 20 downloaded user credentials in a cached list of user credentials. Thereafter, the meeting can end, yet Bob's conference client can maintain the cached list of user credentials for use in one or more subsequent meetings. For example, one day later, consider that Bob joins another meeting with 10 of the participants from the previous call. For an implementation involving the compression dictionary embodiment, when Bob's conference client initially connects to the conference server, the conference client provides a list of the user credentials (or hashes thereof) cached by the conference client to the conference server. In such an embodiment, the conference server can determine that the conference client already knows the user credentials of the 10 participants (e.g., by comparing user credentials (or hashes thereof) of the ratchet tree for the current call to the list of user credentials (or hashes thereof) obtained from the conference server to determine known/unknown or cached/not cached user credentials of the conference server) and can and replaces the known 10 known credentials with index values of the credentials that were included in the list previously obtained from the conference client, so that Bob's conference client does not have to download any of the previously known/cached user credentials.

In another example, consider that Bob subsequently joins a group meeting of 40 people, including 20 coworkers with whom he meets regularly. In accordance with embodiments herein (using either the hash and fetch or the compression dictionary variant), because Bob has met with those 20 coworkers recently in another meeting, Bob's conference client does not need to download the user credentials of those 20 known coworkers, but only the remaining 20 participants, potentially cutting the user credential download time for the group meeting roughly in half.

In some embodiments, the hash and fetch approach and the compression dictionary approach may be combined into yet another approach. For example, starting with the compression dictionary variant, a given client may express the list of credentials it has cached as a Bloom filter, a conference server may indicate known credentials by their hashes. Since Bloom filters can sometimes have false positives, the conference server may accidentally compress a user credential that a conference client does not already know. Thus, in some instances, a conference client may recover from this failure by using the hash to fetch the improperly compressed user credential, using interactions as discussed for the hash and fetch variant.

In various embodiments, user credentials cached at a given conference client may be cleared or otherwise deleted in-whole and/or in-part based on a variety of factors and/or configurations. For example, in various embodiments, a conference client can be configured to clear its cache of user credentials on a periodic basis (e.g., once a week, once every ‘X’ number of hours), based on a user seeking to join an online conference from a new device (e.g., a user can have multiple devices, such as a laptop, a mobile phone, etc., each of which can configured with a corresponding conference client for joining online conferences), based on a trigger received from a conference server (e.g., the server indicating to the conference client to clear its cache of user credentials), based on one or more conditions/criteria (e.g., a user credential for a particular user being updated/expiring/etc., based on the number of cached user credentials exceeding a threshold number [e.g., older user credentials could be ‘rolled-off’ or removed from the cache]), combinations thereof, and/or the like.

Referring to FIG. 3, FIG. 3 is a flow chart depicting a method 300 according to an example embodiment. In at least one embodiment, method 300 illustrates operations that may be performed by a conference client of a given user (e.g., any conference client discussed herein) and/or by a conference server (e.g., any conference server discussed herein) in order to facilitate joining E2EE encrypted meetings, according to an example embodiment.

As shown at 302, the method may include storing, by a conference client of a first user, one or more user credentials in a cached list of user credentials, wherein one or more user credential included in the cached list of user credentials corresponds to one or more other user for each of one or more previous online conferences (e.g., E2EE online conferences) in which the first user has (previously) participated.

At 304, the method may include, for a particular online conference to which the first user seeks to join, determining whether one or more particular user credentials for particular users participating in the particular online conference are not included in the cached list of user credentials (maintained by the conference client of the first user).

At 306, the method may include, based on determining that at least one particular user credential for the particular online conference is not identified in the cached list of user credentials, obtaining, by the conference client of the first user, the at least one particular user credential to enable the first user, via the conference client, to join the particular online conference.

The operations at 304 and 306 may be performed differently depending on whether the hash and fetch variant or the compression dictionary variant may be implemented for a given system deployment.

In one example, consider various example operations that may be performed by a conference client and a conference server in accordance with the hash and fetch embodiment for obtaining user credentials by the conference client for a given E2EE online conference to which a user of the conference client seeks to join as discussed with reference to FIG. 4, which is a message sequence diagram 400 illustrating example operations for the hash and fetch approach for joining the E2EE online conference, according to an example embodiment. FIG. 4 includes a conference client 404A associated with a user 401A. FIG. 4 also includes a conference server 410. A device of the user 401A upon which the conference client 404A can operate is not shown in FIG. 4 for purposes of brevity only in order to illustrate various features associated with embodiments herein.

As shown at 420, consider that conference client 404A maintains a cached list of user credentials in which each user credential included in the cached list of user credentials corresponds to each of one or more other users for each of one or more previous online conferences in which the user 401A has participated.

For joining a particular/current E2EE online conference hosted by the conference server 410, as shown at 430, the conference client 404A can send a network request to the conference server 410 requesting the ratchet tree/user credentials for the current E2WW online conference to which the user 401A seeks to join/enter. As shown at 432, the conference server 410 responds with the ratchet tree for the current online conference in which hashes of the user credentials for each participant in the online conference are included for the ratchet tree.

As shown at 434, the conference client 404A can compare the hashes of the user credentials obtained from the conference server 410 against (hashes of) the cached list of user credentials stored by the conference client 404A in order to determine whether there are any user credentials for participants of the current E2EE online conference that are not cached at the conference client 404A. It is understood that the conference client 404A knows/stores the user credential of the user 401A associated with the conference client 404A.

Upon determining any user credentials for the current online conference that are not stored/cached at the conference client 404A, the conference client 404A can fetch the corresponding (unknown/not cached) user credentials, for example, from the conference server, as generally shown at 436-1 and 438-1 thru 436-N and 438-N for any ‘N’ number user credentials not known/not cached at the conference client 404A. The fetching/downloading of user credential(s) performed by the conference client 404A can be performed individually for each unknown user credential, in a batch manner, using one or more network link(s) (e.g., URLs) contained in the ratchet tree data obtained from the conference server 410, combinations thereof, and/or the like in accordance with various embodiments herein.

The conference client 404A can use the combination of known/cached user credentials from previous E2EE online conference(s) and the newly obtained user credential(s) fetched for the current online conference in order to perform the MLS negotiations among the participants, per MLS standards, in order to complete joining/entering the E2EE online teleconference.

In another example, consider various example operations that may be performed by a conference client and a conference server in accordance with the compression dictionary embodiment for obtaining user credentials by the conference client for a given E2EE online conference to which a user of the conference client seeks to join as discussed with reference to FIG. 5, which is a message sequence diagram 500 illustrating example operations for the compression dictionary approach for joining the E2EE online conference, according to an example embodiment. FIG. 5 includes a conference client 504A associated with a user 501A. FIG. 5 also includes a conference server 510. A device of the user 501A upon which the conference client 504A can operate is not shown in FIG. 5 for purposes of brevity only in order to illustrate various features associated with embodiments herein.

As shown at 520, consider that conference client 504A maintains a cached list of user credentials in which each user credential included in the cached list of user credentials corresponds to each of one or more other users for each of one or more previous E2EE online conferences in which the user 501A has participated.

For joining a particular/current E2EE online conference hosted by the conference server 510, as shown at 530, the conference client 504A can send a network request to the conference server 510 requesting the ratchet tree/user credentials for the current E2EE online conference to which the user 501A seeks to join/enter. As shown at 530, the request can include a compression dictionary such as an ordered list of hashes of user credentials stored in the cached list of user credentials of the conference client 504A, as well as the user credential for the user 501A associated with the conference client 504A.

As shown at 532, the conference server 510 can compare the hashes of the user credentials obtained from the conference client 504A in the compression dictionary against (hashes of) the list of user credentials included in the ratchet tree for the current E2EE online conference in order to determine whether there are any user credentials for participants of the current online conference that are not known/cached at the conference client 504A.

Upon determining, by the conference server 510, user credentials known and/or unknown (i.e., cached and/or not cached) at the conference client 504A, the conference server 510 can construct/generate a ratchet tree for the current E2EE online conference to be sent to the conference client 504A in a manner such that, for any user credential(s) determined (based on the comparison) to be known/cached by the conference client 504A, the conference server 510 can include an index value in the ratchet tree that corresponds to an index of the known user credential as was identified in the ordered list of hashed user credentials of the compression dictionary obtained from the conference client 504A. For any corresponding user credential(s) determined to be unknown/not cached by the conference client 504A, the conference server can include the corresponding user credential(s) in the ratchet tree. As shown at 534, the conference server 510 can send the generated ratchet tree to the conference client 504A (with indices of any user credential(s) known/cached by the conference client 504A and user credential(s) of any user credentials not known/not cached by the conference client 504A).

The conference client 504A can use the combination of known/cached user credentials from previous E2EE online conference(s) and the newly obtained user credential(s) in order to perform the MLS negotiations among the participants, per MLS standards, in order to complete joining/entering the E2EE online teleconference.

Consider other example details with reference to FIGS. 6A, 6C, and 6D, discussed below, that may illustrate features of embodiments herein that may facilitate reducing the amount of data (user credentials) that may be downloaded by a conference client 604A of a user (not shown) seeking to join at least one MLS E2EE online conference using cached user credentials that can be stored at the conference client 604A, thus facilitating a faster join time for entering an MLS E2EE online teleconference as compared to conventional interactions performed for entering such an online conference. A device of the user upon which the conference client 604A can operate is not shown in FIGS. 6A, 6C, and 6D for purposes of brevity only in order to illustrate various features associated with embodiments herein. Further, it is to be understood that the conference client 604A also stores the user credential of the user associated with the conference client 604A.

For example, FIG. 6A is a diagram illustrating example details for joining a first E2EE online conference by conference client 604A of the user (referred to as a user ‘A’) in accordance with the embodiments herein. FIG. 6A includes conference client 604A and a conference server 610. As shown in FIG. 6A, consider that the user seeks to join a first online conference including 7 other users (shown in FIG. 6A as users ‘B’, ‘C’, ‘D’, ‘E’, ‘F’, ‘G’, and ‘H’) for a total of 8 users in the online conference at a time when no user credentials have been cached at the conference client 604A (e.g., for a first online conference of the conference client 604A and/or after a condition/criteria/event/time period that caused the cache to be cleared).

As illustrated in FIG. 6A, consider that the conference client 604A requests the ratchet tree for the current E2EE online conference to which the user of the conference client 604A seeks to join. The size of the request sent by the conference client 604A may be minimal, such as a few bits or less than 1 byte (B) (e.g., near 0B).

The conference server 610 can respond to the request with a ratchet tree 650A for the E2EE online conference that includes a user credential for each of the users (including user ‘A’) in which the size of each user credential may be approximately 3 kilobytes (KB). It is to be understood the size of each user credential is provided for illustrative purposes only and is not meant to limit the broad scope of embodiments herein. Thus, the size of the response may be approximately 24,000 bytes [24 KB] (i.e., 3 KB×8 user credentials).

Consider after the first online conference ends that user ‘A’ via conference client 604A seeks to join a subsequent online conference that includes users, ‘B’, ‘D’, ‘G’, and ‘H’ that participated in the previous online conference of FIGS. 6A and 3 new users, ‘J’, ‘K’, and ‘L’ that did not participate in the previous online conference of FIG. 6A.

FIG. 6B is a diagram illustrating a conventional process for joining a subsequent E2EE online conference by the conference client 604A of FIG. 6A if no user credentials were to be cached at the conference client for any online conferences. For example, as shown in FIG. 6B, if no user credentials were to be cached by the conference client 604A, the conference client 604A would again download/receive each user credential of each participant of the subsequent online conference, or approximately 24,000 bytes [24 KB] of ratchet tree data (i.e., 3 KB×8 user credentials) for a ratchet tree 650B generated by the conference server 610.

However, in accordance with embodiments herein with reference to FIGS. 6C-1, 6C-2, and 6D, consider that conference client 604A does cache each of the user credentials for the other users that participated in the first E2EE online conference of FIG. 6A. For example, for FIGS. 6C-1, 6C-2, and 6D, consider that conference client 604A has a cached list of the user credentials for each of users ‘B’, ‘C’, ‘D’, ‘E’, ‘F’, ‘G’, and ‘H’ that were obtained for the first E2EE online conference of FIG. 6A. As noted above, it is to be understood that conference client 604A also knows/stores the user credential for the user ‘A’ of the conference client 604A.

With reference to FIG. 6C-1 and FIG. 6C-2, FIGS. 6C-1 and 6C-2 are diagrams illustrating example process details for joining a subsequent E2EE online conference by the conference client 604A of FIG. 6A using the hash and fetch approach based on the cached list of user credentials stored by the conference client 604A for the other users that participated in the first E2EE online conference of FIG. 6A, according to an example embodiment.

As illustrated in FIG. 6C-1, consider that the conference server 610 (after receiving a request for the ratchet tree for the current E2EE online conference) generates a ratchet tree 650C for the current E2EE online conference that include a hash of each user credential of each of the users ‘A’, ‘B’, ‘J’, ‘D’, ‘K’, ‘L’, ‘G’ and ‘H’ and further includes, for each hash of each user credential, a link (e.g., a URL) for a network location/server from which the conference client 604A can fetch/download a given user credential, if needed (e.g., if not known to the conference client 604A).

As illustrated in FIG. 6C-1, consider that the approximate size of the hash of each user credential and the link is approximately 100 bytes (100B). Thus, the response from the conference server may be approximately 800 bytes for ratchet tree 650C. Upon receiving the ratchet tree 650C/hash of each user credential and link, the conference client 604A can compare the hash of each user credential obtained from the conference server 610 to a hash of each user credential contained in the cached list of user credentials stored by the conference client 604A from the previous online E2EE conference in which user ‘A’ participated.

Based on the comparison, the conference client 604A (in this example) can determine that the user credentials for each of users ‘B’, ‘D’, ‘G’, and ‘H’, are known to the conference client 604A, as those user's credentials were cached for the previous E2EE online conference of FIG. 6A. The conference client 604A can further determine that it does not have user credentials for each of users ‘J’, ‘K’, and ‘L’, which triggers the conference client 604A to initiate a download of corresponding (unknown) user credentials using the link included in the ratchet tree data obtained for each of users, ‘J’, ‘K’, and ‘L’, as illustrated in FIG. 6C-2.

As shown in FIG. 6C-2, the conference client 604A can download an additional 9000 bytes of user credential data through fetching the user credentials for each of users ‘J’, ‘K’, and ‘L’. Thus, the hash and fetch approach may reduce the overall amount of user credential data downloaded for the subsequent E2EE online conference to approximately 9,100 bytes, as compared to the 24,000 bytes of user credential data to be downloaded (as shown in FIG. 6B) if no user credentials were cached thereat.

Accordingly, the hash and fetch approach utilized by the conference client 604A, performed based on user credentials cached at the conference client 604A from a previous E2EE online conference, may significantly reduce the amount of user credential data to be downloaded by the conference client 604A for joining a subsequent E2EE online conference, which can therefore speed up the time taken to join/enter a subsequent E2EE conference.

Moving to FIG. 6D, FIG. 6D is a diagram illustrating example process details for joining a subsequent E2EE online conference by the conference client 604A of FIG. 6A using the compression dictionary approach based on the cached list of user credentials stored by the conference client 604A for the other users that participated in the first E2EE online conference of FIG. 6A.

As shown in FIG. 6D, consider that for sending a request to the conference server 610 for joining the subsequent E2EE online conference, the conference client 604A generates and sends a compression dictionary 630 that includes an ordered list (e.g., starting from an index of 0 at the top of the list and increasing by an index value of 1 to the bottom of the list) of hashes of user credentials, including a hash of the user credential for user ‘A’ and also corresponding hashes of each corresponding user credential included in the cached list of user credentials maintained by the conference client. For FIG. 6D, the size of the hash of each user credential included in the compression dictionary 630 may be approximately 32 bytes, for approximately 256 bytes of user credential data included in the request sent to the conference server 610.

Upon receiving the compression dictionary 630, the conference server 610 compares the hashes of the user credentials obtained from the conference client 604A in the compression dictionary 630 against (hashes of) the list of user credentials included in the ratchet tree for the current E2EE online conference in order to determine whether there are any user credentials for participants of the current E2EE online conference that are not known/cached at the conference client 604A. For example, the conference server 610 can determine for the present example that the conference client 604A does not have a user credential for each of users ‘J’, ‘K’, and ‘L’ and does have a cached user credential for each of users ‘B’, ‘D’, ‘G’, and ‘H’.

Upon determining, by the user credentials known and/or unknown (i.e., cached and/or not cached) at the conference client 604A, the conference server 610 can construct/generate a ratchet tree 650D to the current E2EE online conference to be sent to the conference client 604A that includes an index value of each user credential known/cached at the conference client 604A, such as index(0) for the user credential for user ‘A’ (that is implicitly known by the conference client 604A), index(1) for the user credential for user ‘B’ that is included in the cached list of user credentials of the conference client 604A, index(6) for the user credential for user ‘G’ that is included in the cached list of user credentials of the conference client 604A, and index(7) for the user credential for user ‘H’ that included in the cached list of user credentials of the conference client 604A. The ratchet tree 650D generated by the conference server 610 can also include a corresponding user credential for each of corresponding users ‘J’, ‘K’, and ‘L’.

Each index value provided for each user credential known/cached by the conference client 604A may be approximately 4 bytes while the user credential provided for each user not known/not cached by the conference client 604A may be approximately 3 KB such that the size of the ratchet tree 650C/user credential data sent to the conference client may be approximately 9,020 bytes.

Accordingly, the compression dictionary approach utilized by the conference client 604A, performed based on user credentials cached at the conference client 604A from a previous E2EE online conference, may also significantly reduce the amount of user credential data to be downloaded by the conference client 604A for joining a subsequent E2EE online conference, which can therefore speed up the time taken to join/enter a subsequent E2EE conference.

Thus, embodiments herein may facilitate joining an E2EE online conference by a conference client of a particular user based on user credentials for other users that can be stored/cached by the conference client from past E2EE online conference(s) in a manner that may take less time as compared to conventional processes for joining an E2EE online conference that involve downloading user credentials for all users of the online conference each time such an online conference is joined/entered by a given user. As people typically meet with the same people often, embodiments herein may exploit this in order to reduce the amount of credential data that a meeting participant has to download, thus getting them into a meeting more quickly.

Referring to FIG. 7, FIG. 7 illustrates a hardware block diagram of a computing device 700 that may perform functions associated with operations discussed herein in connection with the techniques described for embodiments herein. In various embodiments, a computing device or apparatus, such as computing device 700 or any combination of computing devices 700, may be configured as any entity/entities in order to perform operations of the various techniques discussed for embodiments herein, such as any elements, functions, etc. discussed for embodiments herein.

In at least one embodiment, the computing device 700 may be any apparatus that may include one or more processor(s) 702, one or more memory element(s) 704, storage 706, a bus 708, one or more network processor unit(s) 730 interconnected with one or more network input/output (I/O) interface(s) 732, one or more I/O interface(s) 716, and control logic 720. In various embodiments, instructions associated with logic for computing device 700 can overlap in any manner and are not limited to the specific allocation of instructions and/or operations described herein.

For embodiments in which computing device 700 may be implemented as any device capable of wireless communications, computing device 700 may further include at least one baseband processor or modem 710, one or more radio RF transceiver(s) 712 (e.g., any combination of RF receiver(s) and RF transmitter(s)), one or more antenna(s) or antenna array(s) 714.

In at least one embodiment, processor(s) 702 is/are at least one hardware processor configured to execute various tasks, operations and/or functions for computing device 700 as described herein according to software and/or instructions configured for computing device 700. Processor(s) 702 (e.g., a hardware processor) can execute any type of instructions associated with data to achieve the operations detailed herein. In one example, processor(s) 702 can transform an element or an article (e.g., data, information) from one state or thing to another state or thing. Any of potential processing elements, microprocessors, digital signal processor, baseband signal processor, modem, PHY, controllers, systems, managers, logic, and/or machines described herein can be construed as being encompassed within the broad term ‘processor’.

In at least one embodiment, memory element(s) 704 and/or storage 706 is/are configured to store data, information, software, and/or instructions associated with computing device 700, and/or logic configured for memory element(s) 704 and/or storage 706. For example, any logic described herein (e.g., control logic 720) can, in various embodiments, be stored for computing device 700 using any combination of memory element(s) 704 and/or storage 706. Note that in some embodiments, storage 706 can be consolidated with memory element(s) 704 (or vice versa) or can overlap/exist in any other suitable manner.

In at least one embodiment, bus 708 can be configured as an interface that enables one or more elements of computing device 700 to communicate in order to exchange information and/or data. Bus 708 can be implemented with any architecture designed for passing control, data and/or information between processors, memory elements/storage, peripheral devices, and/or any other hardware and/or software components that may be configured for computing device 700. In at least one embodiment, bus 708 may be implemented as a fast kernel-hosted interconnect, potentially using shared memory between processes (e.g., logic), which can enable efficient communication paths between the processes.

In various embodiments, network processor unit(s) 730 may enable communication between computing device 700 and other systems, entities, etc., via network I/O interface(s) 732 (wired and/or wireless) to facilitate operations discussed for various embodiments described herein. In various embodiments, network processor unit(s) 730 can be configured as a combination of hardware and/or software, such as one or more Ethernet driver(s) and/or controller(s) or interface cards, Fibre Channel (e.g., optical) driver(s) and/or controller(s), wireless receivers/transmitters/transceivers, baseband processor(s)/modem(s), and/or other similar network interface driver(s) and/or controller(s) now known or hereafter developed to enable communications between computing device 700 and other systems, entities, etc. to facilitate operations for various embodiments described herein. In various embodiments, network I/O interface(s) 732 can be configured as one or more Ethernet port(s), Fibre Channel ports, any other I/O port(s), and/or antenna(s)/antenna array(s) now known or hereafter developed. Thus, the network processor unit(s) 730 and/or network I/O interface(s) 732 may include suitable interfaces for receiving, transmitting, and/or otherwise communicating data and/or information (wired and/or wirelessly) in a network environment.

I/O interface(s) 716 allow for input and output of data and/or information with other entities that may be connected to computing device 700. For example, I/O interface(s) 716 may provide a connection to external devices such as a keyboard, keypad, a touch screen, and/or any other suitable input and/or output device now known or hereafter developed. In some instances, external devices can also include portable computer readable (non-transitory) storage media such as database systems, thumb drives, portable optical or magnetic disks, and memory cards. In still some instances, external devices can be a mechanism to display data to a user, such as, for example, a computer monitor, a display screen, or the like.

For embodiments in which computing device 700 is implemented as a wireless device or any apparatus capable of wireless communications, the RF transceiver(s) 712 may perform RF transmission and RF reception of wireless signals via antenna(s)/antenna array(s) 714, and the baseband processor or modem 710 performs baseband modulation and demodulation, etc. associated with such signals to enable wireless communications for computing device 700.

In various embodiments, control logic 720 can include instructions that, when executed, cause processor(s) 702 to perform operations, which can include, but not be limited to, providing overall control operations of computing device; interacting with other entities, systems, etc. described herein; maintaining and/or interacting with stored data, information, parameters, etc. (e.g., memory element(s), storage, data structures, databases, tables, etc.); combinations thereof; and/or the like to facilitate various operations for embodiments described herein.

The programs described herein (e.g., control logic 720) may be identified based upon application(s) for which they are implemented in a specific embodiment. However, it should be appreciated that any particular program nomenclature herein is used merely for convenience; thus, embodiments herein should not be limited to use(s) solely described in any specific application(s) identified and/or implied by such nomenclature.

In various embodiments, any entity or apparatus as described herein may store data/information in any suitable volatile and/or non-volatile memory item (e.g., magnetic hard disk drive, solid state hard drive, semiconductor storage device, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM), application specific integrated circuit (ASIC), etc.), software, logic (fixed logic, hardware logic, programmable logic, analog logic, digital logic), hardware, and/or in any other suitable component, device, element, and/or object as may be appropriate. Any of the memory items discussed herein should be construed as being encompassed within the broad term ‘memory element’. Data/information being tracked and/or sent to one or more entities as discussed herein could be provided in any database, table, register, list, cache, storage, and/or storage structure: all of which can be referenced at any suitable timeframe. Any such storage options may also be included within the broad term ‘memory element’ as used herein.

Note that in certain example implementations, operations as set forth herein may be implemented by logic encoded in one or more tangible media that is capable of storing instructions and/or digital information and may be inclusive of non-transitory tangible media and/or non-transitory computer readable storage media (e.g., embedded logic provided in: an ASIC, digital signal processing (DSP) instructions, software [potentially inclusive of object code and source code], etc.) for execution by one or more processor(s), and/or other similar machine, etc. Generally, memory element(s) 704 and/or storage 706 can store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof, and/or the like used for operations described herein. This includes memory element(s) 704 and/or storage 706 being able to store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof, or the like that are executed to carry out operations in accordance with teachings of the present disclosure.

In some instances, software of the present embodiments may be available via a non-transitory computer useable medium (e.g., magnetic or optical mediums, magneto-optic mediums, CD-ROM, DVD, memory devices, etc.) of a stationary or portable program product apparatus, downloadable file(s), file wrapper(s), object(s), package(s), container(s), and/or the like. In some instances, non-transitory computer readable storage media may also be removable. For example, a removable hard drive may be used for memory/storage in some implementations. Other examples may include optical and magnetic disks, thumb drives, and smart cards that can be inserted and/or otherwise connected to a computing device for transfer onto another computer readable storage medium.