DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 10/28/2025.
Claims 1, 5-11 and 15-20 are amended.
Claims 3, 4, 13 and 14 are cancelled.
Claims 1, 2, 5-12 and 15-20 are pending.
Claims 1, 2, 5-12 and 15-20 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive.
Claim Interpretation
Applicant has defined the “data confidence fabric” to be “an operating environment in which one or more physical computing devices, including an edge device, operate as respective nodes of the data confidence fabric, wherein the data confidence fabric includes a decentralized data confidence fabric bank.”
101
Applicant argues “Moreover, the claims recite an improvement to a DCF, namely, an expansion of DCF functionality to include the ability of a DCF element to annotate customer data with trust metadata to facilitate digital transactions between parties and a customer application running on an edge device.” Examiner disagrees.
Applicant’s explanation of the claims’ improvements are not reflected in the limitations. A majority of the steps are not performed with or in the DCF, they are done by a “trust provider”, that “communicates with the edge device”. Given the claims, it is unclear where and how “an improvement to a DCF, namely, an expansion of DCF functionality to include the ability of a DCF element to annotate customer data with trust metadata to facilitate digital transactions between parties and a customer application running on an edge device” is achieved. The rejection is maintained.
112
Applicant argues “Figure 1, and paragraphs 0015 through 0020, explain that nodes of the DCF are implemented by various computing systems and components, such as a "gateway," and "edge server." Further, paragraph 0068 of the present application clearly states "...With reference briefly now to Figure 3, any one or more of the entities disclosed, or implied, by Figures 1-2,and/or elsewhere herein, may take the form of, or include, or be implemented on, or hosted by, a physical computing device..." Emphasis added.” Examiner disagrees.
The provided citations do not address the entire rejection. Neither the disclosure nor the drawings describe or show a “decentralized data confidence fabric bank” included in the “data confidence fabric”. The disclosure does not provide written description support for the recited limitation. The rejection is maintained.
103
Kuchar discloses where the data confidence fabric is an operating environment in which one or more physical computing devices, including an edge device, operate as respective nodes of the data confidence fabric, wherein the data confidence fabric includes a decentralized data confidence fabric bank (Figure 1, 3, 4; Abstract; ¶ 40-50, 164, 223-236);
Claim Interpretation – According to the disclosure(¶ 14, 19), “the DCF 100 may annotate and score any data that flows within it, providing increased confidence to the applications that use that data, such as for analytical purposes for example… A useful aspect of the example DCF 100 is that, as a result of the annotation of trust metadata 112 a, 112 b, and 112 c, the application 110 may have access to additional context about the trustworthiness of the data 102,”. The phrase “data confidence fabric” is not a term of art. The term was coined by Dell and Intel and has only been used in Dell, Intel and EMC corp(owned by Dell) Applications.
Kuchar- Custody data may indicate the party that owns/controls the blockchain address (e.g., the keys). Example parties that may take custody of blockchain addresses may include, but are not limited to, exchanges, wallets, and banks… The method includes determining a consensus trust score based on the local node trust score and the plurality of additional local trust scores. Additionally, the method includes monitoring a ledger on the blockchain network for a contract trust request that specifies the blockchain address and sending, to the blockchain network, the consensus trust score for the blockchain address specified in the contract trust request. (Abstract; ¶ 164)
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 2, 5-12 and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, and claim 11 is directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “connecting a digital wallet … registering a smart contract… receiving, … a request … processing the customer data … creating annotations for the customer data… transmitting the annotations… and obtaining funds ….” The recited limitations fall within the certain methods of organizing human activity grouping of abstract ideas, specifically, fundamental economic principles, for example, mitigating risks by authenticating a user for fraud and receiving funds to pay for services. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application. The use of a distributed ledger or blockchain or smart contract does not preclude the claim from reciting an abstract idea as the blockchain recites functions of a generic computer component, such as storing records.
According to the disclosure(¶ 36), “FIG. 2 discloses aspects of an example use-case in which a customer that intends to utilize DCF functionalities, such as data annotation with confidence information” the recited creating of annotations is confidence information. This is not an additional element, as the “creation” appears to be including confidence information.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “connecting … registering… receiving, … … processing …data and applying…… creating annotations … transmitting … and obtaining …” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of a fundamental economic practice in mitigating risk as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Dependent claims 2, 5-10, 12 and 15-20 discuss functions in more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 2, 5-10, 12 and 15-20 are also rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 2, 5-12 and 15-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1 and 11 recite “where the data confidence fabric is an operating environment in which one or more physical computing devices, including an edge device, operate as respective nodes of the data confidence fabric, wherein the data confidence fabric includes a decentralized data confidence fabric bank”. According to the disclosure and drawings (Figure 1, 2; ¶ 15-22), “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.” The DCF is depicted in Figure 1 and labelled 100. Neither the disclosure nor the drawings describe or show a “decentralized data confidence fabric bank” included in the “data confidence fabric”. The disclosure does not provide written description support for the recited limitation. Dependent claims 2, 5-10, 12 and 15-20 are also rejected.
PNG
media_image1.png
736
1015
media_image1.png
Greyscale
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 2, 5-12 and 15-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 1 and 11 recite “connecting a digital wallet… registering a smart contract… by the data confidence fabric…by the edge device… by a trust provider”. The scope of the claims are unclear and indefinite. Some limitations recite the entities performing the claimed steps with different limitations performed by multiple different entities. Therefore leaving the remaining limitations unclear and indefinite as to their scope and possible entities performing the claimed steps. Dependent claims 2, 5-10, 12 and 15-20 are also rejected.
Claims 1 and 11 recite “where the data confidence fabric is an operating environment in which one or more physical computing devices, including an edge device, operate as respective nodes of the data confidence fabric, wherein the data confidence fabric includes a decentralized data confidence fabric bank …receiving, from a customer application running on the edge device, a request for performance of trust services that comprise a trust function, by the data confidence fabric, with respect to customer data” .The claims are unclear and indefinite. The claims are unclear whether the limitations are being performed “by the data confidence fabric” and if so, how an entire “operating environment in which one or more physical computing devices, including an edge device, operate as respective nodes of the data confidence fabric, wherein the data confidence fabric includes a decentralized data confidence fabric bank” is receiving the data from a client application, and whether the client application is sending it to an entire operating environment and who in the environment is receiving this information. Additionally, it is unclear whether the limitation is referencing that the trust function is by the data confidence fabric, with respect to customer data and not that the data confidence fabric is performing the receipt of the request. The claims are unclear and indefinite. Dependent claims 2, 5-10, 12 and 15-20 are also rejected.
Claims 1 and 11 recite “processing, by a trust provider that communicates with the edge device, the customer data by applying the trust function to the customer data, and applying the trust function comprises generating trust metadata concerning the customer data… by the edge device, returning the customer data and the trust metadata, to the agent”. The claims are unclear and indefinite. The limitation is unclear if “by the edge device” means the limitation is performed by the edge device. If so, it is unclear how the edge device and the trust provider, acquired the customer data and how the edge device has the trust metadata to return it. The correlation between the entities and claimed steps are disjointed. The claims are unclear and indefinite. Dependent claims 2, 5-10, 12 and 15-20 are also rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 5-12 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kuchar et al. (20200027089) (“Kuchar”), in view of Rapowitz et al (US 12045879) (“Rapowitz”) and further in view of Phillips (US 20190019251) (“Phillips”).
Regarding claims 1 and 11, Kuchar discloses connecting a digital wallet of a customer to an agent of a data confidence fabric (¶ 53, 127-129);
Kuchar-the user transactor device 102 includes a transaction application 116 (e.g., a wallet application) that transacts with the cryptocurrency network 118. The transaction application 116 includes a trust request module 126 that interfaces with the trust network 100. For example, the trust request module 126 can generate the trust request 130 (e.g., a web request). The trust request module 126 can also receive the trust response 132 from the trust network 100. In some implementations, the trust request module 126 can generate a graphical user interface (GUI) that the user may interact with in order to send the trust request 130 and view the trust report 132. (¶ 53)
where the data confidence fabric is an operating environment in which one or more physical computing devices, including an edge device, operate as respective nodes of the data confidence fabric, wherein the data confidence fabric includes a decentralized data confidence fabric bank (Figure 1, 3, 4; Abstract; ¶ 40-50, 164, 223-236);
Claim Interpretation – According to the disclosure(¶ 14, 19), “the DCF 100 may annotate and score any data that flows within it, providing increased confidence to the applications that use that data, such as for analytical purposes for example… A useful aspect of the example DCF 100 is that, as a result of the annotation of trust metadata 112 a, 112 b, and 112 c, the application 110 may have access to additional context about the trustworthiness of the data 102,”. The phrase “data confidence fabric” is not a term of art. The term was coined by Dell and Intel and has only been used in Dell, Intel and EMC corp(owned by Dell) Applications.
Kuchar- Custody data may indicate the party that owns/controls the blockchain address (e.g., the keys). Example parties that may take custody of blockchain addresses may include, but are not limited to, exchanges, wallets, and banks… The method includes determining a consensus trust score based on the local node trust score and the plurality of additional local trust scores. Additionally, the method includes monitoring a ledger on the blockchain network for a contract trust request that specifies the blockchain address and sending, to the blockchain network, the consensus trust score for the blockchain address specified in the contract trust request. (Abstract; ¶ 164)
receiving, from a customer application running on the edge device, a request for performance of trust services that comprise a trust function, by the data confidence fabric, with respect to customer data (¶ 53, 128-130, 206, 208, 212, 223-233);
Kuchar- the user transactor device 102 includes a transaction application 116 (e.g., a wallet application) that transacts with the cryptocurrency network 118. The transaction application 116 includes a trust request module 126 that interfaces with the trust network 100. For example, the trust request module 126 can generate the trust request 130 (e.g., a web request). The trust request module 126 can also receive the trust response 132 from the trust network 100. In some implementations, the trust request module 126 can generate a graphical user interface (GUI) that the user may interact with in order to send the trust request 130 and view the trust report 132…provide the sender with the option of acquiring a trust report from the trust network 100 before engaging in the transaction. For example, in FIG. 8A, the user can select (e.g., touch/click) the “Request Trust Report” GUI element to send a trust request to the trust network 100. The trust request may include the receiver's address, as specified in the “To:” box above. (¶ 53, 128)
processing, by a trust provider that communicates with the edge device, the customer data by applying the trust function to the customer data, and applying the trust function comprises generating trust metadata concerning the customer data (¶ 37, 87, 88, 94, 129-134, 186-191, 234);
Kuchar- A trust network 100 generates consensus trust scores for cryptocurrency transactors. For example, for a cryptocurrency based on blockchain technology, the trust network 100 can generate consensus trust scores for different blockchain addresses that interact on the blockchain. The trust network 100 may determine the consensus trust scores based on data retrieved from various data sources (e.g., fraud/custody data) along with blockchain data upon which the cryptocurrency is based. (¶ 37)
by the edge device, returning the customer data and the trust metadata, to the agent (¶ 41, 43, 67, 68, 72, 75, 86-90, 94, 100-106, 134);
Kuchar- The nodes 100 may acquire data associated with cryptocurrency blockchain addresses and determine a variety of trust scores based on the acquired data. A trust score determined locally at a node based on the acquired data may be referred to as a “local node trust score” or a “local trust score.” The nodes 100 may be configured to communicate their local trust scores among one another such that each node may have knowledge of local trust scores associated with other nodes…The distributed trust network 100 described herein distributes the trust score computational workload across a plurality of nodes to produce a resilient network that is resistant to failure/outage and attack. (¶ 41, 43)
creating, by the trust provider, annotations for the customer data, where the annotations are created based on the trust metadata (¶ 129-135, 190-196, 200, 232);
Kuchar-the received trust report indicates that the receiver had a trust score of −0.90. It can be assumed in this case that a negative valued trust score near −1.00 indicates that the receiver address is likely fraudulent. (¶ 129)
transmitting, by the trust provider, the annotations, and a corresponding trust provider fee amount, to a smart contract; and (¶ 110-115, 130, 223-233, 240);
Kuchar- provides a summary of the total amount for the trust-protected transaction. For example, the GUI indicates the trust fee and the network fee for the trust report and the contract execution, (¶ 223)
Kuchar does not disclose registering a smart contract between the client and the decentralized data confidence fabric bank, within which the decentralized data confidence fabric bank calculates, using an oracle, a credit limit of the customer upon reception of a query; when the digital wallet of the customer does not have adequate funds to cover the trust provider fee amount, obtaining funds from a digital wallet of the decentralized data confidence fabric bank of funding associated with the data confidence fabric based on the smart contract.
Rapowitz teaches registering a smart contract between the client and the decentralized data confidence fabric bank, within which the decentralized data confidence fabric bank calculates, using an oracle, a credit limit of the customer upon reception of a query (Abstract; column 3, line 45-67, column 4, line 1-33, column 9, line 36-65, column 10, line 48-60, column 14, line 1-24; claim 7);
Claim Interpretation – According to the disclosure(¶ 8, 21, 34), “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… 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… Specifically, in [2] of the example of FIG. 2 , and embodiment may register customers with a D-DCF bank through a smart contract while using the bank credit scoring mechanisms to determine a suitable loan amount for the customer”. The phrase “data confidence fabric” is not a term of art. The term was coined by Dell and Intel and has only been used in Dell, Intel and EMC corp(owned by Dell) Applications.
Rapowitz - An event query may be sent to an oracle device external to the blockchain network. The event query may include the identity. Event data associated with the identity may then be received from the oracle device in response to the event query… a financial institution device 104 can query the blockchain network 106 for an identity that has applied for an unsecured loan to obtain an indication of the number of creditworthiness tokens originally allocated to the identity and thereby inform the financial institution associated with the financial institution device 104 regarding the risk or creditworthiness of the identity with respect to the requested loan… In another example, a financial institution device 104 can secure a loan based on an amount of creditworthiness tokens. In this example, the financial institution device 104 can store a loan smart contract in the blockchain network 106 that automatically transfers the collateralized creditworthiness tokens to a wallet, …The specification can include a self-executing software program that automatically queries the oracle device 110 for event data and applies a set of rules to the event data to determine a number of creditworthiness tokens that should be allocated to the wallet address (Abstract; column 4, line 16-33, column 8, line 21-33)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kuchar and Rapowitz in order to secure risk in determining creditworthiness when distributing loans from a financial institution (Rapowitz; column 1, line 6-47).
Phillips teaches when the digital wallet of the customer does not have adequate funds to cover the trust provider fee amount, obtaining funds from a digital wallet of the decentralized data confidence fabric bank of funding associated with the data confidence fabric based on the smart contract (¶ 19, 28, 53, 65, 70-78, 94, 95, 112);
Phillips- The cardholder may choose to link credit card(s), prepaid card(s), and/or debit card(s) accounts to the investment card; phrased differently, the cardholder may choose to link these different wallet types to his investment card in addition to the different wallets linked to securities. Furthermore, the issuer may approve purchases even though application of the wallet and payment algorithms to the investment card's securities wallets indicates there are insufficient authorized funds in the cardholder's security portfolio(s) to effectuate the purchase by accessing these different wallet types to compensate for any deficit (i.e., the difference between the purchase price and the authorized funds linked to the securities on the investment card). (¶ 94)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kuchar, Rapowitz and Phillips in order to connect several funding sources in connections with various transactions (Phillips; ¶ 1-4).
Regarding claims 2 and 12, Kuchar discloses wherein after funds are obtained to cover the trust provider fee amount, the customer data and annotations are transmitted to the customer (¶ 226-232).
Regarding claims 5 and 15, Rapowitz teaches wherein the smart contract enables communication of funding between the customer and the decentralized data confidence fabric bank (Figure 3; column 4, line 16-34, column 6, line 26-67, column 7, line 1-13).
Regarding claims 6 and 16, Kuchar discloses of the trust provider fee amount (¶ 223-233). Phillips teaches wherein the obtaining of the funds from decentralized data confidence fabric bank 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 amount (¶ 19, 28, 94, 95, 114-116).
Regarding claims 7 and 17, Kuchar discloses trust provider fee amount (¶ 223-233). Rapowitz teaches wherein obtaining the funds from the decentralized data confidence fabric bank comprises deduction, by a smart contract, of the amount from the decentralized data confidence fabric bank (column 6, line 26-67, column 7, line 1-13, column 10, line 48-60, column 13, line 15-64).
Regarding claims 8 and 18, Kuchar discloses the smart contract transmits the funds to a digital wallet of the trust provider (¶ 223-233). Rapowitz teaches wherein after a smart contract obtains the funds from the decentralized data confidence fabric bank (column 7, line 1-13, column 8, line 21-60, column 11, line 48-67, column 14, line 1-22).
Regarding claims 9 and 19, Rapowitz teaches wherein obtaining the funds from the decentralized data confidence fabric bank comprises transferring, from the decentralized data confidence fabric bank to a smart contract, a bulk amount of funds that exceeds the trust provider fee amount (column 8, line 21-37, column 9, line 3-10, column 10, line 61-67, column 11, line 1-67, column 12, line 11-21).
Regarding claims 10 and 20, Rapowitz teaches wherein obtaining the funds from the decentralized data confidence fabric bank is performed on a per-annotation basis by the smart contract, after the smart contract has determined that the credit limit of the customer has not been exceeded (column 8, line 60-67, column 9, line 1-2, column 10, line 8-22, column 13, line 15-64).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tanimoto (US 20220294650) teaches funds from smart contract to a wallet.
Sliwka et al (US 2021/0082044) teaches trust systems for blockchain transactions
Cella et al (US 2023/0351393) teaches a potential 102
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, NEHA H PATEL can be reached on (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699