Methods and systems for verifying users across multiple domains
By employing location-dependent hashIDs and timestamps, the method addresses the challenge of inconsistent cross-domain identity mapping, ensuring efficient and privacy-focused user verification across multiple domains.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- KK TOSHIBA
- Filing Date
- 2025-08-27
- Publication Date
- 2026-06-10
AI Technical Summary
Existing cross-domain identity verification systems lack a common criterion for attribute selection and verification, leading to inconsistent and incomplete user identity mapping across domains, especially when personal information cannot be shared due to privacy concerns, resulting in failed logins and inefficient access control.
Utilizing location-dependent parameters and hashIDs to map user identities across domains, where a hashID is calculated based on device location and timestamp, enabling anonymized and unique user verification without revealing personal identification attributes, and updating these hashIDs periodically to ensure accurate mapping.
Enables efficient and privacy-preserving cross-domain user identity mapping and verification, allowing access to multiple domains without sharing personal information, even when attributes are inconsistent or missing, by using location-based hashIDs and timestamps.
Smart Images
Figure 2026095311000001_ABST
Abstract
Description
Technical Field
[0001] The embodiments described in this specification relate to a method and system for verifying a user across multiple domains.
Background Art
[0002] Personalized cross-domain services need to access multiple user attributes stored in different data sources within different domains. They typically use a federated identity server configuration in which identities in one domain are mapped to another domain by exchanging multiple identity tokens (ID tokens) between servers. The multiple ID tokens include multiple attributes - such as an email address - that can be used to map multiple identities and share related information. However, currently there is no common criterion as to which attributes should be used or how they are verified. Further, if the multiple attributes include specific personal information that can be used to identify a user, this typically cannot be done without anonymization using hashing or similar techniques, thereby making the mapping more difficult without universally consistent data.
[0003] Since multiple attributes and their validation are not specified, there may be no common attributes available across domains, or if they are not unique, multiple matches may exist. For example, referring to Figure 1, a user may be identified by an email address (or passport number, etc.) and associated with a browser-derived UUID (a browser or otherwise derived UUID) in a first domain, i.e., domain A. However, domains A and B may not have the same attribute data associated with each user for mapping across multiple domains. If domain B does not have an email attribute, an email address used to obtain access to multiple resources in domain A will not allow that user to access multiple resources in domain B. Modern browsers also do not allow personally identifiable information or multiple third-party cookies to be passed between domains (or even used at all), making it difficult for multiple cross-domain web applications to share a common universal identity about a user.
[0004] Open ID Connect (OIDC) is a protocol that facilitates the exchange of multiple ID tokens between domains, but it does not specify or require the use of multiple common or unique attributes. Figure 2A shows an example of an OIDC browser user provisioning / login sequence using the federated identity provider (IdP) "Keycloak". In this case, the user attempts to log in to an application (domain A) using a browser (step S201). Upon receiving the login request, the application generates an authentication request and redirects the user to the Keycloak IdP (steps S203-S207). The user enters their credentials into the Keycloak IdP (step S209), and following authentication of the credentials by the Keycloak IdP (step S211), the IdP generates an authentication code to send to the user (step S213). The user communicates the authentication code to the local (domain A) authenticator (step S215). The Domain A authenticator uses this code to obtain a unique ID token from the Keycloak IdP (steps S217, S219). In steps S221 and S223, the Domain A authenticator authenticates the user by looking up several relevant attributes in the Domain A attribute database (DB); that is, the Domain A authenticator uses several attributes from the ID token to look up and match them with several attributes in the attribute database. If the user is successfully identified and matches the local user ID, the authenticator then provides the user with an access token (step S225) and allows the user to access client Domain A (steps S227, S229).
[0005] Referring to Figure 2B, this shows a continuation of the process shown in Figure 2A, where the user is attempting to log in to a second client domain, namely Domain B. As before, the user sends a login request to Domain B, and in response, the domain redirects the user to the Keycloak IdP (steps S231, S233). The user provides their credentials to the Keycloak IdP (step S235). The IdP does not need to repeat authentication here, as it has already authenticated the credentials in step S211. Instead, the IdP proceeds directly to generate an authentication code to send to the user (step S237). The user communicates the authentication code to the local (Domain B) authenticator (step S239). The Domain B authenticator uses this code to obtain an ID token from the Keycloak IdP (steps S241, S243), the contents of which are the same as those in steps S217, S219 of Figure 2A when accessing Domain A. In steps S245 and S247, the Domain B authenticator authenticates the user by searching for multiple relevant attributes in the Domain B attribute database (DB); that is, the Domain B authenticator uses the attributes from the ID token to search and match them with the attributes in the attribute database. If the user is successfully identified and matches the local user ID, the authenticator then provides the user with an access token (step S249) and allows the user to access client Domain B (steps S251, S253).
[0006] Figure 3 shows an example of an ID token exchanged between IdP Keycloak and multiple domain authenticators using the conventional method shown in Figure 2. As can be seen, in this example, the ID token includes several user personal identification attributes, such as the username (James Smith) and email address (JamesS@university.com). These attributes allow multiple domain authenticators to perform searches in their respective attribute databases.
[0007] The methods shown in Figures 2A, 2B, and 3 require that a user has at least one attribute that is common to both domains and unique to that user. However, multiple attributes may be missing or recorded inconsistently due to errors or omissions, as well as variations in formatting, such as capitalization and spacing or ordering. A user may also have multiple email addresses / addresses or passport and ID numbers, different domains may have different subsets of these, and privacy rules and user choices may prevent the sharing of even multiple anonymized hashes. If the attribute information contained in the ID token is not locally available to the authenticator, a new identity provision must be provided to replicate the user in the local domain. Alternatively, if there are multiple matches for the name contained in the ID token, it becomes impossible to uniquely map the user identity, and the login will likely fail.
[0008] Next, embodiments of the present invention will be described as examples with reference to the accompanying drawings. [Brief explanation of the drawing]
[0009] [Figure 1] Figure 1 illustrates an example of how a user verified in the first domain might fail verification in the second domain in a conventional system. [Figure 2A] Figure 2A shows an example of an OIDC browser user provisioning / login sequence using a federated identity provider (IdP) in a conventional system. [Figure 2B] Figure 2B shows a continuation of the process shown in Figure 2A. [Figure 3] Figure 3 shows an example of ID tokens exchanged between the IdP and multiple domain authenticators in Figures 2A and 2B. [Figure 4A]Figure 4A shows several steps taken when verifying a user in a method according to one embodiment. [Figure 4B] Figure 4B shows the continuation of the steps performed in the method of Figure 4A. [Figure 5] Figure 5 shows an example of an access token used in the embodiments of Figures 4A and 4B. [Figure 6] Figure 6 shows an example of a code sequence for updating location data in an unspecified manner according to one embodiment of the method. [Figure 7] Figure 7 shows how the performance of multiple queries in an embodiment using a distributed database proxy compares to the performance without such a proxy. [Modes for carrying out the invention]
[0010] According to one embodiment, a computer implementation method is provided, and this method is The first domain attribute database receives the first data from the user device, Based on the first data, determine the values of location-dependent parameters for the user device, The first domain attribute database calculates a first hashID for the user of the user device based on the values of location-dependent parameters, The first domain attribute database maps the first hashID to one or more user attributes stored in the first domain attribute database, The first domain attribute database receives a search request from the authenticator for the first domain, which includes a second hashID. If the first domain attribute database determines that the second hashID matches the first hashID, it returns one or more stored user attributes using the mapping between the first hashID and one or more stored user attributes. It is equipped with.
[0011] This method may include an authenticator for the first domain transferring an access token to the user device that allows the user to access the first domain.
[0012] The first hashID can be calculated by the first domain attribute database using the value of a location-dependent parameter and a timestamp indicating the time of reception of the location-dependent parameter value by the first domain attribute database.
[0013] This method, The first domain attribute database receives updated values for location-dependent parameters about the user device at a later point in time, Recalculate the first hashID using the updated values of the position-dependent parameters, It can also be equipped with.
[0014] The recalculated first hashID can be calculated using the updated values of the location-dependent parameters and a timestamp indicating the time of receipt of the updated values of the location-dependent parameters by the first domain attribute database.
[0015] If the first domain attribute database cannot match the second hashID with the first hashID or any other previously received hashID, this method will The authenticator for the first domain issues a request for an ID token from a federated identity provider from which the user previously authenticated, The authenticator for the first domain receives an ID token, The federated identity provider performs a location update on the first domain attribute database using the first hashID, The first domain attribute database uses the hashID attribute from the ID token to search for one or more stored user attributes, and the first domain attribute database returns one or more stored user attributes to the authenticator for the first domain. It may include.
[0016] The method may further include the first domain attribute database receiving an updated value of a location-dependent parameter for the user device from an associated identity provider.
[0017] According to one embodiment, a computer-implemented method is provided, the method comprising: providing, by a user of a user device, a plurality of user authentication credentials and a value of a location-dependent parameter to an associated identity provider; receiving, by the user device, a first hashID from an associated identity provider and in response to being authenticated by the associated identity provider, the first hashID being calculated based on the value of the location-dependent parameter; transferring, by the user device, the first hashID to an authenticator for the first domain; receiving, from the authenticator for the first domain, an access token that permits the user to access the first domain; comprising.
[0018] The first hashID may be calculated based on location data and the time at which the value of the location-dependent parameter was transferred to the associated identity provider.
[0019] The method comprises: providing, by a user of the user device, an updated value of a location-dependent parameter to an associated identity provider at a subsequent point in time; The user device receives a second hashID from the federated identity provider, and the second hashID is calculated based on the updated value of a location-dependent parameter. The user device transfers the second hashID to the authenticator for the second domain, The user receives an access token from the authenticator for the second domain, which allows the user to access the second domain. It can also be equipped with.
[0020] The second hashID may be calculated based on the updated value of the location-dependent parameter and the time when the updated value of the location-dependent parameter was transmitted to the federated identification provider.
[0021] The values of location-dependent parameters can be propagated to the first domain attribute database via the network hosting the distributed ledger.
[0022] According to one embodiment, a computer system is provided comprising one or more computing devices configured to perform a method according to any one of the above embodiments.
[0023] According to one embodiment, a non-temporary computer-readable medium is provided which, when executed by one or more computing devices, causes one or more computing devices to perform the method according to any one of the embodiments described above.
[0024] The embodiments described herein utilize information about a user's location to verify that user's identity across different domains. This mapping of identities across domains can also enable the aggregation of user attributes to support promotions and other applications that need to consider aggregated user behavior.
[0025] The embodiment may enable cross-domain verification and mapping of user identities by integrating with multiple existing federated identity services, for example, using OpenID Connect, to retrieve and share location-dependent property values for one or more user devices. User devices may include, for example, one or more smartphones, laptops, tablets, or other computing devices.
[0026] Figures 4A and 4B illustrate several steps performed in a method according to one embodiment. In this embodiment, the IdP Keycloak is again used as a means for performing federated service login through a browser. However, in contrast to the conventional approach shown in Figures 2A and 2B, the login process in Figures 4A and 4B uses location information obtained within one domain to allow verification of the mapping of multiple user attributes across different domains via ID and access tokens, without revealing multiple true user identification attributes (such as name, email address, or passport number) to domain participants (e.g., third-party promotional applications and services).
[0027] The process shown in Figure 4A, as in Figure 2A, begins with the user logging into a first local domain (domain A) by providing login credentials (username, password) to the IdP Keycloak (steps S401-S411). At this time, the user agent also supplies first data to the IdP (step S409). The first data comprises data that can be used to determine the values of parameters that depend on the device location, which will change as the location changes. In some embodiments, the first data explicitly defines or refers to the user device location; for example, the first data may comprise multiple GPS coordinates for the user device. In other embodiments, the first data comprises measurements of one of the following phenomena, such as magnetic field strength, accelerometer readings, or radio signal strength, where these measurements are correlated with a specific geographic location.
[0028] The first data is transferred to the Domain A attribute database (DB) (step S413) and the Domain B attribute database (DB) (step S415). The first data may be obtained from a mobile or web application (such as a login page) that the user is currently interacting with through the geolocation interface. The first data may also be obtained via background JavaScript loaded in the page header of the login page. Upon receiving the first data, the Domain A attribute database and the Domain B attribute database update their stored user location attributes with location-dependent parameter values, such as those derived from the first data. Each attribute database also applies a timestamp to the received data indicating the time it was received. The time may be obtained from the clock of the computer system used to host the attribute database storage and may be measured using a suitable quantized resolution epoch, such as minutes or seconds, from a starting point, e.g., January 1, 1970.
[0029] The Domain A attribute database and the Domain B attribute database calculate a hashID for the user, using the latest values of the location-dependent parameters, respectively. The hashID can be calculated by passing the value (and optionally, the timestamp) through a one-way hash function. Once calculated, the hashID is mapped to multiple local user attribute tables within each domain attribute database using a usermap stored by the database. The usermap itself is a separate table in each non-virtualized domain attribute database, while the multiple user attribute tables are virtualized so that they appear as a single table of user attributes. In steps S413 and S415, the usermap for each domain attribute database is updated with the newly calculated hashID.
[0030] Following authentication of user credentials by the IdP, the user receives an authentication code from the IdP (step S417). The IdP also provides the user with a hashID along with the authentication code.
[0031] In step S419, the user incorporates the hashID and authentication code into an access token that is communicated to the local (domain A) authenticator. Figure 5 shows an example of an access token used in the embodiment of Figure 4. In contrast to the conventional federated ID token in Figure 3, which includes multiple user personal identification attributes (name, email address), the hashID in the access token in Figure 5 is completely despecific.
[0032] Continuing to refer to Figure 4A, in step S421, the authenticator reconstructs the hashID using the stored values and timestamps of the location-dependent parameters. If the reconstructed hashID matches the hashID received from the user, the authenticator can verify the user. The authenticator uses this hashID as a temporary identity reference for the user and performs join queries against the user map and multiple attribute data tables stored in the attribute database to resolve data related to the user.
[0033] Following this, the Domain A Authenticator provides the user with an additional access token (step S435), enabling the user to access client Domain A (see steps S437 and S439 in Figure 4B). Continuing with Figure 4B, the user can request and obtain access to a second domain (Domain B) using a sequence of steps similar to that in Figure 4A, except that the credentials have been previously authenticated in step S411 in Figure 4A, so the IdP does not need to authenticate the user's credentials again in step S445.
[0034] Returning to Figure 4A, if the verification in step S421 is unsuccessful (step S423), the method proceeds to step S425, where the Domain A Authenticator obtains an ID token from the Keycloak IdP using the authentication code received in step S419. The IdP updates the user map (location) in the Domain A attribute database (step S427) and provides the ID token to the Domain A Authenticator (step S429). The Domain A Authenticator performs a lookup using several attributes from the ID token to match several attributes in the attribute database (step S431). Subsequently, the Domain A Authenticator provides the user with an additional access token (step S435), enabling the user to access client Domain A (see steps S437 and S439 in Figure 4B).
[0035] The access token sent to the authenticator in step S419 already contains identity information, which is de-identified in the form of a hashID, enabling user authentication without the need to exchange ID tokens between the authenticator and the IdP Keycloak. Therefore, steps S423-S431 in Figure 4A only need to be performed if step S421 fails, and if the position has already been successfully propagated in step S421, obtaining a separate ID token from the IdP (step S425) becomes unnecessary.
[0036] Therefore, in the methods shown in Figures 4A and 4B, the user's location is provided to cross-domain services in an anonymized manner using a hashID and compared with data obtained through multiple client applications within those domains (such as location-based promotional apps) via a cross-domain login process, without the multiple applications themselves needing to reveal true user identification. Thus, multiple applications can provide multiple anonymized but personalized cross-domain services using a hashID that includes location along with a timestamp (or other attributes). In this case, the user can be associated with a unique location identifier (location fingerprint), even if multiple other attributes do not match or overlap across multiple domains. Given that it is highly unlikely that two users with the same last name would simultaneously share the exact same location, this approach is unique and does not rely solely on the absolute precision of the location.
[0037] It will be understood that if a user's hashID is not yet provisioned in a particular domain when a verification request is made, a new hashID needs to be provided before the verification process can proceed. Therefore, upon receiving a verification request (for example, step S421 in Figure 4A), a check may be performed for the existence of the previous hashID in the attribute database(s). If the previous hashID does not exist, the IdP will perform a bootstrap operation, where it creates a new entry for the hashID in multiple user maps for the local domain, such as those stored in multiple attribute databases. In this way, the new entry in each database can be mapped the next time the user uses an application from the associated domain. For example, the next time the user uses an application provided by domain A in the conventional way, it will update the user map mapping, allowing multiple login steps and enabling anonymous login.
[0038] The hashID needs to be recalculated when the user session expires at the IdP or when the user's location changes since the last login sequence. The values of location-dependent parameters and their corresponding hashIDs may be updated periodically while an active session is in progress, for example, every minute. When retrieving the first data from the user agent, it is common to specify how often and at what spatial resolution the updates should occur. For example, Javascript code may include instructions to update the first data—and thus the values of location-dependent parameters—every minute, at either a fine or coarse spatial resolution.
[0039] A user's location can be updated by a local domain authenticator each time a new cross-domain login is performed and verified by a hashID by calculating a hash of location-dependent parameters and timestamps obtained in that domain. The location update can then propagate to different data sources in multiple related domains, updating multiple hashIDs and requiring location information to validate mappings when multiple join queries are performed against multiple cross-domain attributes. Figure 6 shows an example sequence of code for despecifically updating location-dependent parameters held in multiple virtual tables in multiple attribute databases. In this example, multiple domain-specific user map tables are used to map hashIDs to multiple local domain IDs, which are then used to update a virtual table (called t_order). Thus, the application client knows only the hashID and location-dependent parameters, and not the actual IDs or other multiple personal attributes of the multiple entries in the multiple t_order virtual tables. The hashID is passed within client-embedded code called either in the login script or on the client application page. Next, the location update returns a report to the location handler in the login domain (i.e., proxy.domainA.com or proxy.domainB.com, etc.).
[0040] In some embodiments, a proxy broker can act as an intermediary between an application running on an end-user device(s), an identity provider (IdP), and multiple cross-domain services. Multiple interactions with multiple cross-domain attribute stores are handled by the proxy broker. The performance of multiple queries is illustrated in Figure 7 for two approaches: with a distributed database proxy (sharding sphere proxy) and without (pgspider). This illustrates the performance impact of using a database proxy when there are many concurrent transactions, but with the advantage that it does not require modifications to the database infrastructure that holds existing applications or user data.
[0041] In further embodiments, it is possible to propagate multiple updates to location-dependent parameter values across multiple domains using a distributed ledger, rather than conventional distributed databases such as sharding spheres or pgspider, or in addition to them. Furthermore, multiple hashIDs may be generated to correspond to the same user in order to control the scope of cross-domain data sharing. Thus, if a user consents only to the sharing of attribute data between domains A and B, a unique hashID may be generated for domains A and B without that hashID being used for multiple other domains.
[0042] In a further embodiment, multiple hashIDs may be embedded in multiple ad URIs across multiple smart (digital) receipts delivered to the end user to support multiple cross-domain ads without disclosing multiple personal identifiers or attributes. In this case, login requires only location / timestamp information and the last hashID calculated from previous updates, which is stored in the browser or application.
[0043] Therefore, the embodiment makes it possible to provide a universal method for performing and verifying user identification mappings across multiple domains based on user location. Combined with a timestamp attribute, this can uniquely identify a user through the location of the end device the user is using, and enable verification of the mapping to actual multiple user identities in the domain.
[0044] The embodiments described herein provide a low-complexity, high-performance method for cross-domain mapping and verification of user attribute data. The embodiments may also allow mapping even without unique cross-domain attributes, while protecting user privacy, by updating hashed location / timestamps.
[0045] The embodiments described herein do not require any additional mechanisms other than including a location derived from the user device where the application interaction resides. Therefore, any user with the same identity attributes or set of attributes at different locations will not be validated and mapped as the same user. On the other hand, a domain that does not have all the same attributes as another domain (such as email or passport number) can still be mapped to a user, even if multiple personal attributes themselves cannot be directly shared.
[0046] Implementations of the subject matter and operations described herein may be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in a combination of one or more thereof. Implementations of the subject matter described herein may be implemented using one or more modules of computer programs, i.e., computer program instructions encoded on a computer storage medium for execution by a data processing device or for controlling the operation of a data processing device. Alternatively or additionally, the program instructions may be encoded on artificially generated propagating signals, such as mechanically generated electrical, optical, or electromagnetic signals generated to encode information for transmission to a receiver device suitable for execution by a data processing device. The computer storage medium may be or include computer-readable storage devices, computer-readable storage boards, random or serial access memory arrays or devices, or a combination of one or more thereof. Furthermore, although the computer storage medium is not a propagating signal, the computer storage medium may be a source or destination for computer program instructions encoded on an artificially generated propagating signal. Computer storage media can also be, or be contained within, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).
[0047] While certain embodiments have been described, these embodiments are presented merely as examples and are not intended to limit the scope of the invention. In fact, the novel methods, devices, and systems described herein can be embodied in various forms, and furthermore, various omissions, substitutions, and modifications in the forms of the methods and systems described herein can be made without departing from the spirit of the invention. The appended claims and their equivalents are intended to cover such forms or modifications as being within the scope and spirit of the invention.
Claims
1. A computer implementation method, The first domain attribute database receives the first data from the user device. Based on the first data, the values of the position-dependent parameters for the user device are determined. Based on the values of the location-dependent parameters, the first domain attribute database calculates a first hashID for the user of the user device. The first domain attribute database maps the first hashID to one or more user attributes stored in the first domain attribute database. The first domain attribute database receives a search request from the authenticator for the first domain, which includes a second hashID. If the first domain attribute database determines that the second hashID matches the first hashID, it returns the one or more stored user attributes using the mapping between the first hashID and the one or more stored user attributes. Computer implementation method.
2. The computer implementation method according to claim 1, wherein the authenticator for the first domain transfers to the user device an access token that allows the user to access the first domain.
3. The computer implementation method according to claim 1, wherein the first hashID is calculated by the first domain attribute database using the value of the location-dependent parameter and a timestamp indicating the time of reception of the value of the location-dependent parameter by the first domain attribute database.
4. The first domain attribute database receives, at a later point in time, updated values for the location-dependent parameters for the user device. The first hashID is recalculated using the updated values of the position-dependent parameters. The computer implementation method according to claim 1.
5. The computer implementation method according to claim 4, wherein the recalculated first hashID is calculated using the updated value of the position-dependent parameter and a timestamp indicating the time of reception of the updated value of the position-dependent parameter by the first domain attribute database.
6. If the first domain attribute database cannot match the second hashID with the first hashID or any other previously received hashID, the method shall The authenticator for the first domain issues a request for an ID token from a federated identity provider from which the user previously authenticated itself. The authenticator for the first domain receives the ID token, The aforementioned federated identification provider performs a location update on the first domain attribute database using the first hashID. The first domain attribute database uses multiple hashID attributes from the ID token to search for one or more stored user attributes. The first domain attribute database returns the one or more stored user attributes to the authenticator for the first domain. The computer implementation method according to claim 5.
7. The computer implementation method according to claim 6, wherein the first domain attribute database receives updated values of the location-dependent parameters for the user device from the federated identification provider.
8. A computer implementation method, The user of the user device provides the federated identity provider with multiple user authentication credentials and location-dependent parameter values. The user device receives a first hashID from and in response to authentication by the federated identity provider, wherein the first hashID is calculated based on the value of the position-dependent parameter. The user device transfers the first hashID to the authenticator for the first domain. The user receives an access token from the authenticator for the first domain that allows the user to access the first domain. Computer implementation method.
9. The computer implementation method according to claim 8, wherein the first hashID is calculated based on location data and the time at which the value of the location-dependent parameter is transmitted to the federated identification provider.
10. The user of the user device provides the federated identification provider with updated values for the location-dependent parameters at a subsequent point in time. The user device receives a second hashID from the federated identification provider, where the second hashID is calculated based on the updated value of the position-dependent parameter. The user device transfers the second hashID to the authenticator for the second domain. The user receives an access token from the authenticator for the second domain that allows the user to access the second domain. The computer implementation method according to claim 8.
11. The computer implementation method according to claim 10, wherein the second hashID is calculated based on the updated value of the position-dependent parameter and the time at which the updated value of the position-dependent parameter was transmitted to the federated identification provider.
12. The computer implementation method according to claim 1, wherein the value of the position-dependent parameter is propagated to the first domain attribute database via a network hosting a distributed ledger.
13. A computer system comprising one or more computing devices configured to perform the method described in claim 1.
14. A non-temporary computer-readable medium comprising a plurality of computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform the method according to claim 1.