System and method for secure memory data access control using a short-range transceiver.

Abstract

This invention provides a data access control system and method that can be controlled by the user. [Solution] The data access control system consists of a server capable of data communication with a client device, a contactless card associated with the user that stores an applet and a user token, and a client application on the client device. The client application receives the user token from the contactless card, sends a request for the user token and data storage key to the server, receives the data storage key from the server, forms a secure memory block on the client device, and encrypts it. The server confirms that the user is authorized to form the secure memory block and sends the data storage key to the client device. [Effect] Access to stored user data may be provided only to authorized users.

Description

Cross - reference to related applications

[0001] This application claims priority to U.S. Patent Application No. 16 / 657,415, filed on October 18, 2019 (issued as U.S. Patent No. 10,742,414 on August 11, 2020), the disclosure of which is hereby incorporated by reference in its entirety.

Technical Field

[0002] This disclosure generally relates to user data control, and more particularly, to exemplary systems and methods for the active control of the formation and access of secure memory blocks through the interaction between a short - range transceiver and a client device.

Background Art

[0003] Typical users have personal user information or data of a confidential or secret nature, including, for example, information identifying an individual, social security numbers, account information, financial information, etc. When a user forms an account, generally the user provides a certain amount of information identifying the individual related to the user and information for access to the account, such as a username and password. Entities other than the user can increase personal user data. Different entities may have, for example, different user data retention policies, different user policies, and different user data sharing policies. The policies for using user - information can be further changed without any notice to the user. In addition, the owner of user information can change without any notice to the user many times through mergers or acquisitions by one entity of another entity.

[0004] Account access typically relies on login credentials (e.g., username and password) to verify the cardholder's identity. However, if login credentials are compromised, another person may gain access to the user's account and potentially their private or confidential information or data. Furthermore, the more entities or individuals a user shares their personal information with, the greater the risk of their information being stolen if at least one of those entities is compromised. In addition, a user may only wish to share certain personal information with an entity or individual for a limited purpose or for a limited time.

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

[0006] The disclosed aspects of the technology include systems and methods for controlling data access through interaction between a near-field transceiver, such as a contactless card, and a client device. The data access control is provided in terms of the formation and access of secure memory blocks within the client device through interaction between the near-field transceiver, such as a contactless card, and the client device, thereby allowing personal user data to be stored in the client device and protected from unauthorized access.

[0007] Embodiments of this disclosure provide a data access control system. The data access control system includes a server configured to communicate data with a client device associated with a user, a contactless card associated with the user, a client application containing instructions for execution on the client device, and a processor that communicates data with the server. The contactless card includes a communication interface, a processor, and memory. The memory stores an applet and a user token. The client application is configured to respond to a tap operation between the contactless card and the client device by receiving a user token from the contactless card, sending a request for the user token and a data storage key to the server, receiving the data storage key from the server, forming a secure memory block in the client device's memory, and encrypting the secure memory block using the data storage key. The processor is configured to receive a request for the user token and a data storage key from the client device, verify the user's identity based on the user token, confirm that the user is authorized to form a secure memory block in the client device, and send the data storage key to the client device.

[0008] Embodiments of this disclosure provide a method for controlling data access. The method includes providing a contactless card comprising a communication interface, a processor, and memory. The memory stores an applet and a user token. The user token includes a user key. The communication interface is configured to support at least one of Near Field Wireless Communication, Bluetooth®, and Wi-Fi®. The contactless card is associated with a user. The method includes providing a client application which includes instructions for execution on a client device associated with the user. The client device has an encrypted, secure memory block which stores personal user data. The client application is configured to receive a user token from the contactless card in response to a tap operation between the contactless card and the client device, send a request for the user token and data access key to a server, receive the data access key from the server, and use the data access key to decrypt the secure memory block. The method includes receiving a request for the user token and data access key from the client device, verifying the user's identity based on the user token, confirming that the user is authorized to access the secure memory block in the client device, and sending the data access key to the client device.

[0009] Embodiments of this disclosure provide a non-temporary, machine-readable medium storing an application, including program code for execution on a client device. The client device is associated with a user. The client device is configured to communicate with a contactless card associated with the user via a near-field communication field. The contactless card includes memory for storing a user token. When executed, the application is configured to perform steps including receiving a user token from the contactless card in response to a tap operation between the contactless card and the client device, sending a request for the user token and a data storage key to a server, receiving the data storage key from the server, forming a secure memory block in the client device's memory, storing personal user data in the secure memory block, and encrypting the secure memory block using the data storage key.

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

[0011] [Figure 1A] Diagram of a data access control system according to one or more exemplary embodiments. [Figure 1B] A diagram illustrating a sequence that provides data access control according to one or more exemplary embodiments. [Figure 1C] A diagram illustrating a sequence that provides data access control according to one or more exemplary embodiments. [Figure 2] A diagram illustrating the components of a client device used in a data access control system according to one or more exemplary embodiments. [Figure 3] A diagram illustrating the components of a short-range transceiver used in a data access control system according to one or more exemplary embodiments. [Figure 4]This diagram illustrates 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 diagram illustrates 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] Flowchart illustrating one or more methods of data access control according to one or more exemplary embodiments [Figure 6B] Flowchart illustrating one or more methods of data access control according to one or more exemplary embodiments [Figure 6C] Flowchart illustrating one or more methods of data access control according to one or more exemplary embodiments [Figure 6D] Flowchart illustrating one or more methods of data access control according to one or more exemplary embodiments [Figure 7A] Flowchart illustrating one or more methods of data access control according to one or more exemplary embodiments [Figure 7B] Flowchart illustrating one or more methods of data access control 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 reference numerals to illustrate features in detail, and teachings of different aspects of the invention. The described embodiments are recognized as being implementable individually or in combination with other embodiments from the description of embodiments. A person skilled in the art who examines the description of embodiments will be able to know and understand the different described aspects of the invention. The description of embodiments facilitates the understanding of the invention to the extent that other implementations that are not specifically covered but are included in the knowledge of a person skilled in the art who has read the description of embodiments will be understood to be consistent with applications of the invention.

[0013] Exemplary embodiments of the disclosed systems and methods provide control over data access through interaction between a near-field transceiver, such as a contactless card, and a client device. Data access control may be provided in the context of the formation and access of secure memory blocks within the client device. Requests to form or access secure memory blocks within the client device may be handled such that, through interaction between the near-field transceiver, such as a contactless card, and the client device, once a secure memory block is formed in the client device's memory, personal user data can be stored within the secure memory block, and access to the stored personal user data can only be provided to users authorized to view the data again. The benefits of the disclosed technology may include improved data security for personal user data, improved access to personal user data stored in and retrieved from a more convenient location (i.e., a client device such as a mobile phone), and an 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 a client device 101, a short-range transceiver 105, a server 110, a processor 120, and a database 130. The client device 101 may communicate with the server 110 through a network 115. While Figure 1 illustrates 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. Each of the one or more client devices may be a network-enabled computer. As described below, a network-enabled computer may include, but is not limited to, computer devices, or communication devices, such as servers, network equipment, personal computers, workstations, telephones, handheld PCs, personal digital assistants, thin clients, fat clients, internet browsers, or other devices. Client device 101 may be a mobile device, and for example, a mobile device may include Apple's iPhone, iPod, iPad, or other mobile devices running on Apple's iOS operating system, any device running on Microsoft's Windows mobile operating system, any device running on 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 are described further 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 a client device such as client device 101 within a short-range communication field, such as near-field communication (NFC) for example. Short-range transceiver 105 may include, for example, contactless cards, smart cards, or may include devices of various form factors such as fobs, pendants, or other devices configured to communicate within a short-range communication field. In other embodiments, short-range transceiver 105 may be the same as or equivalent to client device 101. Additional features that may be included in a short-range transceiver such as short-range transceiver 105 are 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 a microprocessor etc.) coupled to a memory. Server 110 may be configured as a central system, server, or platform that controls and invokes various data at different times to execute a plurality of workflow actions. Server 110 may be a dedicated server computer such as a blade server, or may be a personal computer, laptop computer, notebook computer, palmtop computer, network computer, mobile device, or a processor-controlled device capable of supporting system 100.

[0018] Server 110 may be configured for data communication (e.g., via connection, etc.) with one or more processors, such as processor 120. In some exemplary embodiments, server 110 may include processor 120. In some exemplary embodiments, server 110 may be physically separated from and / or located remotely 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 connection, etc.) with database 130 and / or server 110. Processor 120 may include one or more processing devices, such as a microprocessor, RISC processor, or ASIC, along with associated processing circuits. Processor 120 may include, or be connected to, memory for storing executable instructions and / or data. The processor 120 may communicate, transmit, or receive messages, requests, notifications, data, etc., with other devices such as client devices 101 and / or 103 through the server 110.

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

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

[0021] Server 110 and / or database 130 may include user login credentials used to control access to user accounts. Login credentials are not particularly limited, but may include a username, password, access code, security questions, swipe pattern, image recognition, identification scan (e.g., scan of a driver's license and scan of a passport), device registration, phone number, email address, social media account access information, and biometric identification (e.g., voice recognition, fingerprint scan, retina scan, and face scan).

[0022] Database 130 may contain data relating to one or more users and one or more accounts. User data may include user identifiers and user keys and may be maintained or organized in one or more accounts. Accounts may be maintained and / or associated with one or more of the following entities, for example (and not limited to) banks, businesses, online retailers, service providers, retailers, manufacturers, social media providers, sports or entertainment event providers or promoters, or hotel chains. For example, database 130 may include, 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 these may include an account identifier), account characteristics (e.g., account type, lending and transaction restrictions, and restrictions on access and other activities), and may further include account-related information and data including financial (balance information, payment history, and trading history), social and / or personal information. 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, through 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 device 101 to server 110. For example, network 115 may include one or more of the following: optical fiber networks, passive optical networks, cable networks, internet networks, satellite networks, wireless local area networks (LANs), Global System for Mobile Communication, Personal Communication Service, Personal Area Network, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplexing systems, code division multiplexing systems, D-AMPS, Wi-Fi, fixed wireless access, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth®, NFC, radio frequency identification (RFID), Wi-Fi, and / or similar technologies.

[0024] In addition, network 115 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. In addition, network 115 may support internet networks, wireless communication networks, cellular networks, etc., or any combination thereof. Network 115 may further include a single network or any number of the exemplary types of networks described above, operating as standalone networks or cooperating with one another. Network 115 may use one or more protocols of one or more network elements that are coupled together in a communicative manner. Network 115 may perform conversions between one or more protocols of network devices and another protocol. Although network 115 is depicted as a single network, it may, of course, include 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, according to one or more exemplary embodiments.

[0025] In some exemplary embodiments, the server 110 may access records in the database 130, including records, to determine one or more methods for communicating with the client device 101. Communication methods may include actionable push notifications using applications stored on the client device 101. Other communication methods may include text messages or email, or other appropriate messaging techniques in a network-based client / server configuration. Messages or requests from the client device 101 may be communicated to the server 110 through applications on the client device, or transmitted by text messages or email, or other appropriate messaging techniques in a network-based client / server configuration. Communication originating from the client device 101 may be transmitted to the server 110 using the same communication methods as communication originating from the server 110, or through different communication methods.

[0026] Figure 1B illustrates a sequence of data access control according to one or more exemplary embodiments, which may include a user request for a data storage key to form a secure memory block within a client device. Figure 1B refers to similar components of system 100 in the exemplary embodiment described in Figure 1A. The client device 101 may be associated with a user. The client device 101 may include an application 102 and memory 104. The application 102 may include instructions for execution by the client device 101. The client device 101 may include features further described below with reference to Figure 2. The application 102 may be configured to provide a user interface to the user when the client device 101 is in use. The application 102 may be configured to communicate with other client devices 101, a near-field transceiver 105, and a server 110 through the client device 101. The application 102 may be configured to receive requests and send messages referring to the client device 101, as described below. User information, including identifiers and / or keys, may be stored in the 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 memory for storing an applet 106 and / or a token 107. The token 107 may be associated with a user.

[0028] Tokens may 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, return a verification token to the client device. The verification token may be based on a predetermined token, or it may be a dynamic token based on a secret algorithm known only to Server 110 and the client device. The algorithm may include live parameters, such as temperature at a specific location or time, which can be independently verified by participants. Tokens may be used to verify the identity of a user. Verification requests and / or verification tokens may be based on tokens 107 stored in the near-field transceiver 105.

[0029] Label 150 allows a user to sign in or log in to an application 102 running on a client device 101. Signing in or logging in can be achieved, for example, by entering a username and password, or by scanning biometric information such as a fingerprint scan, retinal scan, or facial scan. In some exemplary embodiments, application 102 may display instructions on the client device 101 prompting the user to begin a tap operation between the near-field transceiver 105 and the client device 101. When used herein, the tap operation may include tapping the near-field transceiver 105 against the client device 101 (or vice versa). For example, if the near-field transceiver 105 is a contactless card and the client device 101 is a mobile device, the tap operation may include tapping the contactless card against the screen or other part of the client device 101. However, the tapping action is not limited to a physical tap of the client device 101 by the near-range transceiver 105, and may include other gestures such as shaking or otherwise moving the near-range transceiver 105 in the vicinity of the client device 101 (or vice versa).

[0030] Label 152 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.

[0031] Label 154 indicates that application 102 can communicate with near-field transceiver 105 (through client device 101) (for example, after near-field transceiver 105 is brought close to client device 101). Communication between application 102 and near-field transceiver 105 may require the near-field transceiver 105 (e.g., a contactless card) to be close enough to the card reader (not shown) of client device 101 to enable NFC data transfer between application 102 and near-field transceiver 105, and may occur in conjunction with (or in response to) a tap operation between near-field transceiver 105 and client device 101 (e.g., a tap operation on label 152). Communication may include the exchange of data or commands to establish a communication session between application 102 and near-field transceiver 105. Data exchange may include the transfer or exchange of one or more keys, which may be pre-existing keys or generated as session keys. In some exemplary embodiments, communication may occur when the near-field transceiver 105 enters the near-field communication field of the client device 101 before a tap operation between the near-field transceiver 105 and the client device 101.

[0032] On label 156, the near-field 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 user token 107 to the application 102 may occur in conjunction with (or in response to) a tap operation between the near-field transceiver 105 and the client device 101 (e.g., a tap operation on label 152). In some exemplary embodiments, the transmission of the user token 107 to the application 102 may occur when the near-field transceiver 105 enters the near-field communication field of the client device 101 prior to a tap operation between the near-field transceiver 105 and the client device 101. In addition to the user token 107, the near-field transceiver may transmit other data to the application 102, including, for example, data such as counters, public keys, and other information (or items of this data may be included in the user token 107).

[0033] On label 158, application 102 may send a user token to server 110 along with a request for a data storage key. This may be done in response to a tap operation between the near-field transceiver 105 and the client device 101 (e.g., a tap operation on label 152). The data storage key enables the user to encrypt a secure memory block formed as described further below.

[0034] Label 159 indicates that processor 120 may receive requests for a user token and a data storage key (for example, through server 110). Processor 120 may use the user token to verify the user's identity. In some exemplary embodiments, user verification may be performed by using the user identifier in the token to retrieve information in database 130. In some exemplary embodiments, label 160 indicates that if the user token contains a key associated with the user, processor 120 may use the user key to authenticate the user. Based on user verification (and thus the verification being authenticated), processor 120 may determine whether the user is authorized to form a secure memory block in the memory 104 of client device 101 and to receive a data storage key used to protect that memory block.

[0035] Label 162 indicates that the processor 120 may send a data storage key to the client device 101. As described above, the processor 120 may verify whether the user is permitted to form a secure memory block in the memory 104 of the client device 101 and to receive the data storage key. The data storage key may be stored in the database 130 or generated based on a user key. Generating a data storage key based on a user key may involve using counters or other data that are synchronously obtained from the processor 120, the client device 101 and / or the near-field transceiver 105, or otherwise maintained. For example, the data storage key may be generated by encrypting a counter value or other data value with the user key. The user key may be stored in the database 130 or contained in the user token 107. In one or more exemplary embodiments, application 102 may generate a new data storage key based on a combination of a received data storage key and data received from the near-field transceiver 105 (for example, a user token 107 which may include a user key, or other data which may include a second user key).

[0036] In one exemplary embodiment, the processor 120 may instead send a denial notice (not shown) to the client device 101 indicating that the user is not permitted to form a secure memory block in the memory 104 of the client device 101 and is not permitted to receive a data storage key.

[0037] Label 164 indicates that application 102 may form a secure memory block in memory 104, for example, by forming a memory partition for a block of memory in memory 104, or by allocating a block of memory in memory 104.

[0038] In some exemplary embodiments, application 102 may store personal user data in a newly formed secure memory block. In some exemplary embodiments, application 102 may store or update personal user data in the secure memory block at a different time. Personal user data may include data for identifying an individual, and / or other personal user information or data that may be of a secret or confidential nature, such as name, address, date of birth, gender, social security number, driver's license number and related data (including an actual digital driver's license), credit card or other financial information, account information for financial, social, utility, or other accounts, medical data, academic data, etc. Personal user data may also include, for example, files relating to confidential matters such as legal documents, collateral, wills, etc., and photographs of confidential matters such as, for example, photos of a driver's license, ID card, credit card, etc. Personal user data may also include, for example, secure keys such as fast identity online (FIDO) keys and blockchain keys.

[0039] Label 166 indicates that application 102 may encrypt a secure memory block using a data storage key (either received or newly generated) to secure the memory block against unauthorized access, while later allowing authorized access, as detailed below. Any suitable algorithm / procedure may be used for data encryption and authorized decryption. In one or more exemplary embodiments, the data storage key may be stored on client device 101.

[0040] In one or more exemplary embodiments, application 102 may form a secure memory block in memory 104 without communicating with processor 120 or server 110, as described with reference to label 164. Once application 102 has formed a secure memory block in memory 104, application 102 may encrypt the secure memory block using a data storage key received from or generated based on data received from the near-field transceiver 105 (e.g., a user token 107 which may contain a user key, or other data which may contain a second user key). Generating a data storage key based on data received from the near-field transceiver 105 may involve using counters or other data which are synchronously obtained or otherwise maintained from client device 101 and the near-field transceiver 105. For example, the data storage key may be generated by encrypting a counter value or other data value with a user key. Before encrypting the secure memory block, application 102 may store personal user data in the newly formed secure memory block. One or more steps, including forming a secure memory block in memory 104 and encrypting the secure memory block, may respond to a tap operation between the short-range transceiver 105 and the client device 101.

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

[0042] Figure 1C illustrates a sequence of data access control according to one or more exemplary embodiments, which may include a user request for a data access key to access or decrypt a pre-formed secure memory block within a client device as described herein. Figure 1C refers to similar components of system 100 in the exemplary embodiments described in Figures 1A and 1B.

[0043] Label 170 indicates that a user may sign in or log in to an application 102 running on a client device 101. Signing in or logging in may be achieved, for example, by entering a username and password, or by scanning biometric information such as a fingerprint scan, retinal scan, or facial scan. In some exemplary embodiments, the application 102 may display instructions on the client device 101 prompting the user to begin tapping between the near-field transceiver 105 and the client device 101.

[0044] Label 172 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.

[0045] Label 174 indicates that application 102 may communicate with near-field transceiver 105 (through client device 101) (for example, after near-field transceiver 105 is brought close to client device 101). Communication between application 102 and near-field transceiver 105 may require the near-field transceiver 105 (e.g., a contactless card) to be close enough to the card reader (not shown) of client device 101 to enable NFC data transfer between application 102 and near-field transceiver 105, and may occur in conjunction with (or in response to) a tap operation between near-field transceiver 105 and client device 101 (e.g., a tap operation on label 152). Communication may include the exchange of data or commands to establish a communication session between application 102 and near-field transceiver 105. Data exchange may include the transfer or exchange of one or more keys, which may be pre-existing keys or generated as session keys. In some exemplary embodiments, communication may occur when the near-field transceiver 105 enters the near-field communication field of the client device 101 before a tap operation between the near-field transceiver 105 and the client device 101.

[0046] On label 176, the near-field 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 user token 107 to the application 102 may occur in conjunction with (or in response to) a tap operation between the near-field transceiver 105 and the client device 101 (e.g., a tap operation on label 172). In some exemplary embodiments, the transmission of the user token 107 to the application 102 may occur when the near-field transceiver 105 enters the near-field communication field of the client device 101 prior to a tap operation between the near-field transceiver 105 and the client device 101.

[0047] In label 178, application 102 may send a user token to server 110 along with a request for a data access key. This may be done in response to a tap operation between the near-field transceiver 105 and the client device 101 (e.g., a tap operation in label 172). The data access key allows the user to decrypt a secure memory block in the client device 101 (a pre-formed and encrypted secure memory block using the techniques described herein) and to store, read, update, or otherwise access personal user data in the secure memory block.

[0048] Label 179 indicates that processor 120 may receive requests for a user token and a data access key (for example, through server 110). Processor 120 may use the user token to verify the user's identity. In some exemplary embodiments, user verification may be performed by using the user identifier in the token to retrieve information in database 130. In some exemplary embodiments, label 180 indicates that if the user token contains a key associated with the user, processor 120 may use the user key to authenticate the user. Based on user verification (and thus the verification being authenticated), processor 120 may determine whether the user is authorized to access a secure memory block in memory 104 of client device 101 and to receive a data access key used to decrypt and access said memory block.

[0049] Label 182 indicates that the processor 120 may send a data access key to the client device 101. As described above, the processor 120 may verify whether the user is authorized to access a secure memory block in the memory 104 of the client device 101 and to receive a data access key. The data access key may be stored in the database 130 or generated based on a user key. Generating a data access key based on a user key may involve using counters or other data that are synchronously obtained from the processor 120, the client device 101 and / or the near-field transceiver 105, or otherwise maintained. For example, the data access key may be generated by encrypting a counter value or other data value with the user key. The user key may be stored in the database 130 or contained in the user token 107. In one or more exemplary embodiments, application 102 may generate a new access key based on a combination of a received data access key and data received from the near-field transceiver 105 (for example, a user token 107 which may contain a user key, or other data which may contain a second user key), and may use the newly generated access key to decrypt a secure memory block.

[0050] In one exemplary embodiment, the processor 120 may instead send a denial notice (not shown) to the client device 101 indicating that the user is not authorized to access a secure memory block in the memory 104 of the client device 101 and is not authorized to receive a data access key.

[0051] Label 184 indicates that application 102 may enable authorized access to a secure memory block by decrypting the secure memory block using a data access key (which may be received or newly generated). In an exemplary embodiment, the data access key may be stored in client device 101.

[0052] Application 102 may store, read, update, or otherwise access personal user data stored in a secure memory block. In one or more exemplary embodiments, Application 102 may display the stored or updated personal user data on the client device 101. In one or more exemplary embodiments, Application 102 may provide a second application (not shown) running on the client device 101 with access to the stored or updated personal user data. In one or more exemplary embodiments, access to the secure memory block (whether by Application 102 or the second application) may be restricted to a specific time period, which may include a predetermined period.

[0053] In one or more exemplary embodiments, application 102 may re-encrypt secure memory blocks using a data storage key, a data access key, or another key generated from one or more of the data storage key, data access key, and user key. Re-encryption of secure memory blocks may be performed automatically, for example, after a predetermined period of time has elapsed, or in response to a user command.

[0054] In one or more exemplary embodiments, application 102 may decrypt a secure memory block using a data access key received from or generated based on data received from the near-field transceiver 105 (e.g., a user token 107 which may contain a user key, or other data which may contain a second user key) without communicating with the processor 120 or server 110. Generating a data access key based on data received from the near-field transceiver 105 may involve using counters or other data that are synchronously obtained or otherwise maintained from the client device 101 and the near-field transceiver 105. For example, a data access key may be generated by encrypting a counter value or other data value with a user key. One or more of the steps involved in receiving or generating a data access key and decrypting a secure memory block may respond to a tap operation between the near-field transceiver 105 and the client device 101.

[0055] In one or more exemplary embodiments, a second application (not shown) running on client device 101 (or another device communicating with client device 101) may include functions for accessing secure memory blocks as described herein. For example, program code or application programming interface available through a software development kit may be incorporated into the second application, and the program code may include functions necessary for obtaining data access keys, storing, reading, updating, or other access to personal user data stored in secure memory blocks, as described with reference to application 102.

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

[0057] Figure 2 shows the 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 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 near-field communication interface 203, a network interface 204, and memory 205. The application 201 may include a software application or executable program code that runs on the processor 202 and may be configured to run any of the features described herein for any client device such as the client device 101, and / or any of the features described herein with reference to the application 102. The application 201 may be configured to send and / or receive data with other devices through the client device 101, for example, through the near-field communication interface 203 and / or the network interface 204. For example, the application 201 may be configured to make one or more requests, such as a near-field data exchange request, to a near-field transceiver (e.g., a contactless card). Application 201 may also be configured to provide a user interface to the user of the client device through a display (not shown). Application 201 may be stored in the memory of the client device 200. The memory may be part of memory 205 or separate from memory 205. The memory may include read-only memory, write-once read-multiple memory, and / or read / write memory, such as RAM, ROM, and EEPROM.

[0058] The processor 202 may include one or more processing devices such as a microprocessor, RISC processor, or ASIC, and may further include associated processing circuits. The processor 202 may include, or be connected to, memory for storing executable instructions and / or data deemed necessary or appropriate for controlling, executing, or interacting with other features of the client device 200, including application 201. The processor 202 (including any associated processing circuits) may include additional components, such as processors, memory, error and parity / CRC checkers, data encoders, collision avoidance algorithms, controllers, commands, decoders, security primitives, and tamper-proof hardware, as deemed necessary to perform the functions described herein.

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

[0060] The network interface 204 may include wired or wireless data communication functions. These functions may support data communication over 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 transmitting 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).

[0061] Memory 205 may include read-only memory, write-once read-multiple memory, and / or read / write memory, such as RAM, ROM, and EEPROM. Client device 200 may include one or more of these memories. Read-only memory may be factory programmable as read-only or one-time programmable. One-time programmable functionality provides the opportunity to write once and then read multiple times. Write-once / read-multiple memory may be programmable after the memory chip leaves the factory. Once programmed, memory cannot be rewritten but can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times. Memory 205 may store one or more applications for execution by processor 202 and may also store data used by one or more applications that can be executed by processor 202.

[0062] A secure memory block 206 may be a block or partition of memory formed within memory 205, and / or may include a file established by the client device operating system. A secure memory block 206 may be formed within memory 205, for example, by forming a memory partition for a block of memory within memory 205, or by allocating a block of memory within memory 205, and may include forming, modifying, or using a file established by the client device operating system. In one or more exemplary embodiments, such a partitioned or allocated memory block may be contained within memory pre-allocated for use by application 201, and thereby maintained under the control of application 201. In one or more exemplary embodiments, such a partitioned or allocated memory block may be contained within memory pre-allocated for general use by one or more applications running on the client device 200.

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

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

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

[0066] The processor 301 may include one or more processing devices such as a microprocessor, RISC processor, or ASIC, and may further include associated processing circuits. The processor 301 may include, or be connected to, a memory for storing executable instructions and / or data deemed necessary or appropriate for controlling, executing, or interacting with other features of the short-range transceiver 300, including the applet 303. The processor 301 (including any associated processing circuits) may include additional components, such as processors, memory, error and parity / CRC checkers, data encoders, collision avoidance algorithms, controllers, commands, decoders, security primitives, and tamper-proof hardware, as deemed necessary to perform the functions described herein.

[0067] Memory 302 may include read-only memory, write-once-read-multiple memory, and / or read / write memory, such as RAM, ROM, and EEPROM. Memory 302 may be configured to store one or more applets 303 and one or more tokens 304. Applet 303 may include one or more software applications configured to run on processor 301, such as a Java card applet that can run on a contactless card. However, it is understood that applet 303 is not limited to a Java card applet and 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 client devices, including requests from devices having a reader, such as a mobile device NFC reader. Applet 303 may be configured to read (or write) data, including tokens 304, from (or to) memory 302 and provide such data in response to requests.

[0068] Token 304 may include a unique alphanumeric identifier assigned to a user of the near-field transceiver 300, the identifier which can distinguish the user of the near-field transceiver 300 from other users of other near-field transceivers (e.g., 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 a near-field transceiver (e.g., a contactless card) associated with the customer's account. In some exemplary embodiments, token 304 may include a key unique to the user or customer to whom the near-field transceiver is associated.

[0069] The near-field communication interface 305 may support communication via a near-field wireless communication field such as NFC, RFID, or Bluetooth. The near-field communication interface 305 may also include one or more antennas (not shown) connected to the near-field communication interface 305 to provide connectivity to the near-field wireless communication field.

[0070] Figure 4 shows the interaction 400 between a client device 401 and a near-field transceiver 420 used in a data access control system according to one or more exemplary embodiments, including the embodiments described above with reference to Figure 1A-1B. The client device 401 may be a client device 101 associated with a user, as described above with reference to Figure 1A-1B. The user interface 402 may be generated by an application 102, as described above with reference to Figure 1A-1B. The near-field transceiver 420 may be a near-field transceiver 105, as described above with reference to Figure 1A-1B. When the near-field transceiver 420 enters the near-field communication field of the client device 401 (e.g., through a tap operation), the client device 401 can communicate with the near-field transceiver 420. The client device 401 may send data or commands to the near-field transceiver 420 through signal transmission 431. The client device 401 may receive data, including a token 422, from the near-field transceiver 420 through signal reception 432. Communication between client device 401 and short-range transceiver 420 may proceed as described above with reference to Figure 1B (for example, between client device 101 and short-range transceiver 105).

[0071] The user interface 402 may present a screen display on the client device 401 for a user data storage request 410, which may include fields 411 and 412. If necessary, the user may enter a username in field 411 and a password in field 412. In some exemplary embodiments, the user may perform a biometric scan, such as a fingerprint scan, retinal scan, or facial scan. The screen display may include an instruction 414 prompting the user to tap the near-field transceiver 420 (in the illustrated example, the near-field transceiver 420 may be a contactless card) to initiate a data storage key request to obtain the data storage key required to form the secure memory block described herein. The instruction 414 may be a push notification from the server 110 (as shown in Figures 1A and 1B-1C). In response to the tap operation, the client device 401 may send the data storage key request, along with a user token 422 (from the near-field transceiver 420), to the server 110.

[0072] Figure 5 shows an interaction 500 between a client device 501 and a near-field 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 and 1C. The client device 501 may be a client device 101 associated with a user, as described above with reference to Figures 1A and 1C. The user interface 502 may be generated by an application 102, as described above with reference to Figure 1C. The near-field transceiver 520 may be a near-field transceiver 105, as described above with reference to Figures 1A and 1C. When the near-field transceiver 520 enters the near-field communication field of the client device 501 (e.g., through a tap operation), the client device 501 can communicate with the near-field transceiver 520. The client device 501 may send data or commands to the near-field transceiver 520 through signal transmission 531. The client device 501 may receive data, including a token 522, from the near-field transceiver 520 through signal reception 532. Communication between client device 501 and short-range transceiver 520 may proceed as described above with reference to Figure 1C (for example, between client device 101 and short-range transceiver 105).

[0073] The user interface 502 may present a screen display on the client device 501 for a user data access request 510, which may include fields 511 and 512. If necessary, the user may enter a username in field 511 and a password in field 512. In some exemplary embodiments, the user may perform a biometric scan, such as a fingerprint scan, retinal scan, or facial scan. The screen display may include an instruction 514 prompting the user to tap the near-field transceiver 520 (in the illustrated example, the near-field transceiver 520 may be a contactless card) to initiate a data access key request to obtain the data access key required to access the secure memory block described herein. The instruction 514 may be a push notification from the server 110 (as shown in Figures 1A and 1B-1C). In response to the tap operation, the client device 501 may send a data access key request to the server 110, along with a user token 522 (from the near-field transceiver 520).

[0074] Figure 6A 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 figures and related descriptions. The data access control method 600 may be implemented by an application 102 running on a client device 101 associated with a user. A short-range transceiver 105 is associated with the user.

[0075] In block 610, application 102 may cause the client device 101 to display a user data storage request screen (for example, shown in Figure 4 and described above with reference to Figure 4). The user data storage request screen may include instructions for the client device 101 to tap the near-field transceiver 105 to initiate a data storage key request. As described above with reference to Figure 4, in the example shown in Figure 4, the near-field transceiver 420 (i.e., the near-field transceiver 105) may be a contactless card.

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

[0077] In block 614, a user token 107 may be received from the near-field transceiver 105. Receiving the user token 107 may be in response to a tap operation in block 612. 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.

[0078] In block 616, the user token 107 may be sent to the server 110 along with a data storage key request in order to obtain a data storage key for encrypting a secure memory block formed in the memory of the client device 101. The transmission of the user token 107 and the data storage key request to the server 110 may be in response to the tap operation in block 612.

[0079] In block 618, the data storage key may be received from server 110.

[0080] In block 620, a secure memory block may be formed in the memory of the client device 101, as described above.

[0081] In block 622, personal user data may be stored in a secure memory block. In some exemplary embodiments, personal user data may later be stored in a secure memory block.

[0082] In block 624, the data storage key may be used to encrypt a secure memory block, thereby protecting the secure memory block from unauthorized access.

[0083] Figure 6B is a flowchart illustrating a data access control method 601 according to one or more exemplary embodiments, referring to the components and features described above, including, but not limited to, the figures and related descriptions. The data access control method 601 may be implemented by an application 102 running on a client device 101 associated with a user. A short-range transceiver 105 is associated with the user.

[0084] In block 630, application 102 may cause the client device 101 to display a user data storage request screen (for example, shown in Figure 4 and described above with reference to Figure 4). The user data storage request screen may include instructions for the client device 101 to tap the near-field transceiver 105 to initiate a data storage key request. As described above with reference to Figure 4, in the example shown in Figure 4, the near-field transceiver 420 (i.e., the near-field transceiver 105) may be a contactless card.

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

[0086] In block 634, a user token 107 may be received from the near-field transceiver 105. Receiving the user token 107 may be in response to a tap operation in block 632. 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.

[0087] In block 636, it may be confirmed that the user has been granted permission to form a secure memory block in the memory of the client device 101 (and consequently, permission to obtain a data storage key). This permission may be based, for example, on the determined user identity from the user token 107.

[0088] In block 638, a data storage key may be received from the near-field transceiver 105, or generated based on data received from the near-field transceiver 105 (e.g., a user token 107 which may contain a user key, or other data which may contain a second user key). In one or more exemplary embodiments, a user key may function as a data storage key.

[0089] In block 640, a secure memory block may be formed in the memory of the client device 101, as described above.

[0090] In block 642, personal user data may be stored in a secure memory block. In some exemplary embodiments, personal user data may later be stored in a secure memory block.

[0091] In block 644, the data storage key may be used to encrypt a secure memory block, thereby protecting the secure memory block from unauthorized access.

[0092] Figure 6C is a flowchart illustrating a data access control method 602 according to one or more exemplary embodiments, referring to the components and features described above, including, but not limited to, the figures and related descriptions. The data access control method 602 may use a secure memory block pre-formed in the client device 101 according to one or more exemplary embodiments as described above. The data access control method 602 may be implemented by an application 102 running on the client device 101 associated with a user. A short-range transceiver 105 is associated with the user.

[0093] In block 650, application 102 may cause a user data access request screen (for example, shown in Figure 5 and described above with reference to Figure 5) to be displayed on the client device 101. The user data access request screen may include instructions for the client device 101 to tap the near-field transceiver 105 to initiate a data access key request. As described above with reference to Figure 5, in the example shown in Figure 5, the near-field transceiver 520 (i.e., the near-field transceiver 105) may be a contactless card.

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

[0095] In block 654, a user token 107 may be received from the near-field transceiver 105. Receiving the user token 107 may be in response to a tap operation in block 652. 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.

[0096] In block 656, the user token 107 may be sent to the server 110 along with a data access key request in order to obtain a key for decrypting a secure memory block formed in the memory of the client device 101. The transmission of the user token 107 and the data access key request to the server 110 may be in response to the tap operation in block 652.

[0097] In block 658, the data access key may be received from server 110.

[0098] In block 660, the data access key may be used to decrypt a secure memory block, thereby enabling authorized access to that secure memory block.

[0099] In block 662, personal user data is stored in a secure memory block, updated, and / or can be accessed from that secure memory block. Application 102 may display personal user data on the client device 101.

[0100] In block 664, secure memory blocks are re-encrypted to protect them from unauthorized access. A data storage key, a data access key, or another key generated from one or more of the data storage key, data access key, and user key may be used to re-encrypt the secure memory blocks. Re-encryption of secure memory blocks may be performed automatically, for example, after a predetermined period of time, or in response to a user command.

[0101] Figure 6D is a flowchart of a data access control method 603 according to one or more exemplary embodiments, referring to the components and features described above, including, but not limited to, the figures and related descriptions. The data access control method 603 may use a secure memory block pre-formed in the client device 101 according to one or more exemplary embodiments as described above. The data access control method 603 may be implemented by an application 102 running on the client device 101 associated with a user. A short-range transceiver 105 is associated with the user.

[0102] In block 670, application 102 may cause a user data access request screen (for example, shown in Figure 5 and described above with reference to Figure 5) to be displayed on the client device 101. The user data access request screen may include instructions for the client device 101 to tap the near-field transceiver 105 to initiate a data access key request. As described above with reference to Figure 5, in the example shown in Figure 5, the near-field transceiver 520 (i.e., the near-field transceiver 105) may be a contactless card.

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

[0104] In block 674, a user token 107 may be received from the near-field transceiver 105. Receiving the user token 107 may be in response to a tap operation in block 672. 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.

[0105] In block 676, it may be confirmed that the user has been granted permission to access a secure memory block in the memory of the client device 101 (and consequently, permission to obtain a data access key). This permission may be based, for example, on the determined user identity from the user token 107.

[0106] In block 678, a data access key may be received from the near-field transceiver 105, or may be generated based on data received from the near-field transceiver 105 (e.g., a user token 107 which may contain a user key, or other data which may contain a second user key). In one or more exemplary embodiments, the user key may function as a data access key.

[0107] In block 680, the data access key may be used to decrypt a secure memory block, thereby enabling authorized access to that secure memory block.

[0108] In block 682, personal user data is stored in a secure memory block, updated, and / or can be accessed from that secure memory block. Application 102 may display personal user data on the client device 101.

[0109] In block 684, secure memory blocks are re-encrypted to protect them from unauthorized access. A data storage key, a data access key, or another key generated from one or more of the data storage key, data access key, and user key may be used to re-encrypt the secure memory blocks. Re-encryption of secure memory blocks may be performed automatically, for example, after a predetermined period of time, or in response to a user command.

[0110] Figure 7A is a flowchart of a data access control method 700 according to one or more exemplary embodiments, referring to the components and features described above, 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 user through a server 110.

[0111] In block 710, a data storage key request may be received from the client device 101 associated with the user, along with a user token 107, requesting a data storage key to enable the formation and protection of secure memory blocks in the memory of the client device 101. The token 107 may include a user identifier. In some exemplary embodiments, the token 107 may include a user key associated with the user.

[0112] In block 712, the user's identity may be verified 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.

[0113] In block 714, the processor may verify that the user is authorized to form a secure memory block (and consequently, to retrieve the data storage key). Authorization may be based on the user's identity and may include retrieving information from database 130.

[0114] In block 716, a data storage key may be sent to the client device 101 associated with the user. As described above, the data storage key may be stored in the database 130 or generated based on the user key.

[0115] Figure 7B is a flowchart of a data access control method 701 according to one or more exemplary embodiments, referring to the components and features described above, including, but not limited to, the figures and related descriptions. Features described in Figure 7B may be added to the features mentioned in Figure 7A. The description of the blocks mentioned in Figure 7A will not be repeated here. As described above with reference to Figure 7A, the data access control method 701 may be performed by a processor 120 that communicates with a client device 101 associated with a user through a server 110.

[0116] In block 740, a data access key request may be received from the client device 101 associated with the user, along with a user token 107, requesting a data access key to enable access to a secure memory block in the memory of the client device 101. The token 107 may include a user identifier. In some exemplary embodiments, the token 107 may include a user key associated with the user.

[0117] In block 742, the user's identity may be verified 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.

[0118] In block 744, the processor may verify that the user is authorized to access a secure memory block (and consequently, to obtain a data access key). Authorization may be based on the user's identity and may include retrieving information from database 130.

[0119] In block 746, a data access key may be sent to the client device 101 associated with the user. As described above, the data access key may be stored in the database 130 or generated based on the user key.

[0120] The description of embodiments in this disclosure provides non-limiting representative examples that refer to reference numerals to illustrate features in detail, and teachings of different aspects of the invention. The described embodiments are recognized as being implementable individually or in combination with other embodiments from the description of embodiments. A person skilled in the art who examines the description of embodiments will be able to know and understand the different described aspects of the invention. The description of embodiments facilitates the understanding of the invention to the extent that other implementations that are not specifically covered but are included in the knowledge of a person skilled in the art who has read the description of embodiments will be understood to be consistent with applications of the invention.

[0121] Throughout this specification and the claims, the following terms have at least the meanings expressly associated herein, unless the context makes otherwise clear. The term “or” is intended to mean an inclusive “or.” Furthermore, the terms “a,” “an,” and “the” are intended to mean one or more unless otherwise specified or unless the context makes it clear that they are singular.

[0122] This description contains many specific details. However, it should be understood that implementations of the disclosed technology can be carried out 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. "Several examples," "other examples," "one example," "example," "various examples," "one embodiment," "embodiment," "several embodiments," "example embodiment," "various embodiments," "one implementation," "implementation," "example implementation," "various implementations," "several implementations," etc., mean that implementations of the disclosed technology described in this way may include certain functions, structures, or characteristics, but not all implementations require certain functions, structures, or characteristics. Furthermore, repeated use of the phrases "in one example," "in one embodiment," or "in one implementation" means that they may, but do not necessarily, refer to the same example, the same embodiment, or the same implementation.

[0123] Where used herein, unless otherwise specified, the use of ordinal adjectives such as "first," "second," "third," etc., to describe a common object merely indicates that different examples of similar objects are being referred to, and is not intended to imply that the objects described in this way must be in a given order, temporally, spatially, sequentially, or otherwise.

[0124] While specific implementations of the disclosed technology have been described in relation to what is currently considered the most practical and diverse implementation, it should be understood that the disclosed technology is not limited to the disclosed implementations, but rather is intended to encompass a variety of variations and equivalent configurations included in the attached claims. Certain terms are used here, but they are used only in a general and descriptive sense and not for limitation.

[0125] This written description discloses specific implementations of the disclosed technology, including the best mode, and uses examples to enable a person skilled in the art to implement specific implementations of the disclosed technology, including any manufacture or manufacture of a system and use and execution of the incorporated method. The patentable scope of a specific implementation of the disclosed technology is defined in the claims and may include other examples conceivable by a person skilled in the art. Such other examples are intended to be within the claims if they have structural elements that are not different from the literal wording of the claims, or if they include equivalent structural elements that are not substantially different from the literal wording of the claims.

Claims

1. A server configured to communicate with client devices associated with a user and The contactless card associated with the user, A client application including instructions for execution on the client device, A processor that communicates data with the aforementioned server, Equipped with, The aforementioned contactless card includes a communication interface, a processor, and memory. The memory stores the applet and the user token. The user token includes a user key, 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 user token and data storage key is sent to the server. The server receives the data storage key generated from the user key, A secure memory block is formed in the memory of the client device, The secure memory block is configured to encrypt using the data storage key, The aforementioned processor, The client device receives the request for the user token and the data storage key, The user's identity is verified based on the user token. The user is authorized to form the secure memory block within the client device, The data storage key is sent to the client device. It is configured in such a way. Data access control system.

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

3. The client application is further configured to store personal user data in the secure memory block. The data access control system according to claim 1.

4. The aforementioned client application is In response to a tap operation between the contactless card and the client device, a request for the user token and data access key is sent to the server. The server receives the data access key, The secure memory block is decrypted using the aforementioned data access key. It is further configured in this way, The aforementioned processor, The client device receives the user token and the data access key request, The user's identity is verified based on the user token. The user is authorized to access the secure memory block in the client device. The data access key is transmitted to the client device. It is further constructed in such a way. The data access control system according to claim 3.

5. The user token includes a user key, The aforementioned data access key is generated from the user key. The data access control system according to claim 4.

6. The processor is further configured to authenticate the user based on the user key. The data access control system according to claim 5.

7. The client application is further configured to display the personal user data on the client device. The data access control system according to claim 4.

8. The client application is further configured to allow a second application on the client device to access the personal user data. The data access control system according to claim 4.

9. The user token includes a user key, 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. The user is authorized to access the secure memory block in the client device. A data access key is generated based on the aforementioned user key. The secure memory block is decrypted using the aforementioned data access key. It is further constructed in such a way. The data access control system according to claim 3.

10. The client application is further configured to display the personal user data on the client device. The data access control system according to claim 9.

11. The client application is further configured to allow a second application on the client device to access the personal user data. The data access control system according to claim 9.

12. A method for controlling data access, The method includes providing a contactless card including a communication interface, a processor, and memory. The memory stores the applet and the user token. The user token includes a user key, The communication interface is configured to support at least one of the following: short-range wireless communication, Bluetooth®, and Wi-Fi®. The aforementioned contactless card is associated with the user. The method includes providing a client application that includes instructions for execution on a client device associated with the user, The client device has an encrypted, secure memory block for storing personal user data. 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 user token and data access key is sent to the server. The data access key is received from the server, where the data access key is generated based on the user key. The system is configured to decrypt the secure memory block using the data access key, The aforementioned method, Receiving the user token and the data access key request from the client device, To verify the identity of the user based on the user token, Confirm that the user is authorized to access the secure memory block within the client device, and To transmit the data access key to the client device, including, method.

13. Further including authenticating the user based on the user key, The method according to claim 12.

14. The client application is further configured to display the personal user data on the client device. The method according to claim 12.

15. The client application is further configured to allow a second application on the client device to access the personal user data. The method according to claim 12.

16. Decryption of the secure memory block using the data access key includes combining the data access key with the data received from the contactless card to generate a new key used for the decryption. The method according to claim 12.

17. A non-temporary machine-readable medium storing an application containing program code for execution on a client device, The aforementioned client device is associated with the user, The client device is configured to communicate with the contactless card associated with the user via a near-field communication field. The aforementioned contactless card includes a memory that stores a user token, which includes a user key. When the aforementioned application is executed, 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 user token and data storage key is sent to the server. Receiving the data storage key generated from the user key from the server, To form a secure memory block within the memory of the client device, Storing personal user data in the aforementioned secure memory block, and, Encrypting the secure memory block using the aforementioned data storage key, Configured to perform a procedure that includes, A non-temporary machine-readable medium.

18. The user token includes a user key, When the aforementioned application is executed, Receiving the user token from the contactless card in response to a tap operation between the contactless card and the client device; Confirm that the user is permitted to access the secure memory block in the client device; To generate a data access key based on the aforementioned user key; Decrypting the secure memory block using the aforementioned data access key; and, Providing the personal user data for display on the client device; Further configured to perform the procedure including, A non-temporary machine-readable medium according to claim 17.

19. The aforementioned communication interface is configured to support short-range wireless communication. The data access control system according to claim 1.

20. The user token further includes a user identifier. The method according to claim 12.

Images