Method for distributed data management - Patents.com

Abstract

The present invention relates to a computer-implemented method for distributed data management on user devices, the method including receiving a query for data from a central server, determining that data stored on the user device satisfies at least one condition of the query, determining a previously generated public key generated by the user device using data stored by the user device, where the data stored by the user device includes a data envelope containing the data and the previously generated public key, the data envelope being signed by an external entity, signing the data envelope using a private key that forms a key pair with the previously generated public key, and responding to the query with the signed data envelope.

Description

[Technical field]

[0001] The present invention relates to a method and system for distributed data management, including information storage and exchange, aimed at enabling aggregate queries without compromising privacy. [Background technology]

[0002] Consumers are becoming increasingly aware of the existence and value of the data trails generated by their commercial activities both online and in the physical world. While many are wary of the potential misuse of this data, they are also evaluating offers from merchants that are mostly data-driven.

[0003] Merchants rely on large repositories of consumer data to optimize their business models and try to collect more than ever before, but are wary of the business threats posed by data breaches. Governments have begun to tighten regulations on data usage and storage, enacting laws such as GDPR, HIPPA, and CCPA (California Privacy Act) and imposing heavy fines for violations. Summary of the Invention

[0004] The system proposed here allows for appropriate control on both sides without sacrificing functionality. Under the system, merchants can query data without having direct access to individual data points. They can make promotional offers to consumers who meet ad-hoc criteria of any complexity without knowing their identity. Consumers can control what data is revealed to merchants, and can redeem offers without disclosing to the merchant that they are doing so. Merchants can see data on the overall effectiveness of promotions without access to the identities of individuals who redeemed the promotions.

[0005] Most people today own a smartphone. These are essentially mobile computing devices connected to a data network. They usually contain strong security and are personal to the user, making them an ideal repository for personal data. By avoiding a centralized store and distributing data across multiple devices, the risk of hacking is greatly reduced. If the data resides only on the consumer's mobile device and not on the merchant's server for both parties, the risk to both parties is reduced.

[0006] By enabling data queries without revealing identity and returning results to the merchant only in aggregate, it can be envisioned that the merchant can include data in the selection criteria that was never secret. For example, a travel company may be interested in offering a promotion to anyone who spent a certain amount or more on airline tickets last year, even if that expenditure occurred elsewhere. In this case, including the desired set would include competitors' customers, but this need not be the case. In some instances, a merchant may be interested in making offers to consumers whose purchasing history in a completely unrelated industry is appealing. Data of interest is not limited to that generated by commercial activities, but may include many other sources, for example, location data collected from GPS or from Bluetooth or WiFi beacons, or lifestyle-related data from fitness applications.

[0007] To avoid data leakage, it is important that consumers be able to claim rewards or promotions without the merchant's knowledge. This means that rewards must be fungible for cash. The desired result can be achieved by creating payment mechanisms where funds are only usable with a specific merchant and potentially have a defined lifespan, but are otherwise indistinguishable.

[0008] There are two most important considerations in the operation of such a scheme: first, neither the system operator nor the participants should obtain user data during the operation of the system, and second, the location and authenticity of all data must be guaranteed.

[0009] According to one embodiment of the present invention, a computer-implemented method for distributed data management on user devices is provided, the method comprising: receiving a query for data from a central server; determining that data stored on the user device satisfies at least one condition of the query; determining a previously generated public key generated by the user device using data stored by the user device, the data stored by the user device including a data envelope containing the data and the previously generated public key, the data envelope being signed by an external entity; signing the data envelope using a private key that forms a key pair with the previously generated public key; and responding to the query with the signed data envelope.

[0010] Signing the data envelope with the private key forming the key pair may be performed before the query is received.

[0011] An external entity may provide the data or an external entity may vouch for the authentication of the data. For example, the external entity may be a merchant that performed a transaction with the user (i.e., the user device) or an information verification service that is used to verify that the user's personal data is accurate / authentic.

[0012] A query for data may include a query public key, and the signed data envelope is encrypted using the query public key before responding to the query.

[0013] The user device may respond with a short-form random identifier and a signed data envelope.

[0014] The queries may be pushed to the user devices by the central server, or the queries may be collected by the user devices from the central server.

[0015] The data stored by the user device may be at least one of transactional data and private data.

[0016] The user device can respond with a signed data envelope, the external entity ID, and optionally the external entity's public key.

[0017] A user device can connect to a number of peer devices, and the user device forwards queries to the peer devices for processing.

[0018] The method includes the steps of: receiving a message associated with a transaction from a central server; generating a transaction public / private key pair and sending a request to the transaction firm for transaction data using the transaction public key; receiving and storing a signed data envelope comprising the transaction data and the transaction public key, the data envelope being signed with the transaction firm's private key.

[0019] The method includes receiving a verifier public key, encrypting data stored by the user device that satisfies at least one condition with the verifier public key, and transmitting the encrypted data to the verifier.

[0020] According to one embodiment of the present invention, a computer-implemented method for distributed data management on a central server is provided, the method comprising: generating a query to user devices; receiving a signed data envelope and a public key from a user device that responds to the query and providing the public key to at least one verifier; and receiving a result from the at least one verifier based on whether the data in the signed data envelope satisfies a condition of the query.

[0021] The method may include pushing the signed data envelope and the public key to at least one verifier or making the signed data envelope and the public key available for collection by the at least one verifier.

[0022] The central server may receive multiple signed data envelopes and associated public keys, provide multiple signed data envelopes and associated public keys to multiple verifiers, and combine results from the multiple verifiers.

[0023] According to one embodiment of the present invention, a computer-implemented method for distributed data management using a verifier is provided, the method comprising: receiving a user device public key and a query from a central server; providing a verification public key for the user device and the user device public key; receiving a data envelope associated with the user device public key, the data envelope being signed with the verification public key; determining whether data in the data envelope satisfies at least one condition of the query; and sending a result to the central server based on whether the data in the data envelope satisfies at least one condition of the query.

[0024] The data envelope may be encrypted using a verification public key, which is a public key issued (or generated) by the verifier.

[0025] The user device's verification public key and the public key may be transmitted to the user device or made available for collection by the user device.

[0026] Receiving the public key and the query for the user device from the central server may comprise receiving a plurality of public keys and selecting one for processing.

[0027] The verifier may be a user device.

[0028] According to one embodiment of the invention there is provided a computer program comprising instructions which, when executed by a computer, cause the computer to carry out any of the methods described above.

[0029] According to one embodiment of the invention, there is provided a computer readable medium containing instructions which, when executed by a computer, cause the computer to perform any of the methods described above.

[0030] According to one embodiment of the present invention there is provided a data processing apparatus comprising a processor configured to perform any of the methods described above. [Brief description of the drawings]

[0031] Embodiments of the invention will now be described, by way of example, with reference to the following drawings: [Figure 1] Showing a representation of the data points; [Diagram 2] Show data flow during payment; [Diagram 3] Show alternative data flows during payment; [Figure 4] 1 illustrates the process of verifying that a data point satisfies a query condition. [Diagram 5] Illustrating a process for storing verified data points; [Figure 6] Show alternative data flows during payment; [Figure 7]Demonstrate a process for validating that a data point satisfies the query conditions; [Figure 8] Here is an example of a token signed by the issuer; [Figure 9] Here is an example of a system signature: [Figure 10] Here is an example of a publisher signature; [Figure 11] Demonstrates alternative encryption methods to asymmetric encryption methods; [Figure 12] 1 illustrates a method according to one embodiment of the present invention; [Figure 13] 4 illustrates a double-signed data envelope according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] The term Nym represents a randomly generated identity used for anonymization purposes. It consists of a public key and an optional short-form random identifier. The private key corresponding to the published public key is held by the Nym owner and is not disclosed to any other party. Nym generation is the process of generating a public / private key pair and an optional short-form identifier. Sending Nym to another party is always only about the public part of Nym, not the private part. A user will typically have many Nyms, possibly one per transaction. The use of Nyms allows a user to present multiple identities when transacting with different parties.

[0033] SC stands for "System Coordinator". This is the process responsible for executing business logic and message routing. This term is synonymous with "Transaction Coordinator" and the two terms are used interchangeably below. The System Coordinator may be implemented on a central server.

[0034] VN stands for "Verifier Node". They check the origin of data and that it meets necessary conditions. This term is synonymous with "Transaction Validator". The two terms are used interchangeably below.

[0035] NAT stands for Network Address Translation.

[0036] IP stands for Issuer Processor. These entities process card transactions on behalf of card issuers.

[0037] BIN stands for Bank Identification Number (the first 6 or 8 digits of the card number).

[0038] PSP stands for payment service providers, also known as "payment gateways." They provide the interface that merchants use to issue payment requests to issuing banks via payment networks (e.g., VISA, MasterCard, and Amex).

[0039] Txn stands for transaction.

[0040] Txn id means the transaction ID.

[0041] Uuid stands for Universal Unique Identifier.

[0042] A system is provided in which users store data on their devices. These devices can be of various types, such as, for example, smartphones, tablets, personal computers, smartwatches, or other devices capable of performing calculations and communicating over a network. The data can be categorized into channels. A channel is associated with a third party that helps create or has a legitimate interest in the particular data. Examples of such third party data may be purchase history or reward points. In addition to these "public" channels, there is at least one channel that contains private data specific to the individual involved. For example, a user's gender, place of birth, date of birth, and financial information are examples of such data.

[0043] The system provides a mechanism for individual users to route messages between themselves to form a peer-to-peer network. Messages are encrypted so that they cannot be read or interpreted by nodes in the network other than the intended destination. The use of nested encryption envelopes allows data to be routed without revealing its contents or ultimate destination.

[0044] A channel partner is an entity with which a user has done business for any reason. This can be a financial transaction, e.g., the purchase of a product or service, but other types of transactions are possible and do not have to involve a financial transaction.

[0045] When a user conducts a transaction with a channel partner, information related to that transaction may be added to a data store on the user's device and marked as belonging to the appropriate channel. The user may choose to make some of that information available to other channel partners, either directly, or by allowing it to be included in aggregate query results (see below).

[0046] To preserve anonymity, each time a user device interacts with a merchant it can generate a new identifier called a "Nym", consisting of the public key of a public / private key pair and an optional shorter form identifier. Nym acts as a surrogate for the user's identity, effectively allowing the user to present different "identities" to different parties while retaining the ability to prove ownership of Nym by storing the key pair on the user's device, and therefore proving ownership of any data point it includes in the signed envelope.

[0047] Channel partners can run queries that return aggregate results (e.g., sum, average, median, etc.) or set membership (e.g., where clauses) without gaining knowledge of any individual's data. In the case of set membership, the results consist of a set of Nyms that represent the user, without revealing the user's identity. This is accomplished by the mechanism described below.

[0048] Each node maintains connections to a small number of peers. In mobile scenarios, the widespread use of multiple NAT layers (often called carrier-grade NAT or CGNAT) P2P networking may require the use of an overlay network (e.g., ZeroTier) to work. When a query is received from a channel partner, the node forwards the query to each of its peers and also executes the query itself. The behavior changes slightly depending on the type of query involved; for set membership queries (e.g., where age is between 30 and 40 years old and gender is male), only a simple binary response is required. There may be situations where a channel partner may want to respond in some way to users who match the query, for example, by issuing a redeemable voucher. To maintain the privacy of the responder, the node generates a unique temporary id to attach to the response. The response is routed through one of the node peers (not necessarily the peer that originally routed the query) that maintains a route back for possible responses. To limit the size of the routing table, routes have a predefined limited lifetime that is attached to the response.

[0049] Reward leakage and claim anonymity Users must be able to claim rewards without the reward issuer having knowledge of each individual claim. Allowing rewards to be substituted for cash as full or partial payment in an electronic transaction would meet this criterion, since when a user pays a merchant, the merchant has no way of knowing the amount, if any, of the reward payment.

[0050] It works by incorporating special functionality into the issuer processor, which acts on behalf of the issuing banks, providing the system of record and authorizing transactions on their behalf.

[0051] Under this system, the Issuer Processor maintains multiple balances for each card in addition to the standard balance of available credit, each additional balance corresponding to available monetary rewards from a participating merchant. Some merchants may have multiple reward schemes, each with its own balance. When a customer wants to make a purchase from a participating merchant, the customer pays using his linked card and transaction details are sent to the Issuer Processor (IP). The IP identifies the merchant in question from the transaction data and checks whether the customer has an available rewards balance that can be used for the transaction. If a balance is available, the system can optionally send a message to the customer to find out if the customer wants to redeem this balance against their purchase, or it can proceed by immediately offsetting the available rewards balance against the purchase and charging the card for the remainder.

[0052] In an alternative scheme, rewards balances are held on the customer's device in the form of digital tokens that can be sent to the IP upon transaction.

[0053] At checkout, the merchant sees the shortfall between the authorizations obtained and the total checkout value, which is equal to the total value of the rewards redeemed. Because this is an aggregate value, little can be inferred about which customers have taken up which offers.

[0054] Anonymization of responses and rewards Each consumer device maintains its own data store. In practice, this most likely means that each consumer installs an application on its device, and this application maintains a data store on the device. Merchants can issue queries that are executed on each device. Queries can be pushed to the device, or queries can be collected and executed when the device contacts a central server. Queries can be of two types: one type determines whether the consumer has a characteristic that makes it included in a given set, the other type results in a numerical answer that is used to compile statistics. The response can be either synchronous or asynchronous. In the latter case, each query must provide a unique identifier (GUID) that can be returned with the response. If the response is positive, the merchant may wish to assign a reward to the customer. This is implemented by giving the device a digital token that can later be "cashed" by sending it to an IP. There may be a secondary market for these digital tokens. It is envisioned that this will benefit both consumers and merchants alike. If a consumer receives a reward token with a face value of, say, $10 from a merchant, the consumer may be interested in selling the token to another consumer. Other consumers may be interested in paying up to, say, $5 for the tokens. For merchants, the benefit of allowing such transactions is that they can acquire new customers.

[0055] As an extension of this scheme, merchants can set certain conditions on the sale of tokens, limiting the availability of purchases to those that meet certain criteria. These conditions may differ from the original conditions attached to the tokens. For example, the original tokens may be issued to existing customers with a high spending profile, but the merchant may be happy for the tokens to be sold to others who are not currently customers but have a certain level of disposable income. The consumer app can facilitate this by publishing the availability of the tokens for exchange with the associated conditions attached. Other consumers will then learn of the offer in the marketplace if they meet the criteria attached to the offer. The conditions may be invisible to end users, whose devices are required to demonstrate compliance with the attached criteria before displaying the offer. Payment can be effected with cash credits or by exchange for other tokens or portions thereof.

[0056] There may be limits on the number of times a token can change hands, and there may be rules governing how the value of the token may change as a result of each transaction. The central exchange may take a fee for each transaction. In addition to having an expiration date, tokens may decrease in value over time according to a predefined formula.

[0057] The ability to split a token implies a centralized ability to revoke a previously issued token and reissue two or more tokens in its place. A ledger system is also required to prevent double spending. This can be managed through a centralized or decentralized database. For example, a cryptocurrency system such as Ethereum, Hyperledger, or other similar blockchain-based systems can be used. Merchants may wish to contribute nodes to this system as part of their assurance that their transactions are legitimate. This is especially true because merchants may be wary of trusting a central authentication due to the way the system anonymizes users.

[0058] In addition to the fixed price offer mechanism, it is also envisioned that the exchange of tokens may occur through an auction.

[0059] See user data points without leaking data Data provided by users to claim eligibility to receive or redeem tokens must be checked for provenance and ownership. Performing this check centrally could leak data to system operators and also raise concerns about excessive centralization of power, and bad actors could be involved in hiring operators to game the system. These issues can be overcome by disseminating the data validation function across a number of randomly selected participants taken from the user pool. This system is extremely resistant to corruption by bad actors, as it removes a central point of attack.

[0060] The user device can be configured to poll the main system at intervals, giving the user the opportunity to handle the tasks. When connecting to collect pending tasks, the user device supplies a public key that can be generated on the fly for each message exchange. This key is then sent to the user requesting data verification, making it possible to encrypt the messages passed to the verifier user in a way that cannot be read by intermediate servers involved in the communication.

[0061] Because the user devices are behind multiple layers of NATs, it is not possible to establish direct peer-to-peer communication, in which case a central server must act as a common communication point with both devices maintaining a connection to it. In any case, there are well-known mechanisms that allow for encrypted end-to-end communication between two user devices.

[0062] For this feature to work, a name resolution facility similar to the Domain Name System (DNS) must be present, allowing two user devices to locate each other.

[0063] In this scheme, the central system knows that data has been passed to a verifier to check, but has no knowledge of the data itself. Similarly, it has knowledge of the predicates used in the conditions attached to any offer, but it does not know why a given user passed or failed a particular check.

[0064] The verifiers involved in each condition check know this information but do not know the identity of the user in question. If the conditions attached to a particular offer allow it, the system can be further improved by splitting the condition check into several steps and dividing the task between different verifiers. For example, if the conditions are that the user must be between 25 and 35 years old, reside in a particular area and have spent more than $5000 on vacations in the last 12 months, these three tests (joined by AND predicates) can be divided between three different verifiers, thus limiting the information revealed to each one. If the conditions are complex, it is advantageous to stratify the verifiers and make the tests work in a map-reduce fashion.

[0065] In addition to ensuring that the verification function can be performed without data leakage, it is also important to be able to check the origin of all data points provided by users. A malicious user cannot create fake data points or claim ownership of data points that are not their own. This can be achieved by ensuring that each data point contains a reference to the data owner and is signed by the data point provider. The structure of such a data point is shown in Figure 1. The user provides a unique but not easily identifiable Nym for the transaction, and the data issuer (typically a merchant) signs the data and Nym with its private key. As only the user has the private key to Nym, the data structure provably guarantees the following: 1) The data publisher is the source of the data 2) Nym Owner is the rightful owner of the data.

[0066] Token Validity and Holder Redemption Eligibility The validity of a token is attested to by the issuer's cryptographic signature. Conditions can be attached to the token.

[0067] To redeem tokens, a user must provide proof of both ownership and eligibility consistent with any attached terms. Ownership is proven by checking a cryptographic signature associated with the token and / or the associated ledger entry. Eligibility can be proven through the use of a vouching system in which unbiased verifiers process claims by verifying each data point check signature on the data points. The verification process can be spread among a group of verifiers randomly selected from a pool of users, and the results are combined using a map-reduce algorithm.

[0068] The location of each data point is checked by verifying the issuing signature. The ownership of each data point is checked by verifying the ownership signature.

[0069] Once the ownership and location of each data point has been verified, it can be checked for compliance with attached criteria. The reverse operation is also possible.

[0070] Each action can be completed by one or more participants, increasing resilience and reducing opportunities for bad actors.

[0071] Steps: Present the token for redemption along with the terms and a list of data points Assign a transaction coordinator Distribute data point validation tasks ● Tailor your response.

[0072] The transaction coordinator receives a list of data points. It assigns each data point to a transaction verifier, who collaborates with the claimant to verify the signature on the point. Note that this process includes verifying that the nym attached to each data point is under the same ownership as the nym used by the claimant when the token is presented. This proof is available because a signature verification check on each data point proves that the claimant has control of the private key corresponding to the public nym key wrapped in the data envelope.

[0073] Message Routing To maintain the integrity of the personal data, it is desirable for the central servers to have no way of guessing the identity of the devices with which they communicate.

[0074] Mobile devices tend to change their IP addresses very frequently on mobile data networks, but when connected to wifi, the IP address may be fixed or semi-fixed with only infrequent address changes. This may lead to the possibility of inferring identity from the originating IP address of the connection. For this reason, it may be desirable to use mixed network types in the system. Mixed networks make the endpoints of a communication difficult to trace using public key cryptography, both for eavesdroppers and malicious mixed nodes. The sender wraps the message in a series of multiple layered encrypted envelopes, each envelope containing the address of the next hop in the chain and the encrypted payload of another envelope. This can be envisioned as a set of Russian Matryoshka dolls, with each doll containing other dolls nested within it. The first node decrypts the outer envelope, gets the address of the next hop, gets the encrypted envelope addressed to that server, and then forwards the message. The next server in the chain operates in the same way until the final destination is reached. Each envelope is encrypted with the public key of the server intended to process the message, with each server having a different public key, thus ensuring that the next destination cannot be read by any other server, and that the final message is only decryptable if the message has passed all the necessary servers in the proper order. Mixed networks typically introduce random delays as each node in the chain forwards the message against frustrated correlation attacks. Responses to messages are usually coordinated by a system similar to that used for the original message, but instead used to provide an anonymous response address. However, in mobile networks, due to the widespread use of multi-layered NAT (Network Address Translation), it is often impossible for a device to receive an inbound connection. This requires a special scheme to overcome the problem. Both responses must be synchronized.This makes the mixed network vulnerable to correlation attacks, or the sender must be able to receive inbound connections and must poll for responses to messages. When mobile networks are involved, it is necessary to either use peer-to-peer networks (which bring their own complexities) or have the sender poll for responses.

[0075] The mixing server may be run by a central authority, a merchant, or a mix of both. Alternatively, the system may be organized as a peer-to-peer network with users' devices acting as mixing nodes.

[0076] Token Security The need to balance token security and the need to do so need to be reconciled.

[0077] Verifier To avoid leaking data to the system operator, randomly selected user peers can be used as verifiers: the system does not need to trust individual verifiers, since several can be used to check the same data points.

[0078] Referring to Figure 4: When the need arises, the system can send a set of required conditions to the user device. The user device then selects the appropriate data points from its storage, selects or generates a key pair for use with each data point or subset of data points, and returns these to the system. The next step is for the system to select one or more verifiers for each data point or subset of data. A verifier is a process that runs on a server owned by any participating organization in the network, or on the device of an individual user. The verifier process becomes trustworthy if the verifier node is selected randomly, the verifier has no interest in the transaction, and optionally multiple verifiers must check each data point. Since each data point or subset of data points is associated with its own nym, the identity of the data holder is not revealed, thus maintaining privacy.

[0079] The validator node then checks that the supplied data point matches the supplied conditions and signs it with its own key.

[0080] Data Security and the Frustration of the Bad Guys It is important that the whereabouts of the data stored on a user's device is traceable and that a malicious user cannot tamper with the data to receive rewards for which he is not eligible. Similarly, it should be impossible for a malicious user to generate fake responses to queries with the same purpose. There are several possible approaches to this problem.

[0081] The preferred scheme is to wrap the user's public key (note: users have many public keys (one associated with each Nym in use)) and the data in a signed envelope at the time of issuance. This can be verified using only the issuer's public key, so no round trip to the issuer is required. Although the computational load is higher when the data is issued and signed, the verification is highly distributed and does not burden the merchant server. This also adds the property of non-repudiation, being able to prove that the merchant issued the data point in question.

[0082] An alternative scheme is to generate an HMAC to store with the data and the user Nym. The verifier must contact the issuer to verify the HMAC, since the HMAC secret cannot be shared with the verifier who is also the user. The merchant server is involved in each verification, but the computational effort in each verification is low. There is some leakage, in that the merchant knows the query on each point.

[0083] Another alternative scheme is to use homomorphic encryption, which allows computations on encrypted values ​​without decryption. The process is slow, but the amount of data involved is small, so it does not pose much of a challenge when performed on consumer devices. It is not yet practical at the time of writing, but this may change in the not-too-distant future. Using this technique, it becomes impossible for a malicious actor to generate fake results for a query, since both the values ​​in the query and the data itself are encrypted and cannot be recovered without the key.

[0084] Zero-Knowledge Proofs (ZKPs) provide a way for parties to claim possession of certain knowledge without having to reveal the knowledge itself. This helps prevent information leakage, but must be combined with other techniques to ensure the veracity of the claims themselves.

[0085] Since this is a large problem space, other solutions will be apparent to those skilled in the art and may be equally suitable for the purpose.

[0086] The transaction flow that leads to the creation of one or more data points See Figures 2 and 5

[0087] A user pays and transacts with a merchant using a card issued by a system provider. The card may be a physical card or a one-time card number generated by the system for use in a particular transaction. The payment network routes the transaction to an IP based on the card's BIN number. The IP has visibility to the transaction details, including the merchant transaction reference number. In addition to the normal processing of the transaction, the IP sends a message containing the merchant ID, merchant transaction ID, and optionally other data to the SC, which queues the message for delivery to the user's app running on his device.

[0088] If the app is currently connected to the system, the message will usually be delivered immediately.

[0089] When the user's app receives the message, it generates a Nym for the transaction and requests the data points from the merchant. The request can optionally include other data that allows the merchant to verify in their system that the request is authentic.

[0090] The merchant adds Nym and the requested data to a signed envelope (signed using one of the merchant's private keys) and returns the entire data structure to the user's app, which stores it for later use.

[0091] Transaction flow involving the redemption of tokens representing rewards Please refer to Figure 3.

[0092] The flow starts in the same way as a flow without token redemption, but when the SC sends the merchant's ID to the user's app, the user is given the option to select which token to redeem for the transaction. The token ID (or the token itself) is then sent to the SC, which checks the token against the ledger to see if all conditions are met, e.g. the user is the rightful owner, the token has not expired, and the token is valid for use with the particular transaction type involved. This final step can require the SC to make a data request to the merchant to retrieve more details of the transaction.

[0093] If the conditions are not met, the user is notified, and if not, a credit for the tokens is applied to the transaction, resulting in the user's account being charged less than the face value and the balance being offset against the tokens. Importantly, this process is invisible to merchants, who have no way of knowing that the tokens have been redeemed.

[0094] Note that there are two possible modes of operation that can be used to achieve the same result. Rewards can be kept in the form of tokens that are issued after users pass the appropriate eligibility checks, or the use of tokens can be dispensed with and eligibility checks can be performed at the point of claim. Note that in either case, a ledger needs to be maintained to prevent double-spending. A ledger is also needed if tokens, for any reason, are exchanged hands or split or their value is adjusted.

[0095] Note that in Figures 2 and 3, the PSPs have been omitted for clarity.

[0096] Transaction flows without a payment network Please refer to Figure 6.

[0097] Instead of using an IP to observe the transaction, the system operator could provide a service that sits between the merchant and the PSP that relays the request and response, correcting both during retransmission if necessary. This would enable the same functionality as described for the IP, but for payment cards as well as cards with a BIN associated with the IP. For example, if a request is made for a payment of $100 and the system determines that the user has a token with a value of $10 that they wish to redeem, the service could dynamically modify the payload of the PSP request, reducing the requested value to $90, and when the response comes back, it could optionally change the data to indicate that a transaction of $100 has been approved. The user would be charged $90, but the merchant would see a normal transaction of $100. The $10 balance would be offset against the merchant account as part of an aggregated daily payment methodology, thus stopping data leakage. Such a service would need a means to correctly interpret the payload sent to the PSP, and therefore the ability to be programmed to work with many different PSPs. Most PSP APIs are HTTP-based with payloads that are XML, JSON, or name-value pairs, so providing this is not onerous. Some PSPs also include the use of hash functions or HMAC signatures in their systems, in which case the hash or digital signature is over the transaction amount, and the system needs to be configurable to allow recreation of the hash or signature after the amount changes.

[0098] Issuing an Offer or Reward A merchant may wish to make offers or promotions to a set of people who meet certain criteria. In addition to users with whom the merchant already has transactions, the merchant may wish to make offers to other users who meet the criteria who have no transaction history. To implement this, the offer must be broadcast to all users or made viewable by the user. In either case, the user app can determine if the criteria are met by inspecting data stored on the user's device, so that the system can filter out users who do not meet the criteria. A user's eligibility only needs to be checked at the time of redemption, or at the time of claim if the reward is in the form of a fungible token.

[0099] Since true broadcasting to mobile devices can be difficult for reasons described elsewhere in this document, a polling mechanism in which the user device checks for offers at intervals may be preferred.

[0100] Token Sale / Transfer The offer may be limited to a finite number of claimants, eg, the first 500, or may be limited only by time, eg, before a certain date.

[0101] Additional restrictions may be imposed by fitness conditions, i.e., meeting certain ad-hoc criteria.

[0102] The offer may be broadcast to all allowing everyone who meets the criteria to remember it for later claim, or it may be available on a first come, first served basis, meaning the first 500 people to claim a token will receive one (we're talking about claiming a token here, not claiming a redemption).

[0103] In addition, people's eligibility may change over time, i.e., at the time the offer is made, but they may become eligible before the redemption date.

[0104] This opens up the possibility of a secondary market.

[0105] Figure 11 illustrates an alternative encryption to the asymmetric encryption method. According to Figure 11, data is encrypted with a symmetric algorithm such as AES, and the AES key is encrypted using asymmetric encryption with the intended recipient's public key. The encrypted symmetric encryption key can then be sent along with the message to the recipient. The recipient then uses its private key to decrypt the encrypted symmetric key, which is then used to decrypt the message.

[0106] FIG 12 illustrates one embodiment of the present invention. In FIG 12, a method 100 includes: ● receiving a query for data from a central server (102); ● determining whether data stored (or held) on the user device satisfies at least one condition of the query (i.e., determining whether the device holds data that matches at least one query condition) (104); ● Using data stored by the user device, determine (or select) 106 a previously generated public key generated by the user device, where the data stored by the user device comprises a data envelope comprising the data and the previously generated public key, the data envelope being signed by an external entity (i.e., select a private key corresponding to the public key in Nym in the data point); ● Signing the data envelope (or data points) using the private key that forms a key pair with the previously generated public key (108); ● Respond to the query with a signed data envelope (or data points) (110).

[0107] The method may include determining 112 whether there are any further matches to other terms of the query, and repeating steps 106 and 108. Further, if the device does not have data that matches at least one of the query terms, the method ends (114).

[0108] 13 illustrates a double-signed data envelope according to one embodiment of the present invention. As illustrated, the original Nym (i.e., user Nym or user public key) is in a signed data envelope with the data provided by the data issuer (or merchant) signed with the data issuer's (or merchant's) private key. The data issuer's identifier, and optionally the public key, are included in a second envelope signed with the user device's private key.

[0109] One embodiment of the invention may include a computer-implemented method for redeeming a token, the method including receiving a token from a user device along with conditions and one or more data points, distributing the one or more data points to one or more verifiers, and coordinating a response.

[0110] Ownership of a token can be proven by checking a cryptographic signature associated with the token and / or the associated ledger entry, and proof of both ownership and eligibility, subject to any attached conditions, can be used to redeem the token.

[0111] Each data point related to the token may be passed to a transaction verifier who cooperates with the claimant to verify the signature on the data point.

[0112] Checks against the ledger may include checking that the user is the rightful owner, that the token has not expired, and that the token is valid for use in the particular transaction type involved. A final step may request the system coordinator to issue a data request to the merchant to retrieve more details of the transaction.

[0113] If a token changes hands, splits, or adjusts in value for any reason, the ledger can be used.

[0114] The term "comprising" encompasses "including" as well as "consisting", e.g., a composition "comprising" X may consist only of X, or it may include something additional, e.g., X+Y.

[0115] Unless otherwise stated, each embodiment described herein can be combined with any other embodiment described herein.

[0116] The methods described herein may be performed by software in machine-readable form on a tangible storage medium, e.g., in the form of a computer program including computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer, and the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, hard drives, thumb drives, memory cards, and the like, and do not include propagated signals. The software may be suitable for execution on parallel or serial processors, such that the method steps may be performed in any suitable order, or simultaneously. This recognizes that firmware and software may be valuable and separately tradable commodities. It is intended to encompass software that runs on or controls "dumb" or standard hardware to perform a desired function. It is also intended to encompass software that "describes" or defines the configuration of hardware, such as HDL (Hardware Description Language) software, such as used to design silicon chips or configure universal programmable chips, to perform a desired function.

[0117] Those skilled in the art will appreciate that storage devices utilized to store program instructions may be distributed across a network. For example, a remote computer may store an example of a process described as software. A local or terminal computer may access a remote computer and download some or all of the software to execute the program. Alternatively, a local computer may download parts of the software as needed, or execute some software instructions at a local terminal and a remote computer (or computer network). Those skilled in the art will also appreciate that all or part of the software instructions may be executed by dedicated circuitry, such as DSPs (digital signal processors), programmable logic arrays, etc., by utilizing conventional techniques known to those skilled in the art.

[0118] It will be understood that the benefits and advantages described above may relate to one embodiment or to several embodiments, and the embodiments are not limited to those that solve any or all of the problems described or those that have any or all of the benefits and advantages described.

[0119] The steps of the methods described herein may be performed in any suitable order, or simultaneously where appropriate. Additionally, individual steps may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the desired effect. Any of the steps or processes described above may be implemented in hardware or software.

[0120] It will be understood that the above description of preferred embodiments is given by way of example only, and that various modifications may be made by those skilled in the art. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art may make numerous modifications to the disclosed embodiments without departing from the scope of the present invention.

Claims

1. 1. A computer-implemented method for distributed data management on user devices, comprising: receiving a query for data from a central server; determining that data stored on the user device satisfies at least one condition of the query; selecting a public key generated by the user device using the data stored by the user device, the data stored by the user device comprising a data envelope comprising data and the public key, the data envelope being signed by an external entity; signing the data envelope using a private key that forms a key pair with the public key; responding to the query with the signed data envelope; receiving a verifier public key, encrypting the data stored by the user device that satisfies the at least one condition using the verifier public key, and sending the encrypted data to the verifier; A method having the following.

2. The method of claim 1 , wherein the external entity provides the data or the external entity is certified as authenticating the data.

3. The method of claim 1 , wherein the query for data includes a query public key, and the signed data envelope is encrypted using the query public key before responding to the query.

4. The method of claim 1 , wherein the user device responds with a short-form random identifier and the signed data envelope.

5. The method of claim 1 , wherein the query is pushed to the user device by the central server.

6. The method of claim 1 , wherein the queries are collected by the user devices from the central server.

7. The method of claim 1 , wherein the data stored by the user device is at least one of transactional data and private data.

8. The method of claim 1 , wherein the user device responds with the signed data envelope, an external entity ID, and optionally a public key of the external entity.

9. The method of claim 1 , wherein the user device is connected to a predetermined number of peer devices, and the user device forwards the query to the peer devices for processing.

10. receiving a message from the central server regarding the transaction; generating a transaction public / private key pair and sending a request to the transaction firm for transaction data using the transaction public key; receiving and storing a signed data envelope containing the transaction data and the transaction public key, the data envelope being signed with the transaction firm's private key; having The method of claim 1.

11. 1. A computer-implemented method for distributed data management on a central server, comprising: generating a query to a user device; sending the query to the user device; receiving a signed data envelope and an ID from the user device in response to the query; providing said ID to at least one verifier; receiving a result from the at least one verifier based on whether the data in the signed data envelope satisfies the query; A method having the following.

12. 12. The method of claim 11, further comprising: pushing the signed data envelope and the ID to the at least one verifier or making the signed data envelope and the ID available for collection by the at least one verifier.

13. 12. The method of claim 11, wherein the central server receives a plurality of signed data envelopes and associated IDs, provides the plurality of signed data envelopes and associated IDs to a plurality of verifiers, and combines results from the plurality of verifiers.

14. 1. A computer-implemented method for distributed data management using verifiers, comprising: receiving an ID of the user device and a query from a central server; providing a verification public key for the user device and an ID of the user device; receiving a data envelope associated with the ID of the user device, the data envelope encrypted with the verification public key; determining whether the data in the data envelope satisfies at least one condition of the query; transmitting a result to the central server based on whether the data in the data envelope satisfies at least one condition of the query; A method having the following.

15. The method of claim 14 , wherein the data envelope is signed using a private key that forms a key pair with a public key of the user device.

16. The method of claim 14 , wherein the verification public key and the ID of the user device are transmitted to the user device or made available for collection by the user device.

17. The method of claim 14 , wherein receiving the user device's ID and query from the central server comprises receiving multiple IDs and selecting one for processing.

18. The method of claim 14 , wherein the verifier is a user device.

19. A computer program comprising instructions which, when said program is executed by a computer, cause said computer to carry out a method according to any one of claims 1 to 18.

20. A computer readable medium comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 18.

21. 19. Data processing apparatus comprising a processor configured to carry out a method according to any one of claims 1 to 18.

Images