Granted Patent B2

US 12,481,978 · App. 18/362,771 · Granted Nov 25, 2025

Inventors: Stephen J. Todd (North Andover, MA); Trevor Scott Conn (Leander, TX); Ahmed Khalid (Cork, IE); Mustafa Al-Bado (Cork, IE)

Assignee: Dell Products L.P.

G06Q20/367G06Q20/389

Abstract

Claims (36)

1 . A method, comprising:

receiving, by a trust provider from a third party proxy, an indication that the third party proxy has instantiated a smart contract on behalf of the trust provider;

connecting wallets of a customer to an agent of a data confidence fabric, wherein the wallets comprise a cryptocurrency wallet and a conventional currency wallet;

in response to a request from an application, providing a trust service that comprises processing customer data by applying a trust function to the customer data;

creating annotations for the customer data, based on the trust function that was applied;

providing the processed customer data to a recipient;

calling the smart contract using successive ones of the customer wallets until the smart contract is successfully executed;

transferring, from the customer wallet that resulted in successful execution of the smart contract to the third party proxy, a trust provider fee assessed for performance of the trust function; and

transferring the trust provider fee from a third party proxy wallet to a trust provider wallet.

2 . The method as recited in claim 1 , wherein the smart contract is called by the customer wallets according to a hierarchy of the customer wallets.

3 . The method as recited in claim 1 , wherein the customer wallet that results in successful execution of the smart contract is whichever customer wallet is first identified as having adequate funds to cover the trust provider fee.

4 . The method as recited in claim 1 , wherein the trust provider is unable to perform cryptocurrency transactions with the customer.

5 . The method as recited in claim 1 , wherein one of the customer wallets does not have sufficient funds to cover the trust provider fee.

6 . The method as recited in claim 1 , wherein the trust service continues to be applied notwithstanding that one or more of the customer wallets do not have sufficient funds to cover the trust provider fee.

7 . The method as recited in claim 1 , wherein the processed data and annotations are provided to a recipient after the trust provider fee has been transferred to the proxy wallet.

8 . The method as recited in claim 1 , wherein the trust provider fee transferred from the third party proxy wallet to the trust provider wallet is in a form other than cryptocurrency.

9 . The method as recited in claim 1 , wherein the customer wallets are only connected after receipt, from the customer, of a customer identifier, and connection credentials.

10 . The method as recited in claim 1 , wherein the customer is unable to perform cryptocurrency transactions with the trust provider.

11 . A non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations comprising:

receiving, by a trust provider from a third party proxy, an indication that the third party proxy has instantiated a smart contract on behalf of the trust provider;

connecting wallets of a customer to an agent of a data confidence fabric, wherein the wallets comprise a cryptocurrency wallet and a conventional currency wallet;

in response to a request from an application, providing a trust service that comprises processing customer data by applying a trust function to the customer data;

creating annotations for the customer data, based on the trust function that was applied;

providing the processed customer data to a recipient;

calling the smart contract using successive ones of the customer wallets until the smart contract is successfully executed;

transferring, from the customer wallet that resulted in successful execution of the smart contract to the third party proxy, a trust provider fee assessed for performance of the trust function; and

transferring the trust provider fee from a third party proxy wallet to a trust provider wallet.

12 . The non-transitory storage medium as recited in claim 11 , wherein the smart contract is called by the customer wallets according to a hierarchy of the customer wallets.

13 . The non-transitory storage medium as recited in claim 11 , wherein the customer wallet that results in successful execution of the smart contract is whichever customer wallet is first identified as having adequate funds to cover the trust provider fee.

14 . The non-transitory storage medium as recited in claim 11 , wherein the trust provider is unable to perform cryptocurrency transactions with the customer.

15 . The non-transitory storage medium as recited in claim 11 , wherein one of the customer wallets does not have sufficient funds to cover the trust provider fee.

16 . The non-transitory storage medium as recited in claim 11 , wherein the trust service continues to be applied notwithstanding that one or more of the customer wallets do not have sufficient funds to cover the trust provider fee.

17 . The non-transitory storage medium as recited in claim 11 , wherein the processed data and annotations are provided to a recipient after the trust provider fee has been transferred to the proxy wallet.

18 . The non-transitory storage medium as recited in claim 11 , wherein the trust provider fee transferred from the third party proxy wallet to the trust provider wallet is in a form other than cryptocurrency.

19 . The non-transitory storage medium as recited in claim 11 , wherein the customer wallets are only connected after receipt, from the customer, of a customer identifier, and connection credentials.

20 . The non-transitory storage medium as recited in claim 11 , wherein the customer is unable to perform cryptocurrency transactions with the trust provider.

Assignments (1)

Continuity (1)

References Cited (128)