Embodiments of the present invention generally relate to data confidence fabrics. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods, for the implementation and use of mechanisms for effecting financial, and other, transactions in the context of a data confidence fabric.
The provision of trust services through data confidence fabric (DCF) functions, such as evaluation and annotation of data with confidence metadata, may be important to consumers, since the data confidence information may reflect the extent to which the customer data is deemed to be trustworthy and suitable for use by applications, and other users. Thus, the consumer has an interest in obtaining, and maintaining, performance of the trust services with respect to its data. However, problems can arise if the consumer does not have adequate funds available to pay for the needed trust services. For example, provision of the trust services may be terminated if the consumer is unable to pay for them.
In order to describe the manner in which at least some of the advantages and features of the invention may be obtained, a more particular description of embodiments of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, embodiments of the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings.
Embodiments of the present invention generally relate to data confidence fabrics. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods, for the implementation and use of mechanisms for effecting financial, and other, transactions and operations in the context of a data confidence fabric.
In general, aspects of an embodiment of the invention may be integrated into, and interoperate with, a DCF and its associated components, functions, and operations. In one example embodiment, an entity and associated methods are provided that may facilitate wider adaptation of the features and functions of a DCF. In more detail, an embodiment may comprise a method that includes registering customers and using customer credit scores to determine the creditworthiness of a customer account. Based on this analysis, a loan may then be made by a D-DCF (decentralized data confidence fabric) bank to the customer solely for the purpose of enabling the customer to make payments to the trust provider for the provision of trust services. In an embodiment, the loan may be made with terms for interest payments to the D-DCF bank. An embodiment may provide an option for customers to deposit and use funds for payments to the trust provider, such as through the Alvarium SDK or other suitable interface, instead of making those payments from a customer wallet. The customer wallet may sometimes be referred to herein as a digital wallet, a user wallet, or a cryptocurrency wallet.
Embodiments of the invention, such as the examples disclosed herein, may be beneficial in a variety of respects. For example, and as will be apparent from the present disclosure, one or more embodiments of the invention may provide one or more advantageous and unexpected effects, in any combination, some examples of which are set forth below. It should be noted that such effects are neither intended, nor should be construed, to limit the scope of the claimed invention in any way. It should further be noted that nothing herein should be construed as constituting an essential or indispensable element of any invention or embodiment. Rather, various aspects of the disclosed embodiments may be combined in a variety of ways so as to define yet further embodiments. For example, any element(s) of any embodiment may be combined with any element(s) of any other embodiment, to define still further embodiments. Such further embodiments are considered as being within the scope of this disclosure. As well, none of the embodiments embraced within the scope of this disclosure should be construed as resolving, or being limited to the resolution of, any particular problem(s). Nor should any such embodiments be construed to implement, or be limited to implementation of, any particular technical effect(s) or solution(s). Finally, it is not required that any embodiment implement any of the advantageous and unexpected effects disclosed herein.
In particular, one advantageous aspect of an embodiment of the invention is that a decentralized bank, such as a cryptocurrency bank for example, is implemented that may provide loan, credit, and deposit, services to a DCF customer. An embodiment may implement transactions between a DCF customer and trust provider using smart contracts. An embodiment may provide various payment mechanisms which may help to ensure that a DCF customer continues to receive trust services, and the trust service provider continues to receive payment for those trust services. An embodiment may provide for the expansion, and improvement, of the functionality of a DCF. Various other advantages of one or more embodiments will be apparent from this disclosure.
It is noted that embodiments of the invention, whether claimed or not, cannot be performed, practically or otherwise, in the mind of a human. Accordingly, nothing herein should be construed as teaching or suggesting that any aspect of any embodiment of the invention could or would be performed, practically or otherwise, in the mind of a human. Further, and unless explicitly indicated otherwise herein, the disclosed methods, processes, and operations, are contemplated as being implemented by computing systems that may comprise hardware and/or software. That is, such methods processes, and operations, are defined as being computer-implemented.
Moreover, an embodiment may comprise, or consist of, operations that are performed only by various types of computing entities, and are not performed by any human(s). That is, unless an embodiment explicitly identifies a human as performing one or more operations of that embodiment, such operations should be understood to be computer-implemented.
The following is a discussion of aspects of example operating environments for various embodiments of the invention. This discussion is not intended to limit the scope of the invention, or the applicability of the embodiments, in any way. In general, embodiments of the invention may be implemented in connection with systems, software, and components, that individually and/or collectively implement, and/or cause the implementation of, a data confidence fabric (DCF).
With reference now to
As shown in
The trust metadata 112a, 112b, and 112c, may comprise, for example, respective confidence scores associated with trust insertion processes performed by the nodes with respect to the data 102. The trust metadata 112a, 112b, and 112c may be associated with the data 102 by respective node APIs (Application Program Interfaces) 104a, 106a, and 108a that communicate with an interface 114 such as an Alvarium SDK (Software Development Kit). After the data 102 has transited the various nodes, the final, comprehensive trust metadata 112c may be entered into a ledger 116 which may make the trust metadata 112c available for use by the applications 110. Note that, in this example, the trust metadata 112c is an accumulation of all the trust metadata respectively added by the gateway 104, edge server 106, and cloud ecosystem 108.
To illustrate with reference to the specific example of
As noted earlier, the DCF metadata, that is, the trust metadata 112a, ultimately arrives at the ledger 116, where a ledger entry may be created that permanently records the contents of the trust metadata 112a table as well as an overall Confidence Score, which is 6.0 in this illustrative example. Note that the equation used to calculate the Confidence Score in the example of
A useful aspect of the example DCF 100 is that, as a result of the annotation of trust metadata 112a, 112b, and 112c, the application 110 may have access to additional context about the trustworthiness of the data 102, addressing the problem of potentially untrustworthy or malicious data sources. The problems presented by such data sources are increasingly faced by enterprise customers as they move their business logic closer to non-enterprise, and potentially untrustworthy, data sources at the edge and/or elsewhere. In the example DCF 100, the path of the data 102 may be largely software-dependent, in the sense that data path handling software, which may comprise a respective instance at each of the gateway 104, edge server 106, and cloud ecosystem 108, may call an annotation/scoring API 104a, 106a, and 108a, respectively, and routing software may be provided at these nodes that forwards the annotations along the data path.
It is noted that as used herein, the term ‘data’ is intended to be broad in scope. Thus, that term embraces, by way of example and not limitation, data segments such as may be produced by data stream segmentation processes, data chunks, data blocks, atomic data, emails, objects of any type, files of any type including media files, word processing files, spreadsheet files, and database files, as well as contacts, directories, sub-directories, volumes, and any group of one or more of the foregoing. Example embodiments of the invention may be applicable to any system capable of storing and handling various types of objects, in analog, digital, or other form. Although terms such as document, file, segment, block, or object may be used by way of example, the principles of the disclosure are not limited to any particular form of representing and storing data or other information. Rather, such principles are equally applicable to any object capable of representing information.
To create a payment mechanism for a DCF based on cryptocurrency and smart contracts, an entity similar, in some respects, to traditional banks may be employed that may, in one embodiment, operate to ensure scalability, seamless transactions, and alternative payment methods for customers of the DCF trust provider. An embodiment may implement a decentralized data confidence fabric bank (D-DCF) to resolve one or more problems, such as an insufficient balance in a customer wallet. An embodiment may comprise additional functions that may enable smart contracts to make bank operations available to customers. In an embodiment, one or more of these functions may be standardized and imported by a trust provider when defining and deploying their smart contract. In an embodiment, a D-DCF bank standard contract may be based on existing fungible token standards, such as ERC20 (Ethereum Request for Comments 20) for example, but may include additional functions as disclosed herein.
One example embodiment comprises an entity, and associated operations, that carries out some tasks associated with conventional banks, and which may also be helpful in enabling and facilitating wider adaptation of the DCF. One example embodiment comprises a method that includes the following operations: [1] registering customers and using credit scores to determine creditworthiness of a customer's account; [2] providing loans to customers for D-DCF payments with well-defined terms for interest payments; and [3] providing a mechanism for customers to deposit and use funds for payments to a trust provider, instead of paying from their own wallet. In this embodiment, the D-DCF bank does not act as a centralized authority for managing or securing the assets of a customer. Instead, in an embodiment, the decentralized D-DCF bank may perform the aforementioned operations by way of one or more smart contracts, so as to maintain the benefits of decentralized and distributed ledger technologies such as may be employed in connection with a DCF.
With attention now to
Particular reference is now made to
In an embodiment, the customer 201 may request registration [2a] of its account with a D-DCF bank 206. In an embodiment, a smart contract 208 and associated function may be defined that may be called by the customer 201. The smart contract 208 may forward [2b] the registration request to an oracle of the D-DCF bank 206 that may calculate the total amount the D-DCF bank 206 is willing to loan to the customer 201. Note that this calculation operation may also be performed within the smart contract 208 for complete transparency.
However the cost of performing the calculation may be indeterminate, or high, depending on the underlying DLT (distributed ledger technology) and the complexity of the calculation function. Where a proprietary credit score calculation mechanism is to be used, the D-DCF bank 206 may, in one embodiment, use an oracle 210 which may be called by the smart contract 208, and the results then returned by the oracle 210 to the smart contract 208. In an embodiment, the D-DCF bank 206 may calculate a maximum possible loan amount by querying [2c] the DCF and billing ledgers 211 to obtain information about the past transactions and payment history of the customer 201. The information obtained as a result of the query [2c] may then be shared, either directly or by way of the D-DCF bank 206, with the smart contract 208 and the customer 201.
With continued reference to
In an embodiment, the annotations may then be sent [6] to the smart contract 208 along with a fee assessed by the trust provider. In an embodiment, the function call will not fail at this step if the wallet 202 of the customer does not have sufficient funds to pay the trust provider fee. Instead, the D-DCF bank 206 may pay the trust provider fee on behalf of the customer 201. In this way, the customer may continue to received needed trust services even when the customer does not have adequate funds available to pay the trust provider fee. Following is a discussion of an approach for providing payment to the trust provider.
In particular, if the customer 201 lacks sufficient funds to pay the trust provider fee, then the smart contract 208 may, possibly automatically, attempt to deduct the fee from the wallet 212 of the D-DCF bank 206. Assuming that the D-DCF bank 206 always has a balance adequate to cover fees assessed by the trust provider, service disruptions to the customer 201, due to the inability to timely make payment, may thus be eliminated.
In an embodiment, payment may be obtained from the wallet 212 of the D-DCF bank 206 in at least two different ways. For example, a bulk amount based on the agreed upon loan may be transferred [7a] from the wallet 212 of the D-DCF bank 206 to the smart contract 208 under the customer 201 name. Then for each trust function call [3] from the customer 201, the smart contract 208 may transfer the corresponding fee from this loan in the wallet 212 to the wallet 214 of the trust provider. As another example, on each annotation provided by the trust provider, the smart contract 208 may check the credit limit for the customer 201 and call [7a] a transfer function to transfer the trust provider fee from the wallet 212 of the D-DCF bank 206 to the provider wallet 214.
Once the smart contract 208 has the required fee to send to the trust provider, however that fee may have been obtained, such as by way of either of the examples noted above or by obtaining the fee from the customer wallet 202, the fee may be sent [7b] by the smart contract 208 to the trust provider wallet 214. After the trust provider has received the fee, the annotations made concerning the customer data may then be written [7c] to the DCF/billing ledger 211 of the trust provider. In an embodiment, the billing information may written to a separate billing ledger if the underlying payment mechanism maintains a separate ledger for billing records. Next, annotated data may be sent [8] back to the application by the DCF.
At some point, based on the terms set out in the smart contract 208, the customer 201 may pay back [9a] the loan to the D-DCF bank 206. In an embodiment, this may be done by calling a smart contract 208 function by the customer 201. The customer 201 may use any wallet, including the wallet 202, or account to pay off any arrears. Finally, the smart contract 208 function may confirm that the amount paid [9a] matches the arrears, including any interest payment set in the smart contract 208, and transfer [9b] the amount back to the D-DCF bank 206.
It is noted in connection with the discussion of the example embodiments of
As disclosed herein, an example embodiment may provide and employ a decentralized data confidence fabric bank, or D-DCF bank, that provides loan, credit, and deposit services to DCF customers who have a need for services, such as trust services, provided by way of a DCF. In an embodiment, a D-DCF bank comprises an entity that is associated with, and possibly integrated into, a DCF, and may typically carry a balance large enough to cover trust provider fees for multiple transactions and/or multiple customers. An embodiment may comprise specific functions implemented within a smart contract to build a trustworthy environment for defining terms among parties, and for automatically executing transactions based upon those terms. Specifically, in [2] of the example of
Following are aspects of one example use case for an embodiment of the invention. This example use case is not intended to limit the scope of the invention in any way and is provided for the purposes of illustration.
It is noted with respect to the disclosed methods, including the example method of
Following are some further example embodiments of the invention. These are presented only by way of example and are not intended to limit the scope of the invention in any way.
Embodiment 1. A method, comprising: connecting a digital wallet of a customer to an agent of a data confidence fabric; receiving, from an application, a request for performance of a trust function, by the data confidence fabric, with respect to customer data; processing the customer data by applying the trust function to the customer data; returning the data, after the processing, to the agent; creating annotations for the customer data, based on the trust function that was applied; transmitting the annotations, and a corresponding trust provider fee amount, to a smart contract; and when the digital wallet of the customer does not have adequate funds to cover the trust provider fee amount, obtaining funds from an alternate source of funding associated with the data confidence fabric.
Embodiment 2. The method as recited in any preceding embodiment, wherein after funds are obtained to cover the fee, the data and annotations are transmitted to the customer.
Embodiment 3. The method as recited in any preceding embodiment, wherein the alternate source of funding comprises a decentralized data confidence fabric bank.
Embodiment 4. The method as recited in any preceding embodiment, wherein the alternate source of funding comprises a decentralized data confidence fabric bank that determines a maximum amount of a potential loan to the customer.
Embodiment 5. The method as recited in any preceding embodiment, wherein a smart contract enables communications between the customer and the alternate source of funding.
Embodiment 6. The method as recited in any preceding embodiment, wherein the obtaining of the funds from the alternate source of funding associated with the data confidence fabric enables the customer to continue to receive trust services from the data confidence fabric without interruption that would otherwise result from lack of payment, by the customer, of the trust provider fee amount.
Embodiment 7. The method as recited in any preceding embodiment, wherein obtaining the funds from the alternate source of funding comprises deduction, by a smart contract, of the trust provider fee amount from a decentralized data confidence fabric bank.
Embodiment 8. The method as recited in any preceding embodiment, wherein after a smart contract obtains the funds from the alternate source of funding, the smart contract transmits the funds to a digital wallet of the trust provider.
Embodiment 9. The method as recited in any preceding embodiment, wherein obtaining the funds from the alternate source of funding comprises transferring, from the alternate source of funding to a smart contract, a bulk amount of funds that exceeds the trust provider fee amount.
Embodiment 10. The method as recited in any preceding embodiment, wherein obtaining the funds from the alternate source of funding is performed on a per-annotation basis by a smart contract, after the smart contract has determined that a credit limit of the customer has not been exceeded.
Embodiment 11. A system, comprising hardware and/or software, operable to perform any of the operations, methods, or processes, or any portion of any of these, disclosed herein.
Embodiment 12. A non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations comprising the operations of any one or more of embodiments 1-10.
The embodiments disclosed herein may include the use of a special purpose or general-purpose computer including various computer hardware or software modules, as discussed in greater detail below. A computer may include a processor and computer storage media carrying instructions that, when executed by the processor and/or caused to be executed by the processor, perform any one or more of the methods disclosed herein, or any part(s) of any method disclosed.
As indicated above, embodiments within the scope of the present invention also include computer storage media, which are physical media for carrying or having computer-executable instructions or data structures stored thereon. Such computer storage media may be any available physical media that may be accessed by a general purpose or special purpose computer.
By way of example, and not limitation, such computer storage media may comprise hardware storage such as solid state disk/device (SSD), RAM, ROM, EEPROM, CD-ROM, flash memory, phase-change memory (“PCM”), or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage devices which may be used to store program code in the form of computer-executable instructions or data structures, which may be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality of the invention. Combinations of the above should also be included within the scope of computer storage media. Such media are also examples of non-transitory storage media, and non-transitory storage media also embraces cloud-based storage systems and structures, although the scope of the invention is not limited to these examples of non-transitory storage media.
Computer-executable instructions comprise, for example, instructions and data which, when executed, cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. As such, some embodiments of the invention may be downloadable to one or more systems or devices, for example, from a website, mesh topology, or other source. As well, the scope of the invention embraces any hardware system or device that comprises an instance of an application that comprises the disclosed executable instructions.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts disclosed herein are disclosed as example forms of implementing the claims.
As used herein, the term ‘module’ or ‘component’ may refer to software objects or routines that execute on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system, for example, as separate threads. While the system and methods described herein may be implemented in software, implementations in hardware or a combination of software and hardware are also possible and contemplated. In the present disclosure, a ‘computing entity’ may be any computing system as previously defined herein, or any module or combination of modules running on a computing system.
In at least some instances, a hardware processor is provided that is operable to carry out executable instructions for performing a method or process, such as the methods and processes disclosed herein. The hardware processor may or may not comprise an element of other hardware, such as the computing devices and systems disclosed herein.
In terms of computing environments, embodiments of the invention may be performed in client-server environments, whether network or local environments, or in any other suitable environment. Suitable operating environments for at least some embodiments of the invention include cloud computing environments where one or more of a client, server, or other machine may reside and operate in a cloud environment.
With reference briefly now to
In the example of
Such executable instructions may take various forms including, for example, instructions executable to perform any method or portion thereof disclosed herein, and/or executable by/at any of a storage site, whether on-premises at an enterprise, or a cloud computing site, client, datacenter, data protection site including a cloud storage site, or backup server, to perform any of the functions disclosed herein. As well, such instructions may be executable to perform any of the other operations and methods, and any portions thereof, disclosed herein.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.