System and method for controlling data access to personal user data using short-range transceivers

Abstract

This invention provides a system and method for controlling data access through interaction between a short-range transceiver, such as a contactless card, and a client device. [Solution] The method includes establishing a database that stores user and service provider (SP) identifiers and keys, and receiving requests from a client device for SP tokens and data access keys. The requests are generated in response to a tap operation between a contactless card associated with the user and the client device. The method also includes verifying that the SP is authorized to receive encrypted personal user data stored on the contactless card, generating a data access key based on the user key, and sending the data access key to the client device so that the client device can decrypt the personal user data retrieved from the contactless card.

Description

Technical Field

[0004] , , ,

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Patent Application No. 16 / 863,750, filed on April 30, 2020, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Field of the Disclosure This disclosure generally relates to user data control, and more specifically, to exemplary systems and methods for actively controlling access to personal user data through the interaction between a short - range transceiver and a client device.

Background Art

[0003] A typical user has highly confidential or sensitive personal user information or data, including information such as personal health data, social security numbers, family contact information, etc. When a user creates an account, the user usually provides a certain amount of personal identification information about the user and information related to account access, such as a username and password. Entities other than the user can add to the personal user data. Different entities can have, for example, different user data retention policies, different usage policies, and different user data sharing policies. The policies regarding the use of user information can be further changed without notice to the user. Furthermore, the owner of the user information can often be changed without notice to the user, for example, by an entity being merged or acquired by another entity.

[0004] Access to an account often relies on login credentials (e.g., username and password) to verify the cardholder's identity. However, if login credentials are compromised, others may be able to access the user's account and, in some cases, access the user's highly confidential or sensitive information or data. Furthermore, the more entities or individuals a user shares personal information with, the higher the risk that the user's information will be stolen if any of those entities are compromised. Moreover, a user may only wish to share certain personal information with entities or individuals for limited purposes or for limited time.

[0005] Therefore, it may be beneficial to provide exemplary systems and methods that enable users to control the use of user information in order to overcome at least some of the defects described herein. [Overview of the project]

[0006] The disclosed aspects of the technology include systems and methods for controlling data access through interaction between a short-range transceiver, such as a contactless card, and a client device. The data access control may be provided in the context of personal user data and may include processing requests to obtain access to personal user data through interaction between a short-range transceiver, such as a contactless card, and a client device, such that the personal user data is provided only to service providers authorized to verify the data, and the disclosure of specific account identifier information or account login information is not disclosed to service providers requesting access to the personal user data.

[0007] Embodiments of this disclosure provide a data access control system. The system includes a database that stores information comprising a user identifier and user key associated with a user, and a service provider identifier and service provider key associated with a service provider; a server configured to communicate data with client devices associated with the service provider over a network; a contactless card associated with a user, the contactless card comprising a communication interface, a processor, and memory, the memory storing an applet, a user token, and personal user data associated with the user, the personal user data being encrypted using the user key; and a client application comprising instructions to be executed on the client device, the client application receiving a user token from the contactless card in response to a tap operation between the contactless card and the client device, and the service The data access control system includes a processor that communicates with the server and database, and the processor is configured to receive requests for a service provider token, a user token, and a data access key from the client device, identify the service provider based on the service provider token, identify the user based on the user token, verify that the service provider is authorized to receive access to the personal user data, and send the data access key to the client device.

[0008] Embodiments of the present disclosure provide a method for controlling data access. The method includes establishing a database that stores information comprising a user identifier and user key associated with a user, and a service provider identifier and a first service provider key associated with a service provider; receiving, via a network, a service provider token and a request for a data access key to access personal user data stored on a contactless card associated with a user from a first client device associated with a service provider, wherein the personal user data is encrypted using the user key, the request is generated in response to a tap operation between the contactless card and the first client device, and the request is accompanied by a user token stored on the contactless card; identifying the service provider based on the service provider token; identifying the user based on the user token; verifying that the service provider is authorized to receive access to personal user data stored on the contactless card; generating a data access key based on the user key; and transmitting the data access key to the first client device.

[0009] Embodiments of this disclosure provide a method for controlling data access. The method includes establishing a database that stores information comprising a user identifier and user key associated with a user, and a service provider identifier and service provider key associated with a service provider; providing a contactless card comprising a communication interface, a processor, and memory, wherein the memory stores applets and user tokens, the communication interface is configured to support at least one of Near Field Communication, Bluetooth®, or Wi-Fi, the contactless card is associated with a user; and providing a client application comprising instructions for execution on a client device associated with a service provider, wherein the client application receives a user token from the contactless card in response to a tap operation between the contactless card and the client device, and sends a request to a server for a service provider token, a user token, and a data access key, the service provider token is associated with the service provider. The method is configured to receive from a server a data access key and a link to a data repository that stores encrypted personal user data associated with the user, the data access key is generated based on the user key, and via the link, a request for encrypted personal user data is sent to the data repository, encrypted personal user data is received from the data repository, and the encrypted personal user data is decrypted using the data access key, the method is to receive from a client device via the network a request for a service provider token and a data access key for accessing personal user data associated with the user, the request is accompanied by a user token, the service provider is identified based on the service provider token, the user is identified based on the user token, the service provider is authorized to receive access to personal user data associated with the user, and a link to a data repository that stores encrypted personal user data is generated,This includes retrieving a user key from a database, generating a data access key based on the user key, and sending the data access key and a link to a data repository containing encrypted personal user data to the client device.

[0010] Further features of the disclosed design and the advantages provided thereby are described below and will be described in more detail below with reference to specific exemplary embodiments shown in the accompanying drawings. [Brief explanation of the drawing]

[0011] [Figure 1A] This is a diagram of a data access control system according to one or more exemplary embodiments. [Figure 1B] This figure shows a sequence for providing data access control according to one or more exemplary embodiments. [Figure 1C] This figure shows a sequence for providing data access control according to one or more exemplary embodiments. [Figure 2] This shows components of a client device used in a data access control system according to one or more exemplary embodiments. [Figure 3] This shows components of a short-range transceiver used in a data access control system according to one or more exemplary embodiments. [Figure 4] This figure shows the interaction between a client device and a short-range transceiver used in a data access control system according to one or more exemplary embodiments. [Figure 5] This figure shows the interaction between a client device and a short-range transceiver used in a data access control system according to one or more exemplary embodiments. [Figure 6A] A flowchart illustrating a data access control method according to one or more exemplary embodiments is provided. [Figure 6B]A flowchart illustrating a data access control method according to one or more exemplary embodiments is provided. [Figure 7A] A flowchart is provided illustrating one or more methods of data access control according to one or more exemplary embodiments. [Figure 7B] A flowchart is provided illustrating one or more methods of data access control according to one or more exemplary embodiments. [Figure 7C] A flowchart is provided illustrating one or more methods of data access control according to one or more exemplary embodiments. [Figure 8] This is a diagram of a data access control system according to one or more exemplary embodiments. [Modes for carrying out the invention]

[0012] The following description of embodiments provides non-limiting representative examples that refer to figures in particular to illustrate features and teachings of different aspects of the invention. It should be recognized that the described embodiments can be implemented separately or in combination with other embodiments from the description of embodiments. A person skilled in the art who is considering the description of embodiments should be able to learn and understand different described aspects of the invention. The description of embodiments should facilitate understanding of the invention so that other embodiments that are not specifically covered but are within the knowledge of a person skilled in the art who has read the description of embodiments are understood to be consistent with the application of the invention.

[0013] Exemplary embodiments of the disclosed systems and methods provide control over data access through interaction between a short-range transceiver, such as a contactless card, and a client device. Data access control may be provided in the context of controlling access to personal user data. Requests for access to personal user data are handled through interaction between a short-range transceiver, such as a contactless card, and a client device, so that the personal user data is provided only to service providers authorized to verify the data, and the disclosure of specific account identifier information or account login information does not need to be disclosed to service providers requesting access to personal user data. Benefits of the disclosed technology may include improved data security for personal user data, improved access to personal user data when access is required without user response or intervention (e.g., in emergencies), and improved user experience.

[0014] Figure 1A shows a diagram illustrating a data access control system 100 according to one or more exemplary embodiments. As will be further described below, the system 100 may include client devices 101 and 103, a short-range transceiver 105, a server 110, a processor 120, and a database 130. Client devices 101 and 103 may communicate with the server 110 via a network 115. While Figure 1 shows specific components connected in a particular way, the system 100 may include additional or multiple components connected in various ways.

[0015] System 100 may include one or more client devices, such as client device 101 and / or client device 103, each of which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to, computer devices, or communication devices, such as servers, network appliances, personal computers, workstations, telephones, handheld PCs, personal digital assistants, thin clients, fat clients, internet browsers, or other devices. Each of client devices 101 and 103 may also be a mobile device. For example, a mobile device may include Apple's iPhone®, iPod®, iPad®, or other mobile devices running Apple's iOS® operating system, devices running Microsoft's Windows® Mobile operating system, devices running Google's Android® operating system, and / or other smartphones, tablets, or similar wearable mobile devices. Additional features that may be included in client devices such as client device 101 and / or client device 103 are further described below with reference to Figure 2.

[0016] System 100 may include one or more short - range transceivers such as short - range transceiver 105. Short - range transceiver 105 can wirelessly communicate with client devices such as client device 101 and / or client device 103 within a short - range communication range, for example, short - range wireless communication (NFC). Short - range transceiver 105 can include, for example, contactless cards, smart cards, or devices having various form factors such as fobs, pendants, or other devices configured to communicate within a short - range communication range. In other embodiments, short - range transceiver 105 can be the same as or similar to client devices 101, 103. Additional functions that can be included in a short - range transceiver such as short - range transceiver 105 will be further described below with reference to FIG. 3.

[0017] System 100 may include one or more servers 110. In some exemplary embodiments, server 110 may include one or more processors (such as microprocessors, etc.) coupled to memory. Server 110 can be configured as a central system, server, or platform for controlling and invoking various data at different times to execute multiple workflow actions. Server 110 can be a dedicated server computer such as a blade server, or it can be a personal computer, laptop computer, notebook computer, palmtop computer, network computer, mobile device, or any processor - controlled device capable of supporting system 100.

[0018] Server 110 may be configured for data communication (e.g., via a connection) with one or more processors such as processor 120. In some exemplary embodiments, server 110 may incorporate processor 120. In some exemplary embodiments, server 110 may be physically separated and / or remote from processor 120. Processor 120 may be configured to function as a backend processor. Processor 120 may be configured for data communication (e.g., via a connection) with database 130 and / or server 110. Processor 120 may include one or more processing devices such as a microprocessor, a RISC processor, an ASIC, etc., together with associated processing circuitry. Processor 120 may include or be connected to a memory for storing executable instructions and / or data. Processor 120 may communicate, transmit, or receive messages, requests, notifications, data, etc. between other devices such as client devices 101 and / or 103 via server 110.

[0019] Server 110 may be configured for data communication (e.g., via a connection) with one or more databases such as database 130. Database 130 may be a relational database or a non-relational database, or a combination of multiple databases. In some exemplary embodiments, server 110 may incorporate database 130. In some exemplary embodiments, database 130 may be physically separated and / or remote from server 110 and be located on another server, a cloud-based platform, or any storage device that is in data communication with server 110.

[0020] The connection between the server 110, processor 120, and database 130 may be made via any wired and / or wireless communication line, link, or network, or a combination thereof, suitable for communication between these components. Such a network may include one or more networks of the same or similar type as those described herein with reference to network 115 and / or network 115. In some exemplary embodiments, the connection between the server 110, processor 120, and database 130 may include a corporate LAN.

[0021] Server 110 and / or database 130 may contain user login credentials used to control access to user accounts. Login credentials may include, but are not limited to, usernames, passwords, access codes, security questions, swipe patterns, image recognition, identification scans (e.g., driver license scans or passport scans), device registrations, phone numbers, email addresses, social media account access information, and biometric authentication (e.g., voice recognition, fingerprint scans, retinal scans, facial scans).

[0022] Database 130 may contain data relating to one or more users, one or more service providers, and one or more accounts. Data relating to users may include user identifiers and user keys and may be maintained or organized in one or more accounts. Data relating to service providers may include service provider identifiers and service provider keys and may be maintained or organized in one or more accounts. Accounts may be maintained and / or associated with (or instead of) one or more of various entities, such as banks, dealers, online retailers, service providers, merchandisers, manufacturers, social media providers, sports or entertainment event providers or promoters, or hotel chains. For example, database 130 may contain, but is not limited to, account identification information (e.g., account number, account owner identification number, account owner name and contact information—one or more of which may comprise an account identifier), account characteristics (e.g., account type, funding and transaction restrictions, access and other activity restrictions), financial information (balance information, payment history, transaction history, etc.), social information, personal information, and other information and data related to accounts. The data stored in database 130 may be stored in any appropriate format, and may be encrypted and stored in a secure format to prevent unauthorized access. Any appropriate algorithm / procedure may be used for data encryption and authorized decryption.

[0023] The server 110 may be configured to communicate with one or more client devices, such as client device 101 and / or client device 103, over one or more networks, such as network 115. Network 115 may include one or more wireless networks, wired networks, or any combination of wireless and wired networks, and may be configured to connect client devices 101 and / or 103 to the server 110. For example, network 115 may include fiber optic networks, passive optical networks, cable networks, Internet networks, satellite networks, wireless local area networks (LANs), global systems for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplex-based systems, code division multiple access-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth®, NFC, radio frequency identification (RFID), and Wi-Fi.

[0024] Furthermore, network 115 includes, but is not limited to, global networks such as telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or the Internet. Additionally, network 115 may support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 115 may further include one network or any number of the exemplary types described above, either as a standalone network or working in cooperation with one another. Network 115 may utilize one or more protocols of one or more network elements that are communicatively coupled. Network 115 may translate to one or more protocols of network devices between other protocols. Although network 115 is shown as a single network, it should be understood that according to one or more exemplary embodiments, network 115 may comprise multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, LANs, and / or home networks.

[0025] In some exemplary embodiments, the server 110 may access records containing records in the database 130 to determine one or more methods for communicating with client devices 101 and / or client device 103. The communication methods may include executable push notifications with applications stored on client devices 101 and / or client device 103. Other communication methods may include text messages, email, or other messaging technologies suitable for a network-based client / server configuration. Messages or requests from client devices 101 and / or 103 may be communicated to the server 110 via applications on the client devices, or sent by text messages, email, or other messaging technologies suitable for a network-based client / server configuration. Communications originating from client device 101 or client device 103 may be sent to the server 110 using the same communication methods as communications originating from the server 110, or via different communication methods.

[0026] Figure 1B shows a diagram illustrating a sequence for providing data access control according to one or more exemplary embodiments, which may include a request by a service provider for a data access key to access or decrypt personal user data stored in a short-range transceiver. Figure 1B refers to a similar component of the exemplary embodiment system 100, as shown in Figure 1A. A client device 101 may be associated with a service provider. The service provider may have an associated service provider token. The client device 101 may include an application 102 which may include instructions for execution by the client device 101. The client device 101 may include functions further described below with reference to Figure 2. The application 102 may be configured to provide a user interface to the service provider when using the client device 101. The application 102 may be configured to communicate with other client devices, a short-range transceiver 105, and a server 110 via the client device 101. The application 102 may be configured to receive requests and send messages, as described herein with reference to the client device 101. Service provider information and user information, including identifiers and / or keys, may be stored in a database 130.

[0027] The short-range transceiver 105 may be associated with a user. The short-range transceiver 105 may include, for example, a contactless card and may include features further described below with reference to Figure 3. The short-range transceiver 105 may have a memory that stores an applet 106 and / or a token 107 and stores personal user data. The token 107 and personal user data 108 may be associated with a user.

[0028] Tokens can be used to enhance security through token authentication. Server 110 may send a verification request to a client device, such as client device 101, receive response information from the client device, and, if verified, send a verification token back to the client device. Verification tokens may be based on predetermined tokens or on dynamic tokens based on a secret algorithm known only to Server 110 and the client device. The algorithm may include live parameters that participants can individually verify, such as temperature and time at a specific location. Tokens can be used to verify the identity of a first service provider or user. Verification requests and / or verification tokens may be based on tokens 107 stored in short-range transceiver 105.

[0029] Personal user data 108 may include personal user information or data that may be highly confidential or sensitive, such as personal health data, social security numbers, and family contact information (including the types of data identified herein with reference to Figure 3). Personal user data 108 may be encrypted and stored in a secure format to prevent unauthorized access.

[0030] In some exemplary embodiments, personal user data may include, for example, personal health data such as height, weight, blood type, prescription medications, allergies, emergency contacts, and treatment or DNR orders. Personal user data may also include personally identifying data such as name, gender, and date of birth. A service provider using client device 101 may be, for example, a first responder, an emergency team member, or an emergency medical provider or technician, and may be associated with a service entity such as a fire department or ambulance division, a police station, or a hospital.

[0031] In some exemplary embodiments, application 102 may display instructions on client device 101 prompting a service provider to initiate a tap operation between the short-range transceiver 105 and client device 101. As used herein, the tap operation may include tapping the short-range transceiver 105 against the client device 101 (or vice versa). For example, if the short-range transceiver 105 is a contactless card and the client device 101 is a mobile device, the tap operation may include tapping the contactless card on the screen or another part of the client device 101. However, the tap operation is not limited to a physical tap by the short-range transceiver 105 against the client device 101 and may include other gestures, such as a wave or other movement of the short-range transceiver 105 near the client device 101 (or vice versa).

[0032] Label 150 may involve a tap operation between the short-range transceiver 105 and the client device 101. The tap operation may be in response to a prompt displayed on the client device 101.

[0033] On label 152, application 102 may communicate with short-range transceiver 105 (via client device 101) (for example, after short-range transceiver 105 is brought close to client device 101). Communication between application 102 and short-range transceiver 105 may include short-range transceiver 105 (e.g., contactless card) being close enough to the card reader (not shown) of client device 101 to enable NFC data transfer between application 102 and short-range transceiver 105, and may occur in conjunction with (or in response to) a tap operation between short-range transceiver 105 and client device 101 (e.g., a tap operation on label 150). Communication may include the exchange of data or commands to establish a communication session between application 102 and short-range transceiver 105. The exchange of data may include the transfer or exchange of one or more keys, which may be existing keys or generated as session keys. In some exemplary embodiments, communication may occur when the short-range transceiver 105 enters the short-range communication range of the client device 101, prior to a tap operation between the short-range transceiver 105 and the client device 101.

[0034] On label 154, the short-range transceiver 105 may transmit a user token 107 associated with the user to the application 102. The token 107 may include a user identifier. In some exemplary embodiments, the user token 107 may include a key associated with the user. In some exemplary embodiments, the transmission of the token 107 to the application 102 may occur in conjunction with (or in response to) a tap operation between the short-range transceiver 105 and the client device 101 (e.g., a tap operation on label 150). In some exemplary embodiments, the transmission of the token 107 to the application 102 may occur when the short-range transceiver 105 enters the short-range communication range of the client device 101, prior to a tap operation between the short-range transceiver 105 and the client device 101.

[0035] At label 156, application 102 may send user token 107 to server 110 along with a request for a service provider token and data access key associated with the service provider. This may be done in response to a tap operation between short-range transceiver 105 and client device 101 (e.g., a tap operation at label 150). The data access key allows the service provider to decrypt encrypted personal user data 108.

[0036] At label 158, processor 120 may receive a user token, a service provider token, and a data access key request (for example, via server 110). Processor 120 may use the user token to identify a user. Processor 120 may use the service provider token to identify a service provider as the sender of a data access key request. In some exemplary embodiments, identifying a service provider may be done by using the service provider identifier in the token to retrieve information in database 130. In some exemplary embodiments, at label 159, if the service provider token contains a key associated with a service provider, processor 120 may use the service provider key to authenticate the service provider. Similarly, if the user token contains a key associated with a user, processor 120 may use the user key to authenticate the user. Based on the identity of the service provider (and since such an identity can be authenticated), processor 120 may determine whether the service provider is authorized to decrypt personal user data 108 and thereby receive a data access key to gain access. In an exemplary embodiment, a service provider key may be available to the service provider and may be valid for a limited period, such as daily, weekly, monthly, or based on other criteria. The client device 101 may send a request for a service provider key to the server 110 at intervals when a new key becomes available (e.g., daily, weekly, monthly, or based on other criteria). The reception of a service provider key by the client device 101 does not require the service provider to be near the short-range transceiver 105, and the service provider key can be requested or received by the client device 101 independently of any tapping operation on the short-range transceiver 105.

[0037] With label 160, processor 120 may send a data access key to client device 101. As described above, processor 120 may verify that the service provider is authorized to receive the data access key. The data access key may be stored in database 130 or generated based on a user key, a service provider key, or a combination of both user and service provider keys. The user key may be stored in database 130 or contained in user token 107. The service provider key may be stored in database 130 or contained in the service provider token received from client device 101.

[0038] In an exemplary embodiment, the processor 120 may instead send a denial notice (not shown) to the client device 101 indicating that the service provider is not authorized to receive the data access key.

[0039] Label 162 indicates that the short-range transceiver 105 may transmit encrypted personal user data 108 to the application 102 via the client device 101. Note that, in relation to other events described with respect to Figure 1B, the timing of the short-range transceiver 105's transmission of the encrypted personal user data 108 to the client device 101 is not critical. The encrypted personal user data 108 may be transmitted at the time of the first tap operation or at any point, including after the client device 101 receives the data access key.

[0040] Application 102 may be configured to receive, decrypt, and access encrypted personal user data 108 using a received data access key. In some embodiments, application 102 may cause personal user data to be displayed on the client device 101. In some embodiments, application 102 may be permitted to store personal user data on the client device 101 for retrieval based on time limits or limited usage counts.

[0041] In one or more exemplary embodiments, access by a service provider to personal user data may be restricted according to data control parameters. In exemplary embodiments, data control parameters may be stored in a database 130. In exemplary embodiments, data control parameters may be stored in the memory of a short-range transceiver 105. The data control parameters stored in the memory of the short-range transceiver 105 are transmitted to an application 102 and used by the application 102 to restrict access by a service provider to personal user data. Applet 106 may be configured to receive data control parameters and store them in the memory of the short-range transceiver 105.

[0042] In one or more exemplary embodiments, data control parameters may be used to restrict a service provider's access to personal user data in one or more ways. For example, a data control parameter may permit access only for a specific or limited period. As another example, a data control parameter may permit a service provider to access for a single use. As yet another example, a data control parameter may permit access only if the short-range transceiver 105 is detected within the short-range communication range of the client device 101. In one or more embodiments, the user may be prompted to confirm that the service provider may access personal user data. In one or more embodiments, the user may pre-authorize the service provider's access to personal data so that the user does not need to grant permission when the service provider attempts to obtain data access. The user may confirm or pre-authorize access to personal user data in various ways, such as tapping the user's short-range transceiver to the client device in response to a prompt.

[0043] In an exemplary embodiment, personal user data is stored in and updated in database 130. The updated personal user data is stored in database 130 and can be transmitted to client device 101 upon request for personal user data.

[0044] In an exemplary embodiment, application 102 may be activated in response to a tap operation between a short-range transceiver 105 and a client device 101.

[0045] Figure 1C shows a diagram illustrating a sequence for providing data access control according to one or more exemplary embodiments, which may include a request by a service provider for a data access key to access or decrypt personal user data stored in a short-range transceiver. Figure 1C refers to similar components of the system 100 of the exemplary embodiment shown in Figure 1A, and similar features of the system 100 of the exemplary embodiment shown in Figure 1B, including the features described above with respect to labels 150-159 (not repeated here). The service provider referred to in the above description with respect to Figure 1B is referred to as the first service provider in the description of Figure 1C. Referring to Figure 1C, if the first service provider is identified as the sender of a data access key request for accessing a user's personal user data by following the procedure described above with respect to labels 150-159, it may be determined that two authorizations are required.

[0046] The response to the two approval requirements may include a client device 103 associated with a second service provider. The second service provider may be associated with the same service entity as the first service provider (see above), or with an entity related to that service entity, or with a different entity. The client device 103 may include an application 104 which may include instructions for execution by the client device 103. The client device 103 may include functions further described below with reference to Figure 2. The application 104 may be configured to provide a user interface to the second service provider when using the client device 103. The application 104 may be configured to communicate with other client devices, a short-range transceiver 105, and a server 110 via the client device 103. The application 104 may be configured to receive requests and send messages as described herein with reference to the client device 103.

[0047] On label 164, processor 120 may send a two-person authorization notice (e.g., via server 110) to client device 101 informing the first service provider that a second service provider is required to authorize the data access key request. Application 102 may cause a message to appear on client device 101 indicating that the system is waiting for authorization of the request by the second service provider. In some exemplary embodiments, the notice may be sent to client device 103, or to both client device 101 and client device 103. Processor 120 may open a data access session with application 102 to provide tracking of the data access key request (associated with the user via a user token) while waiting for authorization.

[0048] Label 166 indicates that a tap operation may occur between the short-range transceiver 105 and the client device 103. The tap operation may respond to two authorization notifications. Application 104 may receive a user token 107 from the short-range transceiver 105.

[0049] On label 168, application 104 may send a user token to server 110 along with a second service provider token and a data access key request associated with the second service provider. This may respond to the tap operation described above with reference to label 166. The second service provider token may include a second service provider key. Processor 120 may open a data access session with application 104 to provide a separate track of the data access key request from the second service provider (associated with the user via the user token). Processor 120 may use the second service provider token to identify the second service provider as the sender of the data access key request. Based on the user token, processor 120 may determine that the data access key request made by the second service provider corresponds to an open data access key request made by the first service provider, and therefore may attempt to authorize the first service provider to access personal user data.

[0050] With label 170, processor 120 may send an approval notice to application 104 requesting approval by the second service provider for a data access key request submitted by the first service provider.

[0051] Application 104 may display an instruction on client device 103 for a second service provider to approve a data access key request made by the first service provider. In some exemplary embodiments, the display may instruct the second service provider to tap a short-range transceiver 105 on / to the client device 103 to indicate approval (as shown, for example, in Figure 5). In some exemplary embodiments, the display may instruct the second service provider to press a button (not shown in Figure 5) to indicate approval. In one or more exemplary embodiments, the display on client device 103 of the instruction to approve the data access key request may respond to an approval notification on label 170. In one or more exemplary embodiments, the display on client device 103 of the instruction to approve the data access key request may respond to a two-person approval notification on label 164.

[0052] If the second service provider takes action to indicate authorization (for example, by tapping or pressing a button) on label 172, application 104 may send an authorization message to server 110. Based on the authorization message, processor 120 may determine that the second service provider has authorized the data access key request by the first service provider.

[0053] In an exemplary embodiment, in response to two authorization notifications, application 102 may display a code (such as a QR code® or a numeric code) on client device 101 that is scanned by client device 103 or otherwise entered into client device 103. Application 104 may send the code (scanned or entered into client device 103) to server 110 to indicate authorization of the data access key request. Based on the transmitted code, processor 120 may determine that the second service provider has authorized the data access key request by the first service provider.

[0054] At label 174, processor 120 may send a data access key to client device 101. The data access key may be stored in database 130 or generated based on a user key, a first service provider key, a combination of a user key and a first service provider key, or a combination of a user key, a first service provider key, and a second service provider key. The user key may be stored in database 130 or contained in user token 107. The first service provider key may be stored in database 130 or contained in a first service provider token received from client device 101. The second service provider key may be stored in database 130 or contained in a second service provider token received from client device 103.

[0055] Label 176 indicates that the short-range transceiver 105 may transmit encrypted personal user data 108 to the application 102 via the client device 101. It should be noted that, in relation to other events described with respect to Figure 1B or 1C, the timing of the short-range transceiver 105's transmission of the encrypted personal user data 108 to the client device 101 is not critical. The encrypted personal user data 108 may be transmitted at the time of the first tap operation or at any point after the client device 101 has received the data access key.

[0056] As described above with reference to Figure 1B, application 102 may be configured to use a received data access key to receive, decrypt, and access encrypted personal user data 108, for example, by displaying the personal user data on a client device 101 and / or storing the personal user data on the client device 101 for retrieval on a time-limited or limited number of uses basis. In an exemplary embodiment, the received data access key may be stored on the client device 101, and application 102 may display the personal user data on the client device only if the data access key remains stored on the client device.

[0057] In an exemplary embodiment, application 104 may be activated in response to a tap operation between a short-range transceiver 105 and a client device 103.

[0058] Figure 2 shows components of a client device 200 used in a data access control system according to one or more exemplary embodiments. In one or more exemplary embodiments, the client device 200 may be one or more of the client devices 101 and / or 103 described above with reference to Figures 1A and 1B-1C. The client device 200 may include one or more applications 201, one or more processors 202, a short-range communication interface 203, and a network interface 204. The application 201 may include software applications or executable program code that run on the processor 202 and are configured to perform the functions described herein for any of the client devices such as client devices 101 and / or 103, and / or any of the functions described herein with reference to application 102. The application 201 may be configured to send and / or receive data to and from other devices via the client device 101, for example, via the short-range communication interface 203 and / or the network interface 204. For example, the application 201 may be configured to initiate one or more requests, such as a short-range data exchange request to a short-range transceiver (such as a contactless card). Application 201 may also be configured to provide a user interface to the user of the client device via a display (not shown). Application 201 may be stored in the memory of the client device 200. The memory may include read-only memory, write-once read-multiple memory, and / or read / write memory, such as RAM, ROM, and EEPROM.

[0059] The processor 202 may include one or more processing devices such as a microprocessor, RISC processor, or ASIC, and may include associated processing circuits. The processor 202 may include, or be connected to, memory for storing executable instructions and / or data, as may be necessary or appropriate for controlling, operating, or interface with other functions of the client device 200, including application 201. The processor 202 (including associated processing circuits) may include additional components, including the processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitives, and tamper-proof hardware, as may be necessary to perform the functions described herein.

[0060] The short-range communication interface 203 may support communication via short-range wireless communication such as NFC, RFID, or Bluetooth®. The short-range communication interface 203 may include a reader such as a mobile device NFC reader. The short-range communication interface 203 may be integrated into the network interface 204 or provided as a separate interface.

[0061] The network interface 204 may include wired or wireless data communication functions. These functions may support data communication with wired or wireless communication networks, including the Internet, cellular networks, wide area networks, local area networks, wireless personal area networks, wide body area networks, other wired or wireless networks for sending and receiving data signals, or any combination thereof. Such networks may include, but are not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, local area networks, wireless personal area networks, wide body area networks, or global networks such as the Internet.

[0062] The client device 200 may also include a display (not shown). Such a display may be any type of device for presenting visual information, such as a computer monitor, a flat panel display, or a mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays.

[0063] The client device 200 may also include one or more device inputs (not shown). Such inputs may include any device for inputting information available to and supported by the client device 300 into the client device, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. The device inputs may be used to input information, interact with the client device 200, and by extension, interact with the system described herein.

[0064] Figure 3 shows components of a short-range transceiver 300 used in a data access control system according to one or more exemplary embodiments. In one or more exemplary embodiments, the short-range transceiver 300 may be one or more short-range transceivers 105 described above with reference to Figures 1A and 1B-1C. The short-range transceiver 300 may include, for example, a contactless card or a device having various form factors such as a fob, pendant or other device configured to communicate within a short-range communication range. The short-range transceiver 300 may include a processor 302, a memory 302, and a short-range communication interface 306.

[0065] The processor 301 may include one or more processing devices such as a microprocessor, RISC processor, or ASIC, and may include associated processing circuits. The processor 301 may include, or be connected to, memory for storing executable instructions and / or data, as may be necessary or appropriate for controlling, operating, or interface with other functions of the short-range transceiver 300, including the applet 303. The processor 301 (including associated processing circuits) may include additional components, as necessary for performing the functions described herein, including the processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and tamper-proof hardware.

[0066] Memory 302 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM. Memory 302 may be configured to store one or more applets 303, one or more tokens 304, and personal user data 305. Applet 303 may comprise one or more software applications configured to run on processor 301, such as a Java card applet which may be runnable on a contactless card. However, it is understood that applet 303 is not limited to a Java card applet and instead may be any software application that can run on a contactless card or other device with limited memory. Applet 303 may be configured to respond to one or more requests, such as near-field data exchange requests from a client device, including requests from a device having a reader, such as a mobile device NFC reader. Applet 303 may be configured to read (or write) data, including tokens 304 and / or personal user data 305, from (or to) memory 302 and provide such data in response to a request.

[0067] Token 304 may include a unique alphanumeric identifier assigned to a user of the short-range transceiver 300, the identifier which can distinguish the user of the short-range transceiver 300 from other users of other short-range transceivers (such as other contactless card users). In some exemplary embodiments, token 304 may identify both a customer and the account assigned to that customer, and further identify the short-range transceiver (such as a contactless card) associated with the customer's account. In some exemplary embodiments, token 304 may include a unique key for the user or customer to whom the short-range transceiver is associated.

[0068] Personal user data 305 is stored in memory 302 and may be located in a data file identified, for example, by a specific memory location or file name. Personal user data 305 may include personal user information or data that may be confidential or sensitive, such as personal health data, social security numbers, or family contact information. Personal user data 305 may be encrypted and stored in a secure format to prevent unauthorized access. Any appropriate algorithm / procedure (including, for example, public / private key encryption) may be used for data encryption and authorized decryption.

[0069] Personal user data 305 (and personal user data 108 as described above with reference to Figures 1B-1C) may include one or more of the following data categories: name, date of birth, email address, home address, ethnic / race, sex, place of birth, mother's maiden name, social security number, national ID number, passport number, visa approval number, driver's license number, vehicle registration number, genetic information, medical information, disability information, insurance details, location information, what you do and when, status, events attended, sexual orientation, education, grades, work history, salary, job title / position, financial, social, public, service account information, or other accounts, photographs, political and religious leanings and affiliations, views on controversial issues, history / background, credit score / record, registered sites, criminal record, and / or commercially sensitive information.

[0070] The short-range communication interface 306 may support communication via short-range wireless communication ranges such as NFC, RFID, or Bluetooth®. The short-range transceiver 300 may also include one or more antennas (not shown) connected to the short-range communication interface 306 to provide connectivity to the short-range wireless communication range.

[0071] Figure 4 shows an interaction 400 between a client device 401 and a short-range transceiver 420 used in a data access control system according to one or more exemplary embodiments, including the embodiments described above with reference to Figures 1A to 1C. The client device 401 may be the client device 101 described above with reference to Figures 1A and 1B to 1C. The client device 401 may be associated with a (first) service provider as described above with reference to Figures 1B to 1C. The user interface 402 may be generated by the application 102 described above with reference to Figures 1B to 1C. The short-range transceiver 420 may be the short-range transceiver 105 described above with reference to Figures 1A and 1B to 1C. When the short-range transceiver 420 enters the short-range communication range of the client device 401 (e.g., via a tap operation), the client device 401 may communicate with the short-range transceiver 420. The client device 401 may transmit data or commands to the short-range transceiver 420 via the transmit signal 431 and receive data from the short-range transceiver 420, including a token 422, via the receive signal 432. The short-range transceiver 420 may also transmit encrypted personal user data (not shown) to the client device 401. Communication between the client device 401 and the short-range transceiver 420 may proceed as described above with reference to Figures 1B-1C (for example, client device 101 or 103 and short-range transceiver 105).

[0072] The user interface 402 may present a screen display on the client device 401 for a user data access request 410, which may include fields 411 and 412. Optionally, the first service provider may enter a username in field 411 and a password in field 412. The screen display may include instructions 414 prompting the first service provider to tap the short-range transceiver 420 (in the illustrated example, the short-range transceiver 420 may be a contactless card) to initiate a data access key request and obtain the data access key necessary to decrypt encrypted personal user data. Instructions 414 may be a push notification from the server 110 (as shown in Figures 1A and 1B-1C). In response to the tap action, the client device 401 may send the data access key request to the server 110 along with a user token 422 (from the short-range transceiver 420) and a first service provider token (as shown in Figures 1A and 1B-1C).

[0073] Figure 5 shows an interaction 500 between a client device 501 and a short-range transceiver 520 used in a data access control system according to one or more exemplary embodiments, including the embodiments described above with reference to Figures 1A to 1C. The client device 501 may be the client device 103 described above with reference to Figures 1A to 1C. The client device 501 may be associated with a second service provider as described above with reference to Figure 1C. A user interface 502 may be generated by an application 104 described above with reference to Figure 1C. The short-range transceiver 520 may be the short-range transceiver 105 described above with reference to Figures 1A and 1B to 1C. When the short-range transceiver 520 enters the short-range communication range of the client device 501 (e.g., via a tap operation), the client device 501 may communicate with the short-range transceiver 520. The client device 501 may transmit data or commands to the short-range transceiver 520 via the transmit signal 531, and may receive data from the short-range transceiver 520, including a token 522, via the receive signal 532. Communication between the client device 501 and the short-range transceiver 520 may proceed as described above with reference to Figures 1B-1C (for example, client device 101 or 103 and short-range transceiver 105).

[0074] The user interface 502 may present a screen display of a user data access request 510 on the client device 501, which may include fields 511 and 512. If necessary, the second service provider may enter a username in field 511 and a password in field 512. The screen display may include instructions 514 that inform the second service provider that two service providers are required to approve the user data access request and prompt the second service provider to tap a short-range transceiver 520 (in the illustrated example, the short-range transceiver 520 may be a contactless card) to complete the approval process. Instructions 514 may be a push notification from the server 110 (as shown in Figures 1A and 1B-1C). In response to the tap, the client device 501 may send a user token 522 (from the short-range transceiver 520) and a second service provider token to the server 110.

[0075] Figure 6A is a flowchart illustrating a data access control method 600 according to one or more exemplary embodiments, with reference to the above-described components and features, including but not limited to the figures and related descriptions. The data access control method 600 may be performed by an application 102 running on a client device 101 associated with a (first) service provider. A short-range transceiver 105 is associated with a user.

[0076] In block 610, application 102 may cause client device 101 to display a user data access request screen (as shown in Figure 4 and described above with reference to Figure 4). The user data access request screen may include instructions to tap the short-range transceiver 105 on / to the client device 101 to initiate a data access key request. As described above with reference to Figure 4, the short-range transceiver 420 (and therefore the short-range transceiver 105) may be a contactless card.

[0077] In block 620, a tap operation can be detected between the short-range transceiver 105 and the client device 101.

[0078] In block 630, the user token 107 may be received from the short-range transceiver 105. Reception of the user token 107 may respond to a tap operation in block 620. The user token 107 may include a user identifier. In some exemplary embodiments, the user token 107 may include a user key associated with the user.

[0079] In block 640, the user token 107 and the service provider token (associated with the service provider) are sent to the server 110 along with a data access key request, and a key may be obtained to decrypt the encrypted personal user data received (or to be received) from the short-range transceiver 105. The transmission of the user token 107, the service provider token, and the data access key request to the server 110 may be in response to the tap operation in block 620.

[0080] In block 650, the data access key can be received from server 110.

[0081] In block 660, encrypted personal user data may be received from short-range transceiver 105. As described above, encrypted personal user data may be received at any time during the process.

[0082] In block 670, encrypted personal user data can be decrypted using a data access key. As discussed above, in some embodiments, application 102 may cause personal user data to be displayed on client device 101. In some embodiments, application 102 may be permitted to store personal user data on client device 101 for retrieval based on time limits or limited usage counts.

[0083] Figure 6B is a flowchart illustrating a data access control method 600 according to one or more exemplary embodiments, with reference to the components and features described above, including but not limited to the drawings and related descriptions. Features described in Figure 6B may be added to those referenced in Figure 6A. The descriptions of the blocks referenced in Figure 6A are not repeated here. As described above with reference to Figure 6A, the data access control method 600 may be performed by an application 102 running on a client device 101 associated with a (first) service provider. A short-range transceiver 105 is associated with a user.

[0084] The memory located in the short-range transceiver 105 (such as the memory 302 shown in Figure 4) may contain basic user data such as name, gender, and date of birth. This basic user data may be a subset of the types of data included in the personal user data, may be additional data, and / or may be data that is less likely to change (less likely to change over time than other types of personal user data). In some exemplary embodiments, such as when the personal user data includes health data, the basic user data may include certain aspects of health data, such as height, weight, allergies, prescriptions, and DNR orders. The types of information that may be included in the basic user data may be selectable by the user.

[0085] Basic user data is stored in the short-range transceiver memory 302 and may be placed in a data file identified, for example, by a specific memory location or file name.

[0086] Basic user data may be encrypted with a key so that it can be decrypted with a basic service provider key available to the service provider. The basic service key may be different from the data access key required to describe personal user data 305. In one or more embodiments, the basic service provider key may be available to the service provider and may be valid for a limited period, such as daily, weekly, monthly, or based on other criteria. The basic service provider key may be common to all personnel associated with a particular service provider entity. The basic service provider key may be stored in a database 130 or generated by the system based on the service provider's identity. By storing (or generating) the basic service provider key by the system and pushing that key to client devices, it becomes possible to control access and log and track access for auditing purposes.

[0087] In block 690, the basic service provider key is received from the server. The basic service provider key can be requested and / or obtained at any time according to any arrangements or protocols that the service provider (or service provider entity) may have in system 100. For example, a client device 101 may send a request for the basic service provider key to the server 110 at intervals when a new key becomes available (e.g., daily, weekly, monthly, or on other criteria). Receiving the basic service provider key does not require the service provider to be near the short-range transceiver 105, and the basic service provider key can be requested or received independently of any tapping operation by the short-range transceiver 105.

[0088] In block 692, the basic service provider key is stored in memory located on the client device 101 so that the service provider can later retrieve and use the basic service provider key.

[0089] In block 694, encrypted basic user information may be received from the short-range transceiver 105. This can be received in response to a tap operation between the short-range transceiver 105 and the client device 101, or whenever the short-range transceiver 105 is within the short-range wireless communication range of the client device 101.

[0090] In block 696, encrypted basic user data can be decrypted using the basic service provider key. Application 102 can display the basic user data on the client device 101. In some embodiments, application 102 may be permitted to store basic user data on the client device 101 for retrieval on a time-limited or limited-use basis. In an exemplary embodiment, basic user data may be stored in the transceiver 105 in an unencrypted format. In an exemplary embodiment, basic user data may be received by the client device 101 in an unencrypted format and accessed without requiring the basic service provider key. Whether basic user data is stored or provided in an unencrypted format is up to the user to decide.

[0091] Figure 7A is a flowchart illustrating a data access control method 700 according to one or more exemplary embodiments, with reference to the above-described components and features, including but not limited to the figures and related descriptions. The data access control method 700 may be performed by a processor 120 that communicates with a client device 101 associated with a first service provider and / or a client device 103 associated with a second service provider via a server 110.

[0092] In block 710, a data access key request may be received from a client device 101 associated with the first service provider, requesting a data access key that enables the decryption of encrypted personal user data, along with a user token 107 and a service provider token (associated with the first service provider). The token 107 may include a user identifier. In some exemplary embodiments, the token 107 may include a user key associated with the user. In some exemplary embodiments, the service provider token may include a first service provider key.

[0093] In block 720, the sender of a data access key request may be identified as a first service provider based on a service provider token. In some exemplary embodiments, if the service provider token includes a first service provider key associated with the first service provider, the first service provider can be authenticated using the first service provider key.

[0094] In block 730, the user may be identified based on the received user token 107. In some exemplary embodiments, if the token 107 includes a user key associated with the user, the user key may be used to authenticate the user.

[0095] In block 740, the processor may verify that the first service provider is authorized to receive access to personal user data (and therefore authorized to obtain the data access key). Authorization may be obtained based on the identity of the service provider, or the identity of the user, or both, and may include retrieving information from database 130.

[0096] In block 750, a data access key may be sent to the client device 101 associated with the service provider. As described above, the data access key may be stored in the database 130, or it may be generated based on a user key, a first service provider key, or a combination of a user key and a first service provider key.

[0097] Figure 7B is a flowchart of a data access control method 701 according to one or more exemplary embodiments, with reference to the above-described components and features, including but not limited to the drawings and related descriptions. Features described in Figure 7B may be added to the features referenced in Figure 7A. The descriptions of the blocks referenced in Figure 7A are not repeated here. As described above with reference to Figure 7A, the data access control method 700 may be performed by a processor 120 that communicates with client devices 101 associated with a first service provider and / or client devices 103 associated with a second service provider via a server 110.

[0098] According to the method in Figure 7B, block 750 (referenced in Figure 7A) is not executed in the sequence shown in Figure 7A. Instead, referring to Figure 7B, block 750' determines that two authorizations are required for service provider access to personal user data.

[0099] In block 760, a notification is sent to client 101 associated with the first service provider stating that for the two parties to approve, the second service provider must approve the data access key request.

[0100] In block 765, a data access key request may be received from the client device 103 associated with the second service provider, along with a user token and a second service provider token. The second service provider token may include a second service provider key.

[0101] In block 770, it may be determined that a data access key request from the second service provider's client device 103 corresponds to a data access key request previously received from the first service provider's client device 101.

[0102] In block 775, an authorization notice requesting authorization for a data access key request made by the first service provider may be sent to the second service provider's client device 103.

[0103] In block 780, an authorization message indicating that the second service provider has authorized a data access key request made by the first service provider may be received from the second service provider's client device 103.

[0104] In block 785, the data access key may be sent to a client device 101 associated with the first service provider. As described above, the data access key may be stored in the database 130, or may be generated based on a user key, a first service provider key, a combination of a user key and a first service provider key, or a combination of a user key, a first service provider key, and a second service provider key.

[0105] Figure 7C is a flowchart of a data access control method 702 according to one or more exemplary embodiments, with reference to the components and features described above, including but not limited to the figures and related descriptions. Features described in Figure 7C may be added to features referenced in Figure 7A or Figure 7B. The descriptions of the blocks referenced in Figures 7A and 7B will not be repeated here. As described above with reference to Figures 7A and 7B, the data access control method 700 may be performed by a processor 120 that communicates with a client device 101 associated with a first service provider and / or a client device 103 associated with a second service provider via a server 110.

[0106] In block 790, a request for a basic service provider key is received from the client device 101. As discussed above, a service provider (or service provider entity) may request a basic service provider key at any time, according to any arrangements or protocols that the system 100 may have. Requesting a basic service provider key does not require the service provider to be near the short-range transceiver 105, and the basic service provider key can be sent to the client device 101 independently of any tapping operation on the short-range transceiver 105.

[0107] In block 792, the processor may verify that the service is authorized to receive access to basic user data (and therefore authorized to obtain basic service provider keys). Authorization may be obtained based on the service provider's identity and may include retrieving information from database 130.

[0108] In block 794, a basic service provider key may be sent to the client device 101 associated with the service provider. The service provider key may be stored in the database 130 or may be generated by the system based on the service provider's identity.

[0109] Figure 8 shows a diagram illustrating a data access control system 800 according to one or more exemplary embodiments. Figure 8 refers to similar components of system 100 in the exemplary embodiment shown in Figure 1A, and the description of those components is not repeated here. In addition to the components shown in Figure 1A and related to system 100 as described above, system 800 may include a data repository 801. The data repository 801 may include a database having some or all of the same or similar structures, functions, or features as described above for database 130. The data repository may include or incorporate a server having some or all of the same or similar structures, functions, or features as described above for server 110. The data repository may also include or incorporate a processor having some or all of the same or similar structures, functions, or features as described above for processor 120. The data repository is configured to store personal user data, such as personal user data of the type described above with respect to personal user data 305 in Figure 3. The data repository may store personal user data in an encrypted format or encrypt personal user data before transmitting it to an authorized service provider. The data repository 801 may be operated by the same or related entities as the operating system 100, or by a third party.

[0110] During operation, system 800 may perform all or many of the same functions performed by the components of system 100 as described above to process requests for data access keys to access personal user data. Once system 800 verifies that the service provider is authorized to receive access to the personal user data, processor 120 may generate a link to the data repository where the personal user data is stored. In an exemplary embodiment, in addition to, or instead of, the link to data repository 801, processor 120 may provide information (e.g., the electronic address of data repository 801).

[0111] The processor 120 may look up a data access key or generate a data access key as described above (including, for example, being generated based on a user key, or based on a user key and a service provider key). The processor 120 may send the data access key and a link to a data repository 801 where personal user data may be located to the client device 101. Upon receiving the data access key and the link to the data repository 801, the client device 101 may look up encrypted personal user data from the data repository 801 based on the link. For example, the client device 101 may send a request for encrypted personal user data to the data repository 801 via the link and receive the encrypted personal user data from the data repository 801. Once the client device 101 has obtained the encrypted personal user data, the client device 101 may use the data access key to decrypt the encrypted personal user data. Once the personal user data is decrypted, the client device 101 may access and use the personal user data as described above.

[0112] In some exemplary embodiments, the data repository 801 may store the same personal user data as stored in the transceiver 105. In some exemplary embodiments, personal user data is stored in the data repository 801 instead of being stored in the transceiver 105. In some exemplary embodiments, personal user data is stored in the data repository 801, and only a limited set of user data (e.g., basic user data) may be stored in the transceiver 105. In some exemplary embodiments, personal user data stored in the data repository 801 may be updated. The updated personal user data is stored in the data repository 801 and may be transmitted to the client device 101 upon request for personal user data.

[0113] The descriptions of embodiments in this disclosure provide non-limiting representative examples with reference to figures and figures in particular to illustrate the features and teachings of different embodiments of this disclosure. It should be recognized that the embodiments described may be practiced separately or in combination with other embodiments from the descriptions of embodiments. A person skilled in the art should be able to learn and understand the different described embodiments of this disclosure. The descriptions of embodiments facilitate the understanding of this disclosure to the extent that other practices, though not specifically described, within the knowledge of a person skilled in the art who has read the descriptions of embodiments will be understood to be consistent with the application of this disclosure.

[0114] Throughout the specification and claims, the following terms have the meanings expressly associated herein, unless the context clearly indicates otherwise. The term "or" is intended to mean an inclusive "or." Furthermore, the terms "a," "an," and "the" are intended to mean one or the plural, unless otherwise specified or the context makes it clear that they are singular.

[0115] This description provides many specific details. However, it should be understood that the disclosed technology may be implemented without these specific details. In other examples, well-known methods, structures, and techniques are not described in detail so as not to obscure the understanding of this description. References to “several examples,” “other examples,” “one example,” “example,” “various examples,” “one embodiment,” “embodiment,” “several embodiments,” “exemplary embodiment,” “various embodiments,” “one implementation,” “implementation,” “exemplary implementation,” “various implementations,” and “several implementations” indicate that the implementation of the disclosed technology described in this way may include certain features, structures, or characteristics, but not all implementations necessarily include those specific features, structures, or characteristics. Furthermore, repeated use of the phrases “in one example,” “in one embodiment,” or “in one implementation” does not necessarily refer to the same example, embodiment, or implementation, but may.

[0116] Where used herein, unless otherwise specified, the use of ordinal adjectives such as “first,” “second,” “third,” etc., to describe a common subject merely indicates that different instances of a similar subject are being referred to, and does not imply that the subjects described in this way must be in a particular order, temporally, spatially, in rank, or otherwise.

[0117] While specific implementations of the disclosed technology have been described in relation to those currently considered to be the most practical and diverse implementations, it should be understood that the disclosed technology should not be limited to the disclosed implementations, but rather is intended to cover a variety of modifications and equivalent arrangements included within the scope of the attached claims. Certain terms are used herein, but they are used in a general and descriptive sense only, and not for limiting purposes.

[0118] This written description, using examples, discloses specific practices of the disclosed technology, including the best mode, and enables a person skilled in the art to practice specific practices of the disclosed technology, including the creation and use of any device or system, and the execution of any incorporated methods. The patentable scope of specific practices of the disclosed technology is defined in the claims and may include other examples that arise for a person skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that are not different from the literal language of the claims, or if they include equivalent structural elements that are substantially different from the literal language of the claims.

Claims

1. A data access control system, A database that stores information including user identifiers and user keys associated with users, and service provider identifiers and service provider keys associated with service providers, A server configured to communicate data with client devices associated with a service provider over a network, A contactless card associated with a user, the contactless card comprising a communication interface, a processor, and memory, the memory storing an applet, a user token, and personal user data associated with the user, the personal user data being encrypted using the user key, and the contactless card, A client application comprising instructions for execution on the client device, The aforementioned client application is In response to a tap operation between the contactless card and the client device, the user token is received from the contactless card, and a request for the service provider token, the user token, and the data access key is sent to the server, and the service provider token is associated with the service provider. The server receives the data access key, The encrypted personal user data is received from the contactless card. The system is configured to decrypt the encrypted personal user data using the aforementioned data access key. The aforementioned data access control system is The system comprises a processor that communicates data with the server and the database, The aforementioned processor, The client device receives requests for the service provider token, the user token, and the data access key. Based on the service provider token, the service provider is identified, Based on the user token, the user is identified, Verify that the service provider is authorized to receive access to the personal user data, Obtain the user key from the aforementioned database, The data access key is generated from the user key. The data access key is configured to be transmitted to the client device. Data access control system.

2. The data access control system according to claim 1, wherein the user token comprises the user key, and the processor is further configured to authenticate the user based on the user key.

3. The data access control system according to claim 1, wherein the service provider token comprises the service provider key, and the processor is further configured to authenticate the service provider based on the service provider key.

4. The data access control system according to claim 1, wherein the service provider token comprises the service provider key, and the data access key is generated from the user key and the service provider key.

5. The data access control system according to claim 1, wherein the client application is further configured to display the decrypted personal user data on the client device.

6. The aforementioned client application is The data access key is stored in the client device. The data access control system according to claim 5, further configured to display the decrypted personal user data on the client device only if the data access key remains stored on the client device.

7. The memory of the contactless card further stores basic user data associated with the user, and the basic user data is encrypted with a basic service provider key. The aforementioned client application is The encrypted basic user data is received from the contactless card. The system is further configured to decrypt the encrypted basic user data using the basic service provider key. The data access control system according to claim 1.

8. The aforementioned client application is The server receives the basic service provider key, The basic service provider key is further configured to be stored in the memory of the client device. The data access control system according to claim 7.

9. The client application is further configured to send a request for the basic service provider key to the server, and the request for the basic service provider key is independent of the tap operation between the contactless card and the client device. The aforementioned processor, Verify that the service provider is authorized to receive the basic service provider key, The basic service provider key is further configured to send the basic service provider key to the client device. The data access control system according to claim 8.

10. The data access control system according to claim 9, wherein the basic service provider key is valid only for a predetermined period of time.

11. A method for controlling data access, Establish a database that stores information including user identifiers and user keys associated with users, and service provider identifiers and first service provider keys associated with service providers, Receiving a request for a data access key from a first client device associated with the service provider via a network, for accessing a service provider token and personal user data stored on a contactless card associated with the user, wherein the personal user data is encrypted using the user key, the request is generated in response to a tap operation between the contactless card and the first client device, and the request is accompanied by a user token stored on the contactless card. Identifying the service provider based on the service provider token, Identifying the user based on the aforementioned user token, Verification that the service provider is authorized to receive access to the personal user data stored on the contactless card, Obtaining the user key from the aforementioned database, The data access key is generated based on the user key, The data access key is transmitted to the first client device. A method that includes this.

12. The method according to claim 11, wherein the user token includes the user key, and the method further comprises authenticating a user based on the user key.

13. The method according to claim 11, wherein the service provider token comprises the first service provider key, and the method further comprises authenticating the service provider based on the first service provider key.

14. The method according to claim 13, wherein the data access key is generated based on the user key and the first service provider key.

15. The aforementioned method, The method according to claim 13, further comprising receiving a second service provider key from a second client device, wherein the data access key is generated based on the user key, the first service provider key, and the second service provider key.

16. The method according to claim 15, wherein the second service provider key is transmitted by the second client device in response to a tap operation between the contactless card and the second client device.

17. The database further stores updated personal user data associated with the user, and the method The updated personal user data is encrypted using the aforementioned user key, The encrypted updated personal user data is transmitted to the first client device, The method according to claim 11, further comprising:

18. A method for controlling data access, Establish a database that stores information including user identifiers and user keys associated with users, and service provider identifiers and service provider keys associated with service providers, The present invention provides a contactless card comprising a communication interface, a processor, and memory, wherein the memory stores applets and user tokens, the communication interface is configured to support at least one of near-field communication, Bluetooth, or Wi-Fi, and the contactless card is associated with a user. The service provider includes providing a client application which comprises instructions for execution on a client device associated with the service provider, In response to a tap operation between the contactless card and the client device, the user token is received from the contactless card, and a request for a service provider token, the user token, and a data access key is sent to the server via the network, the service provider token being associated with the service provider, The server receives the data access key and a link to a data repository that stores encrypted personal user data associated with the user, and the data access key is generated based on the user key. The request for the encrypted personal user data is sent to the data repository via the aforementioned link. The encrypted personal user data is received from the aforementioned data repository. The system is configured to decrypt the encrypted personal user data using the aforementioned data access key. The aforementioned method, Receiving from the client device via the network a request for a service provider token and the data access key for accessing the personal user data associated with the user, wherein the request is accompanied by the user token. Identifying the service provider based on the service provider token, Identifying the user based on the aforementioned user token, Verification that the service provider is authorized to receive access to the personal user data associated with the user, To generate the link to the data repository that stores the encrypted personal user data, Obtaining the user key from the aforementioned database, The data access key is generated based on the user key, The client device is to transmit the data access key and the link to the data repository that stores the encrypted personal user data. A method that includes this.

19. The method according to claim 18, wherein the data access key is generated based on the user key and the service provider key.

Images