DETAILED ACTION
This action is in response to a filing filed on August 2nd, 2024. Claims 1-20 have been examined in this application. The Information Disclosure Statement (IDS) filed on August 2nd, 2024 has been acknowledged.
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 .
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-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without significantly more.
Step 1: Claims 1-12 is/are drawn to system (i.e., a manufacture), and claims 13-14 is/are drawn to method (i.e., a process). (Step 1: YES).
Step 2A - Prong One: In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception.
Claim 1: A system for managing supply chain finance comprising:
a processing subsystem hosted on a server and configured to execute on a network to control bidirectional communications among a plurality of modules comprising:
a finance request receiving module configured to: receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier;
and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier;
a financier seeking module operatively coupled to the finance request receiving module, wherein the financier seeking module is configured to identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier;
a supply chain financing module operatively coupled to the financier seeking module, wherein the supply chain financing module is configured to:
generate a perpetual contract between the buyer and the financier to mitigate the currency volatility risk for financing the funds upon identification of the financier;
enable the financier in financing the funds with one or more currencies to the buyer for paying the supplier for each of the one or more supplied goods or the one or more provided services based on the perpetual contract generated;
and enable the buyer to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the supply chain finance.
Claim 9: A system for managing retail finance comprising:
a retail processing subsystem hosted on a server and configured to execute on a network to control bidirectional communications among a plurality of modules comprising: a finance request receiving module configured to: receive one or more borrowing or borrowers request corresponding to one or more crypto collaterals or one or more collateralized crypto assets from a borrower; and receive a request for process of raising funds from a borrower for the one or more crypto collaterals or the one or more collateralized crypto assets based on the one or more borrowing or borrower request received from the borrower;
a financier seeking module operatively coupled to the finance request receiving module, wherein the financier seeking module is configured to identify a financier for financing the funds to the borrower based on the request received, wherein the funds corresponding to each of the one or more crypto collaterals or the one or more provided collateralized crypto assets is raised by the borrower; a retail financing module operatively coupled to the financier seeking module, wherein the retail financing module is configured to:
generate a perpetual contract to mitigate the currency volatility risk between the buyer and the financier for financing the funds upon identification of the financier;
enable the financier in financing the funds with one or more currencies to the borrower for paying the borrower for each of the one or more crypto collaterals or the one or more collateralized crypto assets based on the perpetual contract generated;
and enable the borrower to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the retail finance.
(Examiner notes: The underlined claim terms above are interpreted as additional elements beyond the abstract idea and are further analyzed under Step 2A - Prong Two)
Under their broadest reasonable interpretation, the claims recite managing financial transactions, including receiving invoices or borrower requests, identifying a financier, generating a financing contract, providing funds in various currencies, and enabling repayment with interest. Such operations constitute fundamental economic practices and methods of organizing human activity, specifically supply-chain financing, collateralized lending, contract-based fund disbursement, and loan repayment structures. Accordingly, the claims are directed to an abstract idea of financial management and economic coordination to perform receiving invoices and financing requests, identifying a financier, generating a financial contract (perpetual contracts), disbursing funds, repaying funs with interest, using different currencies (Claim 1) and receiving borrower requests tied to collateral, identifying a financier, generating a contract between borrower and financier, providing funds based on collateral, repaying funds with interest in fiat or cryptocurrency (Claim 9) constitutes as fundamental economic principles or practices (including hedging, insurance, mitigating risk) falls under “Certain Methods Of Organizing Human Activity”. From applicant’s specification, the claimed invention is implemented to retail processing subsystem 305 includes a retail finance request receiving module 310 configured to receive one or more collateralized requests corresponding to one or more collaterized crypto assets or one or more collateral requests from a borrower. The retail finance request receiving module 310 is also configured to receive a request for the process of raising funds from a borrower for the one or more collateral borrowing requests based on the one or more collateralized crypto assets received from the borrowers and retail financing module 330 is also configured to enable the borrower to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the currency volatility risk in retail finance. As used herein, the term ‘retail finance’ is defined as a set of business and financing practices that form the connections between various parties in a transaction borrower, lender, investor, financier and financing institution in order to lower financing costs and improve business efficiency (see at least [0044 and 0047] of instant published specification). The steps under its broadest reasonable interpretation specifically directed to an abstract idea of financial management and economic coordination implemented on generic computer infrastructure, which is an instance of certain methods of organizing human activity. The Examiner notes that although the claim limitations are summarized, the analysis regarding subject matter eligibility considers the entirety of the claim and all of the claim elements individually, as a whole, and in ordered combination.
And the dependent claims 2-8 and 10-12 recites an abstract idea, including verifying users, converting documents or collateral into digital tokens, receiving repayment inputs, selecting payment forms such as fiat or cryptocurrency, and recording financial information on a blockchain, which constitute specifically fundamental economic practices such as financing, collateral management, loan repayment, risk mitigation, supply-chain payment coordination, and identifying participants in financial transactions and fall within the judicial exception of “certain methods of organizing human activity”. These claims also recite mental processes, including verifying users, converting documents or collateral into digital tokens, receiving repayment inputs, selecting payment forms such as fiat or cryptocurrency, and recording financial information on a blockchain, which constitute the mere collection, analysis, and storage of data. Such features represent routine financial or commercial operations and generic information-processing steps that have been held abstract in cases such as Alice, Bilski, buySAFE, Electric Power Group, and SAP v. InvestPic., i.e. which constitute the mere collection, analysis, and storage of data, which fall under the abstract idea of Mental Processes.
Independent claim(s) 13 and 14 recite/describe nearly identical steps (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis.
As such, the Examiner concludes that claim 1 recites an abstract idea (Step 2A – Prong One: YES).
Step 2A - Prong Two: In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “addition element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
The requirement to execute the claimed steps/functions using a processing subsystem hosted on a server, finance request receiving module, financier seeking module, supply chain financing module, and retail financing module, etc. (Claims 1, 9, and 13-14) is/are equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer.
Similarly, the limitations of using a processing subsystem hosted on a server, finance request receiving module, financier seeking module, supply chain financing module, and retail financing module, etc. (Claims 1, 9, and 13-14, and dependent claims 2-8 and 10-12) are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
Further, the additional limitations beyond the abstract idea identified above, serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computerized environments (e.g., receive, identify, generate, transfer funds, etc. steps performed by a processing subsystem hosted on a server, finance request receiving module, financier seeking module, supply chain financing module, and retail financing module, etc.). This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(h)).
The recited additional element(s) of receive an input message from a receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier, identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier and repay the funds to the financier with interest using the one or more currencies (Independent Claims 1, 9, and 13-14), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application. (See MPEP 2106.05(g)).
Dependent claims 2-8 and 10-12 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e., they are part of the abstract idea recited in each respective claim).
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B: In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for an "inventive concept." An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself. Alice Corp., 134 S. Ct. at 2355, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. at 72-73, 101 USPQ2d at 1966).
As discussed above in “Step 2A – Prong 2”, the identified additional elements in independent Claim(s) 1, 9, and 13-14, and dependent claims 2-8 and 10-12 are equivalent to adding the words “apply it” on a generic computer, and/or generally link the use of the judicial exception to a particular technological environment or field of use. Therefore, the claims as a whole do not amount to significantly more than the judicial exception itself.
The recited additional element(s) of receive an input message from a receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier, identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier and repay the funds to the financier with interest using the one or more currencies (Independent Claims 1, 9, and 13-14), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea) i.e. receiving an input and transmitting is similar to “Receiving or transmitting data over a network, e.g., using the Internet to gather data”, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information), “Storing and retrieving information in memory”, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; “Presenting offers to potential customers and gathering statistics generated based on the testing about how potential customers responded to the offers; the statistics are then used to calculate an optimized price”, OIP Technologies, 788 F.3d at 1363, 115 USPQ2d at 1092-93, Determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93, is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here) (See MPEP 2106.05(d) (II)).
This conclusion is based on a factual determination. Applicant’s own disclosure at paragraph [0049] acknowledges that “receive the loan request for the purpose of trading, a retail financial request receiving module 310 of a retail processing subsystem 3005, receives one or more borrowing requests corresponding to one or more crypto asset collaterals or one or more crypto collateralized assets. The retail financial request receiving module 310 also receives a request for process of raising funds from a borrower for the one or more crypto collaterals or the one or more borrowing requests based on the one or more crypto collaterals received. In such an example, the processing subsystem is hosted on a cloud server 308 and executes on a wireless communication network 315 to control bidirectional communications among a plurality of modules.” (i.e., conventional nature of receiving and transmitting data/messages over a network). This additional element therefore do not ensure the claim amounts to significantly more than the abstract idea.
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer or/and append the abstract idea with insignificant extra solution activity associated with the implementation of the judicial exception, (e.g., mere data gathering, post-solution activity) and/or simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception.
The dependent claims 2-8 and 10-12 fail to include any additional elements. In other words, each of the limitations/elements recited in respective independent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e., they are part of the abstract idea recited in each respective claim).
Claims 2 and 10 merely add user verification and blockchain-based platforms for conducting financial transactions, which constitute generic computer functions used to authenticate participants or record financial information on a distributed ledger, without improving the functioning of the computer or the ledger itself. Claims 3 and 11 recite converting invoices or crypto collaterals into non-fungible tokens or other tokenized digital assets, which reflects a data representation of financial documents rather than a technological improvement. Claims 4 and 5 add that the financing may occur using fiat currency or cryptocurrency, including Bitcoin, Ethereum, or Dogecoin, which are simply alternative forms of financial value and do not alter the underlying abstract idea of executing financing transactions. Claims 6 and 12 recite receiving inputs for repayment decisions, token deposits, or risk-mitigation strategies, which are routine financial decision-making steps implemented on generic computing components. Claim 7 specifies that the financier may be a financial institution or a person, which merely identifies participants in the economic arrangement. Claim 8 recites using a blockchain platform to manage trading of supply chain finance, which again amounts to using known distributed-ledger technology as a tool to perform financial recordkeeping. Collectively, these dependent claims add only field-of-use restrictions, digitization of documents, participant identification, and data-handling operations, all of which constitute well-understood, routine, and conventional activities performed by generic computer components and therefore fail to integrate the abstract financial concept into a practical application.it is recited at a high level of generality and does not integrate the judicial exception into a practical application.
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Therefore, claims 1-14 are not eligible subject matter under 35 USC 101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status:
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 of this title, 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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 7-10, and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20130179330 (“Quillian”) in view U.S. Pub. 20220198562 (“Cella”).
As per claims 1 and 13, Quillian discloses, system for managing supply chain finance comprising: a processing subsystem hosted on a server and configured to execute on a network (“supply chain describes the network of vendors, suppliers, manufacturers, subcontractors, service providers, assembly operations, warehousing and distribution centers, end customers or buyers, and other parties that participate in the sale, production, and delivery of a product or service … Financial institutions or commercial lenders often get involved in the supply chain to provide funding to assist in the financing of such transactions and to support the cash flow of suppliers and buyers” and “electronic supply chain finance system utilized by a buyer, a supplier that provides goods and/or services to the buyer, and a financial institution, each of which is remote from the system, has a computer-readable medium containing program instructions and a processor in operative communication with the computer-readable medium … receiving information from the buyer defining a payment obligation from the buyer to the supplier corresponding to a transaction in which the supplier provides the goods and/or services to the buyer. An offer to sell the payment obligation is received from the supplier. An acceptance of the offer is received from the financial institution. An electronic record of a negotiable instrument is created at the system, wherein the buyer is obligor, and the supplier is obligee, of the negotiable instrument, and the negotiable instrument has a payable date based on a maturity date of the payment obligation and has a payment value based on a payment amount of the payment obligation”) (0005, and 0013-0015) to control bidirectional communications among a plurality of modules comprising (Examiner notes that a network-based supply chain financing system where buyers, suppliers, and financial institutions access the platform via computer interfaces i.e. distributed computing environments where tasks are performed by local and remote processing devices that are linked … through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices) (“financial institution chooses to accept the sell offer, then, pursuant to a previous contractual arrangement between the financial institution and the supplier, the financial institution may execute acceptance via notification to the central entity's system, thereby transferring to the financial institution the supplier's third party rights under the buyer's payment obligation. The financial institution then transfers the discounted amount to the supplier, and the buyer pays the financial institution in full upon the maturity date”) (0011, Fig. 1):
a finance request receiving module configured to: receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier (“when a product leaves the supplier, or after a service has been provided, the supplier creates an invoice and communicates the invoice to the buyer. The invoice date is typically the date the invoice is transmitted from the supplier's place of operation, and this invoice date starts a period of time (i.e. "grace period") during which no payment from the buyer is required or expected. This grace period creates, in effect, a credit line established by the supplier on behalf of the buyer, and is generally offered with no interest being charged on the outstanding balance. Often, the supplier offers a discount for payment before the grace period ends. Once the grace period has passed, payment in full is due …”) (0007);
and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier (Examiner notes that in SCF system, the payment obligation is the buyer’s request for financing, enabling the supplier to raise funds based on the buyer’s approval of the invoice to pay earlier) (“The buyer uploads to the system information relating to the buyer's accounts payable arising from commercial transactions between the buyer and the supplier outside the system and/or which the supplier has submitted one or more invoices to the buyer. Pursuant to an earlier contractual arrangement between the buyer and the central entity, the uploading of the accounts payable information from the buyer to the central entity establishes an irrevocable contractual obligation from the buyer to pay the total amount due on the uploaded obligation. This irrevocable obligation is in favor of the supplier or the supplier's assignees, such party therefore being a third party beneficiary to the contract between the buyer and the central entity. The supplier, who may access the system and view the uploaded obligation(s), may choose to wait and receive full payment on the underlying accounts payable (accounts receivable to the supplier) or may choose to offer for sale its accounts receivable corresponding to the uploaded obligation. If the supplier chooses to sell the accounts receivable, it so indicates through a notification to the central entity's system via the interface. This notice becomes visible to a financial institution when the financial institution accesses the system through an interface”) (0010);
a financier seeking module operatively coupled to the finance request receiving module, wherein the financier seeking module is configured to identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier (Examiner notes that system enables the supplier sell the payment obligation to a third party financial institution prior to maturity that requires identifying a financier willing to accept the obligation.) (“receiving accounts payable information from the buyer defining a payment obligation from the buyer to the supplier that has a payment value and a payment maturity date. An offer to sell the payment obligation is received from the supplier. An acceptance of the offer is received from the financial institution. Upon receipt of acceptance of the offer by the financial institution, the system provides electronic information to the financial institution to print a negotiable instrument, indorsed on behalf of the supplier to the financial institution as obligee thereof. The negotiable instrument has the buyer as obligor, supplier as obligee (i.e. payee), a payable date based on the maturity date, and a payment value based on the payment amount … providing funds to a supplier that provides goods and/or services to a buyer includes receiving from the buyer, via a computer network at a computer system remote from the buyer, the supplier, and a financial institution, information defining a payment obligation from the buyer to the supplier corresponding to a transaction in which the supplier provides the goods and/or services to the buyer. An offer to sell the payment obligation is received at the computer system via a computer network”) (0014-0016, 0012).
Quillian specifically doesn’t discloses, generate a perpetual contract between the buyer and the financier to mitigate the currency volatility risk for financing the funds upon identification of the financier, enable the financier in financing the funds with one or more currencies to the buyer for paying the supplier for each of the one or more supplied goods or the one or more provided services based on the perpetual contract generated, and enable the buyer to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the supply chain finance, however Cella discloses, a supply chain financing module operatively coupled to the financier seeking module, wherein the supply chain financing module is configured to (“The smart contract may be used in banking, government, management, supply chain, automobiles, real estate, health care, insurance, etc. In some embodiments, the smart contract 16840 may be contained and/or executed in a virtual machine or a container (e.g., a Docker container). In some embodiments, one or more of the nodes 16916 of the ledger network 16970 may provide an execution environment for the smart contract 16840. In embodiments, a smart contract 16840 may include information, data, and/or logic related to an instance of digital knowledge 16804, one or more triggering events, one or more smart contract actions to be executed in response to detection of one or more of the triggering events, and the like”) (0915): generate a perpetual contract between the buyer and the financier to mitigate the currency volatility risk for financing the funds upon identification of the financier (Examiner notes that Cella discloses a smart contract 16840 that can be used in supply-chain contexts and that executes on a distributed ledger network, where the smart contract includes stored information, data, and logic defining triggering events and corresponding smart-contract actions (¶0915). The smart contract therefore persists on the ledger and governs the conditions under which financial obligations are performed over time, effectively operating as an ongoing or “perpetual” contract controlling financing relationships. Cella further teaches that the system evaluates collateral using valuation models that account for volatility and sensitivity of collateral values, including jurisdictional and geolocation effects such as market volatility, risk phenomena, and other factors affecting collateral value (¶0293)) (“jurisdictional effects on the timing between default and foreclosure or collection of collateral; and/or jurisdictional effects on the volatility and/or sensitivity of collateral value determinations … A valuation model may utilize a valuation of offset collateral (e.g., a similar item of collateral, a generic value such as a market value of similar or fungible collateral, and/or a value of an item that correlates with a value of the collateral) as a part of the valuation of the collateral …”) (0293);
enable the financier in financing the funds with one or more currencies to the buyer for paying the supplier for each of the one or more supplied goods or the one or more provided services based on the perpetual contract generated (Examiner notes that blockchain-based systems may operate with multiple units of value, including currency, cryptocurrency, collateral tokens, or other digital representations of consideration. As stated in ¶¶0328-0331,0342, 0564, the disclosure explains that a blockchain can be associated with a unit of consideration, collateral, currency, cryptocurrency, or any other form of value, and that blockchains may be used in conjunction with investment, token-trading, or digital-currency marketplaces. Examiner therefore finds that a financier utilizing such a system would have been able to select and disburse funds in various currencies, thereby meeting the claimed “one or more currencies.”) (“the present disclosure, in the former case, a blockchain may also be used in conjunction with investment applications, token-trading applications, and/or digital/cryptocurrency based marketplaces. A blockchain can also be associated with rendering consideration, such as providing goods, services, items, fees, access to a restricted area or event, data, or other valuable benefit. Blockchains in various forms may be included where discussing a unit of consideration, collateral, currency, cryptocurrency, or any other form of value. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the value symbolized or represented by a blockchain” and “the quantum computing system 20214 and/or artificial intelligence system of the platform 20500 may be used to determine a rate of exchange between, among, or across a set of marketplaces, including ones that trade in different fiat currencies, cryptocurrencies, tokens, in-kind value (e.g., exchanges of services), or other units of exchange, such as by simulating a set of trading activities involving the set of marketplaces. For example, an exchange rate may be determined between a renewable energy credit marketplace and a cryptocurrency marketplace (e.g., for Bitcoin™), between a pollution credit marketplace and an advertising marketplace, between a stock market and a bond market, between different fiat currencies, between various fiat and cryptocurrencies, between an advertising marketplace and a loyalty marketplace, and the like, optionally including any pair or other combination of any of the types of marketplace”) (0237, and 1953);
and enable the buyer to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the supply chain finance (Examiner notes that smart contracts may include logic defining triggering events and the actions to be taken in response, and that such actions may be performed by users. Such contracts inherently govern performance of financial obligations, including repayments. When combined with the system’s support for multiple types of currency and value units as noted above, that repayment of financed amounts may likewise be performed using “one or more currencies.) (“The smart contract may be used in banking, government, management, supply chain, automobiles, real estate, health care, insurance, etc. In some embodiments, the smart contract 16840 may be contained and/or executed in a virtual machine or a container (e.g., a Docker container). In some embodiments, one or more of the nodes 16916 of the ledger network 16970 may provide an execution environment for the smart contract 16840. In embodiments, a smart contract 16840 may include information, data, and/or logic related to an instance of digital knowledge 16804, one or more triggering events, one or more smart contract actions to be executed in response to detection of one or more of the triggering events, and the like. In embodiments, the triggering events may define conditions that may be satisfied by events performable by one or more users, such as the knowledge provider 16806, the knowledge recipient 16818, and/or the crowdsourcer 16836, or by one or more third parties” and “in a tiered distribution contract framework, the transaction framework 17476 may be configured to use the distributed ledger 16808 and the smart contract 16840 to allocate one or more of payments, commissions, and costs in a granular manner In another example, in a contingent contract framework, the transaction framework 17476 may be configured to use the distributed ledger 16808 and the smart contract 16840 to manage one or more of options, futures, emergent events, and the like. Other examples of smart contract frameworks 17476 include those configured to manage commissions, incentive payments, payments for milestones (e.g., partial work, delivery partway through a supply chain, etc.), and escrows.”) (0915 and 0962).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a finance request receiving module configured to: receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier, wherein the financier seeking module is configured to identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier, as disclosed by Quillian, generate a perpetual contract between the buyer and the financier to mitigate the currency volatility risk for financing the funds upon identification of the financier, enable the financier in financing the funds with one or more currencies to the buyer for paying the supplier for each of the one or more supplied goods or the one or more provided services based on the perpetual contract generated, and enable the buyer to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the supply chain finance, as taught by Cella for the purpose to automate financing and repayment across multiple currencies under a digitally enforced contract to improve the operation of a known supply chain finance platform to generate and maintain a contract between a buyer and a financier that mitigates currency and value-volatility risk when financing funds upon identification of the financier to mitigate the currency volatility risk for financing the funds upon identification of the financier.
As per claims 2, Quillian discloses, a user verification module configured to verify the supplier for obtaining the funds using a know your customer verification process (“Once buyer program 100 is active, community manager 120 continues to monitor and manage the program using tools provided on the SCF platform. A supplier cannot be added to a buyer program until the buyer program is active, which occurs once the community data is entered, a financial institution has accepted the buyer program, a buyer has entered bank account information, and the service provider has verified bank account information”) (0341).
As per claims 7, Quillian discloses, wherein the financier comprises at least one of a lending financial institution, a person or a combination thereof (“enabling all parties to a "supply chain" (buyers, suppliers, and financial institutions) to collaborate to enable a supplier to negotiate to the financial institution a negotiable instrument on which the buyer is obligor and having a value related to the buyer's accounts payable to the supplier. In a preferred embodiment, this allows negotiation of the instrument to the supplier at a discount from full value that is based on the instrument's maturity date and upon the financial strength of the buyer rather than the financial strength or credit risk of the supplier”) (0003).
As per claims 8, Quillian discloses, wherein the processing subsystem comprises a blockchain based platform for managing trading of supply chain finance (“select the currency to get a community summary by buyer programs 100 trading in similar currencies. Community manager 120 defines the currency of the home page summary and can view the summary in each currency the community 112 is trading in by selecting the currency from a list box of appropriate currencies. Community manager 120 can set the default currency for display when first accessing the home page. Community manager home page 202 allows the user to select the currency for the trading snapshot. The community manager defines the currency of the trading snap shot and views the snap shot in each currency in which the community 112 is trading.”) (0566).
As per claims 9 and 14, Quillian discloses, system for managing retail finance comprising: a retail processing subsystem hosted on a server and configured to execute on a network (“supply chain describes the network of vendors, suppliers, manufacturers, subcontractors, service providers, assembly operations, warehousing and distribution centers, end customers or buyers, and other parties that participate in the sale, production, and delivery of a product or service. Such supply chains are focused on satisfying buyer orders for finished goods or services at chosen locations. Typically, each order describes the desired goods or services, the quantity, a cost, and an expected delivery date. Financial institutions or commercial lenders often get involved in the supply chain to provide funding to assist in the financing of such transactions and to support the cash flow of suppliers and buyers” and “electronic supply chain finance system utilized by a buyer, a supplier that provides goods and/or services to the buyer, and a financial institution, each of which is remote from the system, has a computer-readable medium containing program instructions and a processor in operative communication with the computer-readable medium … receiving information from the buyer defining a payment obligation from the buyer to the supplier corresponding to a transaction in which the supplier provides the goods and/or services to the buyer. An offer to sell the payment obligation is received from the supplier. An acceptance of the offer is received from the financial institution. An electronic record of a negotiable instrument is created at the system, wherein the buyer is obligor, and the supplier is obligee, of the negotiable instrument, and the negotiable instrument has a payable date based on a maturity date of the payment obligation and has a payment value based on a payment amount of the payment obligation”) (0005, and 0013-0015) to control bidirectional communications among a plurality of modules comprising (Examiner notes that a network-based supply chain financing system where buyers, suppliers, and financial institutions access the platform via computer interfaces i.e. distributed computing environments where tasks are performed by local and remote processing devices that are linked … through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices) (“financial institution chooses to accept the sell offer, then, pursuant to a previous contractual arrangement between the financial institution and the supplier, the financial institution may execute acceptance via notification to the central entity's system, thereby transferring to the financial institution the supplier's third party rights under the buyer's payment obligation. The financial institution then transfers the discounted amount to the supplier, and the buyer pays the financial institution in full upon the maturity date”) (0011, Fig. 1):
a finance request receiving module configured to: receive one or more borrowing or borrowers request corresponding to one or more crypto collaterals or one or more collateralized crypto assets from a borrower (Examiner notes that underlined limitation is disclosed by another reference) (“supplier 108 provides goods or services after buyer 106 has requested them, typically through the buyer's issuance of a purchase order. At step 2, after a purchase order is received, supplier 108 accepts the purchase order and provides the requested goods or services. After supplying the goods, supplier 108 generates and delivers an invoice to buyer 106 …”) (0254);
a financier seeking module operatively coupled to the finance request receiving module, wherein the financier seeking module is configured to identify a financier for financing the funds to the borrower based on the request received (Examiner notes that system enables the supplier sell the payment obligation to a third party financial institution prior to maturity that requires identifying a financier willing to accept the obligation) (“receiving accounts payable information from the buyer defining a payment obligation from the buyer to the supplier that has a payment value and a payment maturity date. An offer to sell the payment obligation is received from the supplier. An acceptance of the offer is received from the financial institution. Upon receipt of acceptance of the offer by the financial institution, the system provides electronic information to the financial institution to print a negotiable instrument, indorsed on behalf of the supplier to the financial institution as obligee thereof. The negotiable instrument has the buyer as obligor, supplier as obligee (i.e. payee), a payable date based on the maturity date, and a payment value based on the payment amount … providing funds to a supplier that provides goods and/or services to a buyer includes receiving from the buyer, via a computer network at a computer system remote from the buyer, the supplier, and a financial institution, information defining a payment obligation from the buyer to the supplier corresponding to a transaction in which the supplier provides the goods and/or services to the buyer. An offer to sell the payment obligation is received at the computer system via a computer network”) (0014-0016, 0012), wherein the funds corresponding to each of the one or more crypto collaterals or the one or more provided collateralized crypto assets is raised by the borrower (“a supplier may sell its accounts receivable (A/R) or use the A/R as collateral for a loan to raise capital for operations or other purpose. The term "factoring" is used to describe the sale or collateralization of A/R. The factoring process, however, can be lengthy and cumbersome. For example, suppliers typically must submit detailed paperwork to the factor and follow-up with substantial documentation and proof of invoice validity prior to obtaining cash. Furthermore, the factor typically devalues the supplier's receivable base to some degree, e.g. due to debtors with low credit ratings and/or because it is expected that the supplier's A/R may be reduced by returns and/or other types of chargebacks arising from the underlying transaction. For these reasons, the factor generally only lends up to 80% of the true value of the A/R. Additionally, interest rates in factoring are generally very high (12%+), even for A/R from "investment grade" buyers”) (0009).
Quillian discloses use the A/R as collateral for a loan to raise capital but specifically doesn’t discloses, corresponding to one or more crypto collaterals or one or more collateralized crypto assets from a borrower, and receive a request for process of raising funds from a borrower for the one or more crypto collaterals or the one or more collateralized crypto assets based on the one or more borrowing or borrower request received from the borrower, a retail financing module operatively coupled to the financier seeking module, wherein the retail financing module is configured to: generate a perpetual contract to mitigate the currency volatility risk between the buyer and the financier for financing the funds upon identification of the financier, enable the financier in financing the funds with one or more currencies to the borrower for paying the borrower for each of the one or more crypto collaterals or the one or more collateralized crypto assets based on the perpetual contract generated, and enable the borrower to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the retail finance, however Cella discloses, corresponding to one or more crypto collaterals or one or more collateralized crypto assets from a borrower (“underwriting includes any underwriting, including, without limitation, relating to underwriters, providing underwriting information for a loan, underwriting a debt transaction, underwriting a bond transaction, underwriting a subsidized loan transaction, underwriting a securities transaction, and the like. Underwriting services may be provided by financial entities, such as banks, insurance or investment houses, and the like, whereby the financial entity guarantees payment in case of a determination of a loss condition (e.g., damage or financial loss) and accept the financial risk for liability arising from the guarantee … commitments represented on a blockchain (e.g., distributed ledger); transportation offerings aggregated and fulfilled (e.g., with a wide range of pre-defined contingencies); aggregation of goods and services on the blockchain (e.g., a distributed ledger used for demand planning); with respect to a demand aggregation interface (e.g., presented to one or more consumers); aggregation of multiple submissions; aggregating identity and behavior information (e.g., insurance underwriting); accumulation and aggregation of multiple parties; aggregation of data for a set of collateral; aggregated value of collateral or assets (e.g., based on real time condition monitoring, rea-time market data collection and integration, and the like); aggregated tranches of loans; collateral for smart contract aggregated with other similar collateral; and the like”) (0329-0331);
and receive a request for process of raising funds from a borrower for the one or more crypto collaterals or the one or more collateralized crypto assets based on the one or more borrowing or borrower request received from the borrower (Examiner notes that user initiated submission of tokenized assets into a smart-contract-controlled distributed ledger technologies (DLT system), which constitutes afunctional borrower request associated with a collateralized digital asset) (“The knowledge distribution system may be a blockchain for knowledge system that allows for storage of digital knowledge, buying and selling of digital knowledge, tokenization of digital knowledge, and/or reviewing/auditing of the digital knowledge via a cryptographically secure distributed ledger. Smart contracts may be implemented on the distributed ledger and controlling of rights to digital knowledge, transferring digital knowledge, and adherence of parties to agreements related to the digital knowledge. The blockchain for knowledge system can also facilitate third parties reviewing, auditing, or verifying information related to digital knowledge”) (0029);
a retail financing module operatively coupled to the financier seeking module, wherein the retail financing module is configured to (“the platform 20500 is configured to support different types of traders, including retail traders, institutional traders, individual traders, secondary market traders, brokers, dealers, buyers, sellers, market makers, and others, as well as various other parties and counterparties to marketplace transactions”) (1788): generate a perpetual contract to mitigate the currency volatility risk between the buyer and the financier for financing the funds upon identification of the financier (Examiner notes that Cella discloses a smart contract 16840 that can be used in supply-chain contexts and that executes on a distributed ledger network, where the smart contract includes stored information, data, and logic defining triggering events and corresponding smart-contract actions (¶0915). The smart contract therefore persists on the ledger and governs the conditions under which financial obligations are performed over time, effectively operating as an ongoing or “perpetual” contract controlling financing relationships. Cella further teaches that the system evaluates collateral using valuation models that account for volatility and sensitivity of collateral values, including jurisdictional and geolocation effects such as market volatility, risk phenomena, and other factors affecting collateral value (¶0293)) (“jurisdictional effects on the timing between default and foreclosure or collection of collateral; and/or jurisdictional effects on the volatility and/or sensitivity of collateral value determinations … A valuation model may utilize a valuation of offset collateral (e.g., a similar item of collateral, a generic value such as a market value of similar or fungible collateral, and/or a value of an item that correlates with a value of the collateral) as a part of the valuation of the collateral …”) (0293);
enable the financier in financing the funds with one or more currencies to the borrower for paying the borrower for each of the one or more crypto collaterals or the one or more collateralized crypto assets based on the perpetual contract generated ((Examiner notes that blockchain-based systems may operate with multiple units of value, including currency, cryptocurrency, collateral tokens, or other digital representations of consideration. As stated in ¶¶0328-0331,0342, 0564, the disclosure explains that a blockchain can be associated with a unit of consideration, collateral, currency, cryptocurrency, or any other form of value, and that blockchains may be used in conjunction with investment, token-trading, or digital-currency marketplaces. Examiner therefore finds that a financier utilizing such a system would have been able to select and disburse funds in various currencies, thereby meeting the claimed “one or more currencies.”) (“the present disclosure, in the former case, a blockchain may also be used in conjunction with investment applications, token-trading applications, and/or digital/cryptocurrency based marketplaces. A blockchain can also be associated with rendering consideration, such as providing goods, services, items, fees, access to a restricted area or event, data, or other valuable benefit. Blockchains in various forms may be included where discussing a unit of consideration, collateral, currency, cryptocurrency, or any other form of value. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the value symbolized or represented by a blockchain” and “the quantum computing system 20214 and/or artificial intelligence system of the platform 20500 may be used to determine a rate of exchange between, among, or across a set of marketplaces, including ones that trade in different fiat currencies, cryptocurrencies, tokens, in-kind value (e.g., exchanges of services), or other units of exchange, such as by simulating a set of trading activities involving the set of marketplaces. For example, an exchange rate may be determined between a renewable energy credit marketplace and a cryptocurrency marketplace (e.g., for Bitcoin™), between a pollution credit marketplace and an advertising marketplace, between a stock market and a bond market, between different fiat currencies, between various fiat and cryptocurrencies, between an advertising marketplace and a loyalty marketplace, and the like, optionally including any pair or other combination of any of the types of marketplace”) (0237, and 1953);
and enable the borrower to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the retail finance (Examiner notes that smart contracts may include logic defining triggering events and the actions to be taken in response, and that such actions may be performed by users. Such contracts inherently govern performance of financial obligations, including repayments. When combined with the system’s support for multiple types of currency and value units as noted above, that repayment of financed amounts may likewise be performed using “one or more currencies.) (“The smart contract may be used in banking, government, management, supply chain, automobiles, real estate, health care, insurance, etc. In some embodiments, the smart contract 16840 may be contained and/or executed in a virtual machine or a container (e.g., a Docker container). In some embodiments, one or more of the nodes 16916 of the ledger network 16970 may provide an execution environment for the smart contract 16840. In embodiments, a smart contract 16840 may include information, data, and/or logic related to an instance of digital knowledge 16804, one or more triggering events, one or more smart contract actions to be executed in response to detection of one or more of the triggering events, and the like. In embodiments, the triggering events may define conditions that may be satisfied by events performable by one or more users, such as the knowledge provider 16806, the knowledge recipient 16818, and/or the crowdsourcer 16836, or by one or more third parties” and “in a tiered distribution contract framework, the transaction framework 17476 may be configured to use the distributed ledger 16808 and the smart contract 16840 to allocate one or more of payments, commissions, and costs in a granular manner In another example, in a contingent contract framework, the transaction framework 17476 may be configured to use the distributed ledger 16808 and the smart contract 16840 to manage one or more of options, futures, emergent events, and the like. Other examples of smart contract frameworks 17476 include those configured to manage commissions, incentive payments, payments for milestones (e.g., partial work, delivery partway through a supply chain, etc.), and escrows.”) (0915 and 0962).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a finance request receiving module configured to: receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier, wherein the financier seeking module is configured to identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier, as disclosed by Quillian, corresponding to one or more crypto collaterals or one or more collateralized crypto assets from a borrower, and receive a request for process of raising funds from a borrower for the one or more crypto collaterals or the one or more collateralized crypto assets based on the one or more borrowing or borrower request received from the borrower, a retail financing module operatively coupled to the financier seeking module, wherein the retail financing module is configured to: generate a perpetual contract to mitigate the currency volatility risk between the buyer and the financier for financing the funds upon identification of the financier, enable the financier in financing the funds with one or more currencies to the borrower for paying the borrower for each of the one or more crypto collaterals or the one or more collateralized crypto assets based on the perpetual contract generated, and enable the borrower to repay the funds to the financier with interest using the one or more currencies based on the perpetual contract generated for managing the retail finance, as taught by Cella for the purpose to automate financing and repayment across multiple currencies under a digitally enforced contract to improve the operation of a known supply chain finance platform to generate and maintain a contract between a buyer and a financier that mitigates currency and value-volatility risk when financing funds upon identification of the financier to mitigate the currency volatility risk for financing the funds upon identification of the financier.
As per claims 10, Quillian discloses, wherein the retail processing subsystem comprises a blockchain based platform for managing trading in retail finance (“select the currency to get a community summary by buyer programs 100 trading in similar currencies. Community manager 120 defines the currency of the home page summary and can view the summary in each currency the community 112 is trading in by selecting the currency from a list box of appropriate currencies. Community manager 120 can set the default currency for display when first accessing the home page. Community manager home page 202 allows the user to select the currency for the trading snapshot. The community manager defines the currency of the trading snap shot and views the snap shot in each currency in which the community 112 is trading.”) (0566, 0329).
Claims 3-6 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20130179330 (“Quillian”) in view of U.S. Pub. 20220198562 (“Cella”) in further view of U.S. Pub. 20190356641 (“Isaacson”).
As per claims 3 and 11, Quillian specifically doesn’t discloses, one or more invoices presented by the supplier are scanned using scanners and are converted into non-fungible tokens, however Isaacson discloses, wherein the one or more invoices presented by the supplier are scanned using scanners and are converted into non-fungible tokens (“some documents scanned and provided to the smart contract which could handle recordation requirements. Thus, the communication between the smart contract 2308 and a user 2314 can represent the smart contract initiating an email or text or other communication to the user requesting certain information. An interface could be provided which enables the user to confirm data, attach data, provide a picture or photo, provide commentary via text or audio, electronically sign documents or any other function that might be necessary in order to further the process of the transaction” and “the smart contract could store a tokenized packet of data as part of an Apple Pay, cryptocurrency, PayPal or a Google Pay process. It could be the same type of data which would be simply delivered to a site for submission to their payment processor 2316 as part of a normal payment request API transaction. However, as part of the smart contract concept, the process can include routing that tokenized packet for storage in the smart contract until confirmation of the deposit of the product with the delivery services received”) (0317 and 0349).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a finance request receiving module configured to: receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier, wherein the financier seeking module is configured to identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier, as disclosed by Quillian, one or more invoices presented by the supplier are scanned using scanners and are converted into non-fungible tokens, as taught by Isaacson for the purpose to allow users for keeping their document in a secure place and also lets merchants securely encrypt the payment information without it having to distribute the payment processing certificate as part of the merchant application.
As per claims 4, Quillian specifically doesn’t discloses, wherein the one or more currencies comprises a cryptocurrency and fiat currency, however Isaacson discloses, wherein the one or more currencies comprises a cryptocurrency and fiat currency (“The cryptocurrency could be used as a bridge currency as well such that the first user could pay in a first fiat currency, and exchanges (like Binance or CoinBase) could be used to convert to the cryptocurrency, and then back into a second fiat currency for the second user”) (0014).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a finance request receiving module configured to: receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier, wherein the financier seeking module is configured to identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier, as disclosed by Quillian, wherein the one or more currencies comprises a cryptocurrency and fiat currency, as taught by Isaacson for the purpose to allow users for keeping their document in a secure place and also lets merchants securely encrypt the payment information without it having to distribute the payment processing certificate as part of the merchant application.
As per claims 5, Quillian specifically doesn’t discloses, wherein the cryptocurrency comprises at least one of a Bitcoin, an Ethereum, a Dogecoin or a combination thereof, however Isaacson discloses, wherein the cryptocurrency comprises at least one of a Bitcoin, an Ethereum, a Dogecoin or a combination thereof (“any currency such as Ethereum, Dash, Ripple, etc. Any currency in which transactions are stored on a blockchain via this process can apply. The principles also apply to a social media site or application having a cryptocurrency wallet integrated therein.”) (0103).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a finance request receiving module configured to: receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier, wherein the financier seeking module is configured to identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier, as disclosed by Quillian, wherein the cryptocurrency comprises at least one of a Bitcoin, an Ethereum, a Dogecoin or a combination thereof, as taught by Isaacson for the purpose to allow users for keeping their document in a secure place and also lets merchants securely encrypt the payment information without it having to distribute the payment processing certificate as part of the merchant application.
As per claims 6 and 12, Quillian specifically doesn’t discloses, receive repayment process of the funds from the buyer comprises a decision associated with depositing the funds using fiat currency, a decision associated with depositing the funds using cryptocurrency, a decision associated with depositing the funds using fungible tokens used to transact in the network, a risk mitigation strategy and payback terms, however Isaacson discloses, receive one or more inputs associated with repayment process of the funds from the buyer (“a smart contract is going to be used to manage the process, then funds from the seller are stored in a smart contract 2308. The way this could occur according to the payment request API, is that the data that is transmitted through the payment request API and/or the payment handler API that contains the token or the credit card amount, and credit card information, rather than being delivered to the site for payment processing, could be delivered and held at the smart contract 2308”) (0296), wherein the one or more inputs comprises a decision associated with depositing the funds using fiat currency (“The cryptocurrency could be used as a bridge currency as well such that the first user could pay in a first fiat currency, and exchanges (like Binance or CoinBase) could be used to convert to the cryptocurrency, and then back into a second fiat currency for the second user”) (0014), a decision associated with depositing the funds using cryptocurrency, a decision associated with depositing the funds using fungible tokens used to transact in the network, a risk mitigation strategy and payback terms (“the smart contract could store a tokenized packet of data as part of an Apple Pay, cryptocurrency, PayPal or a Google Pay process. It could be the same type of data which would be simply delivered to a site for submission to their payment processor 2316 as part of a normal payment request API transaction. However, as part of the smart contract concept, the process can include routing that tokenized packet for storage in the smart contract until confirmation of the deposit of the product with the delivery services received.”) (0349).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a finance request receiving module configured to: receive one or more invoices corresponding to one or more supplied goods or one or more provided services from a supplier and receive a request for process of raising funds from a buyer for the one or more supplied goods or the one or more provided services based on the one or more invoices received from the supplier, wherein the financier seeking module is configured to identify a financier for financing the funds to the buyer based on the request received, wherein the funds corresponding to each of the one or more supplied goods or the one or more provided services is raised by the supplier, as disclosed by Quillian, receive repayment process of the funds from the buyer comprises a decision associated with depositing the funds using fiat currency, a decision associated with depositing the funds using cryptocurrency, a decision associated with depositing the funds using fungible tokens used to transact in the network, a risk mitigation strategy and payback terms, as taught by Isaacson for the purpose to allow users for keeping their document in a secure place and also lets merchants securely encrypt the payment information without it having to distribute the payment processing certificate as part of the merchant application.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US. Pub. 20200294140 (“Yang”).
Yang discloses, a method involving a core node of a blockchain that acquires a financing transaction from the blockchain's ledger, which contains account receivable information; the core node then determines the grant limit, repayment period, and loan interest rate based on that information; it subsequently publishes a financing management smart contract that includes these specifications, which the light node can use to manage the financing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GAUTAM UBALE whose telephone number is (571)272-9861. The examiner can normally be reached Mon-Fri. 7:00 AM- 6:30 PM PST.
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, Marissa Thein can be reached at (571) 272-6764. 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.
/GAUTAM UBALE/Primary Examiner, Art Unit 3689