DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, 18/608,989 filed 03/19/2024 which claims priority from U.S. Provisional Application 63/491,967, filed 03/24/2023.
The effective filing date is after the AIA date of March 16, 2013, and so the application is being examined under the “first inventor to file” provisions of the AIA .
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.
Status of the Application
This Final Office Action is in response to Applicant’s communication of 11/20/2025.
Claims 1-6, 8, 9, 11-14, 16, 17, and 19 are pending, of which claims 1 and 12 are independent. Claims 1, 6, 12, and 14 are currently amended, and claims 7, 10, 15, and 18 are currently cancelled.
All pending claims have been examined on the merits.
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-6, 8, 9, 11-14, 16, 17 and 19 are rejected under 35 U.S.C. §101 because the claimed invention is directed to non-statutory subject matter. The claimed invention is directed to an abstract idea, without “significantly more”.
Based on the flowchart in MPEP § 2106, Step 1 of the Alice/Mayo analysis is: “Is the claim to a process, machine, manufacture or composition of matter?”
In regards to Step 1 of the Alice/Mayo analysis, independent claims 1 and 12 are apparatus claims.
For the sake of compact prosecution, we continue with the Alice/Mayo “abstract idea” analysis.
Step 2A, prong 1 of the Alice/Mayo analysis is: “Does the claim recite a law of nature, a natural phenomenon (product of nature), or an abstract idea?”
In regards to Step 2A, prongs 1 and 2 of the Alice/Mayo analysis, the abstract idea elements recited in independent claim 12 are shown in italic font. (The “additional elements” and “extra solution steps” are shown in italic and underlined font):
12. (Currently Amended) A computing system for facilitating transactions, comprising:
a plurality of decentralized computing nodes configured as a peer-to-peer network participating in a distributed ledger on a blockchain, said decentralized computing nodes storing transaction blocks having stateful smart contracts comprising lending pool smart contracts having loop feedback and recursion among the decentralized computing nodes, wherein each computing node is configured to store and maintain a respective copy of the distributed ledger;
said decentralized computing nodes configured as a transaction processor that participates in the distributed ledger and transacts between a buyer self-custodial wallet on a buyer computing device and a supplier self-custodial wallet on a supplier computing device, wherein said supplier self-custodial wallet is configured to generate and upload invoices to the transaction processor,
said transaction processor is configured to mint the invoices as non- fungible tokens on the blockchain, and said buyer self-custodial wallet configured to pay the invoices to buy items via a loan provided by the lending pool smart contract, said transaction processor further comprising a module and application to operate invoices and loans on the blockchain, manage invoices off the blockchain, and onboard and connect buyers and suppliers,
said transaction processor comprising a payments subsystem, a Business-to-Business (B2B) web application, and a backend subsystem, said backend subsystem operating on the decentralized computing nodes, said backend system implementing an Application Programming Interface on the decentralized computing nodes that integrates system payments for the payments subsystem and integrates the B2B web application, and initiates and coordinates all blockchain transactions and implements network operations having logic as instructions that are located off the blockchain.
More specifically, claims 1-6, 8-9, 11-14, 16-17 and 19 recite an abstract idea: “Certain Methods of Organizing Human Activity", specifically “Commercial or Legal Interactions (Including Agreements in the form of Contracts; Legal Obligations; Advertising, Marketing, or Sales Activities or Behaviors; Business Relations)”, as discussed in MPEP §2106(a)(2) Parts (I) and (II), and in the 2019 Revised Patent Subject Matter Eligibility Guidance.
The “Commercial or Legal Interactions” elements include:
“generate and upload invoices to the transaction processor”.
“pay the invoices to buy items via a loan provided by the lending pool smart contract”.
“operate invoices and loans on the blockchain”.
“manage invoices off the blockchain”.
“onboard and connect buyers and suppliers”.
The “additional elements” include: “a plurality of decentralized computing nodes”, “a peer-to-peer network”, “a distributed ledger”, “a blockchain”, “transaction blocks”, “a transaction processor”, “smart contracts”, “lending pool smart contracts”, “a buyer self-custodial wallet”, “buyer computing device”, “a supplier self-custodial wallet”, “ a supplier computing device”, “a payments subsystem”, ”a Business-to-Business (B2B) web application”, “a backend subsystem” and “an Application Programming Interface”.
Moreover, “additional extra-solution elements” include: “wherein each computing node is configured to store and maintain a respective copy of the distributed ledger”, “mint the invoices as non- fungible tokens on the blockchain”.
Step 2A, prong 2 of the Alice/Mayo analysis is “Does the claim recite additional elements that integrate elements that integrate the judicial exception into a practical application?”
In regards to Step 2A, prong 2 of the Alice/Mayo analysis, this abstract idea is not integrated into a practical application, because:
The claim is directed to an abstract idea with additional generic computer elements. The generically recited computer elements (“a plurality of decentralized computing nodes”, “a peer-to-peer network”, “a distributed ledger”, “a blockchain”, “a transaction processor”, “transaction blocks”, “smart contracts”, “lending pool smart contracts”, “a buyer self-custodial wallet”, “buyer computing device”, “a supplier self-custodial wallet”, “ a supplier computing device”, “a payments subsystem”, ”a Business-to-Business (B2B) web application”, “a backend subsystem”, and “an Application Programming Interface”) do not add a meaningful limitation to the abstract idea, because they amount to simply implementing the abstract idea on a computer. The claim amounts to adding the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea.
The extra-solution activities (“wherein each computing node is configured to store and maintain a respective copy of the distributed ledger”, “mint the invoices as non- fungible tokens on the blockchain”) do not add a meaningful limitation to the method, as they are insignificant extra-solution activity;
The combination of the abstract idea with the additional elements (generically recited computer elements), and/or with the extra-solution activities, does not integrate the abstract idea into a practical application.
Step 2B of the Alice/Mayo analysis is: “Does the claim recite additional elements that amount to significantly more than the judicial exception?”
In regards to Step 2B of the Alice/Mayo analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea, because:
When considering the elements "alone and in combination" (“a plurality of decentralized computing nodes”, “a peer-to-peer network”, “a distributed ledger”, “a blockchain”, “a transaction processor”, “transaction blocks”, “smart contracts”, “lending pool smart contracts”, “a buyer self-custodial wallet”, “buyer computing device”, “a supplier self-custodial wallet”, “ a supplier computing device”, “a payments subsystem”, ”a Business-to-Business (B2B) web application”, “a backend subsystem”, and “an Application Programming Interface”.), they do not add significantly more (also known as an "inventive concept") to the exception, because they amount to simply implementing the abstract idea on a computer. Instead, they merely add the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform an abstract idea.
In regards to the extra solution activities (“wherein each computing node is configured to store and maintain a respective copy of the distributed ledger” , “mint the invoices as non- fungible tokens on the blockchain”), these are recognized as such by the court decisions listed in MPEP § 2106.05(d).
More specifically, in regards to the “storing” and “minting” steps, see the court cases Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015) (storing and retrieving information in memory); and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1092-93 (Fed. Cir. 2015) (storing and retrieving information in memory).
More specifically, in regards to the “receiving” / “communicating” / “participating” steps, see the court cases OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network) and (presenting offers and gathering statistics), OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Moreover, in regards to the “displaying” steps, see Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 120 U.S.P.Q.2d 1844 (Fed. Cir. 2016) (Holding that the claimed menu graphic user interface is an abstract idea under 35 USC §101, because claimant "[did] not claim a particular way of programming or designing the software to create menus that have these features, but instead merely claims the resulting systems").
The Examiner holds that the independent claims 1 and 12, “use a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data)” or “simply add a general purpose computer or computer components after the fact to an abstract idea”, given that “a peer-to-peer network”, “a distributed ledger”, and “blockchain” refer to a specific type of database, “transaction blocks” ” refer to components of a specific type of database, that “smart contracts” and “lending pool smart contracts” refer to software-implemented contracts, and that “a buyer self-custodial wallet” and “a supplier self-custodial wallet” refer to computer-implemented financial accounts that store cryptocurrencies. Moreover, “a payments subsystem”, ”a Business-to-Business (B2B) web application”, “a backend subsystem” and “an Application Programming Interface” refer to standard software components.
Independent claim 1 is rejected on the same grounds as independent claim 12, because claim 1 is broader in scope than claim 12.
All dependent claims are also rejected, because they merely further define the abstract idea, except for the following claims, which recite the following features:
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
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:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1-6, 8, 9, 11-14, 16, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over CA-3214519-A1 to Dorogusker et al. (“Dorogusker”. Eff. Filed on April 20, 2021. PCT Published on Oct. 27, 2022) in view of US20190228409A1 to Madisetti et al. (“Madisetti”. Filed on Feb. 27, 2019. Published on Jul. 25, 2019), and further in view of US 2025/0156945 A1 to Guruprasad (“Guruprasad”. Eff. Filed on 02/07/2022. Published on 05/15/2025).
In regards to claim 1,
1. (Currently Amended) A computing system for facilitating transactions, comprising:
a plurality of decentralized computing nodes configured as a peer-to-peer network
(See Dorogusker, para. [0096]: “The network 216 can connect any of the devices and platforms illustrated in FIG. 2. For example, the network 216 can connect host computing device 102, audience member client device 110, and artist computing device 224 together in a peer-to-peer network or can connect these devices through a service or platform such as multi-media platform 108 or social media platform 230.”)
(See Dorogusker, para. [0289]: “According to some examples, the method illustrated in FIG. 10 includes providing the financed amount to the artist at block 1008. For example, the financing engine 214 illustrated in FIG. 2 may provide the financed amount to the artist. For example, the payment processing system may transmit the funds via wire transfer, deposit the funds in a financial account associated with the artist, submit to a peer-to-peer account, and automatically route the funds to an artist's purpose, such as instrument financing or studio booking, or the like.”)
participating in a distributed ledger on a blockchain,
(See Dorogusker, para. [0035]: “Techniques described herein provide for applying distributed ledger technology and non-fungible tokens (NFT) to media licensing, media assignments, and media residuals. In some embodiments, the present technology disclosed herein maintains the digital rights associated with media and tracks digital rights associated with the media content as the rights move from one user to another.”)
said decentralized computing nodes storing transaction blocks having stateful smart contracts
(See Dorogusker, para. [0121]: “The finance platform 244 can provide one or more financial-related services. For example, the 244 includes a financing engine 214 configured to provide financing such as loans or advances to artist accounts so that the artist accounts may use the financing to create additional media content and or produce experiences or merchandise for purchase by other users of the multi-media platform 108. In some embodiments, the financing engine 214 is configured to work with other services illustrated in FIG. 2 to generate financing terms. In some embodiments, the financing terms are based on expected revenues from sales of media content, performances of media content, sales of merchandise in e-commerce service 210, licensing of media content through sales of non-fungible tokens (NFT), etc.”)
(See Dorogusker, para. [0125]: “The NFT component 206 can also be used to create a smart contract used to govern the behavior of the NFT. For example, a smart contract can govern instances when the NFT can be transferred to another party or when a media content can be divided into a smaller portion such as a sample, or when and how the media content can be performed.”)
(See Dorogusker, para. [0126]: “When the NFT includes a smart contract chaincode, (e.g., such as system chaincode available in Hyperledger Fabric 1.0), the governing of the smart contract can be provided by the smart contract arbiter component 212. The smart contract arbiter component 212 can be used to determine that one or more conditions referenced in a smart contract have been satisfied. The smart contract arbiter component 212 can otherwise be configured to interpret and execute the code defining a smart contract. Through a plurality of smart contracts or chain code, the distributed ledger 208 can maintain a consensus between different blockchains with relation to user's wallets and underlying NFTs, route an incoming transaction to one of the blockchain(s), e.g., based on context data, and then enable processing of the transaction on the blockchain.”)
(See Dorogusker, para. [0295]: “In some implementations, the financial offers are associated with specific recorded media content. Furthermore, in some examples, the services illustrated in FIG. 2 allow third-party APIs/SDKs to be exposed to multi-media platform 108 to obtain streaming data. In some embodiments, the lending infrastructure is implemented using smart contracts and/or DeFi technologies. In some implementations, the lending provider can be a crowdsourced entity where the artist's audience can be invested in the album, e.g., by gaining interest in the royalty model. In some implementations, an artist can be associated with multi-media platform 108 through their artist account. The lending provider can be the financing engine 214 or an entity that can generate a financial offer backed by an NFT in the media content.”)
wherein each computing node is configured to store and maintain a respective copy of the distributed ledger;
(See Dorogusker, para. [0126]: “When the NFT includes a smart contract chaincode, (e.g., such as system chaincode available in Hyperledger Fabric 1.0), the governing of the smart contract can be provided by the smart contract arbiter component 212. The smart contract arbiter component 212 can be used to determine that one or more conditions referenced in a smart contract have been satisfied. The smart contract arbiter component 212 can otherwise be configured to interpret and execute the code defining a smart contract. Through a plurality of smart contracts or chain code, the distributed ledger 208 can maintain a consensus between different blockchains with relation to user's wallets and underlying NFTs, route an incoming transaction to one of the blockchain(s), e.g., based on context data, and then enable processing of the transaction on the blockchain.”)
(See Dorogusker, para. [0127]: “The distributed ledger 208 is configured to store NFTs. In some embodiments, the distributed ledger 208 can be a blockchain network, particularly a blockchain network that supports smart contracts. One such blockchain network is the ETHEREUM network.”)
said decentralized computing nodes configured as a transaction processor that participates in the distributed ledger and transacts between a buyer self-custodial wallet on a buyer computing device and a supplier self-custodial wallet on a supplier computing device,
(See Dorogusker, para. [0125]: “The NFT component 206 can be configured to generate (or mint) an NFT for one or more media content in near real time, according to user's preferences (e.g., specific blockchain, expiration time, user's preferences, user's location (e.g., if it is detected that a user is operating in a wallet on a different blockchain) and the context of the conversation (or live media content) between the host and the audience member. The NFT component 206 can be configured to capture a unique description of the media content and/or to provide a persistent link or reference to the media content associated with the NFT.”)
(See Dorogusker, para. [0126]: “When the NFT includes a smart contract chaincode, (e.g., such as system chaincode available in Hyperledger Fabric 1.0), the governing of the smart contract can be provided by the smart contract arbiter component 212. The smart contract arbiter component 212 can be used to determine that one or more conditions referenced in a smart contract have been satisfied. The smart contract arbiter component 212 can otherwise be configured to interpret and execute the code defining a smart contract. Through a plurality of smart contracts or chain code, the distributed ledger 208 can maintain a consensus between different blockchains with relation to user's wallets and underlying NFTs, route an incoming transaction to one of the blockchain(s), e.g., based on context data, and then enable processing of the transaction on the blockchain.”)
The Examiner interprets Dorogusker’s para. [0126] teaching of “user's wallets” as referring to both buyer’s wallets and the seller’s wallets.
(See Dorogusker, para. [0309]: “Ownership of rights to digital and physical assets or collectibles may be recorded in non-fungible tokens (NFTs), a customized music token, and recorded in a blockchain, such as Ethereum. In some embodiments, smart contracts are provided using chaincode, (e.g., such as system chaincode available in Hyperledger Fabric 1.0) that can track the digital rights (ownership, license, royalty structures, etc., and conditions for transfer of rights) associated with media content. Through a plurality of smart contracts or chain code, the distributed ledger 208 can maintain a consensus between different blockchains with relation to user's wallets and underlying NFTs, route an incoming transaction to one of the blockchain(s), e.g., based on context data, and then enable processing of the transaction on the blockchain.”)
wherein said supplier self-custodial wallet is configured to generate and upload invoices to the transaction processor,
(See Dorogusker, para. [0132]: “While not illustrated in FIG. 2, one or more of the multi-media platform 108, the NFT platform 242, the finance platform 244, and the social media platform 230 can also include a gift card service (e.g., for ordering and/or selling gift cards or other stored value cards), a loyalty service (e.g., for managing loyalty rewards and/or redemptions), an invoice service (e.g., for managing invoices for services rendered and/or goods purchased), an estimate service (e.g., for managing estimates for services to be rendered and/or goods to be purchased), a contracts service (e.g., for managing contracts between the user and other entities), a reservation service (e.g., for managing reservations), a chat service (e.g., for facilitating communications between the user and other entities), a feedback service (e.g., to receive feedback about various aspects of a business), a directory service (e.g., for maintaining contact information of contacts of the user), an appointment service (e.g., for managing appointments), a payroll service (e.g., for making payroll payments to workers of the user), etc.”)
said transaction processor is configured to mint the invoices as non-fungible tokens on the blockchain,
(See Dorogusker, para. [0090]: “In some examples, the multi-media platform 108 includes an artist portal displayed via a dashboard component 246. The dashboard component 246 can configure a dashboard to display statistics related to engagement with media content and its usage by users and/or artists. Such a dashboard can be configurable to an artist user account or other user. In some examples, the artist can target merchandise relevant to the user, e.g., by converting data from the dashboard to an e-commerce service 210. The multi-media platform 108 may allow the artist to receive payments instantly for the use of media content through integration with payment processing service 220. For example, the artist can be paid directly before paying publishers or labels. In some embodiments, the multi-media platform 108 may allow artists to receive tips directly from the user interface of a multi-media application operating on client devices, e.g., directly from streams or marketplace sales.”)
(See Dorogusker, para. [0117]: “In addition, the multi-media platform 108 may support payments functionality to pay artist accounts to allow users of the multi-media platform 108 to pay/rent/use the media content and allow multi-media platform 108. The multi-media platform 108 may store and track the use of media content (e.g., in terms of streaming count, revenue collected, artist content, engagement statistics).”)
(See Dorogusker, para. [0132]: “While not illustrated in FIG. 2, one or more of the multi-media platform 108, the NFT platform 242, the finance platform 244, and the social media platform 230 can also include a gift card service (e.g., for ordering and/or selling gift cards or other stored value cards), a loyalty service (e.g., for managing loyalty rewards and/or redemptions), an invoice service (e.g., for managing invoices for services rendered and/or goods purchased), an estimate service (e.g., for managing estimates for services to be rendered and/or goods to be purchased)”)
said transaction processor comprising a payments subsystem, a Business-to-Business (B2B) web application, and a backend subsystem,
said backend subsystem operating on the decentralized computing nodes,
said backend system implementing an Application Programming Interface on the decentralized computing nodes
The Examiner interprets that the difference between “Business-to-Business (B2B) web application” and a “Business-to-Consumer (B2C) web application” (as taught in Dorogusker) is a difference of intended use, not a difference of functionality.
(See Dorogusker, para. [0077]: “In some embodiments, the multi-media platform 108, the NFT platform 242, the finance platform 244, and the social media platform 230 can all be provided by the same service provider or parent entity. In some embodiments, one or more of the multi-media platform 108, the NFT platform 242, the finance platform 244, and the social media platform 230 can be provided by one or more third-party entities, and the components within the various platforms can interact to take advantage of services provided by other components shown in FIG. 2 by calling application programming interfaces (APIs) offered by the components.”)
(See Dorogusker, para. [0122]: “In some embodiments, the financing terms are based on expected revenues from sales of media content, performances of media content, sales of merchandise in e-commerce service 210, licensing of media content through sales of non-fungible tokens (NFT), etc. In some embodiments, the financing engine 214 is also configured to work with a payment processing service to extract a portion of payments received by an artist account, thereby allowing the artist account having financing from financing engines to repay the financing [0122] In some embodiments, artist accounts may be associated with an E-commerce web page offered by e-commerce service 210 that can offer merchandise and experiences for sales to other user accounts of multi-media platform 108. The payment processing service 220 can provide payment processing for carrying out transactions by the e-commerce service 210 and multi-media platform 108.”)
(See Dorogusker, para. [0124]: “The environment illustrated in FIG. 2 also includes the NFT platform 242 for supporting services associated with offering media content and merchandise as a non-fungible token (NFT). In some embodiments, the artist accounts may elect to embody the value of one or more of their media content in a non-fungible token. "Non-fungibility” refers to the uniqueness or non-interchangeability of individual units of an asset. For example, NFTs cannot be replaced with other tokens of the same type. An example format for an NFT on the Ethereum blockchain is a token standard referred to as ERC-721. The ERC-1155 standard offers semi-fungibility. Unlike ERC-721, where the unique identifier represents one asset, the unique identifier of the ERC-1155 token represents a whole class of fungible assets, any number of which the user can transfer to others. Components based on the ERC-998 standard are the templates according to which NFTs can be either non-fungible or fungible assets. While Ethereum is a popular choice for NFT marketplaces, there are non-Ethereum NFT marketplaces as well, belonging to other blockchain networks like Cosmos, Polkadot, International Blockchain Consulting (IBC), Interledger, Binance Smart Chain, etc. Each of the NFT marketplaces operates slightly differently and has its specific instructions, standards, formats, and/or the like. For example, some of the NFTs are curated while others are self-service based. Creating NFTs on some platforms have substantial transaction fees to mint, while some marketplaces do not support specific file formats or sizes of assets. Some platforms are user-friendly, while others have a complex user interface that takes significant training.”)
that integrates system payments for the payments subsystem and integrates the B2B web application,
(See Dorogusker, para. [0194]: “According to some examples, the method includes redirecting, e.g., using a URL, scannable code, QR code, other identifier, etc., the audience member client device to a landing page associated with the host of the live playback stream at block 350. For example, the multi-media platform 108 illustrated in FIG. 1A may redirect the audience member client device to a landing page, e.g., store page, forum page, web application, concert page, artist website, etc., of the live playback stream host. The store page of the host of the live playback stream includes the at least one content for acquisition. As noted above, in some embodiments, the store page could also be associated with other user accounts or even entities that do not have a user account with the multi-media platform 108.”)
(See Dorogusker, para. [0272]: “In some embodiments, the user interface can be presented via a multi-media application on the host computing device 102, a web browser on the host computing device 102, and/or the like, as a web interface, mobile interface, an instant application, or a progressive web application. In some embodiments, the user interface includes a media player to play media content, such as text, still images, video, and audio, etc. The media player can include graphical elements that, when selected, cause media playback or viewing functions, such as play, pause, stop, skip, etc.”)
The Examiner interprets that the difference between “Business-to-Business (B2B) web application” and a “Business-to-Consumer (B2C) web application” (as taught in Dorogusker) is a difference of intended use, not a difference of functionality.
However, under a conservative interpretation of Dorogusker, it could be argued that Dorogusker does not explicitly teach the italicized portions below, which are taught by Madisetti:
said decentralized computing nodes storing transaction blocks having stateful smart contracts comprising lending pool smart contracts having loop feedback and recursion among the decentralized computing nodes,
(See Madisetti, para. [0004]: “Blockchain networks can either be public or private. Public blockchain networks are free and open to all and any user can create an account and participate in the consensus mechanism on a public blockchain and view all the transactions on the network. Private blockchain networks are usually controlled and operated by a single organization and the transactions can be viewed only by the users within the organization. Public blockchain networks are usually unpermissioned or permissionless, as any node can participate in consensus process. Some public blockchain networks adopt a permissioned model where the consensus process is controlled by a pre-selected set of nodes. Private blockchain networks usually adopt the permissioned model. While public blockchain networks can be considered as fully decentralized, private blockchain networks are partially decentralized.”)
The Examiner interprets that the “consensus networks” inherently have “loop feedback and recursion among the decentralized computing nodes”.
and said buyer self-custodial wallet configured to pay the invoices to buy items via a loan provided by a lending pool smart contract,
(See Madisetti, para. [0160]: “Referring now to FIG. 39 an illustration of global variable sharing across smart contracts is described in more detail. The Lending Pool smart contract 2004, Lending Request smart contract 2002 and Loan smart contract 2006 are linked smart contracts in a Peer-to-Pool-Peer (P2P2P) lending system that are used in loan making and loan servicing processes. The Lending Request smart contract 2002 is used in the loan making process. Borrowers send lending requests to the lending system and a Lending Request smart contract is created for each lending request. The Lending Pool smart contract 2004 is used to manage a lending pool. When the lending system matches a lending request to a lending pool, a new Loan smart contract 2006 is created. The Loan smart contract 2006 manages the loan servicing aspects of a loan from the time the loan is disbursed until the loan is paid off. The Loan smart contract 2006 captures the loan details such as loan principal, loan interest rate, address of lending pool contract from where the loan is disbursed as state variables. Loan smart contract 2006 also registers global variables 2042 such as for the loan amount repaid (loanAmountRepaid) and loan status (loanStatus). The Lending Pool smart contract 2004 and Lending Request smart contract 2002 have global variables 2022, 2012 which are registered 2010, 2008 with the Global Variable Name Systems (GVNS) 2000 (lendingPool_AmountRaised, lendingPool_numLenders, lendingRequest_AmountRequested). These global variables are referenced 2032 in the Loan smart contract 2006.”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the system and method for multi-media platforms that support modification of data streams, such as music, in near real-time collaborative media experiences, lending, machine-learning driven social engagement, and distributed ledger-driven licensing and media content management models, as taught by Dorogusker, (see para. [0024]), with the system and method for transaction pools using smart contracts and blockchains, as further taught by Madisetti, to include features such as “pay the invoices to buy items via a loan provided by a lending pool smart contract”, because both of these references are in the same art of using blockchain, crypto and smart contracts to enable loans for purchases, and because Madisetti teaches the use of a “smart contract” to manage a “lending pool”, because it “solves the problems of manual reconciliation and scalability” (see Madisetti, para. [0124]).
However, under a conservative interpretation of Dorogusker in view of Madisetti, it could be argued that Dorogusker in view of Madisetti does not explicitly teach the italicized portions below, which are taught by Guruprasad:
and initiates and coordinates all blockchain transactions and implements network operations having logic as instructions that are located off the blockchain.
(See Guruprasad, para. [0065]: “Various embodiments of the present disclosure provides a hybrid model in which Fiat and cryptocurrencies are used to serve the funding needs of business enterprises. The system happens initially within on-chain and a second stage would happen outside the chain as the borrowers would take it outside the crypto system to deploy it in their businesses.”)
The Examiner interprets that the disclosure in Guruprasad, para. [0065] of “a second stage would happen outside the chain” and “outside the crypto system” read upon the claimed “off the blockchain”, as recited in the claim.
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the system and method for multi-media platforms that support modification of data streams, such as music, in near real-time collaborative media experiences, lending, machine-learning driven social engagement, and distributed ledger-driven licensing and media content management models, as taught by Dorogusker, (see para. [0024]),
with the system and method for transaction pools using smart contracts and blockchains, as further taught by Madisetti, to include features such as “pay the invoices to buy items via a loan provided by a lending pool smart contract”, because both of these references are in the same art of using blockchain, crypto and smart contracts to enable loans for purchases, and because Madisetti teaches the use of a “smart contract” to manage a “lending pool”, because it “solves the problems of manual reconciliation and scalability” (see Madisetti, para. [0124]),
and further with the system and method for managing supply chain and retail finance, as further taught by Guruprasad, to include features such as “smart contracts comprising a lending pool smart contract” and “transaction processor is configured to mint the invoices as non-fungible tokens on the blockchain”, because both of these references are in the same art of using blockchain, crypto and smart contracts to enable loans for purchases, and because Guruprasad teaches the sending of invoices by the seller, in order to receive payment from the customer, which is a necessary feature in order to conduct transactions.
In regards to claim 2,
2. (Original) The computing system of Claim 1 wherein a lending pool smart contract holds stablecoin tokens.
(See Guruprasad, claim 11: “The system as claimed in claim 1, wherein the one or more crypto collaterals presented by the borrowers are incorporated into smart contracts and are converted into non-fungible tokens.”)
The Examiner interprets that the claimed “stablecoin tokens” are one obvious example of Guruprasad’s “one or more crypto collaterals presented by the borrowers”.
In regards to claim 3,
3. (Original) The computing system of Claim 1 wherein the buyer computing device comprises a processor, memory and transceiver.
(See Guruprasad, para. [0039]: “FIG. 3 is a block diagram of a computer or a server in accordance with an embodiment of the present disclosure. The server 200 includes processor(s) 230, and memory 210 operatively coupled to the bus 220. The processor(s) 230, as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor, a microcontroller, a complex instruction set computing microprocessor, a reduced instruction set computing microprocessor, a very long instruction word microprocessor, an explicitly parallel instruction computing microprocessor, a digital signal processor, or any other type of processing circuit, or a combination thereof.”)
In regards to claim 4,
4. (Original) The computing system of Claim 1 wherein said supplier computing device comprises a processor, memory and transceiver.
(See Guruprasad, para. [0039]: “FIG. 3 is a block diagram of a computer or a server in accordance with an embodiment of the present disclosure. The server 200 includes processor(s) 230, and memory 210 operatively coupled to the bus 220. The processor(s) 230, as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor, a microcontroller, a complex instruction set computing microprocessor, a reduced instruction set computing microprocessor, a very long instruction word microprocessor, an explicitly parallel instruction computing microprocessor, a digital signal processor, or any other type of processing circuit, or a combination thereof.”)
In regards to claim 5,
5. (Original) The computing system of Claim 1 wherein said transaction processor comprises a cloud computing network.
(See Guruprasad, para. [0043]: “FIG. 4 is a block diagram of an embodiment of a system 300 for managing retail finance in accordance with an embodiment of the present disclosure. The system 300 includes a retail processing subsystem 305 hosted on a server 308. In one embodiment, the server 308 may include a cloud server. In another embodiment, the server 308 may include a local server. The retail processing subsystem 305 is configured to execute on a network (not shown in FIG. 4 ) to control bidirectional communications among a plurality of modules.”)
In regards to claim 6,
6. (Currently Amended) The computing system of Claim 1 wherein said lending pool smart contracts hold stablecoin tokens from lenders used to pay suppliers.
(See Guruprasad, para. [0037]: “A supply chain finance financing module 130 generates a perpetual contract to mitigate the currency volatility risk between the buyer and the financier for financing the funds upon identification of the financier. Also, the supply chain financing module 130 enables 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. In the example used herein, the one or more currencies may include a cryptocurrency and a fiat currency. In such an example, the cryptocurrency may include at least one of a Bitcoin, an Ethereum, a Dogecoin or a combination thereof.”)
In regards to claim 7, it is cancelled.
In regards to claim 8,
8. (Original) The computing system of Claim 1 wherein said transaction processor is configured to issue a QR code to a buyer computing device for display thereon, wherein said QR code contains data of a transaction card for in-person purchases at a supplier.
(See Dorogusker, para. [0194]: “According to some examples, the method includes redirecting, e.g., using a URL, scannable code, QR code, other identifier, etc., the audience member client device to a landing page associated with the host of the live playback stream at block 350. For example, the multi- media platform 108 illustrated in FIG. 1A may redirect the audience member client device to a landing page, e.g., store page, forum page, web application, concert page, artist website, etc., of the live playback stream host.”)
In regards to claim 9,
9. (Original) The computing system of Claim 1 further comprising a cache storage for storing one or more of access and refresh tokens invalidation, link codes and mobile wallet signed transactions.
(See Dorogusker, para. [0037]: “In some embodiments, techniques described herein can utilize stored and/or determined permissions and/or rules to route communications to users such as certain artists, audience members, hosts, and/or devices. Based on the rules, certain users can access media content or distribute such media content. Further, based on the rules, certain users may be able to control the live playback streams. In some cases, a user may be able to assign access conditionally or provisionally to another user, e.g., for a predefined item.”)
In regards to claim 10, it is cancelled.
In regards to claim 11,
11. (Original) The computing system of Claim 1 wherein the transaction processor is configured to save the transaction between a buyer and supplier to the blockchain.
(See Guruprasad, para. [0006]: “In accordance with an embodiment of a present disclosure, a system for managing supply chain finance is disclosed. The system includes a processing subsystem hosted on a server and configured to execute on a network to control bidirectional communications among a plurality of modules. The processing subsystem includes 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. The invoices generated are scanned using scanners and are made as a non-fungible tokens to deal on-chain in blockchain system.”)
In regards to independent claim 12, it is rejected on the same grounds as independent claim 1.
In regards to claim 13, it is rejected on the same grounds as claim 2.
In regards to claim 14, it is rejected on the same grounds as claim 6.
In regards to claim 15, it is cancelled.
In regards to claim 16, it is rejected on the same grounds as claim 8.
In regards to claim 17, it is rejected on the same grounds as claim 9.
In regards to claim 18, it is cancelled.
In regards to claim 19, it is rejected on the same grounds as claim 11.
Response to Amendment
Re: Claim Objections
The objection to claims 12-19 is withdrawn, because in the amendment, the Applicant amended independent claim 12 to recite “said transaction processor” in what was previously the fourth-to-last line, instead of "said transaction process".
Re: Claim Rejections - 35 USC § 112
The 35 U.S.C. 112(a), first paragraph rejection of claims 7 and 15, as failing to comply with the written description requirement, is withdrawn. More specifically, the written description fails to adequately describe the claimed feature of “local on/off currency ramps” recited in claims 7 and 15. These claims are currently cancelled, so the rejection is now moot.
Re: Claim Rejections - 35 USC § 101
The 35 U.S.C. 101 rejection of claims 1-6, 8, 9, 11-14, 16, 17, and 19 has been amended, as necessitated by Applicant’s amendments to the independent claims 1 and 12.
Re: Claim Rejections - 35 USC § 103
The 35 U.S.C. 103 rejection of claims 1-6, 8, 9, 11-14, 16, 17, and 19 has been amended, as necessitated by Applicant’s amendments to the independent claims 1 and 12.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications should be directed to Examiner Ayal Sharon, whose telephone number is (571) 272-5614, and fax number is (571) 273-1794. The Examiner can normally be reached from Monday to Friday between 9 AM and 6 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SPE Christine Behncke can be reached at (571) 272-8103 or at christine.behncke@uspto.gov. The fax 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.
Sincerely,
/Ayal I. Sharon/
Examiner, Art Unit 3695
January 13, 2026