Patent Description:
The claimed subject-matter is defined by the independent claims. Dependent claims define embodiments thereof. The present technology relates to systems and methods for efficiently and securely requesting and receiving, from a remote service, data for multiple accounts associated with the same device or application. In particular, the technology enables a client device to request application data for all accounts associated with the device or application installation using a single remote procedure call, rather than requiring separate calls for each account. The technology also enables the client device to request this information by providing a single identifier such as an application installation ID or device ID, rather than requiring the client device to include identifiers specific to each account (account IDs) in the remote procedure call, which may raise security or other concerns. Furthermore, the technology enables the remote service to return the requested information in a manner that obfuscates the account IDs and thus limits their potential use if the communication is intercepted. This approach allows all application data to be transmitted together even where security or other concerns would otherwise dictate that separate transmissions should be made for each account ID.

In one aspect, the disclosure describes a method of managing requests for account data over a network. The method comprises: receiving, by one or more processors of a registry service, a remote procedure call from a client device that includes a first identifier; identifying, by the one or more processors, from data maintained by the registry service, a plurality of second identifiers corresponding to a plurality of accounts that are associated with the first identifier; obtaining, by the one or more processors, application data for each of the plurality of accounts from an application for each of the plurality of accounts. In some aspects, identifying which application data within the data structure corresponds to each of the plurality of accounts further comprises using the order of at least two of the entries of the data structure. In some aspects, the application data within the data structure comprises a number of messages associated with each of the plurality of accounts. For example, the number of messages associated with each of the plurality of accounts may represents a number of unread messages or a number of total messages associated with each of the plurality of accounts. In some aspects, the method may further include generating, by the one or more processors, an indication on the client device of the number of messages associated with each of the plurality of accounts. For example, the indication on the client device may comprise one or more of a visible, audible, or tactile indication. In some aspects, the plurality of accounts is associated with a single application installation on the client device. For example, the single application may be an installation of one of an email application, a social media application, or a banking application.

The present technology will now be described with respect to the following exemplary systems and methods.

<FIG> schematically illustrates one embodiment of an example system in accordance with the present technology. Client device <NUM> can be any device, such as a personal computer, mobile phone, netbook, tablet PC, PDA, or wearable device. In the embodiment of <FIG>, client device <NUM> is shown running two applications <NUM> and <NUM>, one or both of which may be any type of application such as email applications, social media applications, banking applications, etc. Application <NUM> is shown being associated with a plurality of accounts <NUM>. Accounts 112a, 112b, and 112c represent accounts that are currently logged-in on client device <NUM>. Account 112d, shown in dashed lines, represents an account that has previously been logged-in on device <NUM>, but which is currently logged-out on device <NUM>. The second application <NUM> is shown having a single account <NUM> that is currently logged-in. Although referred to herein as "accounts," elements <NUM> and <NUM> may also refer to any other types of profiles, avatars, or linked services or devices. For example, accounts <NUM> could each represent a single thermostat, sensor, camera, or electric lock in a "smart home" or security system.

The applications are configured to request application data from a remote service over connection <NUM>. Connection <NUM> may be any type of wired or wireless connection such as cellular networks, wide-area networks, local area networks, etc., as well as any interconnected combination(s) thereof such as the Internet. In the embodiment of <FIG>, the remote service is comprised of a registry service <NUM> and an application backend service <NUM>. Registry service <NUM> and application backend service <NUM> are connected via connection <NUM>, which also may be any type of wired or wireless connection, as well as any interconnected combination(s) thereof. In addition, registry service <NUM> and application backend service <NUM> may be processes running on a single computing device or a distributed set of devices (e.g., a server farm), in which case connection <NUM> may represent internal connections within that computing device or across the set of devices.

Registry service <NUM> maintains a server-side view of the accounts that are logged into each installed application and/or device. Thus, in the embodiment of <FIG>, registry service <NUM> maintains log-in data <NUM> indicating that accounts 112a, 112b, and 112c are logged into application <NUM> on device <NUM>, and that account <NUM> is logged into application <NUM> on device <NUM>. In other embodiments, registry service <NUM> may be application-specific, and, for example, only maintain data regarding which accounts are logged into application <NUM> on device <NUM>. Registry service <NUM> and log-in data <NUM> may be resident on the same computing device. Alternatively, registry service <NUM> may be running on a first computing device, and log-in data <NUM> may be maintained in one or more separate computing devices such as database servers or separate networked storage devices.

Application backend service <NUM> is the source for the application data <NUM> associated with each account. For example, application backend service <NUM> may be one or more servers containing the email messages associated with accounts <NUM>, the social media profile data associated with accounts <NUM>, and/or the banking data associated with accounts <NUM>. Similarly, application backend service <NUM> may be one or more devices or servers to which a plurality of thermostats, cameras, sensors, electric locks, or other "smart home" devices associated with accounts <NUM> are connected. Application backend service <NUM> and application data <NUM> may be resident on the same computing device. Alternatively, application backend service <NUM> may be running on a first computing device, and application data <NUM> may be maintained in one or more separate computing devices such as database servers or separate networked storage devices. In addition, although application backend service <NUM> is only shown having a connection <NUM> to registry service <NUM>, it may also have a separate direct or indirect connection to client device <NUM>.

As discussed above, client device <NUM> may be any type of computing device including a personal computer, mobile phone, netbook, tablet PC, PDA, or wearable device. Likewise, registry service <NUM> and application backend service <NUM> may be processes resident on one or more computing devices. In all cases, these computing devices may include one or more processors, memory and other components typically present in general purpose computing devices. The memory may store information accessible by the one or more processors, including instructions and data that may be executed or otherwise used by the processor(s). The memory may be of any type capable of storing information accessible by the processor(s), including a computing device-readable medium. The memory may include a non-transitory medium such as a hard-drive, memory card, optical disk, solid-state, tape memory, or the like. Computing devices suitable for the roles described herein may include different combinations of the foregoing, whereby different portions of the instructions and data are stored on different types of media.

The computing devices described herein may further include any other components normally used in connection with a computing device such as a user interface subsystem. The user interface subsystem may include one or more user inputs (e.g., a mouse, keyboard, touch screen and/or microphone) and one or more electronic displays (e.g., a monitor having a screen or any other electrical device that is operable to display information). Output devices besides an electronic display, such as speakers, lights, and vibrating, pulsing, or haptic elements, may also be included in the computing devices described herein.

The one or more processors included in each computing device may be any conventional processors, such as commercially available CPUs. Alternatively, the one or more processors may be a dedicated device such as an ASIC or other hardware-based processor. Each processor may further have multiple cores that are able to operate in parallel. The processor(s), memory, and other elements of a single computing device may be stored within a single physical housing, or may be distributed between two or more housings. Similarly, the memory of a computing device may include a hard drive or other storage media located in a housing different from that of the processor(s), such as in an external database or networked storage device. Accordingly, references to a processor or computing device will be understood to include references to a collection of processors or computing devices or memories that may or may not operate in parallel. Further, as noted above, the computing devices on which registry service <NUM> and application backend service <NUM> are resident may comprise one or more servers. In that regard, those servers may be part of a load-balanced server farm or cloud-based system.

The computing devices described herein may store instructions capable of being executed directly (such as machine code) or indirectly (such as scripts) by the processor(s). The computing devices may also store data (e.g., log-in data <NUM> and application data <NUM>), which may be retrieved, stored, or modified by one or more processors in accordance with the instructions. Instructions may be stored as computing device code on a computing device-readable medium. Instructions may also be stored in object code format for direct processing by the processor(s), or in any other computing device language including scripts or collections of independent source code modules that are interpreted on demand or compiled in advance. By way of example, the programming language may be C#, C++, JAVA or another computer programming language. Similarly, any components of the instructions or programs may be implemented in a computer scripting language, such as JavaScript, PHP, ASP, or any other computer scripting language. Furthermore, any one of these components may be implemented using a combination of computer programming languages and computer scripting languages.

In addition to the systems described above and illustrated in the figures, various operations will now be described. In that regard, there are multiple ways that application <NUM> could be configured to request application data for accounts 112a, 112b, and 112c. For example, application <NUM> could be configured to make separate remote procedure calls directly to application backend service <NUM> for each account. However, this has the drawback of increasing latency, which may become unacceptably long over slower or intermittent data connections and/or where applications require authentication steps for each transmission. Latency concerns such as these can be particularly unacceptable for applications where users typically spend only a matter of seconds or factions of a second checking for updates, as is common with email and social media services.

Alternatively, application <NUM> could be configured to make a single remote procedure call directly to application backend service <NUM> in which application data for all logged-in accounts is requested together. However, this has the drawback of sending calls that could, if intercepted, expose the associations between multiple account IDs, which can present security concerns. For example, some users may use separate accounts that are otherwise unlikely to be correlated (e.g., a personal email account and a different account for the user to send emails under the name of the user's business or trade name). If a third party could discover that the user's personal email account was associated with the same device ID or application installation ID as other the user's other email account(s), the user's security measures would be thwarted. Likewise, in certain circumstances, the associations between multiple accounts could also reveal associations between friends or family members who have used that application or device, and thus pose security risks to other users. There may be numerous other ways in which the associations between multiple account IDs may be used maliciously.

In view of these drawbacks, the present technology provides an approach in which application <NUM> is configured to make a single remote procedure call to registry service <NUM>, rather than making a remote procedure call directly to application backend service <NUM>. Examples of this proposed method are described below and illustrated in the flow diagrams of <FIG>. While various operations will now be described, it should be understood that the following operations do not have to be performed in the precise order described below. Rather, various steps can be handled in a different order or simultaneously, and steps may also be added or omitted, unless expressly stated otherwise.

As shown in step <NUM> of example <NUM> of <FIG>, client device <NUM> and/or application <NUM> makes a remote procedure call to registry service <NUM> requesting application data for application <NUM>. Step <NUM> may be performed by application <NUM>, or by one or more other processes running on client device <NUM>. The remote procedure call includes at least an identifier associated with client device <NUM> (hereinafter a "device ID") or the installed instance of application <NUM> on client device <NUM> (hereinafter an "application installation ID"). A device ID may be sufficient if registry service <NUM> is specific to application <NUM>, or if registry service <NUM> can otherwise determine that an instance of application <NUM> made the remote procedure call. Client device <NUM> and/or application <NUM> may be further configured to provide registry service <NUM> with credentials for at least one of accounts 112a, 112b, or 112c, e.g., one or more usernames and passwords, authentication tokens, or any other data sufficient to authenticate the request as to at least one of the accounts. In some contexts, however, it may not be necessary to authenticate the request, in which case credentials need not be sent to registry service <NUM>. In addition, though not required, application <NUM> may further be configured to identify to registry service <NUM> a callback function to be invoked by registry service <NUM> when it requests the application data from application backend service <NUM>.

In the examples set forth herein, the application installation ID of application <NUM> may be any text, number, string, image, or other data that identifies the installed instance of application <NUM> on device <NUM> which initiates the remote procedure call. Each installation of application <NUM> on device <NUM> will generate a new application installation ID. Likewise, a device ID associated with device <NUM> may be any text, number, string, image, or other data that identifies device <NUM>. For example, the device ID may be a hardware identifier such as a MAC address of device <NUM>. It also may be sufficient in certain contexts for the device ID to be something less permanent, such as the assigned IP address of device <NUM>.

Continuing with the example of <FIG>, following receipt of the remote procedure call (and, where applicable, one or more authentication steps if one or more credentials are provided to registry service <NUM>), registry service <NUM> acts as a "delegate" for client device <NUM> and handles all further communications with application backend service <NUM>. In that regard, at step <NUM>, registry service <NUM> uses the application installation ID or device ID to identify the account IDs for all accounts that are known to be logged-in and associated with the application installation ID or device ID. For example, in the system of <FIG>, if application <NUM> sends a remote procedure call to registry service <NUM>, then registry service <NUM> would use the application installation ID of application <NUM> or a device ID associated with client device <NUM> to find the account IDs associated with accounts 112a, 112b, and 112c. In all examples set forth herein, the account IDs associated with accounts 112a, 112b, and 112c may be any text, number, string, image, or other data that identifies accounts 112a, 112b, and 112c. For example, if accounts 112a, 112b, and 112c are email accounts, the account ID for each account may be their associated email address, user name, account number, etc..

Next, at step <NUM>, registry service <NUM> makes separate remote procedure calls to application backend service <NUM> using each of the account IDs identified in step <NUM> in order to obtain the requested application data associated with those account IDs. In response, at step <NUM>, application backend service <NUM> separately responds to each remote procedure call by transmitting to registry service <NUM> the application data associated with each identified account ID. For example, in the system of <FIG>, application backend service <NUM> would receive a separate remote procedure call and would transmit a separate response for each of accounts 112a, 112b, and 112c that includes the requested application data associated with each respective account. In all examples set forth herein, application data associated with accounts 112a, 112b, and 112c may be any data specific to accounts 112a, 112b, and 112c. For example, if accounts 112a, 112b, and 112c are email accounts, the application data may be one or more emails the accounts, the number of new messages, unread messages, or total messages associated with each account, etc..

After registry service <NUM> receives the application data for accounts 112a, 112b, and 112c at step <NUM>, the exemplary method may proceed as shown in either <FIG>, <FIG>, or <FIG>.

In the example <NUM> of <FIG>, at step <NUM>, registry service <NUM> performs one or more hash functions on the identified account IDs. For example, in the system of <FIG>, registry service <NUM> would perform a hash function on the account IDs for accounts 112a, 112b, and 112c. In all examples discussed herein, the hash function may be any type of hash function, such as SHA-<NUM>, MD5, etc..

Next, at step <NUM>, registry service <NUM> truncates each hashed account ID to a predefined length, resulting in a truncated hash value for each account. For example, the hashed account IDs may be truncated to <NUM> bits, which would allow for <NUM> unique <NUM>-bit values. In other examples, the truncation may be to fewer than <NUM> bits (e.g., <NUM>-<NUM> bits) or more than <NUM> bits (e.g., <NUM>-<NUM> bits).

Although steps <NUM> and <NUM> are described in this example as taking place after application backend service <NUM> transmits the application data associated with each identified account ID in accordance with step <NUM> of <FIG>, one or both of the actions described in steps <NUM> and <NUM> may alternatively take place prior to the actions described in step <NUM> of <FIG>.

At step <NUM>, registry service <NUM> creates a data structure that associates, for each account, the application data received from application backend service <NUM> (i.e., the data received in step <NUM> of <FIG>, above) with the truncated hash value for that account.

Then, at step <NUM>, registry service <NUM> transmits the data structure to client device <NUM>. By way of example, the data structure can be a table or any other type and format of data structure that is capable of associating each account's application data with its corresponding truncated hash value.

At step <NUM>, client device <NUM> and/or application <NUM> determines from its own data which accounts are currently logged into application <NUM>, and then hashes each of the account IDs associated with those logged-in accounts and truncates the resulting hash values using the same hash function(s) and truncation procedure as was used by registry service <NUM> in steps <NUM> and <NUM>. The output of step <NUM> is thus a set of truncated hash values corresponding to the accounts that are currently logged into application <NUM>. Finally, in step <NUM>, client device <NUM> and/or application <NUM> uses the set of truncated hash values generated in the step <NUM> as a key to determine, within the data structure received in step <NUM> from registry service <NUM>, what application data corresponds to each of the accounts logged into application <NUM>. Both of steps <NUM> and <NUM> may be performed by application <NUM>, or by one or more other processes running on client device <NUM>.

One benefit of truncating the hashed account IDs as set forth above with respect to <FIG> (and below with respect to steps <NUM> and <NUM> of <FIG> and <FIG>) is that, for a service with a very large number of accounts (e.g., a service with <NUM> billion accounts or more) and a low average number of accounts per application installation or device (e.g., <NUM>-<NUM> accounts per application installation or device), there can be a very low probability (e.g., less than <NUM>% chance) that two or more of the account IDs associated with a single application installation ID or device ID will end up producing the same truncated hash values (i.e., producing "collisions"), while those truncated hash values will necessarily match those of a very large number of other users' accounts. For example, if a service has <NUM> billion accounts, and <NUM>-bit truncated hash values are being used, then roughly <NUM> million accounts will generate each of the <NUM> possible truncated hash values, while there is a less than <NUM>% chance that a set of three accounts associated with the same application installation ID or device ID will end up causing a collision.

As a result, in these examples, even if a third party were to intercept the transmission from registry service <NUM> back to client device <NUM>, the truncated hash values would be of very little, if any, use to the third party in creating a reverse lookup table or otherwise identifying the actual account IDs associated with the installation ID or device ID. This is because a large number of unrelated account IDs will also generate those same truncated hash values. On the other hand, because client device <NUM> already knows the account IDs for accounts 112a, 112b, and 112c, it can use them to generate its own list of truncated hash values. This list of truncated hash values then can be used as a key to decipher the data structure received from registry service <NUM> and thus determine what application data corresponds to each of accounts 112a, 112b, and 112c. Thus, rather than using values that uniquely identify each account, the examples set forth herein operate counter to conventional thinking by utilizing truncated hash values that will necessarily cause collisions and thus provide users with anonymity.

The length of the truncated hash values may be shortened or lengthened based on one or more factors, such as the type of application, total number of accounts, average number of accounts per application installation ID or device ID, etc. In this way, the length of the truncated hash value can be "tuned" for a given set of factors so as to provide a suitably small likelihood of collisions for the accounts associated with a single application installation ID or device ID, while providing a suitably high likelihood of collisions between the accounts of all users. What constitutes "suitably small" and "suitably high" likelihoods will vary based on implementation, and will ultimately depend on what the implementer deems suitable under their particular circumstances. For example, in some implementations, a <NUM>% chance of collisions between accounts associated with a single application installation ID may be deemed "suitably small. " The likelihood of such collisions is analogous to the "birthday problem" or "birthday paradox" (which pertains to the likelihood that at least two people in a group will share the same birthday), and can be calculated according to well-known statistical formulas. Thus, for truncated hash values that are b bits in length, the likelihood P of at least one "collision" occurring in a set of n truncated hash values can be approximated as follows: <MAT>.

Nevertheless, even with optimal tuning, there may be instances in which two or more account IDs associated with the same application installation ID or device ID will generate the same truncated hash values. This may be deemed acceptable in certain applications. However, there are also ways to limit the negative impact of such collisions. Two such examples are set forth in <FIG> and <FIG>.

In the example <NUM> of <FIG>, at step <NUM>, registry service <NUM> sorts the account IDs that were identified at step <NUM> of <FIG>. The registry service <NUM> may perform this sorting procedure according to the account IDs themselves (e.g., by placing the account IDs in alphabetical or numerical order), or according to some other data associated with each associated account (e.g., by ordering the account IDs according to the profile name, email address, or bank account number associated with each respective account).

After sorting, at steps <NUM> and <NUM>, registry service <NUM> hashes each of the identified account IDs and creates truncated hash values for each account in the same manner as described above with respect to steps <NUM> and <NUM> of <FIG>. Although steps <NUM>, <NUM>, and <NUM> are described in this example as taking place after application backend service <NUM> transmits the application data associated with each identified account ID in accordance with step <NUM> of <FIG>, one or more of the actions described in steps <NUM>, <NUM>, and <NUM> may alternatively take place prior to the actions described in step <NUM> of <FIG>.

At step <NUM>, registry service <NUM> creates a data structure in the same manner as described above with respect to step <NUM> of <FIG>, except that, in the method of <FIG>, registry service <NUM> orders the data structure according to how the account IDs were sorted in step <NUM>. Ordering the data structure may encompass listing each entry of the data structure in the order set in step <NUM>, or simply including a number or other indication for each entry of the data structure regarding how its account ID was ranked in step <NUM>. Next, at step <NUM>, registry service <NUM> transmits the data structure to client device <NUM>.

At step <NUM>, client device <NUM> and/or application <NUM> determines from its own data which accounts are currently logged into application <NUM>, and then performs the same sorting function(s), hashing function, and truncation method as was used by registry service <NUM> in steps <NUM>, <NUM>, and <NUM>. Step <NUM> thus results in an ordered set of truncated hash values corresponding to the accounts that are logged into application <NUM>.

Finally, in step <NUM>, client device <NUM> and/or application <NUM> uses the ordered set of truncated hash values generated in the step <NUM> as a key to determine, within the data structure received in step <NUM> from registry service <NUM>, what application data corresponds to each of the accounts logged into application <NUM>. In that regard, if none of the truncated hash values generated in step <NUM> end up causing a collision, then client device <NUM> and/or application <NUM> need not consider the ordering of the data structure in order to determine what application data corresponds to each of the accounts logged into application <NUM>. However, if two or more of the truncated hash values generated in step <NUM> do end up causing a collision, then client device <NUM> and/or application <NUM> can use the ordering of the data structure in order to determine which application data corresponds to each of those accounts. Both of steps <NUM> and <NUM> may be performed by application <NUM>, or by one or more other processes running on client device <NUM>.

In the example <NUM> of <FIG>, at step <NUM>, registry service <NUM> begins by hashing the account IDs that were identified at step <NUM> of <FIG>. This hashing step may be performed in the same manner as described above with respect to step <NUM> of <FIG>. Then, at step <NUM>, registry service <NUM> sorts two or more of the hashed account IDs that were generated in step <NUM> according to the hashed account IDs (e.g., by placing two or more of the hashed account IDs in alphabetical or numerical order). In that regard, registry service <NUM> may be configured to sort all of the hashed account IDs, or only those that generate the same truncated hash values. If registry service <NUM> is configured to sort only those hashed account IDs that generate the same truncated hash values, steps <NUM> and <NUM> may be performed in reverse order, or an additional truncation step may be performed prior to step <NUM>. At step <NUM>, registry service <NUM> truncates each hashed account ID in the same manner as described above with respect to step <NUM> of <FIG>. Although steps <NUM>, <NUM>, and <NUM> are described in this example as taking place after application backend service <NUM> transmits the application data associated with each identified account ID in accordance with step <NUM> of <FIG>, one or more of the actions described in steps <NUM>, <NUM>, and <NUM> may alternatively take place prior to the actions described in step <NUM> of <FIG>. At step <NUM>, registry service <NUM> creates a data structure in the same manner as described above with respect to step <NUM>, except that, in the method of <FIG>, registry service <NUM> orders two or more of the entries of the data structure according to how the hashed account IDs were sorted in step <NUM>. In this example, ordering the data structure may encompass listing the two or more entries of the data structure in the order set in step <NUM>, or simply including a number or other indication for the two or more entries regarding how their hashed account IDs were ranked in step <NUM>. Finally, steps <NUM>, <NUM>, and <NUM> of <FIG> proceed in the same manner as described above with respect to steps <NUM>, <NUM>, and <NUM> of <FIG>, respectively.

In addition to the examples described above with respect to <FIG> and <FIG>, it will be appreciated that there are other ways of avoiding the negative impact of collisions between two or more account IDs associated with the same application installation ID or device ID. For example, in response to two or more account IDs generating the same truncated hash value, registry service <NUM> may be configured to use one or more additional hash functions on those account IDs until they generate truncated hash values that are distinct. Client device <NUM> and/or application <NUM> would then be configured to follow the same process flow as registry service <NUM>, thus allowing them to arrive at the same set of truncated hash values used in the data structure received from registry service <NUM>.

As another example, registry service <NUM> and client device <NUM> (or application <NUM>) could be configured to respond to a collision by sending a truncated version of the unhashed account ID for one or more of the matching account IDs rather than the truncated hash values for those account IDs. Thus, in the exemplary system of <FIG>, if the account IDs associated with accounts 112a and 112b end up generating the same truncated hash value, registry service <NUM> and client device <NUM> (or application <NUM>) could be configured to instead truncate one or both of the matching account IDs.

As another example, registry service <NUM> and client device <NUM> (or application <NUM>) could be configured to respond to a collision by sending one or more additional digits for each hash value.

In a further example, registry service <NUM> and client device <NUM> (or application <NUM>) may be configured to respond to a collision by sending the first n bits, letters, digits, etc. of the hashed account IDs as opposed to the last n bits, digits, letters, etc. of the hashed account IDs. Likewise, registry service <NUM> and client device <NUM> (or application <NUM>) could be configured to respond to a collision by sending some other contiguous or noncontiguous subset of n bits, letters, digits, etc. from the hashed account IDs. This could be done for all accounts, or only those whose account IDs end up generating a collision.

Finally, for applications where an account ID need not be constant, registry service <NUM>, client device <NUM>, or application <NUM> could simply be configured to respond to a collision by requesting that application backend service <NUM> assign a new account ID for one of the accounts so that it will no longer produce collisions with the other account IDs associated with that application installation ID or device ID.

While the alternatives mentioned above are all possible, the choice of whether to use sorting or any of the alternatives just mentioned may depend on a variety of situation-specific factors such as the total number of accounts, the average number of accounts per application installation ID or device ID, the length of the account IDs, the length of the truncated hash values, the sensitivity of the account IDs and their association with the application installation ID or device ID, processing speeds of the registry service <NUM> and/or client device <NUM>, transmission speeds between the registry service <NUM> and client device <NUM>, etc..

In addition to the advantages already mentioned, another benefit of the methods and systems described above is that they will provide protection even in the potential failure modes where the registry service's data has become outdated for some reason. For example, in the exemplary system of <FIG>, even if registry service <NUM>'s log-in data <NUM> incorrectly indicates that account 112d is also currently logged-in to application <NUM>, that will simply result in registry service <NUM> returning a data structure to client device <NUM> and/or application <NUM> that includes additional unneeded application data. Client device <NUM> and/or application <NUM> will thus still be able to determine what data corresponds to the accounts that really are logged-in (i.e., accounts 112a, 112b, and 112c) and can simply ignore the extra application data corresponding to account 112d. Critically, because that extra application data for account 112d was associated with the truncated hash value, this additional information does not risk identifying that account 112d is also associated with client device <NUM>, application <NUM>, or accounts 112a, 112b, and 112c.

On the other hand, if registry service <NUM>'s log-in data <NUM> incorrectly indicates that only accounts 112a and 112b are currently logged-in to application <NUM> (i.e., it does not reflect that account 112c is also logged-in), client device <NUM> and/or application <NUM> will still receive a data structure that includes data for accounts 112a and 112b, and client device <NUM> and/or application <NUM> can then make follow-up requests until the registry service <NUM>'s log-in data <NUM> has been refreshed. Here again, because client device <NUM> can make each request using its application installation ID or device ID, and registry service <NUM> returns a data structure identified by truncated hash values, the associations between client device <NUM>, application <NUM>, and accounts 112a, 112b, 112c, and 112d continue to be protected.

Claim 1:
A method (<NUM>), comprising:
identifying (<NUM>), by one or more processors of a registry service (<NUM>), from data maintained by the registry service (<NUM>), a plurality of second identifiers corresponding to a plurality of accounts (112a, 112b, 112c, 112d) of a user that are logged into an application (<NUM>) at a client computing device (<NUM>) and that are associated with a first identifier of the client computing device (<NUM>) or an instance of the application (<NUM>) installed on the client computing device (<NUM>);
performing (<NUM>), by the one or more processors of the registry service (<NUM>), one or more hash functions on each of the plurality of second identifiers to obtain a hash value for a set of accounts (112a, 112b, 112c);
reducing (<NUM>), by the one or more processors of the registry service (<NUM>), each of the hash values to a predefined length to obtain a truncated hash value for each account of the set (112a, 112b, 112c), wherein the predefined length is selected so as to provide a suitably small likelihood of collisions for the truncated hash values for the set of accounts (112a, 112b, 112c), while providing a suitably high likelihood of collisions for truncated hash values for accounts of all users of the application (<NUM>); and
generating (<NUM>), by the one or more processors of the registry service (<NUM>), a data structure comprising an entry for each account that associates the truncated hash value for that account with application data associated with the account, and which does not include any of the plurality of second identifiers.