Internet Data Usage Control System

Abstract

A method is described for seamlessly and automatically granting comprehensive, customized permissions for the use and transfer of Internet data between databases. The method uses a graphical language, such as JOSN‑LD, to integrate and utilize cryptographically signed Information Sharing Agreements (ISAs) between parties; when appropriate permissions are obtained, data is serialized for easy transfer between databases; and using controlled communications, granular data exchange can be automated between any number of parties on the Internet. Specifically, the method provides a way for users to control not only how their data is processed, but also to which business or businesses the data is transferred. Advertisements can then be served to users based on their preferences defined in a web or desktop application, which in turn applies to all relevant advertisers that publish to the domains visited by the user.

Description

Technical Field

[0001] The present invention relates to Internet data, and more particularly to licensing data exchange between parties on the Internet. Background Art

[0002] In our modern computer society, data sharing and transfer over networks is ubiquitous. Many individuals, groups, companies, organizations, and so on, often share not only digital data about themselves and their knowledge, but also access data and information about other parties and other things across closed networks, multiple networks, and the internet. Generally speaking, data portability refers to the ability for users to move their data from one data host to another. Such users can be individuals, companies, or other entities, and user data can be moved by the user themselves, or the user can grant permission to another party or entity to move or receive data or a currently updated copy of data, such as through a link. Such data hosts can be on a single network, across different networks, or even across the entire internet. This data can include self-created data and / or data about the user that has been created as a result of the user's activities or other information stored.

[0003] Data portability is important for users, vendors, and / or other parties who wish to obtain or exchange identity information or other related information, such as for potential purchases or other business transactions / exchanges. Of course, the unlimited availability and exchange of identity information or other personal information can have many drawbacks, and few people are willing to provide their personal data in an open and unrestricted manner. As is well known, there are almost always requirements, restrictions, or other protections associated with providing such personal data.

[0004] While the exchange of identity data or other personal data can generally be controlled or restricted when it occurs within a single controlled network or domain, providing data portability across multiple different servers, networks, or the internet can be problematic in many cases. For example, where a user may wish to obtain information about a particular product, they may provide their personal information or data to a single network of known suppliers or specialized websites for that type of product. In such cases, it is reasonable to expect that such information will be kept secure or protected by the reputable operator of that single website or network. However, repeatedly providing personal information or data can be complex and inefficient, for example, where a user may wish to provide and / or access data from multiple suppliers, networks, or sites.

[0005] In fact, it has become increasingly common to simply provide personal data on the internet, sometimes in an unsecured or unprotected manner. The internet has become a common network connecting many other types of digital networks and communications and data exchange devices. Increased internet usage has led to an increase in the number of applications and services running on it, the volume and value of transactions conducted, and the number and types of relationships that can be formed and maintained electronically. Each of these factors has in turn increased the importance of trust in online activities. While many known technologies and services have been developed to meet this need, each currently known technology and service often has shortcomings or limitations.

[0006] Currently, there is no automated way to control the use of data after it has been transmitted from one computing device to another, or from one database to another, using the internet or other networks. There is currently no automated way to verify the chain of custody or provenance for data received using the internet. Furthermore, there is currently no available protocol to reconcile and harmonize the rules of PSD2 and the GDPR.

[0007] Therefore, there is a need for a new system and method by which an entity's data can be controlled and its use can be securely and automatically restricted by the originator of the data based on preferences established by the entity. Furthermore, there is a need for a methodological system that utilizes cryptographically signed, automated agreements between participants, users, or entities to provide complete transparency regarding the use and transfer of data. Such a system provides a clear chain of custody for personal internet data and enables users to restrict certain forms of use and / or transfer / sharing. The system is preferably configured to simply define and describe data, facilitating its movement from one database to another. The system and method preferably utilize existing graphical languages ​​and existing PKI—public / private key pairs. Furthermore, such a system is preferably architected with separation of concerns, meaning that roles and points within the system are separated and interact with each other, rather than a walled garden where everything is housed in a single server or hub.

[0008] At least one previous attempt at creating a graph-based, user-controlled Internet data exchange system has failed. XDI aspired to provide embedded data access control through data graphs. However, this effort never found an effective solution to achieve this goal. XDI, as a graph language, was overdetermined, inefficient, and complex, and ultimately failed to work because it was not database-friendly. In order to facilitate transfer between databases, data could not be simply defined. XDI named "link contracts" but never functionally defined "link contracts" for developers in a meaningful way. In contrast to XDI, the present invention currently adopts JSON-LD as the underlying graph language and continues to define, create, and manage link contracts de facto. This allows the present invention to facilitate data usage control for users of the data they share, and to control how, where, and for what purpose the recipient can use the obtained data through user-defined and mutually agreed-upon permissions.

[0009] Furthermore, a system and protocol that is compatible and consistent with both GDPR and PSD2 is required. The spirit of the EU General Data Protection Regulation (GDPR) is to empower end users in their relationships with companies. The JLINC protocol truly places the data subject (data rights holder) at the center of every data event. As Lawrence Lessig noted, "code is law," and the JLINC protocol of our invention embodies the spirit of GDPR in its structure.

[0010] Another European regulation, Payment Services Directive 2 (PSD2), requires banks to simplify the process of financial services accessing customer banking services. This may seem contradictory to GDPR regulations, but it is believed that by placing data rights holders at the center of every data event, the system of the present invention makes it possible to meet the intent and text of both regulations. Summary of the Invention

[0011] This summary is provided to introduce some concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0012] The present invention is a method and system for establishing cryptographically signed agreements regarding data usage permissions and data ownership between computing devices on the Internet. The selection, signing, and exchange of agreements can also be automated. Furthermore, the present invention is a method that allows two or more entities to exchange data in a manner that allows each party to cryptographically sign the agreed terms using the Internet or other decentralized transmission network. The present invention uses a novel combination of existing standard protocols and methods to achieve the novel goal of creating a decentralized data usage permission control mechanism.

[0013] The present invention provides a system and method by which users can control not only which entities can access their data when one or more entities need it, but also what entities are permitted to do with the data after it has been transmitted or collected. The system involves the mutual signing of Information Sharing Agreements (ISAs), which are typically cryptographically signed. Contractual signing of ISAs is facilitated by a robust, automated system primarily implemented using graphical languages ​​such as JSON-LD. The agreements are legally binding and are configured to strongly encourage entities to honor them or face reputational damage and / or legal consequences.

[0014] The system is based on exchanging these ISAs, and software facilitates the system of the present invention to enable users to share data securely and confidently only after negotiating and deciding on permissions and rights to use the data.

[0015] Most peer-to-peer data sharing on the internet is implemented through some form of access control. Administrators control whether users can access or exchange data. Currently, when data is exchanged, such as metadata, personal information, browsing history, and similar user data, the possessor always has the upper hand in lawsuits. Once an entity possesses a user's internet data, they can do whatever they want with it according to the current typical terms of service. This is unfortunate for many ordinary internet users, who are unaware that their data is being captured, how it will be processed, or with whom it will be shared. Once an entity possesses a user's data, they can do whatever they want with it.

[0016] Today, graphical languages ​​like JSON-LD make it easier to move data between databases. The current invention adds cryptographically signed protocols for how data can be used and combined, and how such activities can be automated. This has the beneficial side effect of facilitating the movement of data between disparate sources, as it provides a common language and format for storing data. This system helps prove the actions taken on the data, as well as the date and time, thereby identifying the data's provenance. Furthermore, it allows for proof that both parties consented to the exchange. Ideally, the agreement should include an option for a user to disable any and all access to their data, with the other party obligated to comply. The user retains the ability to retroactively perform this action at any time and receive a signed confirmation from the other party that they have signed the agreement. Each party maintains a cryptographic hash of the agreement signed by all parties, and the signed hash is also recorded on any audit service or ledger designated by any party.

[0017] The system of the present invention embodies a secure, cryptographically signed, and automated data protection and exchange system that allows for agreements on what can be done with personal data exchanged on the internet and manages that data after it is exchanged. This also applies to other agreements, including any type of commercial contract or agreement on the internet. Currently, data exchange can be automatically managed by so-called "smart contracts," such as on Ethereum. These contracts are effectively black boxes with obfuscated code, so the results of the contract are only known when the code is executed. This leads to unintended commercial transactions and theft of value due to software bugs, errors, or fraud. If the code is not easily understandable, it can lead to data being shared without the user's knowledge and with unknown parties, or even worse. The purpose of the present invention is to break free from this ambiguous and obscure black box and provide users with direct and transparent ongoing control over their own contractual agreements and data.

[0018] A distributed system (non-centralized) is required, where user control is distributed across multiple distributed systems. Unlike blockchain, this invention provides a method for describing data using a graphical language, such as JSON-LD, which effectively defines and maps user data, thereby allowing data to be seamlessly transferred from one database to another.

[0019] In order to facilitate the permitted exchange of data between entities, the data must be described in a specific way so that it can be successfully moved from one database to another. Strictly speaking, in order to do this, the data must be serialized. Using a graphical language, data can be moved between databases. However, many entities do not permit this exchange without an agreement on what specific data can be exchanged and what to do with the data once it has been moved. Specific data within a database can be shared using a graphical language, but this remains a problem without an automated agreement on how the data will be handled once it has been acquired. The present invention provides a mechanism where the agreement itself is written in a graphical language and represented in a manner that is understandable to both computers and humans. The agreement can be signed using standard PKI, and once the agreement is transmitted, a link to the agreement is included in the audit record of the agreement, allowing both parties to display, and any third party to irrefutably confirm, that the agreement they each hold was also signed by the other party and is valid.

[0020] This invention, called JLINC, uses JSON-LD to express human- and machine-readable contracts that govern how this data is processed, with audit trails easily referenced and maintained within the transfer protocol itself, allowing entities to be held legally and reputationally accountable. Once companies (entities) have signed binding agreements, they can be held accountable both reputationally and legally, making them more likely to comply. Companies anywhere in the world that hold or process personal data for EU citizens will be fined up to 4% of their global turnover for non-compliance with GDPR.

[0021] Furthermore, the system of the present invention is suitable for three-party interactions and enables the data rights holder to maintain control over who has access to his / her data and what can be done with the data after it is obtained. The parties involved need not be limited to the data holder, financial institutions, and companies, but can also include devices, businesses, and Internet of Things (IoT) devices manufactured by the company. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings, which are incorporated herein and constitute a part of the specification, illustrate the invention and, together with the description, further serve to explain the principles of the invention and enable one skilled in the art to make and use the invention.

[0023] The present invention may be better understood with reference to the accompanying drawings, in which:

[0024] Figure 1 Depicted is a diagram of the components necessary to perform and use the method of the present invention as it relates to advertising.

[0025] Figure 2 A flow chart detailing the back-end processing implemented by the method of the present invention to facilitate seamless control of one's own Internet data with respect to advertising is shown.

[0026] Figure 3 Flowcharts for implementing and automating the use of the systems and methods of the present invention are specifically described.

[0027] Figure 4 A flow chart describing the method steps of the present invention is presented, which illustrates the processing of Internet data when querying and obtaining permission with respect to advertising.

[0028] Figure 5 A flow chart showing the interaction between three parties and the JLINC data service of the present invention is depicted. DETAILED DESCRIPTION

[0029] This specification discloses one or more embodiments that incorporate features of the present invention. The disclosed embodiments are merely examples of the present invention. The scope of the present invention is not limited to the disclosed embodiments.

[0030] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes that particular feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered that it is within the knowledge of those skilled in the art to implement that feature, structure, or characteristic in conjunction with other embodiments, regardless of whether explicitly described.

[0031] The present invention is a system and method by which data can be simply defined, mapped, and transferred between databases, with and only with permission. Permissions are negotiated through cryptographically signed, legally binding Information Sharing Agreements (ISAs). These agreements ensure that data is only used for the permitted purpose and is only transferred to other parties with permission. The system and method of the present invention uses JSON-LD, a data graph language, through which administrators can define data transfers and then add new layers through which owners can define and agree on permissions associated with the data.

[0032] For example, suppose a user is interested in purchasing a car. Therefore, the user discloses to the supplier through the ISA protocol, stating that they are interested in a car today. This data relates to the user's intention or interest in the vehicle. The user can later request the return or destruction of this data. This data is highly valuable to both the user and the supplier. They must comply with the user's interests, but they also have an interest in protecting their reputation. The supplier has little to gain by stealing this data. On the contrary, by respecting the agreement, the company's reputation is maintained and strengthened. Once the company fully adopts the new system, it also benefits from improved data quality and significantly reduces data maintenance costs, allowing more sales resources to be focused on important buyers rather than wasting energy on currently uninterested customers, such as those who recently purchased a car.

[0033] The systems and methods of the present invention can also be applied to the online advertising space, where a user can set his / her preferences through a network of publishers and be provided with advertisements tailored to their interests while remaining largely anonymous to advertisers and without being tracked as with traditional ad tracking.

[0034] The system of the present invention can be used for authenticated users of a website, or for users who are not (or not yet) users of the site. In this scenario, a non-logged-in user viewing a site can customize his / her advertising experience (and thereby qualify for the use of his / her anonymous user data), but wishes to view the site using advertising options without revealing their actual identity and without logging in. Strictly speaking, the present invention allows users to remain anonymous, but also allows users to have ads customized for them.

[0035] The system of the present invention is built using a data graph language, such as JSON-LD, an open software protocol widely used on the Internet. JSON-LD is a new graph language. The system, called JLINC, is represented using this graph language and adds cryptographically signed contracts and usage controls also written in this graph language. The system of the present invention is built in this way to split or separate the endpoints of the data exchange - that is, between two adversarial entities. This concept of "separation of concerns" is important to the essence of the present invention, which helps to expand the scale and scope of the system of the present invention to include not only the use / exchange of data, but also other online contracts and agreements. The audit trail of completed contracts is held by a fourth party, and a third party can provide standard contracts, or be a verified attribute provider (such as verification of age / location, etc.). This separation promoted by the present invention allows the establishment of a protocol foundation for this on the Internet.

[0036] It should be understood that the sharing of user data between entities is particularly relevant to advertising. Companies want to send advertisements to users who are interested in their products or services. Companies that are either co-branded or offer similar goods or services to other companies often want to exchange user data for mutual benefit. Therefore, much of the exchange of user data is related to advertising. The system of the present invention includes a robust web application and desktop application that interfaces with the websites of these entities to enable users to set broad permissions related to their interests and user data preferences, which are globally enforced for all entities equipped with the data access control system of the present invention (advertiser publishers to domains, and the domain companies themselves).

[0037] The following terms are defined below as they relate to the processes and uses of the systems and methods of the present invention:

[0038] Publisher—A content provider that hosts advertisements on websites within a domain that it controls.

[0039] User – an individual consumer of content and advertisements through a web browser.

[0040] Ad Networks – Providers of advertising content that contract with publishers to deliver advertisements to users.

[0041] Advertising preferences – A specific set of choices made by a user based on a set of options provided, which can include what type of advertising, in what interest areas, from whom, etc.

[0042] ADprefs—A JLINC-enabled domain where users can set and manage their advertising preferences.

[0043] like Figure 3As shown, the execution and automatic use process of the system and method of the present invention is preferably carried out as follows:

[0044] 1. The user uses the ADprefs button to reach the publisher's page. (100)

[0045] 2. When the user clicks the ADprefs button, the user arrives at the ADprefs page under the ADprefs domain. (110)

[0046] 3. The user is given the opportunity to select their advertising preferences (or accept the default) and is then returned to the publisher page. (120)

[0047] 4. Each time the user returns to the publisher page, it calls the API on the ad network or other ad source to serve ads using the ad preference mask. (130)

[0048] 5. If the user clicks the small ad preferences icon on the ad, they will be returned to the ADprefs page which will identify them. (140) This will work whether the user is from the original publisher they logged into, or any other publisher that hosts the ADprefs service. If they are a new publisher, they will be asked if they want to use the same ad preferences or create a set of publisher-specific ad preferences. (150)

[0049] 6. If a user logs in to a new publisher page for the first time, after the initial login, a login button will be displayed to the user, but when the user accesses the ADprefs page, the system will recognize them and store the random ID of the new publisher for them in the list of publisher IDs for that user. (160)

[0050] 7. The entire solution is device or browser specific. If the user wishes to associate multiple devices, they can do the following:

[0051] a. On the ADprefs page, on a device, the user creates a username and password. (170)

[0052] b. On the ADprefs page, on another device, they log in using the same username and password. The two users' preferences are now linked, and changing them on one device will update them on all linked devices. (175)

[0053] 8. Note that neither the ad networks nor Adpref collect any PII, so by definition, they do not share or sell any PII. User information is kept intact in the form of pseudonyms and random IDs. (180)

[0054] like Figure 4As shown, an example of an end user using the JLINC system and interface of the present invention to control his / her advertising permissions and data usage is shown as follows:

[0055] 1. The user logs into BobCo's website (using her username and password). (200)

[0056] 2. She clicks the "Control Your Data" button and is directed to the JLINC web application, where a key pair is created and registered for her, and then an ISA is negotiated between the user data server and BobCo's corporate server. (210)

[0057] 3. Additionally, when logging into the JLINC web application, the user's public key is saved in their browser's local storage. (220) It could also be saved in a cache, but the present invention does not require any cache, so the system does not require cache notification. Some browsers have default settings that provide the user with a permission box to confirm "OK" when a site wants to write to local storage for the first time.

[0058] 4. The user then logs in to CharlieCo's site and clicks his "Control Your Data" button. The JLINC web application reads local storage, sees that the user already has an account, and offers to add CharlieCo to her list of suppliers. (230)

[0059] 5. If the user agrees, the user data service records this choice and adds any additional data from CharlieCo to her profile. Any subsequent changes she makes to her profile or settings will be shared with BobCo and CharlieCo. (240)

[0060] 6. To subsequently return to her JLINC web application, the user still uses the “Control Your Data” button to log in through (any) one of her bound providers, but when she does so, the JLINC web application displays her relationships with all providers with whom she has agreed to be bound. (250)

[0061] 7. If her local storage is deleted, or she moves to a different device, when she logs in using the "Control Your Data" button, the backend user data service will recognize her as an existing user (via the code in the button) and restore the local storage key. (260)

[0062] 8. Whenever a user logs into her JLINC web application, she will see a notification containing a link. The notification states that for greater security and more functionality, the user can download and install the JLINC desktop or mobile application. (270)

[0063] 9. If she chooses the desktop application, the web application will trigger the user data server to generate a one-time use token that she can copy and paste into her new desktop application so that the user data server can identify her desktop application as her. (280)

[0064] 10. The desktop application then generates and registers a new locally stored master key pair for the user so that subsequent logins from the desktop application do not require a password or access to the vendor site. (290)

[0065] 11. If she installs the mobile application, the same process is used except that the user data server sends the token to her phone via Short Message Service (SMS). (300)

[0066] Security considerations

[0067] The web application of the present invention is only as secure as logging into BobCo and CharlieCo. This is exactly the same as the OAuth situation, i.e. if a user logs into all sites they use with Facebook™, and someone compromises the user's Facebook account, they have access to all of the user's data.

[0068] Unfortunately, SMS as a second authentication factor isn't as useful as it seems. Essentially, if a malicious actor can take over a user's phone account (which they can do), they have access to their SMS and likely their email. In this scenario, the present invention encourages the use of a Yubikey (or similar) for security. It's predicted that eventually everyone will have two Yubikeys, one easily accessible and the other hidden in case the first is lost or stolen.

[0069] Numerous variations are possible when using the system and method of the present invention. The previous description of the system primarily focused on voluntary personal data use cases. As previously mentioned, the system also includes use cases related to advertising. It is contemplated that the system of the present invention also provides a technical solution for complying with legal requirements for PSD2 open banking or Know Your Customer (KYC) rules, as well as GDPR requirements for control and portability of personal data. It is contemplated that, after legal processing of the system's functionality, the system of the present invention could be used with PSD2 APIs to enable GDPR-compliant uses by FinTech companies. Currently, PSD2 requires banks to open APIs, but when a user provides API access to a third-party FinTech company, the FinTech company currently cannot meet GDPR requirements for control of personal data. Through JLINC, FinTech providers can leverage this opportunity to expand into new services offered by PSD2 while also providing their customers with the granular control over their data necessary to comply with GDPR.

[0070] The system of the present invention can also be used for identity verification. For example, businesses that sell age-restricted goods and services often require proof of identity, such as age or location / zip code. In these domains, the system can be used to confirm that a user is indeed X years old, or physically present in a certain location, and data can then be shared based on this verified and legally obtained data.

[0071] Similarly, the system can be configured so that a third party can countersign with a key (e.g., similar to strict identity qualifications), including a statement that the user is over 18, or a statement that this is the child of the person authenticated by the token, all without knowing that person's identity. This allows the system to be used for sub-authentication spaces of a domain even for anonymous users.

[0072] It should be understood that the systems and methods of the present invention are not necessarily limited to use in advertising, but rather extend to any and all agreements made securely over the Internet by one or more parties. While JSON-LD is used as the graphical language, it should be understood that other graphical languages ​​may be used in place of JSON-LD.

[0073] For example, it should be appreciated that another key advantage of the current invention is that it provides a mechanism for delegated consent, wherein one party can consent to the use of data, and a second party, with the authorization of the first party, can share that data with additional third or fourth parties, etc. Conditions can be automated and set by the first party based on conditions that must be met by the additional parties, which can then be combined with other conditions in a logical or Boolean network. For example, continue to share this data with a car dealer that has a specific model or color in stock until a specified date, or until notification is sent that the first party has completed the purchase and is no longer in the market. After receiving instructions from the first party to delete the data, neither party may retain or retransmit the data.

[0074] This automated logical contract hierarchy is not limited to business-to-consumer use cases but can be applied to any commercial contract or supply chain. For example, a potential customer may place an open order to obtain information or actually execute an automated purchase based on the seller meeting specific terms such as product specifications, shipping dates, and financing terms. Commercial contracts can include transactions in pure financial instruments as well as commodities, derivatives, or other financial instruments or products.

[0075] It should be understood that the present invention can be used to establish alternative commodity-backed trade credits, where machine-readable contracts backed by one or more commodities are exchanged as trade credits. These credits serve as inflation-resistant units of exchange, where liquidity is provided by the ability to express the unit in a contract that is both human-readable and machine-readable and can be inspected by a judge (unlike other previous blockchain-based contracts).

[0076] Similarly, it should be understood that the present invention can be used to establish a mutually trusted trade credit system, where individuals and / or entities can provide credit to each other in the form of tradable IOUs. These tradable contracts constitute a method for creating liquidity between networks or communities. The ability to automate contract exchange and associate identities with attributes that can be represented as keys, which in turn are used to countersign the keys used to sign trade credit contracts, enables the present invention to provide the necessary missing infrastructure for a working community credit system.

[0077] Other versions include scenarios involving the Internet of Things (IoT) where a device creates data about and / or on behalf of a person or other entity, where the device signs the data before transmitting it and where use of the data is governed under an ISA between the person or entity using the device and the entity receiving the data.

[0078] In another class of embodiments, data may be exchanged between two or more business entities that are in a business relationship, where the contract governing the data is a complex legal document that has been negotiated between their respective governing databases to govern the exchange of specific data between the respective databases under specific terms and conditions on an automated basis that may be triggered by internal or external events and / or time period events.

[0079] In another class of embodiments, a data provenance chain created by a series of commercial parties, each of which signs an ISA associated with the movement and handling of goods through the supply chain, can be used to help manage the supply chain. Here, data provenance represents and verifies the physical chain of custody or provenance associated with the sequence of activities in the material supply chain. Cryptographically signed and verified documents, proving the provenance of raw materials or food inputs, thus demonstrate the integrity of the supply chain and may also add value to the final product for the end user or customer.

[0080] In another preferred embodiment class, the protocol and system of the present invention may be used for three-party interactions, as described below.

[0081] The JLINC protocol of the present invention enables a more secure and flexible solution that meets the requirements of PSD2 and GDPR. The following is a description of the JLINC protocol applied to three-party interaction:

[0082] The three participants involved in the implementation and system of the present invention, and their interactive cloud services, each of which is illustrated as follows:

[0083] · Banks, referred to as “BankCo”.

[0084] · The bank's agent, BankCo JLINC Solution Services.

[0085] Financial technology companies, known as “FinCos”.

[0086] Agent for financial technology companies, FinCo JLINC solution services.

[0087] The end user, the “data subject” in GDPR terms, or the “resource owner” in OAuth terms, is referred to as “Alice”.

[0088] Her agent is JLINC Data Services, accessed through her JLINC app.

[0089] The three-party interaction Figure 5 shown.

[0090] Alice can log in the system (JLINC) of the present invention initially by BankCo or FinCo. For this discussion example, it is assumed that she is logged in by BankCo, but no matter how Alice logs in the system, the process is the same.

[0091] BankCo initializes each existing or new customer on the JLINC Solution Service by sending the customer's account number or other ID that uniquely identifies the customer in the bank's records to the appropriate JLINC Solution Service API. The process then proceeds as follows:

[0092] 1. The JLINC Solution Service contacts Alice’s JLINC Data Service, which instantiates a key pair for the user (Alice) and returns the public key as a pseudonymous identifier to the JLINC Solution Service, along with a proposed information sharing agreement signed by Alice’s private key.

[0093] 2. The JLINC Solution Service records the public key, countersigns the information-sharing agreement, and returns it to Alice's JLINC Data Service. Both services can record this agreement through a third-party audit service. The JLINC Solution Service also creates a one-time random ID and uses it to generate a one-time-use URL that BankCo can provide to Alice to log her in.

[0094] 3. The JLINC solution sender can also return some data that the bank wants to share and / or jointly manage with Alice together with the signed information sharing agreement, and Alice can change, update or withdraw this data at any time according to the information sharing agreement.

[0095] 4. When Alice visits the URL, she is taken to the JLINC data service login page. When she logs in, the new pseudonym is associated with her account. If she doesn't have an account yet, she can register a new one, and the pseudonym is then associated with her new account.

[0096] Alice can add a FinCo account to her JLINC data service by selecting it in her JLINC application. This process works similarly to the above process, but in reverse. Preferably, the process is as follows:

[0097] 1. First, JLINC Data Service generates a new key pair for Alice and sends the public key along with the signed proposed information sharing agreement to FinCo JLINC Solution Service.

[0098] 2. FinCo J LINC Solution Service countersigns the information sharing agreement and returns it to JLINC Data Service. It sends a message to FinCo API to create a new customer record and record the new customer's ID.

[0099] 3. FinCo can then request data from Alice's JLINC data service. When Alice initiates the FinCo account request, she will have pre-authorized a profile or dataset, which she can change, update, or withdraw at any time. The shared data authorized by Alice can include BankCo data that Alice received from BankCo under the information sharing agreement.

[0100] The list of available JLINC Solution Services that Alice can choose to add to her JLINC Data Service is created and maintained by an out-of-band registration process that creates a unique API key and API secret that are shared between that JLINC Solution Service and her JLINC Data Service.

[0101] All communication between the respective services takes place over encrypted sessions (usually TLS), but two additional measures are required for further security.

[0102] First, all messages contain the sender’s API key and are formatted as a JSON Web Token, partially protected by an HMAC of the shared API secret, mitigating the ability for a man-in-the-middle attacker to alter messages transmitted between services without detection.

[0103] Furthermore, the content of the message is encrypted using the public key of the intended recipient in the relationship. Therefore, only the owner of Alice’s corresponding private key can read the content of the message, and any attempt to alter the content of the message will fail.

[0104] PSD2 Services

[0105] To implement PSD2 services, FinCo needs to access BankCo's PSD2-required APIs on Alice's behalf. The OAuth2 framework is currently being considered by relevant standards bodies to achieve this. The preferred steps of this approach are as follows:

[0106] 1. First, the present invention uses an extension to OAuth2 to allow Alice and / or her JLINC data service to authenticate with BankCo using a key challenge instead of a username and password. It will work as follows.

[0107] 2. Next, Alice indicates to FinCo (either by logging in at FinCo's site or by prior arrangement) that she would like FinCo to perform some operations on her behalf involving BankCo.

[0108] 3. Then, under the existing ISA (the hash of the ISA is included in the request), FinCo’s JLINC Solution Service calls Alice’s JLINC Data Service API to request capabilities from BankCo.

[0109] 4. Next, Alice’s JLINC Data Service makes an API call to BankCo’s JLINC Solution Service to obtain the capability, including the hash of Alice’s ISA and BankCo’s.

[0110] 5. Next, BankCo’s JLINC solution service presents Alice’s public key to BankCo’s authentication API in place of the username.

[0111] 6. Next, BankCo returns an authentication challenge, a random number or string. Critical to the security of this step is that the challenge must be sufficiently long and random, and must never be reused. BankCo's JLINC solution service should ideally include checks to prevent the reuse of this challenge.

[0112] 7. BankCo's JLINC Solution Service then encrypts the challenge using Alice's public key and sends it to her JLINC Data Service. Her JLINC Data Service decrypts the challenge, signs it with Alice's private key, re-encrypts the signed challenge using BankCo's public key, and sends it back.

[0113] 8. Then, if BankCo itself does not have the capability to do so, BankCo's JLINC Resolution Service decrypts the signed challenge using BankCo's private key and in any case presents the signed challenge to BankCo.

[0114] 9. Next, BankCo verifies the signature using Alice’s public key and returns an OAuth token. This step replaces the standard OAuth technique where Alice would be redirected to BankCo’s site, authenticated, and then redirected to FinCo using the OAuth token.

[0115] 10. BankCo's JLINC Solution Service then encrypts the token with Alice's public key and transmits it to Alice's JLINC Data Service. Alice's JLINC Data Service decrypts the token, re-encrypts it with FinCo's public key, and transmits it to FinCo's JLINC Solution Service.

[0116] 11. Finally, FinCo’s JLINC solution service decrypts the token and presents it to FinCo for use according to the established OAuth framework.

[0117] At the end of this process, the system of the present invention presents FinCo with the capabilities generated by BankCo, but significantly reduces the ability of a "man-in-the-middle" attacker to repeat the transaction or steal Alice's credentials or her OAuth token. By placing Alice at the center of the data event, the system of the present invention enables her to see and control the entire process.

[0118] JLINC Solution Service Connector

[0119] Enterprises / businesses / entities can connect their data sources to the JLINC Solution Service using a direct CRM connector to the JLINC Solution Service database (e.g., a foreign data wrapper mechanism for the Postgresql database system) or using the JLINC Solution Service API.

[0120] New end user login

[0121] There are two ways for an enterprise to initialize an existing or new customer on its JLINC Solution Service. If the enterprise is using a direct CRM connector to the JLINC Solution Service database, the JLINC Solution Service database will trigger the creation of a random one-time use identification number. Otherwise, the enterprise can send the customer's account number or other unique ID in the enterprise's records to the corresponding JLINC Solution Service API.

[0122] At that time, no matter what happens:

[0123] 1. First, the JLINC Solution Service of the present invention contacts the JLINC Data Service of the new end user, which instantiates a key pair for the user and returns the public key as a pseudonymous identification number to the JLINC Solution Service together with a proposed information sharing agreement signed by the new end user's private key.

[0124] 2. The JLINC Solution Service then records the public key, countersigns the information sharing agreement, and returns it to the new end user's JLINC Data Service. Both services can also record this agreement through a third-party audit service. The JLINC Solution Service also creates a one-time random ID, or an ID created using a database trigger (if applicable), and uses this ID to create a one-time-use URL that BankCo can present to the new end user via email or other means to log her in.

[0125] 3. JLINC Solution Services may then also return some of the data that the bank wishes to share and / or jointly manage with the new end-user along with the signed information sharing agreement, which she may change, update or withdraw at any time in accordance with the information sharing agreement.

[0126] 4. When a new end user visits the URL, she will be taken to the JLINC Data Services login page. When she logs in, the new pseudonym is associated with her account. If she does not already have an account, she can register one, and the pseudonym will then be associated with her new account.

[0127] JLINC Audit Services

[0128] As part of the JLINC protocol of the present invention, all parties to any data event may each designate a JLINC audit service. The protocol requires each notified party to send a copy of the signed data event receipt created as part of the data event to the designated JLINC audit service within a reasonable period of time.

[0129] JLINC Audit Service matches receipts and issues notifications to all parties involved if no matching receipts are received from both or all parties involved in a data event after a certain period of time. These receipts are intended to provide cryptographically irrefutable evidence that the parties agreed to the exchange of the data in question.

[0130] The JLINC Audit Service of the present invention also provides a key registration service that registers public keys for all parties using the service. If the corresponding private key is compromised or removed from service for any reason, the JLINC Audit Service will record this fact and the public key that has replaced the invalid key, if applicable. If the JLINC Audit Service receives a receipt containing an invalid public key, the service will return a notification to that effect and any information about the replacement key. The JLINC Audit Service also provides an API for directly checking the validity and replacement of public keys.

[0131] It should be understood that the protocols and techniques of the systems and methods of the present invention may be deployed in any situation where there are multiple parties involved in the exchange of data on a permissioned basis.

[0132] The above descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously, many modifications and variations are possible in light of the above teachings. The exemplary embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

[0133] Having described the present invention, it will be appreciated that various modifications and variations may be implemented without departing from the essence of the present invention. In addition, it will be appreciated that the present invention is not limited to the invention described in the foregoing embodiments, but further encompasses any and all embodiments within the scope of this application.

Claims

1. A method for controlling data usage, comprising: Use one or more computer processors to: establishing a cryptographically signed information sharing agreement between a first party and one or more other parties; automatically granting customized permissions related to use of the first party's data and related to transfer of the first party's data between databases based on the information sharing agreement; automatically permitting and managing automatic data exchange of the first party's data between the first party and the one or more other parties based on the information sharing agreement; automatically permitting and managing automatic data exchange of the first party's data between the one or more other parties and one or more further parties based on the information sharing agreement; In response to one or more selections from the first party, restrict or revoke previously permitted uses of the first party data based on the terms of the information sharing agreement; as well as An audit record of all data events for the first party's data is stored, the audit record being signed by each of the other parties that have participated in any data event, thereby establishing one or more chains of custody for the first party's data.

2. The method of claim 1, further comprising: The one or more computer processors are used to provide one or more advertisements to the first party based on the first party's preferences.

3. The method of claim 2, further comprising: Based on the first party's preferences contained in the information sharing agreement, one or more aspects of advertising that will be permitted to be provided to the first party are managed.

4. The method of claim 1 , further comprising: The information sharing protocol is established using a graphical language.

Images