Patent Description:
A typical user has multiple different accounts with one or more entities. When a user creates an account, the user will generally provide a certain amount of personal, identifying information regarding the user, as well as information for account access such as a username and password. Each entity may have, for example, different user data retention policies, different use policies, and different user data sharing policies. The policies of using user-information may further change without any notification to the user. In addition, the possessor of the user information may also change through a merger or buy-out of one entity by another, many times without any notice to the user.

Account access will often rely on log-in credentials (e.g., username and password) to confirm a cardholder's identity. However, if the log-in credentials are compromised, another person could have access to the user's account. In addition, the more entities or individuals that a user shares their personal information with, the greater the risk of the user's information being stolen by a breach at one of the entities. Further, a user may only desire to share certain pieces of personal information with an entity or individual for limited purposes or limited in time.

Thus, it may be beneficial to provide exemplary systems and methods which allow users to control the use of user information to overcome at least some of the deficiencies described herein.

<CIT> discloses a method including: receiving a first request from a first user device to access a first resource that includes data for a second user account for which access to the data is restricted to authorized users, the first request including an authorization token and associated with a first user identifier that identifies a first user; determining that the first user identifier does not identify an authorized user and in response: determining that the first user identifier identifies an authorized user based on the authorization token, and provide the first resource to the first user device; receiving a second request for access to data to the second user account, the second request associated with the first user identifier; and based on the first user identifier being determined to identify authorized user, providing access to the data to the second user account in response to the second request.

<CIT> discloses systems and methods for cryptographic authentication of contactless cards.

<CIT> discloses techniques to contain lateral movement of attackers through just-in-time (JIT) provisioned accounts comprising an account management component to receive a request from a first account via a client device for a second account to access a server device in a set of server devices, an account authorization component to authorize the request for the second account based at least partially on account information associated with the first account, an account provisioning component to provision the second account to enable a client to access the server device, and an account notification component to provide account information associated with the second account to a client via the client device.

Aspects of the disclosed technology include systems and methods for controlling data access through the interaction of a contactless card, with a client device. Data access control is provided in the context of account information, including handling requests to link a first account with a second account, via the interaction of a contactless card, with a client device such that disclosure of certain account identifier information, or account login information, need not be disclosed to individuals or entities requesting access to account data of another individual or entity.

Embodiments of the present disclosure provide a data access control system, comprising: a database storing information for a plurality of accounts comprising, for a first account associated with a first account holder, a first account identifier and first account data, and, for a second account associated with a second account holder, a second account identifier; a server configured to communicate over a network with a plurality of client devices, including a first client device associated with the first account holder and a second client device associated with the second account holder; a contactless card comprising a communications interface, a processor, and a memory, the memory storing an applet and a token, wherein the contactless card is associated with the first account holder; a client application comprising instructions for execution on the first client device and the second client device, the client application configured to: when executed on the second client device: in response to a tap action between the contactless card and the second client device: receive the token from the contactless card, and transmit to the server the token and an account link request to link the first account with the second account; and receive from the server an account link confirmation message including instructions for access to the first account data; and, when executed on the first client device: in response to a link approval request from the server to approve the account link request, transmit to the server a link approval message approving the account link request; and, a processor in data communication with the server and the database, the processor configured to: receive from the second client device the token and the account link request; identify the first account based on the token; transmit to the first client device the link approval request to approve the account link request; receive from the first client device the link approval message approving the account link request; and transmit to the second client device the account link confirmation message including instructions for access to the first account data.

Embodiments of the present disclosure provide a method for controlling data access, comprising: establishing a database storing information for a plurality of accounts comprising, for a first account associated with a first account holder, a first account identifier, first account data and data control parameters, and, for a second account associated with a second account holder, a second account identifier; receiving, by a processor, from a client device of the second account holder, via a network, an account link request to link the first account with the second account, the account link request generated in response to a tap action between a contactless card and the second account holder client device, the account link request accompanied by a token stored on the contactless card, wherein the contactless card is associated with the first account holder; identifying, by the processor, the first account based on the token; transmitting, by the processor, to a client device of the first account holder, via the network, a link approval request to approve the account link request; receiving, by the processor, from the first account holder client device, via the network, a link approval message, the link approval message generated in response to an indication by the first account holder approving the account link request; and transmitting , by the processor, to the second account holder client device, via the network, an account link confirmation message, the account link confirmation message confirming approval of the account link request and providing instructions for access to the first account data.

Further features of the disclosed design, and the advantages offered thereby, are explained in greater detail hereinafter with reference to specific example embodiments described below and illustrated in the accompanying drawings.

The following description of embodiments provides non-limiting representative examples referencing numerals to particularly describe features and teachings of different aspects of the invention. The embodiments described should be recognized as capable of implementation separately, or in combination, with other embodiments from the description of the embodiments. A person of ordinary skill in the art reviewing the description of embodiments should be able to learn and understand the different described aspects of the invention. The description of embodiments should facilitate understanding of the invention to such an extent that other implementations, not specifically covered but within the knowledge of a person of skill in the art having read the description of embodiments, would be understood to be consistent with an application of the invention.

Exemplary embodiments of the disclosed systems and methods provide for controlling data access through the interaction of a short-range transceiver, such as a contactless card, with a client device. Data access control may be provided in the context of controlling access to account information. Requests to link a first account with a second account may be handled via the interaction of a short-range transceiver, such as a contactless card, with a client device such that disclosure of certain account identifier information, or account login information, need not be disclosed to individuals or entities requesting access to account data of another individual or entity. Benefits of the disclosed technology may include improved data security for account information, improved fraud prevention, and improved user experience.

<FIG> shows a diagram illustrating a data access control system <NUM> according to one or more example embodiments. As discussed further below, system <NUM> may include client device <NUM>, client device <NUM>, short-range transceiver <NUM>, server <NUM>, processor <NUM> and database <NUM>. Client device <NUM> and client device <NUM> may communicate with server <NUM> via network <NUM>. Although <FIG> illustrates certain components connected in certain ways, system <NUM> may include additional or multiple components connected in various ways.

System <NUM> may include one or more client devices, such as client device <NUM> and/or client device <NUM>, which may each be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to a computer device, or communications device including, e.g., a server, a network appliance, a personal computer, a workstation, a phone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other device. Each of client devices <NUM> and <NUM> also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device. Additional features that may be included in a client device, such as client device <NUM> and/or client device <NUM>, are further described below with reference to <FIG>.

System <NUM> may include one or more short-range transceivers, such as short-range transceiver <NUM>. Short-range transceiver <NUM> may be in wireless communication with a client device, such as client device <NUM> and/or client device <NUM>, within a short-range communications field such as, for example, near field communication (NFC). Short-range transceiver <NUM> may include, for example, a contactless card, a smart card, or may include a device with a varying form factor such as a fob, pendant or other device configured to communicate within a short-range communications field. In other embodiments, the short-range transceiver <NUM> may be the same or similar as the client devices <NUM>, <NUM>. Additional features that may be included in a short-range transceiver, such as such as short-range transceiver <NUM>, are further described below with reference to <FIG>.

System <NUM> may include one or more servers <NUM>. In some example embodiments, server <NUM> may include one or more processors (such as, e.g., a microprocessor) which are coupled to memory. Server <NUM> may be configured as a central system, server or platform to control and call various data at different times to execute a plurality of workflow actions. Server <NUM> may be a dedicated server computer, such as bladed servers, or may be personal computers, laptop computers, notebook computers, palm top computers, network computers, mobile devices, or any processor-controlled device capable of supporting the system <NUM>.

Server <NUM> may be configured for data communication (such as, e.g., via a connection) with one or more processors, such as processor <NUM>. In some example embodiments, server <NUM> may incorporate processor <NUM>. In some example embodiments, server <NUM> may be physically separate and/or remote from processor <NUM>. Processor <NUM> may be configured to serve as a back-end processor. Processor <NUM> may be configured for data communication (such as, e.g., via a connection) with database <NUM> and/or server <NUM>. Processor <NUM> may include one or more processing devices such as a microprocessor, RISC processor, ASIC, etc., along with associated processing circuitry. Processor <NUM> may include, or be connected to, memory storing executable instructions and/or data. Processor <NUM> may communicate, send or receive messages, requests, notifications, data, etc. to/from other devices, such as client devices <NUM> and/or <NUM>, via server <NUM>.

Server <NUM> may be configured for data communication (such as, e.g., via a connection) with one or more databases, such as database <NUM>. Database <NUM> may be a relational or non-relational database, or a combination of more than one database. In some example embodiments, server <NUM> may incorporate database <NUM>. In some example embodiments, database <NUM> may be physically separate and/or remote from server <NUM>, located in another server, on a cloud-based platform, or in any storage device that is in data communication with server <NUM>.

Connections between server <NUM>, processor <NUM> and database <NUM> may be made via any communications line, link or network, or combination thereof, wired and/or wireless, suitable for communicating between these components. Such network may include network <NUM> and/or one or more networks of same or similar type as those described herein with reference to network <NUM>. In some example embodiments, connections between server <NUM>, processor <NUM> and database <NUM> may include a corporate LAN.

Server <NUM> and/or database <NUM> may include user login credentials used to control access to user accounts. The login credentials may include, without limitation, user names, passwords, access codes, security questions, swipe patterns, image recognition, identification scans (e.g., driver's license scan and passport scan), device registrations, telephone numbers, email addresses, social media account access information, and biometric identification (e.g., voice recognition, fingerprint scans, retina scans, and facial scans).

Database <NUM> may contain data relating to one or more accounts. Accounts may be maintained by (or on behalf of) and/or relate to any one or more of a variety of entities, such as, for example (and without limitation) a bank, merchant, online retailer, service provider, merchandizer, manufacturer, social media provider, provider or promoter of sporting or entertainment events, or hotel chain. For example, database <NUM> may include, without limitation, account identification information (e.g., account number, account owner identification number, account owner name and contact information - any one or more of which may comprise an account identifier), account characteristics (e.g., type of account, funding and trading limitations, and restrictions on access and other activity), and may include data pertinent to the account, including financial (such as balance information, payment history, and transaction history), social and/or personal information. Data stored in database <NUM> may be stored in any suitable format, and may be encrypted and stored in a secure format to prevent unauthorized access. Any suitable algorithm/procedure may be used for data encryption and for authorized decryption.

Server <NUM> may be configured to communicate with one or more client devices, such as such as client device <NUM> and/or client device <NUM>, via one or more networks, such as network <NUM>. Network <NUM> may include one or more of a wireless network, a wired network or any combination of wireless network and wired network, and may be configured to connect client devices <NUM> and/or <NUM> to server <NUM>. For example, network <NUM> may include one or more of a fiber optics network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a Global System for Mobile Communication, a Personal Communication Service, a Personal Area Network, Wireless Application Protocol, Multimedia Messaging Service, Enhanced Messaging Service, Short Message Service, Time Division Multiplexing based systems, Code Division Multiple Access based systems, D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE <NUM>. 11b, <NUM>. <NUM>, <NUM>. 11n and <NUM>, Bluetooth, NFC, Radio Frequency Identification (RFID), Wi-Fi, and/or the like.

In addition, network <NUM> may include, without limitation, telephone lines, fiber optics, IEEE Ethernet <NUM>, a wide area network, a wireless personal area network, a LAN, or a global network such as the Internet. In addition, network <NUM> may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network <NUM> may further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. Network <NUM> may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network <NUM> may translate to or from other protocols to one or more protocols of network devices. Although network <NUM> is depicted as a single network, it should be appreciated that according to one or more example embodiments, network <NUM> may comprise a plurality of interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, corporate networks, such as credit card association networks, a LAN, and/or home networks.

In some example embodiments, server <NUM> may access records, including records in database <NUM>, to determine a method or methods for communicating with client device <NUM> and/or client device <NUM>. The communication method may include an actionable push notification with an application stored on client device <NUM> and/or client device <NUM>. Other communication methods may include a text message or an e-mail, or other messaging techniques appropriate in a network-based client/server configuration. Messages or requests by client devices <NUM> and/or <NUM> may be communicated to server <NUM> via an application on the client device, or may be sent by a text message or an e-mail, or other messaging techniques appropriate in a network-based client/server configuration. Communications originating with client device <NUM> or client device <NUM> may be sent to server <NUM> using the same communications method as communications originating with server <NUM>, or via a different communications method.

<FIG> shows a diagram illustrating a sequence for providing data access control according to one or more example embodiments, which may include a request to link two accounts, each account held by separate account holders. <FIG> references similar components of example embodiment system <NUM> as illustrated in <FIG>. Client device <NUM> may be associated with a first account holder. The first account holder may have an associated first account, which may include a first account identifier and first account data. Client device <NUM> may include application <NUM>, which may include instructions for execution by client device <NUM>. Client device <NUM> may include features further described below with reference to <FIG>. Application <NUM> may be configured to provide a user interface for the first account holder when using client device <NUM>. Application <NUM> may be configured to communicate, via client device <NUM>, with other client devices, with short-range transceiver <NUM>, and with server <NUM>. Application <NUM> may be configured to receive requests and send messages as described herein with reference to client device <NUM>. Account information, including account identifiers and account data, may be stored in database <NUM>.

Client device <NUM> may be associated with a second account holder. The second account holder may have an associated second account, which may include a second account identifier. Client device <NUM> may include application <NUM>, which may include instructions for execution by client device <NUM>. Client device <NUM> may include features further described below with reference to <FIG>. Application <NUM> may be configured to provide a user interface for the second account holder when using client device <NUM>. Application <NUM> may be configured to communicate, via client device <NUM>, with other client devices, with short-range transceiver <NUM>, and with server <NUM>. Application <NUM> may be configured to send requests and receive messages as described herein with reference to client device <NUM>.

Short-range transceiver <NUM> may be associated with the first account holder. Short-range transceiver <NUM> may include, for example, a contactless card, and may include features further described below with reference to <FIG>. Short-range transceiver <NUM> may have memory storing an applet <NUM> and/or a token <NUM>, token <NUM> being associated with the first account holder.

A token may be used to increase security through token authorization. Server <NUM> may send a validation request to client device <NUM> and/or <NUM>, receive responsive information from client device <NUM> and/or <NUM>, and if validated, send a validation token back to client device <NUM> and/or <NUM>. The validation token may be based on a pre-determined token, or may be a dynamic token based on an algorithm that can be secret and known only to server <NUM> and client device <NUM> and/or <NUM>; the algorithm may include live parameters independently verifiable by the participants, such as the temperature at a particular location or the time. The token may be used to verify the identity of the first account holder or the second account holder. The validation request and/or validation token may be based on token <NUM> stored on short-range transceiver <NUM>.

In some example embodiments, application <NUM> may display an instruction on client device <NUM> prompting the second account holder to initiate a tap action between short-range transceiver <NUM> and client device <NUM>. As used herein, a tap action may include tapping short-range transceiver <NUM> against client device <NUM> (or vice-versa). For example, if short-range transceiver <NUM> is a contactless card and client device <NUM> is a mobile device, the tap action may include tapping the contactless card on a screen or other portion of client device <NUM>. However, a tap action is not limited to a physical tap by short-range transceiver <NUM> against client device <NUM>, and may include other gestures, such as, e.g., a wave or other movement of short-range transceiver <NUM> in the vicinity of client device <NUM> (or vice-versa).

At label <NUM>, there may be a tap action between short-range transceiver <NUM> and client device <NUM>. The tap action may be in response to a prompt displayed on client device <NUM>.

At label <NUM>, application <NUM> may communicate (via client device <NUM>) with short-range transceiver <NUM> (e.g., after short-range transceiver <NUM> is brought near client device <NUM>). Communication between application <NUM> and short-range transceiver <NUM> may involve short-range transceiver <NUM> (such as, e.g., a contactless card) being sufficiently close to a card reader (not shown) of the client device <NUM> to enable NFC data transfer between application <NUM> and short-range transceiver <NUM>, and may occur in conjunction with (or response to) a tap action between short-range transceiver <NUM> and client device <NUM> (such as, e.g., the tap action at label <NUM>). The communication may include exchange of data or commands to establish a communication session between application <NUM> and short-range transceiver <NUM>. The exchange of data may include transfer or exchange of one or more keys, which may be preexisting keys or generated as session keys. In some example embodiments, the communication may occur upon entry of short-range transceiver <NUM> into a short-range communication field of client device <NUM> prior to a tap action between short-range transceiver <NUM> and client device <NUM>.

At label <NUM>, short-range transceiver <NUM> may send token <NUM> associated with the first account holder to application <NUM>. Token <NUM> may include the first account identifier, which may be unique to a specific user account. In an example embodiment, token <NUM> may include an identifier unique to the first account holder, but not to a specific account; in which case if the first account holder has more than one account, the second account holder would need to select the account to be linked. In some example embodiments, token <NUM> may include a key associated with the first account holder. In some example embodiments, the sending of token <NUM> to application <NUM> may be in conjunction with (or response to) a tap action between short-range transceiver <NUM> and client device <NUM> (such as, e.g., the tap action at label <NUM>). In some example embodiments, the sending of token <NUM> to application <NUM> may occur upon entry of short-range transceiver <NUM> into a short-range communication field of client device <NUM> prior to a tap action between short-range transceiver <NUM> and client device <NUM>.

At label <NUM>, application <NUM> may send token <NUM> to server <NUM>, along with an account link request to link the first account (associated with the first account holder) with the second account (associated with the second account holder). This may be carried out in response to a tap action between short-range transceiver <NUM> and client device <NUM> (such as, e.g., the tap action at label <NUM>).

At label <NUM>, processor <NUM> may receive (e.g., via server <NUM>) the token and the account link request. Processor <NUM> may use the token to identify the first account associated with the first account holder. In some example embodiments, identifying the first account may be carried out by using the first account identifier in the token to look up account information in database <NUM>. In some example embodiments, at label <NUM>, if the token includes the key associated with the first account holder, processor <NUM> may use the key in the token to authenticate the first account holder as the first account holder associated with short-range transceiver <NUM>.

At label <NUM>, processor <NUM> may send (e.g., via server <NUM>) a link approval request to client device <NUM>, requesting that the first account holder approve the account link request, by the second account holder, to link the first account with the second account. The link approval request may include, for example, the name of the second account holder, and any information or instructions required by the first account holder to consider the request. The link approval request may include a notice that the first account holder may approve or deny the request. The link approval request may be sent as a push notification to application <NUM> (via client device <NUM>). In some example embodiments, application <NUM> may display an instruction on client device <NUM> prompting the first account holder to initiate a tap action between short-range transceiver <NUM> and client device <NUM>.

At label <NUM>, there may be a tap action between short-range transceiver <NUM> and client device <NUM>. The tap action may be responsive to the link approval request (and/or to a prompt displayed on client device <NUM>), and may indicate approval by the first account holder of the account link request.

At label <NUM>, application <NUM> may send a link approval message to the server, indicating approval by the first account holder of the account link request. This may be carried out in response to a tap action between short-range transceiver <NUM> and client device <NUM> (such as, e.g., the tap action at label <NUM>). In an example embodiment, application <NUM> may instead send a denial message (not shown) to the server, indicating denial by the first account holder of the account link request.

At label <NUM>, processor <NUM> may send (e.g., via server <NUM>) a link confirmation message to client device <NUM>, confirming approval of the request to link the first account with the second account. The link confirmation message may be sent as a push notification to application <NUM> (via client device <NUM>). In some example embodiments, information for the first account and/or the second account in database <NUM> may be updated with the permission granted by the first account holder to link the first and second accounts.

In an example embodiment, processor <NUM> may instead send a denial notification (not shown) to client device <NUM>, indicating denial by the first account holder of the account link request.

At label <NUM>, processor <NUM> may send (e.g., via server <NUM>) to client device <NUM> instructions for obtaining access to first account data in the first account. The instructions for access to the first account data may be included with the link confirmation message (at label <NUM>), or may be sent as part of a separate communication, including a push notification to application <NUM>.

Processor <NUM> may retrieve the requested first account data from database <NUM> and transmit the data to client device <NUM>. Processor <NUM> may encrypt the requested first account data, prior to transmission to client device <NUM>, using any suitable encryption method, such as Triple DES, RSA public-key private-key encryption, asymmetric encryption, Blowfish encryption, Twofish encryption, Advanced Encryption Standard (AES), quantum key distribution, Honey Encryption, etc. In some embodiments, the requested first account data may already be encrypted as stored in database <NUM> prior to retrieval by processor <NUM>.

Upon receipt of the requested first account data, client device <NUM> may decrypt the information, if the information was encrypted prior to transmission by processor <NUM>. Client device <NUM> may receive a decryption key separate from the first communication of encrypted first account data. The encryption may allow for control of access to first account data according to data control parameters. For example, the first account data may be encrypted in a manner that requires a new key to be requested by client device <NUM> from processor <NUM> each time client device <NUM> desires to gain access to the first account data, such that the data would need to be decrypted for each access by client device <NUM>; this procedure would permit processor <NUM> to keep track of and ensure that the first account data is not accessed in a manner inconsistent with data control parameters.

In an example embodiment, the second account holder may login to the second account and, via data sharing on the backend, obtain access to first account data, in accordance with any data control parameters.

Application <NUM> executing on client device <NUM> may through the use of application programming interfaces (APIs), perform the steps of sending and receiving messages and requests with server <NUM>/processor <NUM>. Application <NUM> may be configured to receive, decrypt, and access the requested first account data. Through interaction with application <NUM>, processor <NUM> may monitor access of the requested first account data by client device <NUM>, including in accordance with data control parameters. For example, processor <NUM> may through interaction with application <NUM> determine the number of times client device <NUM> has obtained access to the requested first account data, or the period(s) of time such access occurred. In some embodiments, application <NUM> may be permitted to store the requested first account data on a time-limited, or limited number of uses, basis.

In an example embodiment, processor <NUM> may be configured to determine whether the first account is eligible to be linked with the second account. Eligibility for account linking may be based on, for example, the type of accounts involved (e.g., business accounts), or identity of the account holders (e.g., family members or members of the same business entity). Eligibility may also be based on whether the first account holder has previously approved or revoked approval of account linking, or whether requested access would violate data control parameters (discussed further below). Eligibility for account linking may, e.g., be indicated in a flag stored in database <NUM> or in memory of short-range transceiver <NUM>.

In one or more example embodiments, access by the second account holder to first account data may be limited in accordance with data control parameters. In an example embodiment, data control parameters may be stored in database <NUM> with the first account information. Application <NUM> may provide an interface for the first account holder to select the data control parameters stored in database <NUM>. The selected data control parameters may be stored in database <NUM> and may be applied to limit access by the second account holder to first account data. Application <NUM> may also transmit the selected data control parameters to short-range transceiver <NUM>. In an example embodiment, data control parameters may be stored in memory of short-range transceiver <NUM>. Data control parameters stored in memory of short-range transceiver <NUM> may be sent to application <NUM> and used by application <NUM> to limit access by the second account holder to first account data. Applet <NUM> may be configured to receive the data control parameters and store the data control parameters in memory of short-range transceiver <NUM>. Applet <NUM> may be further configured to transmit the data control parameters to client device <NUM>. In some example embodiments, the first account holder may select data control parameters at the time of approving the request to link accounts, and application <NUM> may transmit the selected data control parameters to server <NUM> along with the link approval message. The selected data control parameters may be stored in database <NUM> and may be applied to limit access by the second account holder to first account data.

In one or more example embodiments, data control parameters may be used to limit access by the second account holder to first account data in one or more ways. For example, the data control parameters may permit access only for a specific or limited period of time. As another example, the data control parameters may permit access to a single use by the second account holder. As another example, the data control parameters may permit access for an unlimited period of time, unless the first account holder revokes the approval of the request to link the first account with the second account. As another example, the data control parameters may permit access only to portions of first account data corresponding to a predefined category. As another example, the data control parameters may provide different access permissions based on the identity of the second account holder. As another example, the data control parameters may permit access only when short-range transceiver <NUM> is detected within range of a short-range communication field of client device <NUM>. In some example embodiments, each time the second account holder attempts to access first account data after account linking approval is obtained, processor <NUM> may check to determine whether such access is permitted based on data control parameters and any revocation by the first account holder.

In an example embodiment, application <NUM> may be launched in response to a tap action between short-range transceiver <NUM> and client device <NUM>. In an example embodiment, application <NUM> may be launched in response to a tap action between short-range transceiver <NUM> and client device <NUM>.

<FIG> illustrates components of a client device <NUM> used in a data access control system according to one or more example embodiments. In one or more example embodiments, client device <NUM> may be one or more of client devices <NUM> and/or <NUM>, described above with reference to <FIG> and <FIG>. Client device <NUM> may include one or more applications <NUM>, one or more processors <NUM>, a short-range communications interface <NUM>, and a network interface <NUM>. Application <NUM> may include a software application or executable program code to be executed on processor <NUM> and configured to carry out features described herein for any of the client devices, such as client devices <NUM> and/or <NUM>, and/or any of the features described herein with reference to application <NUM>. Application <NUM> may be configured, for example, to transmit and/or receive data with other devices via client device <NUM>, such as via short-range communications interface <NUM> and/or network interface <NUM>. For example, application <NUM> may be configured to initiate one or more requests, such as near field data exchange requests to a short-range transceiver (such as a contactless card). Application <NUM> may also be configured to provide a user interface via a display (not shown) for a user of the client device. Application <NUM> may be stored in memory in client device <NUM>; the memory may include a read-only memory, write-once read-multiple memory and/or read/write memory, e.g., RAM, ROM, and EEPROM.

Processor <NUM> may include one or more processing devices such as a microprocessor, RISC processor, ASIC, etc., and may include associated processing circuitry. Processor <NUM> may include, or be connected to, memory storing executable instructions and/or data, as may be necessary or appropriate to control, operate or interface with the other features of client device <NUM>, including application <NUM>. Processor <NUM> (including any associated processing circuitry) may contain additional components including processors, memories, error and parity/CRC checkers, data encoders, anticollision algorithms, controllers, command decoders, security primitives and tamperproofing hardware, as necessary to perform the functions described herein.

Short-range communications interface <NUM> may support communication via a short-range wireless communication field, such as NFC, RFID, or Bluetooth. Short-range communications interface <NUM> may include a reader, such as a mobile device NFC reader. Short-range communications interface <NUM> may be incorporated into network interface <NUM>, or may be provided as a separate interface.

Network interface <NUM> may include wired or wireless data communication capability. These capabilities may support data communication with a wired or wireless communication network, including the Internet, a cellular network, a wide area network, a local area network, a wireless personal area network, a wide body area network, any other wired or wireless network for transmitting and receiving a data signal, or any combination thereof. Such network may include, without limitation, telephone lines, fiber optics, IEEE Ethernet <NUM>, a wide area network, a local area network, a wireless personal area network, a wide body area network or a global network such as the Internet.

Client device <NUM> may also include a display (not shown). Such 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.

Client device <NUM> may also include one or more device inputs (not shown). Such inputs may include any device for entering information into the client device that is available and supported by the client device <NUM>, such as a touch-screen, keyboard, mouse, cursor-control device, touch-screen, microphone, digital camera, video recorder, or camcorder. The device inputs may be used to enter information and interact with the client device <NUM> and, by extension, with the systems described herein.

<FIG> illustrates components of a short-range transceiver <NUM> used in a data access control system according to one or more example embodiments. In one or more example embodiments, short-range transceiver <NUM> may be one or more of short-range transceiver <NUM>, described above with reference to <FIG> and <FIG>. Short-range transceiver <NUM> may include, for example, a contactless card, or may include a device with a varying form factor such as a fob, pendant or other device configured to communicate within a short-range communications field. Short-range transceiver <NUM> may include a processor <NUM>, memory <NUM>, and short-range communications interface <NUM>.

Processor <NUM> may include one or more processing devices such as a microprocessor, RISC processor, ASIC, etc., and may include associated processing circuitry. Processor <NUM> may include, or be connected to, memory storing executable instructions and/or data, as may be necessary or appropriate to control, operate or interface with the other features of short-range transceiver <NUM>, including applet <NUM>. Processor <NUM> (including any associated processing circuitry) may contain additional components including processors, memories, error and parity/CRC checkers, data encoders, anticollision algorithms, controllers, command decoders, security primitives and tamperproofing hardware, as necessary to perform the functions described herein.

Memory <NUM> may be a read-only memory, write-once read-multiple memory or read/write memory, e.g., RAM, ROM, and EEPROM. Memory <NUM> may be configured to store one or more applets <NUM>, and one or more tokens <NUM>. Applet <NUM> may comprise one or more software applications configured to execute on processor <NUM>, such as a Java Card applet that may be executable on a contactless card. However, it is understood that applet <NUM> is not limited to Java Card applets, and instead may be any software application operable on contactless cards or other devices having limited memory. Applet <NUM> 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 <NUM> may be configured to read (or write) data, including token <NUM>, from (or to) memory <NUM> and provide the data, including token <NUM>, in response to a request.

Token <NUM> may include a unique alphanumeric identifier assigned to a user of the short-range transceiver <NUM>, and the identifier may distinguish the user of the short-range transceiver <NUM> from other users of other short-range transceivers (such as other contactless card users). In some example embodiments, token <NUM> may identify both a customer and an account assigned to that customer and may further identify the short-range transceiver (such as a contactless card) associated with the customer's account. In some example embodiments, token <NUM> may include a key unique to the user or customer with which the short-range transceiver is associated.

Short-range communications interface <NUM> may support communication via a short-range wireless communication field, such as NFC, RFID, or Bluetooth. Short-range transceiver <NUM> may also include one or more antennas (not shown) connected to short-range communications interface <NUM> to provide connectivity with a short-range wireless communications field.

<FIG> is diagram illustrating the interaction <NUM> between a client device <NUM> and a short-range transceiver <NUM> used in a data access control system according to one or more example embodiments, including embodiments described above with reference to <FIG>. Client device <NUM> may be client device <NUM> described above with reference to <FIG> and <FIG>. Client device <NUM> may be associated with the second account holder. User interface <NUM> may be generated by application <NUM> described above with reference to <FIG>. Short-range transceiver <NUM> may be short-range transceiver <NUM> described above with reference to <FIG> and <FIG>. Upon entry of short-range transceiver <NUM> into a short-range communication field of client device <NUM> (such as, e.g., via a tap action), client device <NUM> may communicate with short-range transceiver <NUM>. Client device <NUM> may send data or commands to short-range transceiver <NUM> via transmit signal <NUM>, and may receive data from short-range transceiver <NUM>, including token <NUM>, via receive signal <NUM>. Communication between client device <NUM> and short-range transceiver <NUM> may proceed as described above with reference to <FIG> (e.g., client device <NUM> or <NUM> and short-range transceiver <NUM>).

User interface <NUM> may present on client device <NUM> a screen display for an account link request <NUM>, which may include field <NUM> and field <NUM>. If necessary, the second account holder may enter a username in field <NUM> and password in field <NUM>. The screen display may include an instruction <NUM> prompting the second account holder to tap short-range transceiver <NUM> (in the example shown, short-range transceiver <NUM> may be a contactless card) to initiate an account link request to link the first account with the second account. Instruction <NUM> may be a push notification from server <NUM> (shown in <FIG> and <FIG>). Client device <NUM> may transmit an account link request to server <NUM> (shown in <FIG> and <FIG>) in response to a tap action.

<FIG> is diagram illustrating the interaction <NUM> between a client device <NUM> and a short-range transceiver <NUM> used in a data access control system according to one or more example embodiments, including embodiments described above with reference to <FIG>. Client device <NUM> may be client device <NUM> described above with reference to <FIG> and <FIG>. Client device <NUM> may be associated with the first account holder. User interface <NUM> may be generated by application <NUM> described above with reference to <FIG>. Short-range transceiver <NUM> may be short-range transceiver <NUM> described above with reference to <FIG> and <FIG>. Upon entry of short-range transceiver <NUM> into a short-range communication field of client device <NUM> (such as, e.g., via a tap action), client device <NUM> may communicate with short-range transceiver <NUM>. Client device <NUM> may send data or commands to short-range transceiver <NUM> via transmit signal <NUM>, and may receive data from short-range transceiver <NUM>, including token <NUM>, via receive signal <NUM>. Communication between client device <NUM> and short-range transceiver <NUM> may proceed as described above with reference to <FIG> (e.g., client device <NUM> or <NUM> and short-range transceiver <NUM>).

User interface <NUM> may present on client device <NUM> a screen display for an account link request <NUM>, which may include field <NUM> and field <NUM>. If necessary, the first account holder may enter a username in field <NUM> and password in field <NUM>. The screen display may include an instruction <NUM> notifying the first account holder that the second account holder (named 2_Acc_Hldr as shown in the example) has requested to link the first account with the second account, and prompting the first account holder to tap short-range transceiver <NUM> (in the example shown, short-range transceiver <NUM> may be a contactless card) to approve the account link request to link the first account with the second account. Instruction <NUM> may result from a push notification from server <NUM> (shown in <FIG> and <FIG>). Client device <NUM> may transmit an account link approval message to server <NUM> in response to a tap action. In some example embodiments, user interface <NUM> may provide the first account holder the option to select data control parameters at the time of approving the request to link accounts. Client device <NUM> may transmit the selected data control parameters to server <NUM> along with the link approval message; the selected data control parameters may be stored and may be applied to limit access by the second account holder to first account data, as discussed above.

<FIG> is a flowchart illustrating a method of data access control <NUM> according to one or more example embodiments, with reference to components and features described above including but not limited to the figures and associated description. Data access control method <NUM> may be carried out by application <NUM> executing on client device <NUM> associated with the second account holder. Short-range transceiver <NUM> is associated with the first account holder.

At block <NUM>, application <NUM> may cause client device <NUM> to display an account link request screen (such as shown in, and described above with reference to, <FIG>). The account link request screen may include an instruction to tap short-range transceiver <NUM> with/against client device <NUM> to initiate the account link request. As described above with reference to <FIG>, short-range transceiver <NUM> (and, hence, short-range transceiver <NUM>) may be a contactless card.

At block <NUM>, a tap action may be detected between short-range transceiver <NUM> and client device <NUM>.

At block <NUM>, token <NUM> may be received from short-range transceiver <NUM>. Receiving token <NUM> may be in response to the tap action of block <NUM>. Token <NUM> may include the first account identifier. In some example embodiments, token <NUM> may include a key associated with the first account holder.

At block <NUM>, token <NUM> may be transmitted to server <NUM> along with an account link request to link the first account with the second account. Transmission of token <NUM> and the account link request to server <NUM> may be in response to the tap action of block <NUM>.

At block <NUM>, an account link confirmation message may be received from server <NUM> along with instructions for access to first account data. As discussed above, the instructions may be part of the account link confirmation message, or part of a separate message.

At block <NUM>, the second account holder may access the first account data according to the received instructions. As discussed above, in some example embodiments access to first account data may be only provided in accordance with data control parameters. In some example embodiments, the data control parameters are stored in database <NUM> with the first account information, and data access is limited by processor <NUM>. In some example embodiments, the data control parameters are stored in memory of short-range transceiver <NUM> and are received by application <NUM> from short-range transceiver <NUM>. In some example embodiments, the first account data may be encrypted prior to receiving instructions for access to the first account data. Decryption of the encrypted first account data may be performed using the key associated with the first account holder.

<FIG> is a flowchart illustrating a method of data access control <NUM> according to one or more example embodiments, with reference to components and features described above including but not limited to the figures and associated description. Data access control method <NUM> may be carried out by application <NUM> executing on client device <NUM> associated with the first account holder. Short-range transceiver <NUM> is associated with the first account holder.

At block <NUM>, a link approval request may be received from server <NUM> seeking approval to link the first account with the second account.

At block <NUM>, application <NUM> may cause client device <NUM> to display an account link request screen (such as shown in, and described above with reference to, <FIG>). The account link request screen may include an instruction to tap short-range transceiver <NUM> with/against client device <NUM> to approve the account link request. As described above with reference to <FIG>, short-range transceiver <NUM> (and, hence, short-range transceiver <NUM>) may be a contactless card.

At block <NUM>, a tap action may be detected between short-range transceiver <NUM> and client device <NUM> indicating approval of the link approval request. The tap action may be responsive to the link approval request. In an example embodiment, approval may be indicated by other methods (such as, e.g. selecting a button).

At block <NUM>, token <NUM> may be received from short-range transceiver <NUM>. Token <NUM> may include the first account identifier. In some example embodiments, token <NUM> may include a key associated with the first account holder.

At block <NUM>, a link approval message may be sent to server <NUM> indicating approval of the request to link the first account with the second account.

<FIG> is a flowchart illustrating a method of data access control <NUM> according to one or more example embodiments, with reference to components and features described above including but not limited to the figures and associated description. Data access control method <NUM> may be carried out by processor <NUM> in communication with, via server <NUM>, client device <NUM> associated with the first account holder and/or client device <NUM> associated with the second account holder.

At block <NUM> an account link request may be received, along with token <NUM>, from client device <NUM> associated with the second account holder, requesting to link the first account with the second account. Token <NUM> may include the first account identifier. In some example embodiments, token <NUM> may include a key associated with the first account holder.

At block <NUM>, the sender of the account link request may be identified as the second account holder.

At block <NUM>, the first account may be identified based on received token <NUM>. In some example embodiments, when token <NUM> includes the key associated with the first account holder, the key associated with the first account holder may be used to authenticate the first account holder.

At block <NUM>, the processor may confirm that the first account is eligible to be linked with the second account. As discussed above with reference to <FIG>, eligibility for account linking may be based on, for example, the type of accounts involved (e.g., business accounts), or identity of the account holders (e.g., family members or members of the same business entity).

At block <NUM>, a link approval request may be sent to client device <NUM> associated with the first account holder seeking approval to link the first account with the second account.

At block <NUM>, a link approval message may be received from client device <NUM>, indicating approval of the request to link the first account with the second account.

At block <NUM>, an account link confirmation message may be sent to client device <NUM> associated with the second account holder, along with instructions for access to first account data. As discussed above, the instructions may be part of the account link confirmation message, or part of a separate message. In some example embodiments, access to first account data may be limited in accordance with data control parameters. In some example embodiments, processor <NUM> may encrypt the first account data prior to providing client device <NUM> instructions for access to the first account data. Encryption of the first account data may be performed using the key associated with the first account holder.

The description of embodiments in this disclosure provides non-limiting representative examples referencing figures and numerals to particularly describe features and teachings of different aspects of the disclosure. The embodiments described should be recognized as capable of implementation separately, or in combination, with other embodiments from the description of the embodiments. A person of ordinary skill in the art reviewing the description of embodiments should be able to learn and understand the different described aspects of the disclosure. The description of embodiments should facilitate understanding of the disclosure to such an extent that other implementations, not specifically covered but within the knowledge of a person of skill in the art having read the description of embodiments, would be understood to be consistent with an application of the disclosure.

Throughout the specification and the claims, the following terms take at least the meanings explicitly associated herein, unless the context clearly dictates otherwise. The term "or" is intended to mean an inclusive "or. " Further, the terms "a," "an," and "the" are intended to mean one or more unless specified otherwise or clear from the context to be directed to a singular form.

In this description, numerous specific details have been set forth. It is to be understood, however, that implementations of the disclosed technology may be practiced without these specific details. References to "some examples," "other examples," "one example," "an example," "various examples," "one embodiment," "an embodiment," "some embodiments," "example embodiment," "various embodiments," "one implementation," "an implementation," "example implementation," "various implementations," "some implementations," etc., indicate that the implementation(s) of the disclosed technology so described may include a particular feature, structure, or characteristic, but not every implementation necessarily includes the particular feature, structure, or characteristic. Further, 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, although it may.

As used herein, unless otherwise specified the use of the ordinal adjectives "first," "second," "third," etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

While certain implementations of the disclosed technology have been described in connection with what is presently considered to be the most practical and various implementations, it is to be understood that the disclosed technology is not to be limited to the disclosed implementations, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claim 1:
A data access control system, comprising:
a database storing information for a plurality of accounts comprising, for a first account associated with a first account holder, a first account identifier and first account data, and, for a second account associated with a second account holder, a second account identifier;
a server configured to communicate over a network with a plurality of client devices, including a first client device associated with the first account holder and a second client device associated with the second account holder;
a contactless card comprising a communications interface, a processor, and a memory, the memory storing an applet and a token, wherein the contactless card is associated with the first account holder;
a client application comprising instructions for execution on the first client device and the second client device, the client application configured to:
when executed on the second client device:
in response to a tap action between the contactless card and the second client device: receive the token from the contactless card, and transmit to the server the token and an account link request to link the first account with the second account;
and
receive from the server an account link confirmation message including instructions for access to the first account data;
and, when executed on the first client device:
in response to a link approval request from the server to approve the account link request, transmit to the server a link approval message approving the account link request;
and,
a processor in data communication with the server and the database, the processor configured to:
receive from the second client device the token and the account link request;
identify the first account based on the token;
transmit to the first client device the link approval request to approve the account link request;
receive from the first client device the link approval message approving the account link request; and
transmit to the second client device the account link confirmation message including instructions for access to the first account data.