Patent Application
20210073804
The disclosure relates to the field of cryptocurrency, and more particularly to the field of automating bookkeeping for nostro and vostro financial institutional accounts using immutable distributed ledgers.
In the field of finance and banking, the terms “nostro” and “vostro” refer to accounting held between banks for assets of the other bank, with “nostro” referring to a bank's own account of their own money being held at a different institution, and “vostro” referring to a bank's own account of another bank's money that the first bank holds. Numerous difficulties arise in the use of “nostro” and “vostro” accounts for financial and banking institutions. Keeping track of balances appropriately and transparently, with the trust of both sides, and in a secure manner that keeps track of changes in the balances to the two accounts, is a challenging task, requiring synchronization and clearing of funds between multiple institutions in certain cases, such as the use of a third party financial institution to store and handle transactions in a foreign currency, for which there may be multiple tied accounts in such an arrangement. Further, no integration with smart wallet or blockchain systems exists for such accounting practices and systems.
What is needed is a system and method of non-cryptographic immutable distributed ledger technology for sending and receiving multiple assets including fiat currencies, in which the convenience of nostro and vostro accounts and similar pool accounts are combined with the trust and transparency created by an immutable distributed ledger technology (“iDLT”) or blockchain system. In this exemplary system all parties involved may be able to see in real time who is involved in each payment transactions, and all persons involved in executing the transaction(s) are identified and recorded, so there are no anonymous, unattributable errors or other issues, as all recordation is immutable and transparent.
Further, in some cases, this system allows certain Personally Identifiable Information (PII) to be forgettable in accordance with the law (for example the General Data Protection Regulation (GDPR) in current EU law, and future, anticipated, similar laws in other jurisdictions) while still being compliant with Anti-Money Laundering (AML), Know Your Customer (KYC), and Know Your Customer's Customer (KYCC) laws, regulations, and standards.
Accordingly, the inventor has conceived and reduced to practice, a system of non-cryptographic immutable distributed ledger technology for sending and receiving multiple assets including fiat currencies, comprising: a first financial institution; a second financial institution; an other-control account; a financial institution endpoint comprising at least a first plurality of programming instructions stored in the at least one memory of, and operating on at least one processor of, the computer system, wherein the first plurality of programming instructions, when operating on the at least one processor, cause the computer system to: communicate with another financial institution other than the operating financial institution; facilitate customer transactions with a customer account held by the operating financial institution; facilitate transactions between the operating financial institution and a separate financial institution by means of an other-control account, such as nostro and vostro accounts; wherein the transactions between the financial institutions take place over a secure network; store records of personally identifying information on entities involved in transactions with the financial institution endpoint; communicate with a data trustee and allow the data trustee to copy all stored transaction record data for storage purposes; a secure network comprising at least a first plurality of programming instructions stored in the at least one memory of, and operating on at least one processor of, the computer system, wherein the first plurality of programming instructions, when operating on the at least one processor, cause the computer system to: receive transactions from at least one financial institution endpoint; facilitate transactions between customers and financial institution endpoints; store records of transactions that have passed through the secure network; wherein the records include a key or identifier to a block of data held by a data trustee, the block of data containing personally identifying information on the entity or entities involved in a transaction or transactions; and a data trustee comprising at least a first plurality of programming instructions stored in the at least one memory of, and operating on at least one processor of, the computer system, wherein the first plurality of programming instructions, when operating on the at least one processor, cause the computer system to: communicate with a financial institution endpoint over a secure network; query or receive data from a financial institution endpoint; wherein the data received or queried from a financial institution endpoint comprises transaction data and personally identifying information on the entity or entities involved in the transaction or transactions; maintain a key or identifier paired with each segment or portion of transaction and personally identifying information; wherein the key or identifier matches the key or identifier for the transaction data held by the secure network; and allow entities with proper legal authorization to query transaction data and personally identifying information on entities involved in the transaction data from the data trustee, using a paired key or identifier.
According to one aspect, a method of non-cryptographic immutable distributed ledger technology for sending and receiving multiple assets including fiat currencies, is disclosed, comprising the steps of: communicating with another financial institution other than the operating financial institution, using a financial institution endpoint; facilitating customer transactions with a customer account held by the operating financial institution, using a financial institution endpoint; facilitating transactions between the operating financial institution and a separate financial institution by means of an other-control account, such as nostro and vostro accounts, using a financial institution endpoint; wherein the transactions between the financial institutions take place over a secure network, using a financial institution endpoint; storing records of personally identifying information on entities involved in transactions with the financial institution endpoint, using a financial institution endpoint; communicating with a data trustee and allow the data trustee to copy all stored transaction record data for storage purposes, using a financial institution endpoint; receiving transactions from at least one financial institution endpoint, using a secure network; facilitating transactions between customers and financial institution endpoints, using a secure network; storing records of transactions that have passed through the secure network, using a secure network; wherein the records include a key or identifier to a block of data held by a data trustee, the block of data containing personally identifying information on the entity or entities involved in a transaction or transactions, using a secure network; communicating with a financial institution endpoint over a secure network, using a data trustee; querying or receive data from a financial institution endpoint, using a data trustee; wherein the data received or queried from a financial institution endpoint comprises transaction data and personally identifying information on the entity or entities involved in the transaction or transactions, using a data trustee; maintaining a key or identifier paired with each segment or portion of transaction and personally identifying information, using a data trustee; wherein the key or identifier matches the key or identifier for the transaction data held by the secure network, using a data trustee; and allowing entities with proper legal authorization to query transaction data and personally identifying information on entities involved in the transaction data from the data trustee, using a paired key or identifier, using a data trustee.
The accompanying drawings illustrate several aspects and, together with the description, serve to explain the principles of the invention according to the aspects. It will be appreciated by one skilled in the art that the particular arrangements illustrated in the drawings are merely exemplary, and are not to be considered as limiting of the scope of the invention or the claims herein in any way.
The inventor has conceived, and reduced to practice, a system and method of non-cryptographic immutable distributed ledger technology for sending and receiving multiple assets including fiat currencies.
One or more different aspects may be described in the present application. Further, for one or more of the aspects described herein, numerous alternative arrangements may be described; it should be appreciated that these are presented for illustrative purposes only and are not limiting of the aspects contained herein or the claims presented herein in any way. One or more of the arrangements may be widely applicable to numerous aspects, as may be readily apparent from the disclosure. In general, arrangements are described in sufficient detail to enable those skilled in the art to practice one or more of the aspects, and it should be appreciated that other arrangements may be utilized and that structural, logical, software, electrical and other changes may be made without departing from the scope of the particular aspects. Particular features of one or more of the aspects described herein may be described with reference to one or more particular aspects or figures that form a part of the present disclosure, and in which are shown, by way of illustration, specific arrangements of one or more of the aspects. It should be appreciated, however, that such features are not limited to usage in the one or more particular aspects or figures with reference to which they are described. The present disclosure is neither a literal description of all arrangements of one or more of the aspects nor a listing of features of one or more of the aspects that must be present in all arrangements.
Headings of sections provided in this patent application and the title of this patent application are for convenience only, and are not to be taken as limiting the disclosure in any way.
Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more communication means or intermediaries, logical or physical.
A description of an aspect with several components in communication with each other does not imply that all such components are required. To the contrary, a variety of optional components may be described to illustrate a wide variety of possible aspects and in order to more fully illustrate one or more aspects. Similarly, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may generally be configured to work in alternate orders, unless specifically stated to the contrary. In other words, any sequence or order of steps that may be described in this patent application does not, in and of itself, indicate a requirement that the steps be performed in that order. The steps of described processes may be performed in any order practical. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to one or more of the aspects, and does not imply that the illustrated process is preferred. Also, steps are generally described once per aspect, but this does not mean they must occur once, or that they may only occur once each time a process, method, or algorithm is carried out or executed. Some steps may be omitted in some aspects or some occurrences, or some steps may be executed more than once in a given aspect or occurrence.
When a single device or article is described herein, it will be readily apparent that more than one device or article may be used in place of a single device or article. Similarly, where more than one device or article is described herein, it will be readily apparent that a single device or article may be used in place of the more than one device or article.
The functionality or the features of a device may be alternatively embodied by one or more other devices that are not explicitly described as having such functionality or features. Thus, other aspects need not include the device itself.
Techniques and mechanisms described or referenced herein will sometimes be described in singular form for clarity. However, it should be appreciated that particular aspects may include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise. Process descriptions or blocks in figures should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of various aspects in which, for example, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those having ordinary skill in the art.
The terms “blockchain” or “immutable ledger” as used herein means an immutable, additive transaction database which is formed by encrypting “blocks” of information and adding them to a “chain” of prior blocks. Immutability of a blockchain is ensured by testing it against a hash of all prior transactions in the blockchain. If the test does not match the hash, the blockchain has been tampered with in some way. Blockchains do not have to be distributed, although most implementations to date have been of that type. The phrases “distributed blockchain” or “immutable distributed ledger” means an immutable, additive transaction database which is of the distributed type.
The term “transaction” as used herein means any electronic transaction between two or more parties, including but not limited to transactions in the form of smart contracts and digital currencies. Transactions may include zero-value transactions such as tracking of events, completion of checklists, etc.
The term “token” as used herein means any unit of data that allows tracking of some item of information. In many cases, a token will be a digital representation of an agreed unit of exchange, but a token may represent any trackable information for which a historical record is needed (e.g., a series of events, a checklist of items to complete, etc.). Where a token is a digital representation of an agreed unit of exchange, a token is not required to have any inherent value other than what people are willing to exchange for it (e.g., as in the case of cryptocurrencies), or it may be tied to a real world thing of value such as a real currency, a contractual right, or physical asset. Tokens may be unitary, meaning that each token represents a value that is indivisible, or they may be divisible, meaning that the value of each token can be divided into smaller units. In some embodiments, tokens may represent a sort of digital “account” to which value can be added or subtracted.
The terms “digital currency” or “virtual currency” as used herein mean a representation of value in digitized form which may be transferred to others or exchanged with others for goods and services.
The term “cryptocurrency” as used herein means a digital currency for which security is provided by means of encryption. The definition of a cryptocurrency does not necessarily require the use of blockchains, although all major cryptocurrencies currently in use are so defined. The valuation associated with cryptocurrencies is often referred to as coins or tokens, with fractional parts of a coin or token typically being allowed to be transferred or utilized.
The terms “mine” or “mining” as used herein mean incentivizing nodes to provide computer processing power to validate transactions by generating a small additional portion of the valuation associated with a blockchain database for each successful entry validation in that database, and giving that small portion to a node or nodes that perform(s) the successful entry validation.
The term “node” as used herein means any one of a plurality of computers that validate transactions in the blockchain database as part of a peer-to-peer network.
The term “proof of work” or “PoW” as used herein means solving of a complex mathematical operation such as a cryptographical puzzle which serves as validation of a potential block in the blockchain. In current blockchain implementations, PoW requires broadcasting of the potential block to every node in the network and competition among the nodes to complete the PoW first. This requires every node to have the entire information on the blockchain. As the blockchain grows, with more users and a higher number of transactions, there is increasing load on each node. Participation of every participating node in transaction validation makes the transaction process slower.
“Artificial intelligence” or “AI” as used herein means a computer system or component that has been programmed in such a way that it mimics some aspect or aspects of cognitive functions that humans associate with human intelligence, such as learning, problem solving, and decision-making. Examples of current AI technologies include understanding human speech, competing successfully in strategic games such as chess and Go, autonomous operation of vehicles, complex simulations, and interpretation of complex data such as images and video.
“Machine learning” as used herein is an aspect of artificial intelligence in which the computer system or component can modify its behavior or understanding without being explicitly programmed to do so. Machine learning algorithms develop models of behavior or understanding based on information fed to them as training sets, and can modify those models based on new incoming information. An example of a machine learning algorithm is AlphaGo, the first computer program to defeat a human world champion in the game of Go. AlphaGo was not explicitly programmed to play Go. It was fed millions of games of Go, and developed its own model of the game and strategies of play.
The phrase “real currency” (aka fiat money) as used herein means the official currency of a country, region, or other globally-recognized governmental entity. For example, the U.S. dollar is the official currency of the country of the United States of America, the Euro is the official currency of the region of the European Union, and the Scottish bank notes are an officially recognized currency in Scotland, notwithstanding the fact that they are tied to the value of the British Pound.
The phrase “functional area” as used herein means any industry, grouping, association, political region (for example special economic zone), type of work, or other field of human endeavor, which may or may not correspond to a geographical area.
The phrase “geographical area” as used herein is used in its common meaning as any demarcated area of the Earth. Geographical areas are often, but not always, defined by agreed-upon borders such as between countries, states, counties, and cities.
A smart contract validation server 101 is a server which may, in some implementations, create the code for a smart contract or self-fulfilling digital contract, may encode the contract in a blockchain, and may validate and execute the contract when conditions are met, the conditions being specified at the time of creation for the smart contract. The smart contract validation server may do this by means of one or several computer programming languages and frameworks that allow for creation of such contract objects.
A user mobile device 102 may be a mobile phone such as a smartphone, a tablet computer, a personal digital assistant or similar, or some other mobile computing device capable of operating software applications and downloading new applications to operate over a network, such as those operating the ANDROID™ or IOS™ operating systems. A user mobile device may operate a client application 102b which handles interfacing between a user and at least a smart wallet server 103, over a network or networks 120, through the use of a graphical user interface and the computing power of the mobile device. Such an application may be used to gather and utilize biometric information about a user for verification purposes, display balances and information about the smart wallet, send information to a smart wallet server to be received and written on the smart wallet blockchain, or in some implementations the application may interact directly with the blockchain. The application may also interface over a network such as WIFI™ or BLUETOOTH™ or over the internet with email, with third party applications and services, to complete transactions, or may display a scannable code for a point-of-sale system to complete the transaction.
A smart wallet server 103 communicates with at least the user application 102b over the network or networks 120, and with a possible plurality of other servers and services, in order to manage the services' interactions with the smart wallet blockchain and end users. The smart wallet server 103 may be in charge of decrypting and providing access to the smart wallet blockchain, and may forward relevant communications between servers and services and the end user for purposes such as risk assessment and jurisdiction services. A smart wallet server may be synonymous with a blockchain host 110, or such a host may be a separate computing device or server.
A health record transaction server 104 is a server which may store blockchain-encoded records of a user's health records, or may provide services for handling them according to local laws and regulations such as HIPAA, for a user. It may also provide services and software protocols for a client application 102b to interface with hospital software over a network 120.
A risk training server 105 is a server which may operate a datastore of some manner internally or externally, such as MONGODB™ or MICROSOFT SQL SERVER™, may receive records of transactions, physical movements of a user, transaction locations and metadata, and establish patterns of behavior for users, which can be matched against future transactions and decisions to determine if potential fraud is being committed rather than a genuine transaction. Furthermore, such basic pattern recognition may be utilized in conjunction with microgestures in the user's body language, facial expressions, or voice patterns, to determine if the user is at risk, under duress, or is dealing with a potentially dishonest or illegitimate businessperson, with the help of a transaction context server 106 and microgesture analysis server 107.
A transaction context server 106 specifically may be used by a risk training server 105 for analyzing the context of given purchases of a user, such as analyzing patterns of user needs and habits in a more abstract sense and then comparing those, and typical or possible future needs such as getting a car oil change in 8 months even if no pattern of getting oil changes is identified yet, to current and pending transactions, to determine if a severe anomaly has been detected. For instance a user's habits might include buying certain accessories for their vehicle, which may not be out of the ordinary, but if they have no history of buying anything relating to new cars or any history of visiting car dealerships, and suddenly a new car has been purchased without any contextual basis for the transaction such as changes to their credit score, visiting dealerships, or having records of conversations with a dealer through the passive monitoring of the smart wallet app, this may be seen as highly suspicious because of the lack of context for the transaction.
A microexpression detection server 107 may receive patterns of user behavior both in terms of their physical body language and facial expressions, and their voice samples and voice patterns of people they interact with, to attempt to gauge the mental and emotional state of both parties in very general terms such as “potentially under duress,” “potentially lying/deceiving,” “honest vendor,” and more, to provide the rating of the user and vendor if available to a risk training server 105 for training of risk models.
A jurisdiction services server 108 may communicate over a network 120 with a smart wallet app 103b to handle integration, if possible, with a user's jurisdiction or various jurisdictions for the purposes of digital voting and storage of voting records on the blockchain, with the smart wallet server 103 and a smart contract validation server 101, in which the smart contract validation server 101 may be used to execute smart contract code for voting mechanisms, if digital voting is allowed in a user's jurisdiction at all.
A DRM-based secure messaging server 109 may provide digital rights management (“DRM”) protection for secure messaging between servers and services listed herein, to encrypt and protect messages exchanged between services and users, where possible. A DRM secure messaging server 109 may be communicated with inbetween each other server or service's communication with another server or service, or a DRM-based secure messaging server 109 may be operated locally in tandem with each other server or service, encrypting and protection messages before they go to the network and then being decrypted at the destination point.
A smart contract validation server 101 is a server which may, in some implementations, create the code for a smart contract or self-fulfilling digital contract, may encode the contract in a blockchain, and may validate and execute the contract when conditions are met, the conditions being specified at the time of creation for the smart contract. The smart contract validation server may do this by means of one or several computer programming languages and frameworks that allow for creation of such contract objects.
A blockchain server or servers 210a, 210x may be a separate server that hosts a smart wallet blockchain, that may be communicated with, for instance with a smart wallet server 103 which may handle permissioned requests from the blockchain server 210a, 210x and then write data to the chain, which is sent back from the smart wallet server 103 to the blockchain servers 210a, 210x to be added as a new block.
A smart wallet server 103 communicates with at least a user application or blockchain server 210a, 210x over the network or networks 120, and with a possible plurality of other servers and services, in order to manage the services' interactions with the smart wallet blockchain and end users. The smart wallet server 103 may be in charge of decrypting and providing access to the smart wallet blockchain, and may forward relevant communications between servers and services and the end user for purposes such as risk assessment and jurisdiction services. A smart wallet server may be synonymous with a blockchain host 110, or such a host may be a separate computing device or server.
A health record transaction server 104 is a server which may store blockchain-encoded records of a user's health records, or may provide services for handling them according to local laws and regulations such as HIPAA, for a user. It may also provide services and software protocols for a client application or blockchain server 210a, 210x to interface with hospital software over a network 120.
A risk training server 105 is a server which may operate a datastore of some manner internally or externally, such as MONGODB™ or MICROSOFT SQL SERVER™, may receive records of transactions, physical movements of a user, transaction locations and metadata, and establish patterns of behavior for users, which can be matched against future transactions and decisions to determine if potential fraud is being committed rather than a genuine transaction. Furthermore, such basic pattern recognition may be utilized in conjunction with microgestures in the user's body language, facial expressions, or voice patterns, to determine if the user is at risk, under duress, or is dealing with a potentially dishonest or illegitimate businessperson, with the help of a transaction context server 106 and microgesture analysis server 107.
A transaction context server 106 specifically may be used by a risk training server 105 for analyzing the context of given purchases of a user, such as analyzing patterns of user needs and habits in a more abstract sense and then comparing those, and typical or possible future needs such as getting a car oil change in 8 months even if no pattern of getting oil changes is identified yet, to current and pending transactions, to determine if a severe anomaly has been detected. For instance a user's habits might include buying certain accessories for their vehicle, which may not be out of the ordinary, but if they have no history of buying anything relating to new cars or any history of visiting car dealerships, and suddenly a new car has been purchased without any contextual basis for the transaction such as changes to their credit score, visiting dealerships, or having records of conversations with a dealer through the passive monitoring of the smart wallet app, this may be seen as highly suspicious because of the lack of context for the transaction.
A microexpression detection server 107 may receive patterns of user behavior both in terms of their physical body language and facial expressions, and their voice samples and voice patterns of people they interact with, to attempt to gauge the mental and emotional state of both parties in very general terms such as “potentially under duress,” “potentially lying/deceiving,” “honest vendor,” and more, to provide the rating of the user and vendor if available to a risk training server 105 for training of risk models.
A jurisdiction services server 108 may communicate over a network 120 with a smart wallet app 103b to handle integration, if possible, with a user's jurisdiction or various jurisdictions for the purposes of digital voting and storage of voting records on the blockchain, with the smart wallet server 103 and a smart contract validation server 101, in which the smart contract validation server 101 may be used to execute smart contract code for voting mechanisms, if digital voting is allowed in a user's jurisdiction at all.
A DRM-based secure messaging server 109 may provide digital rights management (“DRM”) protection for secure messaging between servers and services listed herein, to encrypt and protect messages exchanged between services and users, where possible. A DRM secure messaging server 109 may be communicated with inbetween each other server or service's communication with another server or service, or a DRM-based secure messaging server 109 may be operated locally in tandem with each other server or service, encrypting and protection messages before they go to the network and then being decrypted at the destination point.
A smart contract validation server 101 is a server which may, in some implementations, create the code for a smart contract or self-fulfilling digital contract, may encode the contract in a blockchain, and may validate and execute the contract when conditions are met, the conditions being specified at the time of creation for the smart contract. The smart contract validation server may do this by means of one or several computer programming languages and frameworks that allow for creation of such contract objects.
A user device 310 may possess a copy of a distributed blockchain 320, without having the ability to decrypt or access any blocks except for the blocks which their own biometrics may be permitted to access, through the use of a plurality of servers and services which provide the permissioned protocols and functionality. A distributed blockchain may be hosted by a plurality of devices 330 and exist in a plurality of instances, in which case a smart wallet server 103 or some other server may be required to verify and validate changes to the blockchain. A second possibility exists in which a distributed blockchain 320, 330 may each be a separate blockchain of their own, and not publicly accessible to others, but the blockchain must still be accessed with the proper permissions handled by the other servers and services such as a smart wallet server 103 and microgesture detection server 107 over a network 120.
A smart wallet server 103 communicates with at least a user application or blockchain 320, 330 over the network or networks 120, and with a possible plurality of other servers and services, in order to manage the services' interactions with the smart wallet blockchain and end users. The smart wallet server 103 may be in charge of decrypting and providing access to the smart wallet blockchain, and may forward relevant communications between servers and services and the end user for purposes such as risk assessment and jurisdiction services. A smart wallet server may be synonymous with a blockchain host 110, or such a host may be a separate computing device or server.
A health record transaction server 104 is a server which may store blockchain-encoded records of a user's health records, or may provide services for handling them according to local laws and regulations such as HIPAA, for a user. It may also provide services and software protocols for a client application or blockchain 320, 330 to interface with hospital software over a network 120.
A risk training server 105 is a server which may operate a datastore of some manner internally or externally, such as MONGODB™ or MICROSOFT SQL SERVER™, may receive records of transactions, physical movements of a user, transaction locations and metadata, and establish patterns of behavior for users, which can be matched against future transactions and decisions to determine if potential fraud is being committed rather than a genuine transaction. Furthermore, such basic pattern recognition may be utilized in conjunction with microgestures in the user's body language, facial expressions, or voice patterns, to determine if the user is at risk, under duress, or is dealing with a potentially dishonest or illegitimate businessperson, with the help of a transaction context server 106 and microgesture analysis server 107.
A transaction context server 106 specifically may be used by a risk training server 105 for analyzing the context of given purchases of a user, such as analyzing patterns of user needs and habits in a more abstract sense and then comparing those, and typical or possible future needs such as getting a car oil change in 8 months even if no pattern of getting oil changes is identified yet, to current and pending transactions, to determine if a severe anomaly has been detected. For instance a user's habits might include buying certain accessories for their vehicle, which may not be out of the ordinary, but if they have no history of buying anything relating to new cars or any history of visiting car dealerships, and suddenly a new car has been purchased without any contextual basis for the transaction such as changes to their credit score, visiting dealerships, or having records of conversations with a dealer through the passive monitoring of the smart wallet app, this may be seen as highly suspicious because of the lack of context for the transaction.
A microexpression detection server 107 may receive patterns of user behavior both in terms of their physical body language and facial expressions, and their voice samples and voice patterns of people they interact with, to attempt to gauge the mental and emotional state of both parties in very general terms such as “potentially under duress,” “potentially lying/deceiving,” “honest vendor,” and more, to provide the rating of the user and vendor if available to a risk training server 105 for training of risk models.
A jurisdiction services server 108 may communicate over a network 120 with a smart wallet app 103b to handle integration, if possible, with a user's jurisdiction or various jurisdictions for the purposes of digital voting and storage of voting records on the blockchain, with the smart wallet server 103 and a smart contract validation server 101, in which the smart contract validation server 101 may be used to execute smart contract code for voting mechanisms, if digital voting is allowed in a user's jurisdiction at all.
A DRM-based secure messaging server 109 may provide digital rights management (“DRM”) protection for secure messaging between servers and services listed herein, to encrypt and protect messages exchanged between services and users, where possible. A DRM secure messaging server 109 may be communicated with inbetween each other server or service's communication with another server or service, or a DRM-based secure messaging server 109 may be operated locally in tandem with each other server or service, encrypting and protection messages before they go to the network and then being decrypted at the destination point.
A user 2301 and exemplary organization or organization manager 2310 may use their applications 2302a . . . n and 2311a . . . n, which may be singular applications designed to interface with such a firewalled blockchain network, or may be a plurality of applications for this purpose, to request and send information on their devices 2303 and 2312, respectively. These devices 2303, 2312 may be mobile cellular devices, personal digital assistants (“PDA”), laptop or desktop or other personal computing devices, tablets, or other computing devices capable of operating applications and communicating over a network. User application 2302a . . . n may be a web application such as a browser-enabled application, or an application from an application marketplace such as those on modern smartphones including ANDROID™ and IPHONE™ devices, which allows the user to have several accounts in different organizations/currencies, stores money, and sends transactions to other accounts. Organization manager application 2311a . . . n may be a web application such as a browser-enabled application, or an application from an application marketplace such as those on modern smartphones including ANDROID™ and IPHONE™ devices, which acts as an interface for the organization's SGW.
In a potential first step, a user application 2302a . . . n may request a digital certificate from a certificate authority (“CA”) service 2320, which is a separate container responsible for basic security and identity verification, such as for example the hypertext transfer protocol secure (“HTTPS”). A user application 2302a . . . n may then send an access request to SGW 2321, a separate container which manages the organization's business rules, users, data access, and transactions; and provides local cache mechanisms. After the SGW 2321 validates the application parameters and checks access, user application or applications 2302a . . . n may access blockchain 2322 (the main data store for all money transfers). Blockchain 2322 then sends a success response back to user application 2302a . . . n via SGW 2321.
Such communications may take place with communications protocols over networks including the Internet or a PSTN using dial-tones. User 2302a . . . n and organization manager applications 2311a . . . n can only access the SGW, and only the SGW 2321 can access the blockchain. This restricted access is critical because it creates the firewall.
SGW 2321 may contain at least four elements 2330 including a rules engine 2333 which may inspect requests to make sure requests comply with a set of rules, allowing only select, compliant requests to be passed on to the blockchain. Further, an SGW may include an organization admin 2331 or generic admin module, a report system 2332, and local database (DB) 2334. In this example the datastore 2334 may contain only one organization's data, for instance data pertaining to the users and rulesets for a particular bank's operation. An organizational administration module 2331 may allow qualifying administrators in the system, as specified in the local database 2334, to make changes to the system as required of administrators, including potentially adding other administrators or changing the rules encompassed in the rules engine 2333, or viewing and acting on reports from the report system 2332 which may include reports on unauthorized access attempts, or even a log of authorized SGW usage. However, a database 2334, rules engine 2333, and a security gateway 2321 could potentially be configured to operate for multiple organizations or groups or administrators (or some combination thereof), allowing a centralized system to operate as a blockchain firewall for multiple organizations and users rather than only one.
In addition to deciding whether or not a user application request may continue on to the blockchain, the SGW in this example may manage users at least by creating new accounts, setting account balances, managing rules by checking black and white lists, processing the accounts' limitations, managing data access which guarantees that the user can see only his/her transactions and the organization can manage only its own users, managing transactions which guarantees that the user's transitions are atomic, and provides local cache mechanisms to ensure fast searching and provide rules management.
An exemplary SGW workflow for a user 2505 may begin with a user 2505 sending a request to the SGW 2502, for instance to see their balance, the request being sent via their user application or applications 2507. Such requests may be sent over the Internet, over a wide area or local area network, over the PSTN, or over some other network, and the application or applications may be operating on a device including but not limited to a cellular phone, personal digital assistant, tablet computer, personal computer or laptop, or other computing device capable of the requisite connections and application execution. After an initial request or requests are sent from a user, the SGW 2502 would receive these requests and may check if the request type is allowed 2503 such as with a ruleset or with any of the checks in a database schema such as described earlier, including verifying or having another service verify the identity and authorization of the user making the request. The SGW V might determine if the user 2505 is provisioned to make the request to 2504 based on the database entries including ruleset values, before the SGW 2502 may forward the request to the encapsulated blockchain 2501, whereupon the encapsulated blockchain 2501 may process the request. The encapsulated blockchain 2501 may then send a success response to SGW V 2502, and the SGW V 2502 may pass the success response to user 2505. The SGW workflow for a blacklisted user 2506 may follow a similar succession, except the SGW V 2502 may not forward the user request (sent via blacklisted user application 2508) to the blockchain, and instead may send a standard ETHEREUM® error response back to blacklisted user 2506 after step 3.
It is important to note that the specific steps in the use of the SGW system to produce a secure, firewalled blockchain are not specific only to the ETHEREUM® blockchain implementation, and this system may be used with other forms of blockchain networks, including those used for purposes other than currency transfers. Smart contracts are capable of being executed through the blockchain firewall and security gateway system if the ruleset for permitted transactions and network connections through the SGW V includes smart contract executions, and further, a ruleset and SGW V could be configured to allow only specific kinds of smart contracts, or only smart contracts for specific users, to be executed. The system offers highly modular functionality which may work across numerous network types and in numerous possible situations, and the methodology described merely describes exemplary implementations.
The SGW is crucial to ensure that only select users (those not blacklisted) request the balance of a wallet. In a workflow without an SGW, any user can request the balance of any wallet. In a workflow with an SGW, the standard wallet will send the same request as if there was no SGW, but the SGW V will only allow the user request to pass on if the wallet is not blacklisted. If the wallet is blacklisted, the user will receive a standard error message. Therefore, with a SGW, only select users can request the balance of any wallet.
After the blockchain grants the user access, the user can log in to the SGW online and manage the blacklist and list of users. Managing these lists gives the user control of which users can send requests to the blockchain and gain access to the balance of a wallet.
In other cases, rather than organizations, this SGW could be used for online shopping, supply chain management, software management etc. or any other suitable situation in which insecure devices need to access a secure blockchain section.
In some cases, where users with insecure devices need to access a system with a secure blockchain, a security gateway may be employed. In the systems, the SGW V may have at least two sets of communication ports, a rules engine, an admin module, a reporting system, and a local database. The SGW rules engine is responsible for checking the credentials of the requestor;
inspecting access requests (which may include a TPSC); inspecting the TPSC to ensure compliance with a rule set; and either rejecting or passing on these requests to the blockchain. In cases where a TPSC transfer is accepted, the transfer may only be completed after the TPSC is wrapped in a safety wrapper so it is partially or fully disabled. In some cases, a SGW V with at least two sets of communication ports, one connected to the secure blockchain, with several modules including at least one rules engine, admin module, reporting system, and local database, will have a rules engine that is learning and creating new rules based on inspection of previous transactions on the blockchain. In yet another case, between a secure blockchain, users on a not secure network, a SGW V with at least two sets of communication ports, one connected to the secure blockchain, and that SGW having several modules including at least one rules engine, admin module, reporting system, and local database, that rules engine inspects transactions for compliance with a set of rules, and only fully compliant transactions are passed on. Further, such compliance includes checking of credentials of the transaction initiator. Furthermore, the request or transaction may include a TPSC. In yet some cases, the TPSC is inspected for its behavior according to a rule set, and in response to the outcome of the inspection a transfer may be rejected. Further, that TPSC is inspected for its behavior according to a rule set, and in response to the outcome of the inspection a transfer may be completed only after wrapping the token in a safety wrapper disabling at least part of its active functionality. Moreover, some TPSC are inspected for their behavior according to a rule set, and in response to the outcome of the inspection a transfer may be completed only after placing those tokens in a safety container disabling all of its active functionality. In some cases, in a system with a secure blockchain, users on a not secure network, a SGW with at least two sets of communication ports, one connected to the secure blockchain, the SGW having several modules including at least one rules engine, admin module, reporting system, and local database, that gateway enforcing secure access between endpoints to a blockchain domain that comprises a ledger. In some other cases, in a system with a secure blockchain, users on a not secure network, an SGW with at least two sets of communication ports, one connected to the secure blockchain, that SGW having several modules including at least one rules engine, admin module, reporting system, and local database, that gateway enforcing communication filtering, hardening and Distributed Denial of Service (“DDoS”) protection. In yet other cases, in a system with a secure blockchain, users on a not secure network, an SGW with at least two sets of communication ports, one connected to the secure blockchain, that SGW having several modules including at least one rules engine, admin module, reporting system, and local database, wherein the gateway enforces blockchain protocol filtering based on organizational policy. In some cases, in a system with a secure blockchain, users on a not secure network, a SGW with at least two sets of communication ports, one connected to the secure blockchain, the SGW having several modules including at least one rules engine, admin module, reporting system, and local database, wherein the gateway enforces blockchain protocol filtering based on user identification and adjust to the user permissions.
An individual may register for a wallet with a smart wallet client application 2610, which may require some combination of password, biometric security, and personal information in order to register for it and access it in the future. A user may perform the registration steps with the smart wallet client application 102b, at which point actual registration with the blockchain is attempted by the application, sending data to the smart waller server 103 which is then written onto the blockchain 2605 if registration is successful 2615, 2620. The smart wallet server 103 then sends the blockchain credentials and information to the client application 102b, 2625. An individual may use the wallet according to a specific wallet configuration 2630, in this case an individual wallet. User configurations that may be specified for wallets include the permission method and values, the wallet connection to a bank account or other financial institution (if any), preset limits on how much the wallet is allowed to spend on any one transaction, or other configuration settings. In another embodiment, multiple individuals may register a smart wallet with a client application, each registering individually and with their own device and application, wherein the wallets are set up with an organization configuration which may be specified through the use of smart contracts in the smart wallet blockchain, or which may be specified by the organization the wallet is tied to, using the smart wallet application itself to maintain the connection rather than the blockchain. Individuals with the organizational wallets may utilize the wallets as separate individuals, but with organizational rules and settings, such as any limits the organization's administrator may impose on the spending limit of the wallets, or jurisdiction limitations (such as being unable to use the organizational wallets outside of a specific country, or not being able to use them in a given jurisdiction such as a city), and their wallets may all connect to the same or separate business funding accounts depending on how the organization chooses to set up the wallets. According to a different embodiment for a shared group-wallet, a group of individuals may create a group wallet in a blockchain client application, or may be registered in an existing group wallet by authorized members of the group wallet. In the case of a group wallet, users of the group wallet share one true wallet, with shared permissions and one account balance for the group to utilize, and potentially one transaction history for the wallet that they all share and write to. Regardless of the configuration chosen, the wallet settings are sent from the client application to the smart wallet server 103, 2630, and transaction attempts may then be made with the client application 102 to the smart wallet blockchain 2605, 2635, using the smart wallet server 103 as an intermediary in some embodiments. Whether the transaction is executed or not, the result is reported back to the client application based on the state of the blockchain 2640, letting a user or users (depending on its configuration) know the state of the wallet.
An individual may register for a wallet with a smart wallet client application 2710, 2715, 2720, which may require some combination of password, biometric security, and personal information in order to register for it and access it in the future. Blockchain credentials and decrypted data may be sent to the client application 102b after successful registration on the blockchain 2705, 2725. A smart wallet application may request a user take a current self-photo or “selfie,” and a voice sample, and upload government-issued photo ID (such as a driver's license) through a photograph which may have optical character recognition software identify the specific text of the ID. The new user photo may be checked against the ID to verify a user's identity and ensure the user is who they claim to be, using facial recognition and mapping software, while other identifying information may also be added to prove identity such as their social security number or a similar piece of identifying information, depending on the user's jurisdiction. The user's photo and voice sample and ID may be stored in a permission-based blockchain, and may be updated over time 2730 using a historical database or server that tracks changes in a user's voice and appearance, while a user's historical identifying information and biometrics are stored in the smart wallet blockchain indefinitely along with the updated versions, to establish patterns of user changes in order to build up a user identity over time. In this way, unexpected user changes such as losing a limb, changing hairstyles, growing older, or similar, may be accounted for and will not prevent a user from accessing their smart wallet.
A user may set a wallet's regional rules and travelling rules with client application 2805, in which there may be rules for wallet configuration when travelling to or from specific areas, and rules for when a user travels in general which may be applied when more specific rules are not being applied, or which may be applied if they are compatible with the more specific regional rules set by the user. The wallet server 103 may then ask for periodic updates of the user's position if any, and hand these off to the jurisdiction services server 108, 2810 for processing. A user may then travel to a different region, such as a different state, country, continent, city, or other jurisdiction or region, as detected by a user's GPS coordinates, or cell tower usage, or transactions which may be tied to a specific geographic location, at which point the smart wallet access, balance, and other features may be restricted according to the user's regional rules or travel rules 2815. The travel rules may cover situations where specific regional rules are not specified as previously mentioned, and user transactions in other regions may be examined by transaction context and risk training servers to determine if fraud or theft is occurring 2815, 2820, such as if a user was in Seattle one moment and then suddenly logs a wallet user at London making transactions the next moment. If fraud or theft are detected, the attempting user may be asked to prove their identity with biometrics such as visual or audio cues, voice samples, and microexpressions, before transactions can go through, ensuring only the true user may access the wallet. If a user's travel is legitimate but they have set up rules restricting the wallet's operation abroad for security reasons, the wallet will restrict itself according to their rules 2825, as determined by the jurisdiction services and smart wallet servers 108, 103.
A user may register private records, e.g. medical records, to a smart wallet 2910, through a smart wallet application, which may be written to the smart wallet blockchain, with the use of a specialized health record transaction server 104, 2915. The health record transaction server 104 may provide special functionality and regulation implementations to safeguard user data, such as double encryption. The user may then grant access to other clients, such as medical professionals, to medical records by using the same authentication established for their wallet, including biometrics to access the wallet, to authorize decryption and sharing of medical records, which may be accomplished over a network, through email, or through some other method of sharing data between devices 2920. The authorized medical professionals may add to the medical records by using the connection between their device and the user's device, which manages the data to be written to the wallet blockchain, at which point the medical records may be updated on the blockchain. In this way, the user may carries up-to-date medical records with them, accessible only by them, which may be sharable with medical professionals easily and swiftly wherever they go.
According to this aspect, real-time credit scoring may be performed with multiple servers such as a microexpression detection server, transaction context server, and risk training server, and may utilize a connection to other information and services such as medical records and jurisdiction changes, in order to generate and maintain a new kind of credit scoring that uses a smart wallet and user behaviors to track and maintain user credit worthiness. Client transaction data is tracked and sent to not only the blockchain 3005 but also a transaction context analysis server 106 and risk training server 105, 3010, to be examined for anomalous behavior, credit limit usage of the smart wallet is tied to a credit account, loan payments if applicable, and large transactions which may be a good or bad thing for a user's credit worthiness in different circumstances. Microexpression detection may identify a user or other parties as being potentially illicit in intent 3015 specifically, such as determining that a user may be unsure of their ability to pay a loan back when applying, or determining that a car dealer is potentially behaving unscrupulously based on body language (if available to examine) or voice intonation and wording. Credit score information of the user may be encoded in the smart wallet blockchain, accessible by agencies requiring a credit score if they have installed software to communicate with the smart wallet server and make a request for only the credit score segment of a user wallet, as a result of the smart wallet credit scoring. As part of the credit scoring and individual evaluations, the wallet software may even be configured to warn others if the user is behaving potentially illicitly, or warn its own user if another party or parties are behaving suspiciously based on body language (point camera at each other if allowed) or speech patterns, changes in voice and tone, specific wording and phrasing, outright helping individuals avoid dangerous or illicit interactions based on microexpression validation. Other relevant client data such as travel habits may be sent to servers to be analyzed 3020, and with these data points, the risk training server 105 may issue internal client credit score updates 3025 which may be held only on the servers and may be made available to credit reporting agencies, but in other implementations may also be written to the blockchain 3005.
A user may specify, upon wallet registration, their government ID number such as social security number, in addition to other ID or biometrics normally required for smart wallet creation 3110. The user's location may then be registered and tracked with GPS and their transaction history, when possible, to ensure an accurate user location is available for voting purposes 3115, so that if and when a government agency or other voting agency including a corporate voting agency begins an election and enables digital voting, a smart contract may be created involving the user, to allow voting with the voting agency or agencies, supplying the necessary code to execute a digital vote for the wallet owner for their jurisdiction. A user's voter registration data must also be confirmed by a jurisdiction services server 108 based on a user's identifying information 3120 in order for a user to be allowed to case a digital vote with their smart wallet. In this way, a smart contract validation server and a jurisdiction server may, together, allow for a user to use their smart wallet and personal identifying information to maintain their voter registration and cast their votes 3125. Government or organizational voting rules may be implemented in the smart contract on contract creation, depending on implementations, allowing a smart contract validation server 101 to validate and then execute the code to cast the user's vote 3130. Some governments may not allow digital voting, and digital voting may be disabled or simply not implemented by an organization or government agency, rendering digital voting impossible, but potentially still allowing for user to ID themselves with their wallet as normal for in-person voting, due to being connected to their ID or IDs. In this sense the smart wallet acts not as a voting device, but as an identification tool. Client voting records may also be stored on the blockchain as part of a user's personal information, accessible only to the user unless the user grants access to others, as with medical records.
A user may specify account settings including login and registration information for their smart wallet with a smart wallet application on a mobile device, either at wallet registration or at a later time, for device-resident instancing 3210. A user can specify a duration for their device to maintain a token or for a smart contract to last before execution on smart wallet and smart contract validation servers 3215, that allow the device to access a smart wallet balance for transactions without re-authorization or biometrics, up to a maximum specified by the blockchain provider or implementation 3220. While this validation token is valid, a user may make wallet requests without having to re-authorize, from the same device 3225. After the duration is passed, the token expires due to the smart contract executing causing the device to no longer be authorized for access to the blockchain 3230, and the device must operate client software and go on the blockchain over a network such as the Internet, and re-authorize as normal, through the use of user permissions such as passwords or personal identifying information or biometric authentication, or some combination thereof, as preferred by the implementation of the blockchain and servers and services at hand.
A user, when first creating a smart wallet, may perform pre-set gestures and audio cues in front of their mobile device camera, which may be self-held, or held by another person or a stand of some kind, depending on what their typical use case might be 3310, 3315, 3320. By “pre-set gestures” it is meant either gestures that the smart wallet application asks a user to make for calibration purposes, or gestures that a user decides upon to teach the smart wallet application and microexpression detection server how to recognize specific gestures, microexpressions, and movements in accordance with specific behaviors, or in accordance with a baseline of normal body movement. Pre-set actions may be those defined by the user in advance, i.e. “what I will do now is typical body language while talking to someone,” or defined by client application, i.e. “please make a hand gesture” or “please roll your eyes derisively”. The client application may request the user to repeat gestures multiple times, and may ask for or be given increasingly subtle gestures and contexts for them. A plurality of convolutional neural networks may be applied to photos of numerous angles and repeated gestures to learn how to visually analyze user gestures and microexpressions, and if the client application or microexpression detection server identify something incorrectly in production, a user may select an instance of the wallet taking action, and flag it as inaccurate, requiring re-learning 3325, and backtesting of historical actions with re-learned models to attempt to differentiate its judgement, to improve performance. When the specified gestures or audio cues are detected by the smart wallet application, the smart wallet may limit its own functionality 3330 until the user both authorizes themselves, clears the error, and there are no longer any flagging expressions, movements, or verbal cues being displayed.
A user may set specific circumstances or rules in the smart wallet client application for variable balances, limits, and other features for their smart wallet 3410, such limitations may take the form of a smart contract that executes its code when conditions are met, limiting the smart wallet until conditions change 3415. Conditions may include location which may be tracked by transactions, GPS and phone location, venues and merchants to spend money at, or be context dependent, such as being under duress, detecting a suspicious third party actor such as an untrustworthy salesman, or other contextual conditions for limiting the smart wallet. When conditions are met 3420, the user balance may show a lower amount or user may have their spending limit temporarily lowered, to prevent misuse, fraud, and obey user directives for such limits if set prior, as well as limits not required to be set by a user such as limiting purchases if fraudulent or untrustworthy transactions are suspected 3425.
A user's condition is continuously monitored passively by a smart wallet client on a user's mobile device 3510, listening for verbal cues of events occurring and for the purposes of evaluating the user's mental or emotional state with the help of a microexpression detection server. A user may set up at any time with their smart wallet application, a single or plurality of codewords, activity patterns, facial patterns or body gestures, or other cues or duress signals to signify that the user is under duress 3510, which may alter smart wallet behavior. The client application may learn microexpressions and verbal cues of the user over time, from the use of duress signals and the user actively teaching it, or this learning and application may be relegated to a microexpression detection server and risk analysis server. When the user is detected to be under duress or in danger 3515, the client application may limit the available smart wallet balance and functionality indefinitely, such that the user may attempt a transaction 3520 but is prevented from using the wallet's full functionality 3525 so that a potentially dangerous or fraudulent transaction does not take place, until client is no longer under duress, both by using microgesture and verbal detection, and user biometrics, to ensure both that the user is the one attempting to access the wallet and that the user is not under duress.
When the sender 3603 sends a transaction request to transfer token value to the recipient 3604, the transaction request goes to the immutable ledger manager 2700, which issues a token distribution request to intermediary A 3601, which checks its immutable ledger for entries associated with the sender 3603. If the sender 3603 has a sufficient token value in the intermediary A's 3601 immutable ledger, intermediary A 3601 adds a new entry to its immutable ledger reducing the sender's 3603 token value and issuing a new token for the value the sender requested to distribute. The sender 3603 is notified of the reduction in value of the sender's token and a confirmation of the creation of the new token in favor of the recipient 3604 is sent to the immutable ledger manager 3700. Note that, in this embodiment, the new token itself is not transferred, just the confirmation of the creation and storage of the new token in the immutable ledger of intermediary A 3601, which has now also become a token holder for the recipient 3604. However, in other embodiments, an entry about the new token may be entered in the immutable ledger of intermediary A 3601 and an actual digital token transferred.
Upon receipt of the token distribution confirmation, the immutable ledger manager 3700 issues a token issuance request to intermediary B 3602, an intermediary which holds tokens for the recipient 3604. Intermediary B 3602 adds a new entry to its immutable ledger, adding value to the recipient's token in the amount of the new token generated and stored at intermediary A 3601, and sending a token issuance confirmation to the immutable ledger manager 3700, which sends a token issuance notification both to the recipient 3604 and to intermediary A 3601, which adds an entry to its immutable ledger canceling the new token on its own immutable ledger. The recipient 3604 may then request access to or use of the value of the new token stored at intermediary B 3602 on the recipient's 3604 behalf.
In other embodiments, instead of canceling the token at intermediary A 3601, intermediary B 3602 simply notes that the new token exists on the immutable ledger of intermediary A 3601 in favor of the recipient 3604 (i.e., a pointer is created on the immutable ledger of intermediary B 3602 pointing to the existence of the new token held by intermediary A 3601 in favor of the recipient 3604).
In this example, because the immutable ledgers at the intermediaries 3601-3602 are privately held and not open to public inspection as in distributed blockchain implementations, a different form of trust and verification must be used. Here, auditors 3605 may be allowed to access the immutable ledgers of the intermediaries 3601-3602. Various auditor arrangements may be used to provide trust and verification while still maintaining the confidentiality of the privately held immutable ledgers. As one example, third party private auditors may be hired by contract to conduct audits under an obligation of confidentiality. As another example, small groups of intermediaries (e.g., small local banks) may group together to arrange their immutable ledgers into small distributed immutable ledgers wherein the members of the group verify the integrity of one another's immutable ledgers by performing testing of the hashes of those immutable ledgers.
Audits may be conducted manually, or by automated random sampling, or both. In the case of a manual audit, an audit request is received by the auditing portal 3705, which verifies that the credentials contained in the audit request are valid, and then provides access to the immutable ledger of interest through the transaction router 3704. The results of the audit may be stored in an auditing database 3706 for subsequent verification. In an audit conducted by automated random sampling 3707, the audit random sample engine 3707 may periodically select random tokens to query from a random immutable ledger and confirm with that ledger that the value of those tokens is as stored in the auditing database 3706, or may randomly select an immutable ledger for testing of the hash of that ledger against a hash in the auditing database to confirm the validity of the ledger. Many variations of this sort of auditing are possible.
While there are many possible multi-party transactions, for purposes of clarity, let Entity A be a producer of goods, Entity B be a distributor, and Entity C be a merchant. Entity A produces goods for distribution to its merchants. Entity A's immutable ledger 3801 issues an original token for the goods and enters a new entry on its immutable ledger indicating that the goods have been produced. Entity A's immutable ledger further sends a token issuance request to Entity B's immutable ledger 3804, the token issuance request indicating that the goods are ready for pickup and distribution by Entity B. When Entity B picks up the goods, Entity B's immutable ledger issues the requested token and enters a new entry on Entity B's immutable ledger, indicating that the goods have been picked up for distribution. Entity B delivers the goods to Entity C, and Entity B's immutable ledger 3804 sends a token issuance request for a portion of the goods (i.e., a portion of the token issued and stored on Entity B's immutable ledger 3804) to Entity C. Upon acceptance of the portion of the goods delivered, Entity C's immutable ledger 3807 issues the requested token and enters a new entry on Entity C's immutable ledger 3807, indicating that the portion of the goods have been accepted by Entity C. Entity C's immutable ledger 3807 further sends a token cancelation request to Entity A's immutable ledger 3801, whereupon Entity A's immutable ledger 3801 enters a new entry that the portion of goods was received by Entity C, and that that portion of the its originally issued token on Entity A's immutable ledger 3801 for production of the goods can be canceled, as that portion of the goods have been confirmed as delivered to Entity C. The token cancelation process follows through by having Entity A's immutable ledger issue a token cancelation request to Entity B's immutable ledger 3804, which sends a token cancelation request to Entity C's immutable ledger 3807. In this manner, a full accounting and tracking of the entirety of the produced goods and their distribution to various distributors and/or merchants is permanently recorded on three separate, private immutable ledgers, the trust and validity of each of which is ensured by the auditor's copies.
The above example shows a transaction involving a supply chain for production and sale of goods, but this process may be used for any trackable information for which a historical record is needed (e.g., a series of events, a checklist of items to complete, etc.). In the context of supply chains, for example, the token may simply represent the events of producing, shipping, and receiving the goods or a portion of the goods. For purposes of clarity, this simplified example above includes only three entities, but this process may be extended to any number of entities in a supply chain or any other chain of transactions or events. The process may be branched at any level, some connections may be bi-directional, and there may be cyclical processes.
Different processes or concepts may be used for issuance of tokens. In the supply chain example above, an original token is issued by the first entity in the transaction, and all or a portion of it is passed from one entity to the next, whereupon it is eventually returned to the first entity in the transaction to be canceled out (which may occur in parts if the token has been divided along the way). An original token would be the first record of a chain of transactions or events across one or more immutable ledgers, and may be either permanent or temporary. In other embodiments, each entity along the way issues and retains its own permanent tokens, and sends requests to other entities for issuance or cancelation of their own permanent tokens representing all of, or a portion of, the information contained in the token held by the requesting entity. Permanent tokens represent the generation of new trackable information and would not normally expire automatically (e.g., due to expiration of a time limit). In other embodiments, a first entity issues and retains its own permanent tokens, and sends requests to other entities for issuance or cancelation of their own temporary tokens representing all of, or a portion of, the information contained in the token held by the requesting entity. Temporary tokens represent information related to a permanent token, and do not represent new trackable information. Temporary tokens may be configured to expire automatically (e.g., due to expiration of a time limit). In yet other embodiments, a first entity issues and retains its own permanent tokens, and sends requests to other entities to record pointers in their immutable ledgers to all of, or a portion of, the permanent token(s) held by the first entity.
Note that it is not required that each entity create and maintain a separate immutable ledger. If a party in a transaction chain has an immutable ledger that is trusted by other parties in the transaction chain, the parties who trust the immutable ledger may simply rely on the trusted immutable ledger to record the transactions. Thus, in some cases, there may be only one immutable ledger in a chain of transactions (where the immutable ledger is trusted by all parties involved) or there may be any number of such immutable ledgers, where certain parties in the chain of transactions trust the immutable ledgers of some of the other parties, but not others.
The sender 3901 initiates a transaction through his or her communication device 3902, which may be any computing device configurable to support digital smart wallets, the transaction request is received by Bank A's immutable ledger manager 3911, which confirms the identity of the sender 3901 and the validity of the transaction using a know your customer (KYC) or know your customer compliance (KYCC) service 3903 using the credentials contained in the sender's 3901 digital smart wallet stored in the customer wallet database 3912 at Bank A 3910. Bank A's immutable ledger manager 3911 then enters a new entry on its immutable ledger with a token value deduction from the token or tokens stored for the sender and a corresponding token value issuance in favor of the recipient 3904. Where the recipient 3904 is already a customer of the bank 3904 or already has a token or tokens on the bank's 3910 immutable ledger, the bank 3910 may simply notify the recipient 3904 of the new entry showing the token value issuance in favor of the recipient 3904. Where the recipient 3904 is not known to the bank, the bank 3910 may issue a notice to the recipient using information contained in the transaction request. When the recipient 3904 responds to the request, the bank's immutable ledger manager 3911 confirms the identity of the recipient 3904 and the validity of the transaction using a know your customer (KYC) or know your customer compliance (KYCC) service 3906 using the credentials contained in the recipient's response, which may be credentials from the recipient's digital smart wallet stored on the recipient's communication device 3905 or a digital smart wallet stored on a cloud-based service, etc. After confirmation of identity, the recipient 3904 is granted access to, and use of, the token value in his or her favor.
Note that in a single bank embodiment such as the one described here, no reciliation of other immutable ledgers is required (unless the bank's implementation has multiple internal immutable ledgers). Further, while this example shows a bank as an intermediary, the intermediary may be of any form capable of operating an immutable ledger manager and an immutable ledger. This may include the communications devices 3902, 3905 of the sender 3901 and/or the recipient 3904, in which case the transaction is made directly between the communication devices 3902, 3905 without an intermediary.
In this example, Bank A 4020 has an immutable ledger containing tokens for sender 4001, and Bank B has an immutable ledger containing tokens for recipient 4004. Neither bank has access to the immutable ledger of the other, so the transaction is coordinated through an external interbank immutable ledger manager 4010. The sender 4001 initiates a transaction through his or her communication device 4002, which may be any computing device configurable to support digital smart wallets, the transaction request is received by Bank A's immutable ledger manager 4021, which confirms the identity of the sender 4001 and the validity of the transaction using a know your customer (KYC) or know your customer compliance (KYCC) service 4003 using the credentials contained in the sender's 4001 digital smart wallet stored in the customer wallet database 4022 at Bank A 4020. Bank A's immutable ledger manager 4021 then enters a new entry on its immutable ledger with a token value deduction from the token or tokens stored for the sender and a corresponding token value issuance in favor of the recipient 4004. Bank A's issuance of the token distribution is sent by the sender's communication device 4002 as a token distribution notification to the interbank immutable ledger manager 4010, which forwards the token distribution request to Bank B's immutable ledger manager 4031.
In this example, the sender 4001 is not known to Bank B, so Bank B's immutable ledger manager 4031 confirms the identity of the sender 4001 and the validity of the transaction using a know your customer (KYC) or know your customer compliance (KYCC) service 4006 using the credentials contained in the sender's token distribution notification, which may be credentials from the sender's digital smart wallet stored on the sender's communication device 4002 or a digital smart wallet stored on a cloud-based service, etc. After confirmation of identity, the value of the tokens from sender 4001 is entered as a new entry on Bank B's 4030 immutable ledger in favor of recipient 4004. In some embodiments, the immutable ledger of Bank B will simply contain a pointer to the token stored on the immutable ledger of Bank A in favor of recipient, and not an actual shift or transfer of token value.
Note that the multiple bank embodiment such as the one described here, no reciliation of other immutable ledgers between Bank A 4020 and Bank B 4030 is required. Further, while this example shows banks as intermediaries, the intermediary may be of any form capable of operating an immutable ledger manager and an immutable ledger. This may include the communications devices 4002, 4005 of the sender 4001 and/or the recipient 4004, in which case the transaction is made directly between the communication devices 4002, 4005 without an intermediary.
When the sender 4001 initiates a transaction through his or her communication device 4108, which may be any computing device configurable to support digital smart wallets, the transaction request is received by the local domestic bank's immutable ledger manager 4103, which confirms the identity of the sender 4107 and the validity of the transaction using a know your customer (KYC) or know your customer compliance (KYCC) service 4109 using the credentials contained in the sender's 4107 digital smart wallet. The local domestic bank's immutable ledger manager 4103 then enters a new entry on its immutable ledger with a token value deduction from the token or tokens stored for the sender and a corresponding token value issuance in favor of the recipient 4110. The local domestic bank's immutable ledger manager 4103 then send a token distribution notification to the international immutable ledger manager 4101, which coordinates a foreign currency exchange with the international bank 4102, and sends a token distribution request for the exchanged value of the token to the foreign bank immutable ledger manager 4105.
In this example, the sender 4107 is not known to the local foreign bank 4106, so the foreign bank's immutable ledger manager 4105 confirms the identity of the sender 4107 and the validity of the transaction using a know your customer (KYC) or know your customer compliance (KYCC) service 4112 using the credentials contained in the sender's token distribution notification, which may be credentials from the sender's digital smart wallet stored on the sender's communication device 4002 or a digital smart wallet stored on a cloud-based service, etc. After confirmation of identity, the exchanged value of the tokens from sender 4107 is entered as a new entry on foreign bank's 4105 immutable ledger in favor of recipient 4004. In some embodiments, the immutable ledger of the local foreign bank will simply contain a pointer to the token stored on the immutable ledger of the local domestic bank in favor of recipient, and not an actual shift or transfer of token value.
Note that, in this embodiment where there is a foreign currency exchange requirement, settlement between the immutable ledgers of the local domestic bank 4104 and the local foreign bank 4106 may be required. Such a settlement is coordinated by the international immutable ledger 4101, and may be stored as an third immutable ledger kept by the international bank 4102.
The VPN manager establishes a virtual private network among the various communications devices 4201. As communications (including transaction requests) are received by a communications device through the VPN, transactions are separated out and sent to an immutable ledger manager 4203, which updates an immutable ledger to reflect the transaction by creating a new entry on the immutable ledger showing a reduction in value of the token from the wallet associated with the sending device and a corresponding increase in value of the token from the wallet associated with the receiving device. A notification of the new entry on the immutable ledger is sent via the VPN back to the communication devices 4201 involved in the transaction.
Other types of communications are sent to a network interface 4205, which routes audio, video, and text communications to other components of the system. Video conference requests between communication devices 4201 are routed to a private room manager 4204 which establishes a private video conference through the VPN among communication devices 4201 participating in the video conference. Audio to audio communication requests are sent to call/intercom manager 4206 which establishes audio communications through the VPN between participating communication devices 4201. The audio communications may be on different types of audio networks (e.g., one device may be on a cellular network, which the other device is using a voice-over-Internet-protocol (VOIP) audio connection). Audio to text communications (e.g., a voicemail to be translated to a text message) are sent to an ASR engine 4209 and the resulting text is forwarded to an NLP engine 4208 for further processing. Text, whether direct from a text message or converted by the ASR engine 4209 is sent to a natural language processing engine 4208 to determine the context and meaning of the text such that an appropriate response can be formulated. Where the communication devices 4201 involved in the communication operate in different languages, the text may be translated from one language to another using a multi-language translator 4210.
Finally, the text is sent either to a chatbot manager 4211 for formulation of a response. When text is received by the chatbot manager 4211 from a sending device to a recipient device, the chatbot manager 4211 determines from the output of the NLP engine 4208 whether a response is needed, and if so, what kind of response. It formulates an appropriate text response (using the NLP engine 4208, where necessary), and sends a response back to the receiving device, answering the text communication sent by the sending device. Where the sending device is communicating by text (e.g., text message) and the receiving device expects an audio response (e.g., voicemail) the response text is sent through a TTS engine 4207 to convert the text of the response to audio for receipt by the receiving device.
As an example, user A 4311 may establish an automatic monthly payment to user B 4314. Each month on the specified date, the digital smart wallet 4325 on user A's 4311 communication device 4312 will send a transaction request through the communications integration and automation platform 4200 to make the payment to user B 4313. The communications integration and automation platform 4200 will coordinate the transfer with the digital smart wallet 4335 on user B's 4314 communication device 4313, and the transfer will be made without any input from either user A 4311 or user B 4314.
The nodes 4807 typically hold copies of the blockchain, which acts as the ledger of a blockchain transaction. Also, the sender 4801 and recipient 4810 have digital wallets (not shown) that store information about their accounts. The complete details of blockchain transactions are not shown here, but they are well known in the art. Examples of cybercurrency currently using such an approach are Bitcoin, which has the bitcoin as the principal unit of currency and the satoshi, equal to 0.00000001 bitcoin. Another cybercurrency is the Ether (ETH), one of which is currently (mid July 5717) valued at approximately one-twelfth of a Bitcoin (BTC) and has approximately one million subunits. The problem, as mentioned above, is that it can take roughly half an hour to get a sufficient number of ledgers in a blockchain to execute a simple wallet transaction. For example, when a user wants to send an amount from one wallet to another, he needs to point to the address where his wallet keeps the bitcoin that he has currently with his private pointer and take the amount in that location. He then points to the payee and indicates the amount that he wants to send to the payee, retaining the rest for himself as the payor. The amount in that wallet location is split in two, with one amount sent to the payee and the remainder sent back to the payor. Such is the transaction in the blockchain, which can be publicly inspected. When a sufficient number of nodes in the blockchain community have accepted this transaction, it is considered fulfilled and transacted. The problem is that most participants who make such transactions, often for a small amount of satoshi, use most of the capacity for mining new bitcoin, so that mining is becoming increasingly more expensive. As a result, with the growing size of the ledger, the time for this transaction, waiting in queue and then actually executing, grows exceedingly long, leaving the cybercurrency involved in the transaction vulnerable to currency fluctuations. Also, mixer service or mixer wallets are sometimes used to anonymize currency. Many approaches exist and are known in the art.
One or more different aspects may be described in the present application. Further, for one or more of the aspects described herein, numerous alternative arrangements may be described; it should be appreciated that these are presented for illustrative purposes only and are not limiting of the aspects contained herein or the claims presented herein in any way. One or more of the arrangements may be widely applicable to numerous aspects, as may be readily apparent from the disclosure. In general, arrangements are described in sufficient detail to enable those skilled in the art to practice one or more of the aspects, and it should be appreciated that other arrangements may be utilized and that structural, logical, software, electrical and other changes may be made without departing from the scope of the particular aspects. Particular features of one or more of the aspects described herein may be described with reference to one or more particular aspects or figures that form a part of the present disclosure, and in which are shown, by way of illustration, specific arrangements of one or more of the aspects. It should be appreciated, however, that such features are not limited to usage in the one or more particular aspects or figures with reference to which they are described. The present disclosure is neither a literal description of all arrangements of one or more of the aspects nor a listing of features of one or more of the aspects that must be present in all arrangements.
Headings of sections provided in this patent application and the title of this patent application are for convenience only, and are not to be taken as limiting the disclosure in any way.
Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more communication means or intermediaries, logical or physical.
A description of an aspect with several components in communication with each other does not imply that all such components are required. To the contrary, a variety of optional components may be described to illustrate a wide variety of possible aspects and in order to more fully illustrate one or more aspects. Similarly, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may generally be configured to work in alternate orders, unless specifically stated to the contrary. In other words, any sequence or order of steps that may be described in this patent application does not, in and of itself, indicate a requirement that the steps be performed in that order. The steps of described processes may be performed in any order practical. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to one or more of the aspects, and does not imply that the illustrated process is preferred. Also, steps are generally described once per aspect, but this does not mean they must occur once, or that they may only occur once each time a process, method, or algorithm is carried out or executed. Some steps may be omitted in some aspects or some occurrences, or some steps may be executed more than once in a given aspect or occurrence.
When a single device or article is described herein, it will be readily apparent that more than one device or article may be used in place of a single device or article. Similarly, where more than one device or article is described herein, it will be readily apparent that a single device or article may be used in place of the more than one device or article.
The functionality or the features of a device may be alternatively embodied by one or more other devices that are not explicitly described as having such functionality or features. Thus, other aspects need not include the device itself.
Techniques and mechanisms described or referenced herein will sometimes be described in singular form for clarity. However, it should be appreciated that particular aspects may include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise. Process descriptions or blocks in figures should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of various aspects in which, for example, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those having ordinary skill in the art.
The machines that process transactions in these regions can process only in their own region, and only fractional transactions. Also, because only fractional transactions of fractional currency occur in these regions, no currency mining can occur, because no mining is allowed in these regions. If a user wants to change the currency, the currency is reserved via gateways 4910 and 4911 and blocked into the ledger in the main region and transferred into the lower region and made available as fractional currency. A small portion of that coin is then allocated to the operators of the ledger machines in each region, to pay operating costs. With no mining occurring in the regions, and with the regions being regionally limited in range, the cost of operation is much lower. Also, the local fractional currency could be, for example, bound to a local physical currency such as, for example, the U.S. dollar or the Euro, rather than to a cybercurrency such as Bitcoin or Ether, so there might be a local master currency available, issued by the conversion gateway, such as gateway 4910 or 4911, which would be paid for by currency in the upper domain and then actually converted by the gateways into a local physical currency. Those gateways might act as central banks, rather than as gateways, issuing a fractional currency only, and further in these regions there cannot be mining. Thus the transactions are faster and less vulnerable to currency fluctuations. Additionally, the ledgers may be split by years, with the current ledgers containing only transaction for the current year or two, and all previous transactions kept in archived ledgers, accessed only if a user has a wallet with an old balance. In such a case, as soon as the user wants to use the old balance, the wallet is retrieved from the archive, updated, and removed from the archive. Thus archived wallets may take a little longer to transact, but current wallets are much faster, because the ledger is kept current only in the ledger currency. Because the ledgers are regionalized, they can be much smaller and thus process transactions much more quickly. However, being regionalized does not mean a ledger is limited to one country. For example, in North America, each region could contain a piece of Canada, the United States, and Mexico. Thus, including multiple jurisdictions could avoid putting a region under the control of just one country. Wallets could simultaneously contain the physical currency of multiple regions, such as, for example, Euros, dollars, and yen. Most people spend currency in their home region, so merchants could execute transactions much more cheaply, because of the reduced risk of currency fluctuations in most cases.
Further, in some cases, when liquidity runs below a certain level, due to large outflow, a program or an AI module in the system can take at least one of several countermeasures: a) it can change exchange rate to reduce outflow, b) it can offer an interest for delaying a conversion, or c) it makes a cash call on certain members of a reserve group to allow a larger reserve to be built up quickly and thus maintain liquidity. This process can be triggered in an automated way by software and or an AI supervisory module (not shown) running as part of the management software of the system on at least one of the servers or as part of the EVM system (or similar) or both.
Various embodiments of the present disclosure may be implemented in computer hardware, firmware, software, and/or combinations thereof. Methods of the present disclosure can be implemented via a computer program instructions stored on one or more non-transitory computer-readable storage devices for execution by a processor. Likewise, various processes (or portions thereof) of the present disclosure can be performed by a processor executing computer program instructions. Embodiments of the present disclosure may be implemented via one or more computer programs that are executable on a computer system including at least one processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program can be implemented in any suitable manner, including via a high-level procedural or object-oriented programming language and/or via assembly or machine language. Systems of the present disclosure may include, by way of example, both general and special purpose microprocessors which may retrieve instructions and data to and from various types of volatile and/or non-volatile memory. Computer systems operating in conjunction with the embodiments of the present disclosure may include one or more mass storage devices for storing data files, which may include: magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data (also called the “non-transitory computer-readable storage media”) include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits) and other forms of hardware.
In some cases, a cryptocurrency system may include one or more demarcated sections, or areas, in which transactions are limited to those of a lesser denomination, with a limited number of ledger transacting nodes and a limited number of gateways interacting between the general area of unlimited currency and the demarcated area. Such areas may have a limited-time active ledger, and older transactions are moved to an archive to speed up new transactions. In such cases, old wallet entries are then transferred at the time of use to a new section of a new ledger. Also, in that demarcated area, no mining is allowed.
Further, in this area, a central issuer, or bank, with a reserve, may stabilize the currency, and currency in this area may be traded at a fixed rate to another currency in the same area, which may be a real currency rather on a major cryptocurrency. Additionally, in such areas, so called mixer wallets may be blocked or confiscated to avoid misuse of funds for illegitimate purposes.
Further, while looking at details of a node, such as node 5209, a user can click a login information link and open a new window 5206 to see what is happening in detail inside the node, for example on the blockchain 5207a-n. An analogous approach for clients 5205 would result in multiple additional terminal windows.
For the infrastructure and pre-generated datasets, there would be, for example, five nodes, at a minimum, in a private ETHEREUM®-based network in the AWS cloud. Pre-generated ad re-usable datasets could comprise 10,000 accounts (wallets), where each wallet holds a random number of tokens between 10 and 5100. In a simplified view such as
In the implementation phases, the goal for each phase is to measure performance. Performance may be defined as N transactions/seconds (TPS), with the TPS stable after M seconds.
In phase one of building such a system, a minimum five-node ETHEREUM® network is established on AWS. Then datasets are pregenerated in a database, such as, for example, Mongo database. Programs to generate accounts and wallets with tokens in ETHEREUM® and to pre-load transactions in ETHEREUM® queues without executing them are created. Transaction in out-of-box ETHEREUM® are executed, and performance is measured. The test run may be stopped after the TPS becomes stable. Then the test run and measurements are repeated using a 15-node ETHEREUM® network.
In phase two, users would decrease the ETHEREUM® block time to six seconds, run transactions, and measure performance. Testing would be repeated, decreasing the ETHEREUM® block time further, running transactions, and measuring performance, until we the minimum viable block time is established.
It is expected that Phase 1 and 2 should be completed in 2 weeks from start.
Phase three runs in parallel to phases one and two. In phase three, the crypto puzzle is replaced with alternative puzzles such as a trust puzzle that is much simple and faster, enabling the TPS to increase dramatically. Transactions are run in iterations, and performance is measured.
Phase four requires additional implementation of demarcated blockchains. Again, this phase runs in parallel to phases one and two. Transactions are run in iterations, and performance is measured.
Phase five comprises establishment of shared blockchains. Again, this phase runs in parallel to phases one, two, and three. Transactions are run in iterations, and performance is measured.
Further, digital (token) wallets for this multi-bank retail blockchain (not shown) can enable, via API, integration of existing banking apps and wallet apps, so a user can operate all his accounts and transactions from one location.
As money is moved among various different banks on the blockchain, typically by users transacting on the above-mentioned handsets acting as mobile wallets, money between the FIAT pools 5602a through 5602n needs to be moved between banks periodically to reflect the motion of tokens on the blockchain, either because the difference between tokens and FIAT between banks has grown too large, during or at the end of the day. Such moves are typically done through the RTGS network 5610. However, currently in the United States, the federal reserve shuts down such activities at night, during the weekend, and on holidays. In many other countries RTGS systems shut down in similar manner as in the United States. Thus, during such periods of enforced inactivity, a large imbalance may occur, and there is even the theoretical possibility of a bank becoming illiquid because more money has gone out than the bank owns. As an alternative solution, central bank 5611 may keep an account, such as account 5613, open at all times, 24/7/365, as well as operate at least part of RTGS 5610 accordingly. Or, if the bank is unwilling to operate around the clock, the central bank may hold the FIAT money in accounts such as account 5613, during hours of inactivity, and update the FIAT pools correctly at the next instance of activity based on the status reported from blockchain. Alternatively, at least one clearing house, such as clearing house 5621 (only one shown), may keep a special account, such as account 5622 (only one shown), open during the hours when banks are not open, that is, nights, weekends, holidays, or as a normal transaction vehicle for FIAT transactions among banks. In that case, banks would transfer, for example, all their balances every 10 or 15 minutes, or even every 5 minutes, depending on their volume, frequency of transactions, imbalances, and other triggers as desired or required, into or from the clearing house. Thus the clearing house plays the role of a trusted third party, similar to the central bank, as the clearing house has relationships 5620 with most, if not all, banks, and is a trusted, licensed player in the banking system. A clearing house can take over this role easily, and most clearing houses today operate 24/7/365, because they have this transaction capability for the stock exchanges. Hence, they can offer, for a small fee, to do FIAT transactions for the banks. These transactions can be done in a single account or they could be done as subaccounts for each bank, in which case the clearing could happen locally. Thus, the balances could be always reflected correctly, 24/7, and FIAT balances could be operated correctly, no matter whether the central bank is available or not. In places where there is no central bank and no clearing houses, a third party could be used to provide clearing bank services. In some cases, these FIAT transactions could be operated over the blockchain network rather than over the regular RTGS network.
In some cases, banks linked in a private network, which in some cases may be a virtual private network, may participate in transactions made on behalf of their retail customers on a retail-oriented blockchain. In addition, a supervisory bank or agency may participate in this private network, so that in certain cases this supervisory party may exert its supervisory power under a contractual agreement. These banks may also participate in a second private network for blockchain transactions, which network may be used for interbank and international transactions. Furthermore, a preferred Internet provider may be connected to the banks' private network. This provider may hold the master security certificate for operating the private network, or it may transfer the master security certificate to the supervisory bank or agency, thus making the recipient of the master certificate the future provider of the master security certificate. In other cases, a non-transacting auditor may also be connected to the private network. The holder of the master key may be located in the private network, linked with its own computing device on the blockchain, enabling auditors to have various levels of access rights, including but not limited to section-limited, read-only limited, time- or time-period limited, etc. access to the blockchain via certificate and network access for audit and review purposes under a contractual agreement.
In a system where payments are done using tokens representing a currency, these tokens may be transacted on a blockchain and sometimes moved among banks, possibly resulting in an imbalance of bank FIAT accounts. In such cases, from time to time one or more banks may require a transfer on an RTGS system to correct a such an imbalance. In those cases where said RTGS system is not available during hours of non-operation, banks may move the RTGS transfer to a clearing house that is operational non-stop without any breaks, thus enabling settlements at any time of any day of the year. In some cases, to avoid complicated transfers of operations, such operations may always run via a clearing house. Further, the transfers to the clearing house are operated using the block chain network, to avoid any limitation of the RTGS time of operation. Additionally, should a particular bank's available balance on its FIAT account drop below a preset threshold, either the central bank or another pre-agreed partner will automatically launch an infusion of additional FIAT funds into the bank's account to maintain sufficient liquidity. Alternatively, rather than depending on a preset threshold, an AI system may be used to calculate the level upon which such an infusion is made, and also to calculate the required size of the infusion to stabilize the bank. In all such cases, one or more persons or institutions are notified at or shortly before such an event.
In various aspects, functionality for implementing systems or methods of various aspects may be distributed among any number of client and/or server components. For example, various software modules may be implemented for performing various functions in connection with the system of any particular aspect, and such modules may be variously implemented to run on server and/or client components.
Referring generally to
In the example, The LGs either net out as they trade, or they act as a hedge of the L currencies at the same price for the buy and sell. Any “know your customer” (KYC) or other regulatory certificates are added as necessary into the transaction.
In those cases where there are regulatory issues with the LGs needing to be actually transferred rather than netted, traders would need to inventory a small amount of LG to facilitate these spread trades.
In this system for transacting multiple payment tokens on a blockchain, it has at least one processor, but typically many more, often in the cloud, or in different location for redundancy and security. Application software running on that system (meaning on at least one of the processors) allows one to perform the steps of a transaction consisting of listing a first trader buying an intermediary token with a first currency with the intent to buy a second currency, finding at least one second trader willing to sell a matching amount of said second currency sought by first trader against said intermediary token, and once a price has been agreed upon, a transaction is closed. Further, in some cases, the step of the intermediary token is explicit. Furthermore, in other cases the step of the intermediary token is eliminated after the regulatory needs have been met. In yet other cases after the transaction closes the intermediary token in immediately re-used in a new transaction thereafter.
Once the user spends his e-cryptos, full or fractional crypto tokens are settled via the non-permissioned blockchains with the respective parties. Since the user had to use his more secure wallet, only authorized transactions will be enabled and cleared.
Because there are multiple types of networking information embedded in the QR code, of interest is the specific networking information extracted in step 6104. The specific networking information may be used in step 6105, a decision tree that determines the best choice of network. For example, if the merchant and buyer have different phones (android versus iOS) a different type of network may be the appropriate choice compared to if both parties have the same phone. This is because certain types of networks only work between two phones with the same operating system versus two phones with different operating systems. Therefore, there are typically four P2P network options, including in some cases additionally near field communication or other suitable methods to choose from in step 6106a-n, depending on the situation: direct Wi-Fi, ad hoc Wi-Fi, P2P Wi-Fi, P2P barcode and P2P Bluetooth, or any other suitable option. Other factors that influence network choice are whether the location has fixed Wi-Fi or whether the merchant is willing to share its Wi-Fi. If not, an ad-hoc P2P type network may be best. For example, in some cases, rather than using a traditional wireless local network, the two devices may exchange a series of at least two 2D barcodes or QR codes with each other, having the same net effect of conducting a private local data exchange. In some aspects, such private data exchanges are conducted using closed and trusted applications (apps) on each device that create and read dynamic, time dependent and encrypted 2d barcodes or QR codes.
Step 6107a-n shows the different kinds of connection parameters necessary for each type of P2P network. If the connection fails during step 6108, the transaction loops back to step 6109 to try a different approach and select the next best connection parameter. If the connection succeeds during step 6108, the transaction continues on to step 6110. Step 6111 tests if the transaction is connected to the backbone. If not, both the merchant and buyer phones propagate the transaction (with increasing intervals) to other known, trusted devices in step 6113 until one of these devices connects to the backbone. If so, the transaction ends at step 6112.
This process 6100 protects merchants by ensuring buyers can't cheat or deny involvement in a transaction and vice versa. Buyers and sellers are accountable for their transactions because of step 6111, in which other devices can get an encrypted copy of this transaction, and any or all of them may then send this transaction to the backbone. (For example, even if the buyer throws away his device and claims to not have done the transaction, said transaction may have propagated through other devices to the backbone and still be registered.)
This process 6100 also ensures that the network can't be abused or used for personal gain. Because the network is only live for the duration of the transaction (a few seconds or minutes), and is not available after the transaction is completed, the user can't use it to download movies, for example. Also, in cases where the network only connects to the merchant's phone, instead of through to the backbone, the user won't have access to the Internet. In these cases the transaction is propagated to the backbone from the merchant's phone into the blockchain, etc.
Once a transaction has been sent to the backbone, it is added to the blockchain. Multiple copies may be added and should reconcile. If they don't, it may invoke a dispute resolution. Typically, offline transactions are limited in amount and numbers of transactions. Amount and number may vary depending on account balance and account history and offline rating and dispute history or lack thereof.
In systems where transactions are unable to connect to the backbone, the merchant phone and the buyer phone connect via an ad hoc network. Both phones keep a record of this transaction and make repeat attempts to send this information to the backbone. If neither phone can connect to the backbone, said phones will send an encrypted copy of their transaction to a known, trusted device on the network. This trusted device serves as a proxy and transmits the copied transaction to the backbone as soon as it is able to connect.
Some transactions may propagate in multiple paths from the non-connected area to the connected area, and third-party delivery may be much faster than the user's direct delivery. The multiple propagation paths may result not only from how reachable the network service originally was, but also about overloaded services and service availability. Examples of service disruption include high-service overload events such as concerts or shows (issues of service overload) and natural disasters (issues of service availability), where messages can only send from time to time instead of continuously and reliably.
In some cases a system for transacting in an environment without connectivity between a network backbone and a blockchain, a merchant device such as a phone or point of sale offers or transmits a set of credentials for an ad hoc network to close the transaction (by offering or transmitting an embedded set of optional ways to connect an ad hoc network between a buyer phone and a merchant phone or point of sale), and allows a direct exchange of multiple handshakes to secure the transaction, Both phones (or the consumer phone and the merchant phone and/or point of sale) will then keep a record of this transaction and try at the next opportunity to send this transaction over the network backbone to a blockchain. In yet other cases, each time such a client or merchant devices encounters other known, trusted devices on a P2P network, they may send an encrypted copy of their mutual transactions to the trusted devices, thereby enabling the encrypted copy to be transmitted over the network backbone to a blockchain as quickly as possible via repeated attempts by one or more trusted devices that may have better connectivity than the original sending device. A device that may or may not have been involved in the actual transaction may transmit the transaction to the network backbone and propagate it to the blockchain. Furthermore, in some cases, such client and/or merchant devices may be antitamper-hardened devices.
Alternatively, a secured transaction can be based on three-way optical interaction (P2P barcode). In this case, the buyer reads an encrypted dynamic (that is, one that may be changed every several seconds for security purposes) barcode (or QR code) with a time signature. The barcode or QR code represents a merchant identity or the merchant identity and additional transaction details (for example detailed list of groceries and their prices, as well as in some cases network information). The buyer validates (in a closed and trusted app) the merchant identity and transaction details and approves to send the required digital money from his wallet to the merchant. In those cases where there is no network available, the buyer may present an encrypted barcode to the merchant. The merchant then reads the barcode via the merchant wallet app (closed and trusted app) and validates the correctness of the transaction. The merchant sends approval via another encrypted barcode to the buyer that summarizes the transaction, so the two sides have both evidence and a receipt that the transaction has been completed. When the receipt of the merchant or the receipt of the buyer is sent and received on appropriate servers, the transaction may be added to a blockchain ledger and the transaction declared completed.
An implementation of the networks shown 6306, 6311 may include blockchain technology, wherein messages received are written to a chain of blocks that maintain references to the adjacent blocks of data in the chain, are encrypted, and cannot be destroyed or edited once created and attached to the chain. Such technology may constitute an immutable digital ledger technology or iDLT, and may be used to implement smart contracts or other self-enforcing digital contracts that operate by executing code when certain conditions are met, to ensure the execution of terms agreed to in the contract upon writing the contract into the blockchain.
The gateways 6302, 6310 used may prevent unauthorized or questionable or otherwise inadmissible messages from transmitting between networks 6306, 6311 over the broader network connection 6301 such as the internet or another network connecting the two sub-networks 6306, 6311, through a rules engine implementation that operates with rules agreed to by both institutions in part or in whole, to ensure only valid and agreed-upon message are transmitted between the two institutions 6303, 6312. Such messages from either institution may be transmitted and written to the opposing institution's blockchain, regarding their OCA or CA accounting 6304a . . . n, 6305a . . . n, 6314a . . . n, 6313a . . . n, 1a . . . n, 2a . . . n. In this way, an immutable and unambiguous, and secure, record of transactions between the two institutions in their respective accounts, which may include nostro and vostro accounts, may be maintained, for easier and more secure cross-institution recordkeeping such as for the transfer of fiat currency between institutions that operate with different currencies from each other.
When a user signs up, some of the personally identifying information (“PII”) data is not put in the iDLT database 6405. Immutable Distributed Ledger Technology may be represented as a database but may also be a blockchain implementation with many transactions recorded, wherein a customer signing up creates a record on this blockchain which may be used or viewed similarly to a database. Instead, some of the PII is put in the BDB 6403. This information can be erased as necessary (for example for GDPR when the customer needs to be forgotten). All the transactions related to the customer are linked to that customer via a key (not necessarily to be confused with a “primary key,” which is a specification in some database technologies), and that key is connected to all the transactions 6402a . . . n in the iDLT or blockchain storage 6405, respective to the blockchain itself 6404. A data trustee gets through connection 6431a, 6431b, 6431c, 6431d through the internet or WAN 6407, and copies the above-mentioned keys and PII into their BDB 6421 or iDLT 6422 with the same key.
If a customer instructs the FI to forget their information, the FI will remove the local copy of the PII according to the instruction from the BDB. The FI will no longer know the customer's personal information (name, address, etc.) but will still have the key and may also maintain a record of the date and time range when they were an active customer. Knowledge of this time period allows the customer's transactions to be found without needing to store their PII. For example, if the government were to investigate a certain transaction, the key will tell them which data trustee (in this case 6420) has information about a specific customer. The government may present proper documentation to the data trustee and request the specific transaction information. The data trustee can then retrieve said information from their BDB or iDLT store, effectively recreating the full FI database. In this way, customer information can be controlled by the customer of the financial institution 6401, while full data is maintained through a data trustee 6420 that only government access or other authorized access as law allows, may be utilized to attain full data on customers, thereby protecting both customer privacy and government intelligence requirements.
Additionally, customers may use the presence of this data trustee to store additional information in the data trustee's iDLT 6422 through a connection to the data trustee over the WAN 6432a, 6432b, 6432c, 6432d, which may be a paid service or may be offered for free depending on the policies of the data trustee and the local laws in effect. This data storage option allows the trustee to make additional fees beyond what they get paid through the FI for the key management of the PII data.
In some cases, a system that offers a convenient, trustworthy, and transparent method of transferring money or other assets is needed. This system will use at least one OCA; the OCA can be Nostro/Vostro/Pool accounts. When there is a transfer between two accounts in two endpoints in different currencies by customers of an IF, the transfer is sent as a secure message over a secure network. In some cases, the currencies at the endpoints could compromise more than one fiat currency. The secure network can be either iDLT or blockchain. This transfer results in in debit to one account in a first account of a first customer in a first asset type, a credit to a FI, a debit to OCA, and a transfer from a FI to a second account of a second customer in a second asset type based on the value rate plus an transaction cost (split). The transferred message contains all relevant information about sender, recipient, their bank accounts, and KYC and AML statuses. At least one of the asset types is a Fiat currency.
In some cases the secure message can be a smart token with certificates. When the message contains one or more value tokens in one or more denominations, said tokens replace the transactions of the one or more OCA accounts. The tokens are purchased with funds from the customer's accounts and the proceeds are deposited to the customer's accounts.
In some cases part of the data is replaced with a certificate if legally possible. When the certificate is sent in lieu of the data, and the data is kept in a secure location at either end of the transaction, the transaction(s) is (are) linked with a unique key.
In some cases, a Financial Transaction System (FTS) that uses iDLT for receiving data is used. This system includes PII wherein all key parts of PII are NOT written into the local iDLT but are only written into a key. The key is used to link the data to a database and said database is replicated to an independent trustee. The data is kept in a separate iDLT with the key. If the customer requests a GDPR “forget me,” the PII can be safely erased from the database after a complete account close out and asset transfer. The PII would still be available with proper court orders for inquiries as needed by recovery from said trustee. For an extra fee the customer can have additional information, etc. be earmarked for secure iDLT storage at the trustee and has the option to be the only person allowed to recover the data.
The gateways used may prevent unauthorized or questionable or otherwise inadmissible messages from transmitting between networks over the broader network connection such as the internet or another network connecting the two sub-networks, through a rules engine implementation that operates with rules agreed to by both institutions in part or in whole, to ensure only valid and agreed-upon message are transmitted between the two institutions. Such messages from either institution may be transmitted and written to the opposing institution's blockchain, regarding their OCA or CA accounting. In this way, an immutable and unambiguous, and secure, record of transactions between the two institutions in their respective accounts, which may include nostro and vostro accounts, may be maintained, for easier and more secure cross-institution recordkeeping such as for the transfer of fiat currency between institutions that operate with different currencies from each other.
In some cases, a Financial Transaction System (FTS) that uses iDLT for receiving data is used. This system includes PII wherein all key parts of PII are NOT written into the local iDLT but are only written into a key. The key is used to link the data to a database and said database is replicated to an independent trustee. The data is kept in a separate iDLT with the key. If the customer requests a GDPR “forget me,” the PII can be safely erased from the database after a complete account close out and asset transfer. The PII would still be available with proper court orders for inquiries as needed by recovery from said trustee. For an extra fee the customer can have additional information, etc. be earmarked for secure iDLT storage at the trustee and has the option to be the only person allowed to recover the data.
Generally, the techniques disclosed herein may be implemented on hardware or a combination of software and hardware. For example, they may be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, on an application-specific integrated circuit (ASIC), or on a network interface card.
Software/hardware hybrid implementations of at least some of the aspects disclosed herein may be implemented on a programmable network-resident machine (which should be understood to include intermittently connected network-aware machines) selectively activated or reconfigured by a computer program stored in memory. Such network devices may have multiple network interfaces that may be configured or designed to utilize different types of network communication protocols. A general architecture for some of these machines may be described herein in order to illustrate one or more exemplary means by which a given unit of functionality may be implemented. According to specific aspects, at least some of the features or functionalities of the various aspects disclosed herein may be implemented on one or more general-purpose computers associated with one or more networks, such as for example an end-user computer system, a client computer, a network server or other server system, a mobile computing device (e.g., tablet computing device, mobile phone, smartphone, laptop, or other appropriate computing device), a consumer electronic device, a music player, or any other suitable electronic device, router, switch, or other suitable device, or any combination thereof. In at least some aspects, at least some of the features or functionalities of the various aspects disclosed herein may be implemented in one or more virtualized computing environments (e.g., network computing clouds, virtual machines hosted on one or more physical computing machines, or other appropriate virtual environments).
Referring now to
In one aspect, computing device 10 includes one or more central processing units (CPU) 12, one or more interfaces 15, and one or more busses 14 (such as a peripheral component interconnect (PCI) bus). When acting under the control of appropriate software or firmware, CPU 12 may be responsible for implementing specific functions associated with the functions of a specifically configured computing device or machine. For example, in at least one aspect, a computing device 10 may be configured or designed to function as a server system utilizing CPU 12, local memory 11 and/or remote memory 16, and interface(s) 15. In at least one aspect, CPU 12 may be caused to perform one or more of the different types of functions and/or operations under the control of software modules or components, which for example, may include an operating system and any appropriate applications software, drivers, and the like.
CPU 12 may include one or more processors 13 such as, for example, a processor from one of the Intel, ARM, Qualcomm, and AMD families of microprocessors. In some aspects, processors 13 may include specially designed hardware such as application-specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), field-programmable gate arrays (FPGAs), and so forth, for controlling operations of computing device 10. In a particular aspect, a local memory 11 (such as non-volatile random access memory (RAM) and/or read-only memory (ROM), including for example one or more levels of cached memory) may also form part of CPU 12. However, there are many different ways in which memory may be coupled to system 10. Memory 11 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, and the like. It should be further appreciated that CPU 12 may be one of a variety of system-on-a-chip (SOC) type hardware that may include additional hardware such as memory or graphics processing chips, such as a QUALCOMM SNAPDRAGON™ or SAMSUNG EXYNOS™ CPU as are becoming increasingly common in the art, such as for use in mobile devices or integrated devices.
As used herein, the term “processor” is not limited merely to those integrated circuits referred to in the art as a processor, a mobile processor, or a microprocessor, but broadly refers to a microcontroller, a microcomputer, a programmable logic controller, an application-specific integrated circuit, and any other programmable circuit.
In one aspect, interfaces 15 are provided as network interface cards (NICs). Generally, NICs control the sending and receiving of data packets over a computer network; other types of interfaces 15 may for example support other peripherals used with computing device 10. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, graphics interfaces, and the like. In addition, various types of interfaces may be provided such as, for example, universal serial bus (USB), Serial, Ethernet, FIREWIRE™, THUNDERBOLT™, PCI, parallel, radio frequency (RF), BLUETOOTH™, near-field communications (e.g., using near-field magnetics), 802.11 (WiFi), frame relay, TCP/IP, ISDN, fast Ethernet interfaces, Gigabit Ethernet interfaces, Serial ATA (SATA) or external SATA (ESATA) interfaces, high-definition multimedia interface (HDMI), digital visual interface (DVI), analog or digital audio interfaces, asynchronous transfer mode (ATM) interfaces, high-speed serial interface (HSSI) interfaces, Point of Sale (POS) interfaces, fiber data distributed interfaces (FDDIs), and the like. Generally, such interfaces 15 may include physical ports appropriate for communication with appropriate media. In some cases, they may also include an independent processor (such as a dedicated audio or video processor, as is common in the art for high-fidelity A/V hardware interfaces) and, in some instances, volatile and/or non-volatile memory (e.g., RAM).
Although the system shown in
Regardless of network device configuration, the system of an aspect may employ one or more memories or memory modules (such as, for example, remote memory block 16 and local memory 11) configured to store data, program instructions for the general-purpose network operations, or other information relating to the functionality of the aspects described herein (or any combinations of the above). Program instructions may control execution of or comprise an operating system and/or one or more applications, for example. Memory 16 or memories 11, 16 may also be configured to store data structures, configuration data, encryption data, historical system operations information, or any other specific or generic non-program information described herein.
Because such information and program instructions may be employed to implement one or more systems or methods described herein, at least some network device aspects may include nontransitory machine-readable storage media, which, for example, may be configured or designed to store program instructions, state information, and the like for performing various operations described herein. Examples of such nontransitory machine-readable storage media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as optical disks, and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM), flash memory (as is common in mobile devices and integrated systems), solid state drives (SSD) and “hybrid SSD” storage drives that may combine physical components of solid state and hard disk drives in a single hardware device (as are becoming increasingly common in the art with regard to personal computers), memristor memory, random access memory (RAM), and the like. It should be appreciated that such storage means may be integral and non-removable (such as RAM hardware modules that may be soldered onto a motherboard or otherwise integrated into an electronic device), or they may be removable such as swappable flash memory modules (such as “thumb drives” or other removable media designed for rapidly exchanging physical storage devices), “hot-swappable” hard disk drives or solid state drives, removable optical storage discs, or other such removable media, and that such integral and removable storage media may be utilized interchangeably. Examples of program instructions include both object code, such as may be produced by a compiler, machine code, such as may be produced by an assembler or a linker, byte code, such as may be generated by for example a JAVA™ compiler and may be executed using a Java virtual machine or equivalent, or files containing higher level code that may be executed by the computer using an interpreter (for example, scripts written in Python, Perl, Ruby, Groovy, or any other scripting language).
In some aspects, systems may be implemented on a standalone computing system. Referring now to
In some aspects, systems may be implemented on a distributed computing network, such as one having any number of clients and/or servers. Referring now to
In addition, in some aspects, servers 32 may call external services 37 when needed to obtain additional information, or to refer to additional data concerning a particular call. Communications with external services 37 may take place, for example, via one or more networks 31. In various aspects, external services 37 may comprise web-enabled services or functionality related to or installed on the hardware device itself. For example, in one aspect where client applications 24 are implemented on a smartphone or other electronic device, client applications 24 may obtain information stored in a server system 32 in the cloud or on an external service 37 deployed on one or more of a particular enterprise's or user's premises. In addition to local storage on servers 32, remote storage 38 may be accessible through the network(s) 31.
In some aspects, clients 33 or servers 32 (or both) may make use of one or more specialized services or appliances that may be deployed locally or remotely across one or more networks 31. For example, one or more databases 34 in either local or remote storage 38 may be used or referred to by one or more aspects. It should be understood by one having ordinary skill in the art that databases in storage 34 may be arranged in a wide variety of architectures and using a wide variety of data access and manipulation means. For example, in various aspects one or more databases in storage 34 may comprise a relational database system using a structured query language (SQL), while others may comprise an alternative data storage technology such as those referred to in the art as “NoSQL” (for example, HADOOP CASSANDRA™, GOOGLE BIGTABLE™, and so forth). In some aspects, variant database architectures such as column-oriented databases, in-memory databases, clustered databases, distributed databases, or even flat file data repositories may be used according to the aspect. It will be appreciated by one having ordinary skill in the art that any combination of known or future database technologies may be used as appropriate, unless a specific database technology or a specific arrangement of components is specified for a particular aspect described herein. Moreover, it should be appreciated that the term “database” as used herein may refer to a physical database machine, a cluster of machines acting as a single database system, or a logical database within an overall database management system. Unless a specific meaning is specified for a given use of the term “database”, it should be construed to mean any of these senses of the word, all of which are understood as a plain meaning of the term “database” by those having ordinary skill in the art.
Similarly, some aspects may make use of one or more security systems 36 and configuration systems 35. Security and configuration management are common information technology (IT) and web functions, and some amount of each are generally associated with any IT or web systems. It should be understood by one having ordinary skill in the art that any configuration or security subsystems known in the art now or in the future may be used in conjunction with aspects without limitation, unless a specific security 36 or configuration system 35 or approach is specifically required by the description of any specific aspect.
In various aspects, functionality for implementing systems or methods of various aspects may be distributed among any number of client and/or server components. For example, various software modules may be implemented for performing various functions in connection with the system of any particular aspect, and such modules may be variously implemented to run on server and/or client components.
The skilled person will be aware of a range of possible modifications of the various aspects described above. Accordingly, the present invention is defined by the claims and their equivalents.
| Number | Date | Country | |
|---|---|---|---|
| 62876368 | Jul 2019 | US | |
| 63015108 | Apr 2020 | US | |
| 62767757 | Nov 2018 | US | |
| 62749665 | Oct 2018 | US | |
| 62697377 | Jul 2018 | US | |
| 62696793 | Jul 2018 | US | |
| 62667153 | May 2018 | US | |
| 62661595 | Apr 2018 | US | |
| 62616060 | Jan 2018 | US | |
| 62594519 | Dec 2017 | US | |
| 62570064 | Oct 2017 | US | |
| 62554546 | Sep 2017 | US | |
| 62549138 | Aug 2017 | US | |
| 62547227 | Aug 2017 | US | |
| 62540943 | Aug 2017 | US | |
| 62772527 | Nov 2018 | US | |
| 62841020 | Apr 2019 | US | |
| 62794913 | Jan 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16875595 | May 2020 | US |
| Child | 16933883 | US | |
| Parent | 16796159 | Feb 2020 | US |
| Child | 16875595 | US | |
| Parent | 16747982 | Jan 2020 | US |
| Child | 16796159 | US | |
| Parent | 16684517 | Nov 2019 | US |
| Child | 16747982 | US | |
| Parent | 16660695 | Oct 2019 | US |
| Child | 16684517 | US | |
| Parent | PCT/US19/41500 | Jul 2019 | US |
| Child | 16660695 | US | |
| Parent | 16875595 | May 2020 | US |
| Child | PCT/US19/41500 | US | |
| Parent | 16796159 | Feb 2020 | US |
| Child | 16875595 | US | |
| Parent | 16747982 | Jan 2020 | US |
| Child | 16796159 | US | |
| Parent | 16684517 | Nov 2019 | US |
| Child | 16747982 | US | |
| Parent | 16660695 | Oct 2019 | US |
| Child | 16684517 | US | |
| Parent | PCT/US19/28812 | Apr 2019 | US |
| Child | 16660695 | US | |
| Parent | 16875595 | May 2020 | US |
| Child | PCT/US19/28812 | US | |
| Parent | 16796159 | Feb 2020 | US |
| Child | 16875595 | US | |
| Parent | 16747982 | Jan 2020 | US |
| Child | 16796159 | US | |
| Parent | 16684517 | Nov 2019 | US |
| Child | 16747982 | US | |
| Parent | 16660695 | Oct 2019 | US |
| Child | 16684517 | US | |
| Parent | PCT/US19/13272 | Jan 2019 | US |
| Child | 16660695 | US | |
| Parent | 16208853 | Dec 2018 | US |
| Child | PCT/US19/13272 | US | |
| Parent | 16875595 | May 2020 | US |
| Child | 16208853 | US | |
| Parent | 16796159 | Feb 2020 | US |
| Child | 16875595 | US | |
| Parent | 16747982 | Jan 2020 | US |
| Child | 16796159 | US | |
| Parent | 16684517 | Nov 2019 | US |
| Child | 16747982 | US | |
| Parent | 16660695 | Oct 2019 | US |
| Child | 16684517 | US | |
| Parent | 16208853 | Dec 2018 | US |
| Child | 16660695 | US | |
| Parent | 16152090 | Oct 2018 | US |
| Child | 16208853 | US | |
| Parent | 16122870 | Sep 2018 | US |
| Child | 16152090 | US | |
| Parent | 16875595 | May 2020 | US |
| Child | 16122870 | US | |
| Parent | 16796159 | Feb 2020 | US |
| Child | 16875595 | US | |
| Parent | 16696352 | Nov 2019 | US |
| Child | 16796159 | US | |
| Parent | 16684517 | Nov 2019 | US |
| Child | 16696352 | US | |
| Parent | 16862419 | Apr 2020 | US |
| Child | 16684517 | US | |
| Parent | 16747429 | Jan 2020 | US |
| Child | 16862419 | US | |
| Parent | 16696352 | Nov 2019 | US |
| Child | 16747429 | US | |
| Parent | 16862419 | Apr 2020 | US |
| Child | 16696352 | US | |
| Parent | 16796159 | Feb 2020 | US |
| Child | 16862419 | US | |
| Parent | 16748213 | Jan 2020 | US |
| Child | 16796159 | US | |
| Parent | 16747982 | Jan 2020 | US |
| Child | 16748213 | US | |
| Parent | 16862419 | Apr 2020 | US |
| Child | 16747982 | US | |
| Parent | 16162066 | Oct 2018 | US |
| Child | 16862419 | US | |
| Parent | 16122870 | Sep 2018 | US |
| Child | 16162066 | US |
