DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. 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
2. 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.
3. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
4. In the instant case, claims 1, 9, and 17 are directed to a “method, system, and non-transitory machine-readable storage medium for enterprise resource planning and management systems integration”.
5. Claim 1 recites “processing a sales order for an object, creating the object and registering the object”. Specifically, claim recites “determining that a sales order has been created…; publishing … a first event message indicating that the sales order has been created based on the determining that the sales order has been created … comprising a message broker to which events are published asynchronously, the message broker subsequently distributing the events to one or more event consumers; causing … corresponding to the sales order to be minted … based on the publishing of the first event message; receiving an indication that … has been minted … the indication comprising a transaction identification corresponding …; publishing … a second event message indicating that … has been minted … based on the indication that … has been minted …; and storing the transaction identification … in association with the sales order based on the publishing of the second event message”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
6. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “determining that a sales order has been created in a database”, “an event-driven architecture”, “causing a non-fungible token (NFT) corresponding to the sales order to be minted on a decentralized blockchain”, and “storing the transaction identification of the NFT in the database” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of processing a sales order for an object, creating the object and registering the object. With respect to “receiving an indication that the NFT has been minted on the decentralized blockchain” and “storing the transaction identification of the NFT in the database” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
7. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of processing a sales order for an object, creating the object and registering the object using computer technology. Therefore, as the use of these additional elements do no more than employ a computer as a tool to automate and/or implement the abstract idea, they cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
8. Hence, claim 1 is not patent eligible.
9. Claims 9 and 17 also recite “processing a sales order for an object, creating the object and registering the object”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
10. As in the case of claim 1, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of the claims 9 and 17 such as “at least one hardware processor”, “a database”, “a non-transitory computer-readable medium”, “determining that a sales order has been created in the database”, “an event-driven architecture comprising a message broker”, “causing a non-fungible token (NFT) corresponding to the sales order to be minted on a decentralized blockchain”, “storing the transaction identification of the NFT in the database”, and “a non-transitory machine-readable storage medium” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of processing a sales order for an object, creating the object and registering the object. With respect to “receiving an indication that the NFT has been minted on the decentralized blockchain” and “storing the transaction identification of the NFT in the database” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
11. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of processing a sales order for an object, creating the object and registering the object using computer technology. Therefore, as the use of these additional elements do no more than employ a computer as a tool to automate and/or implement the abstract idea, they cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
12. Hence, claims 9 and 17 are not patent eligible.
13. The following dependent claims recent additional elements not addressed above:
claims 2, 10, and 18 recite “an enterprise resource planning (ERP) software system” and “one or more software applications in the ERP system”;
claims 3, 11, and 19 recite “a computing device” and “a smart contract”;
claims 4, 12, and 20 recite “a computing device”;
claims 5 and 13 recite “a blockchain management system”;
claims 6 and 14 recite “an application programming interface (API)” and “a blockchain management system”; and
claims 8 and 16 recite “a computing device”.
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the enterprise resource planning (ERP) software system, one or more software applications in the ERP system, the computing device, the smart contract, the blockchain management system, and the application programming interface.
Dependent claims 2-8, 10-16, and 18-20 merely expand upon the abstract ideas of the independent claims, and are therefore rejected under the same rationale as claims 1, 9, and 17 respectively.
Conclusion of 35 USC §101
14. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
15. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
16. 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.
17. 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.
18. The factual inquiries 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.
19. Claims 1-4, 6, 8-12, 14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over US11973874B1 to Mordan et al. in view of US20160292672A1 to Fay et al.
20. As per claims 1, 9, and 17:
Mordan et al. discloses the following limitations:
A computer-implemented method comprising (Col.1, lines 43-44 “The method may be performed, for example, by one or more processors coupled to memory”)
causing a non-fungible token (NFT) corresponding to the sales order to be minted on a decentralized blockchain based on the publishing of the first event message (Col.1, lines 6-11 “Non-fungible tokens (NFTs) are created or “minted” using blockchain technology. Various NFTs may be minted using smart contracts, which may be software with pre-defined rules that is encoded on the blockchain. Smart contracts may be executed by nodes in a blockchain network to mint NFTs by writing transactions to the blockchain.”, col.13, lines 42-46 “the token minter 135 can initiate the minting of one or more tokens, for example, by creating and broadcasting a transaction on the blockchain network 125 that calls a minting function of a smart contract to mint various tokens (e.g., NFTs such as ERC-721 tokens, etc.)”, col.13, lines 48-54 “The token minter 135 may initiate minting of one or more tokens in response to input from an operator of the data processing system 105, in response to a request from an external computing system via the network 110, or in response to detecting that a predetermined rule or condition previously provided to the token minter 135 has been satisfied.”, col.9, lines 27-29 “The blockchain network 125 includes a decentralized system of nodes, e.g., computing systems, each maintaining a copy of the entire blockchain.”)
receiving an indication that the NFT has been minted on the decentralized blockchain, the indication comprising a transaction identification corresponding to the NFT on the decentralized blockchain (Col.14, 16-22 “Once the transaction request to mint the one or more tokens has been transmitted to the blockchain network 125, the blockchain network 125 may return a transaction hash, which can be a unique identifier for the transaction on the blockchain. Using this transaction hash, the token minter 135 can monitor the progress of the transaction to determine whether the tokens have been minted.”, col.14, lines 27-33 “the smart contract may emit events over the blockchain network 125 during the minting process that can be detected, for example, by querying event logs of the smart contract. Events may include information about the successful minting of tokens, such as the number of tokens minted and the address to which they were assigned.”, col.14, lines 37-39 “the token minter 135 can determine that the tokens have been successfully minted and added to the central wallet.”, col.12, lines 3-5 “When doing so, the smart contract executing on the blockchain network 125 (e.g., the nodes thereof) can return corresponding identifiers of the minted tokens.”)
publishing, in the event-driven architecture, a second event message indicating that the NFT has been minted on the decentralized blockchain based on the indication that the NFT has been minted on the decentralized blockchain (Col.14, lines 27-33 “the smart contract may emit events over the blockchain network 125 during the minting process that can be detected, for example, by querying event logs of the smart contract. Events may include information about the successful minting of tokens, such as the number of tokens minted and the address to which they were assigned.”)
storing the transaction identification of the NFT in the database in association with the sales order based on the publishing of the second event message (Col.14, lines 44-48 “Once token minter 135 has determined that the token(s) have been minted on the blockchain, the metadata manager 145 can generate and/or store token metadata 185 for each minted token at a location in the database 115 corresponding to the identifier of the token.”, col.6, lines 20-22 “Token metadata 185 for a token can be stored in association with, and may be accessed based on, a corresponding token identifier for the token.”, col.6, lines 33-34 “The database 115 can store corresponding token metadata 185 for any number of tokens, including NFTs.”)
Mordan et al. does not explicitly disclose, however, Fay et al., as shown, teaches the following limitations:
determining that a sales order has been created in a database ([0026] “Order book 106 stores electronic data messages that have been received from order submitting clients. In certain example embodiments, order book 106 stores a list of electronic data messages …”, [0042] “In step 242, if the order is valid, and as part of the order booking process, the exchange computer system 100 saves the newly submitted order to the order book 106…”, [0043] “In step 243, the exchange computer system 100 generates market data based on the order book (e.g., every time there is a change to the order book) and transmits the market data to computing device A 120A and/or other 3rd party computer systems…”)
publishing, in an event-driven architecture, a first event message indicating that the sales order has been created based on the determining that the sales order has been created the event- driven architecture comprising a message broker to which events are published asynchronously, the message broker subsequently distributing the events to one or more event consumers ([0043] “In step 243, the exchange computer system 100 generates market data based on the order book (e.g., every time there is a change to the order book) and transmits the market data to computing device A 120A and/or other 3rd party computer systems. It will be appreciated that the market data feed may be a continuing process that is triggered whenever there is a change to the order book (e.g., a modification to an existing order, the addition of a new order, the match of two or more orders, etc.) …”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system that communicates with a distributed blockchain computing system that includes multiple computing nodes and the exchange stores an order book and a plurality of digital wallets associated with different clients of Fay et al. (‘672, abstract) with teaching of Mordan et al. for addressing minting new NFTs by providing a smart contract that mints NFTs using a shared, or “base” uniform resource identifier (URI) in place of the metadata for minted tokens (‘874, col.1, lines 25-28) for storing a list of electronic data messages, generating market data based on the order book, transmitting the market data to computing device and/or other 3rd party computer systems, and continuing a process that is triggered whenever there is a change to the order book such as the match of two or more orders (‘672, [0026], [0043]).
As per claim 9 Mordan et al. additionally discloses the following limitations:
at least one hardware processor (Col.2, line 25 “The system includes one or more processors”)
a database (Fig.1, item 115, col.4, lines 33-34 “a system 100 is shown that includes … a database 115”)
a non-transitory computer-readable medium storing executable instructions that, when executed, cause the at least one hardware processor to perform computer operations comprising (Col.24, lines 46-47 “one or more processors coupled to the non-transitory memory, the one or more processors configured to”)
As per claim 17 Mordan et al. additionally discloses the following limitations:
A non-transitory machine-readable storage medium tangibly embodying a set of instructions that, when executed by at least one hardware processor, causes the at least one hardware processor to perform computer operations comprising (Col.24, lines 45-47 “non-transitory memory; and one or more processors coupled to the non-transitory memory, the one or more processors configured to:”, col.5, lines 7-10 “The memory can store processor-executable instructions that, when executed by a processor, cause the processor to perform one or more of the operations described herein”)
21. As per claims 2, 10, and 18:
Mordan et al. does not explicitly disclose, however, Fay et al., as shown, teaches the following limitations:
wherein the database is located within an enterprise resource planning (ERP) software system and stores product master data for a plurality of products, wherein one or more software applications in the ERP system perform calculations on the product master data ([0028] “Exchange computer system 100 may be coupled to (or include) database 118. Database 118 may hold account information, audit information, mappings between blockchain transactions, colored coin mappings (e.g., a list of asset or type identifiers and the asset or type that those identifiers correspond to), and other data…”, [0039] “In certain example embodiments, the exchange stores a list of asset or type identifiers in database 118 and each of these identifiers corresponds to one or more types of assets or ‘types’ of transactions that may be subject to an electronic data transaction request and/or order contained therein…”, [0026] “Order book 106 stores electronic data messages that have been received from order submitting clients … In certain example embodiments, order book 106 stores a list of electronic data messages… two separately ordered lists are stored and maintained per type identifier (e.g., per ticker symbol or other asset identifier).”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system that communicates with a distributed blockchain computing system that includes multiple computing nodes and the exchange stores an order book and a plurality of digital wallets associated with different clients of Fay et al. (‘672, abstract) with teaching of Mordan et al. for addressing minting new NFTs by providing a smart contract that mints NFTs using a shared, or “base” uniform resource identifier (URI) in place of the metadata for minted tokens (‘874, col.1, lines 25-28) for storing a list of electronic data messages, generating market data based on the order book and storing a list of asset or type identifiers in database and each of these identifiers corresponds to one or more types of assets (‘672, [0026], [0039]).
22. As per claims 3, 11, and 19:
Mordan et al. discloses the following limitations:
receiving, from a computing device, a request to add a smart contract identification field and a token identification field to a record of the product master data for one of the products in the plurality of products in the database (Col.13, lines 48-58 “The token minter 135 may initiate minting of one or more tokens in response to input from an operator of the data processing system 105, in response to a request from an external computing system via the network 110, or in response to detecting that a predetermined rule or condition previously provided to the token minter 135 has been satisfied. The transaction request that initiates minting may include an address of the smart contract (or the minting function thereof), a number of the one or more tokens to be minted, and various properties of the token(s) that are to be written to the blockchain.”, col/line 13/61-14/2 “The minting function of the smart contract may receive various parameters, which may be encoded in the transaction used to mint the tokens. For example, the minting function of the smart contract may receive various parameters as part of the transaction, including a destination wallet for the resulting tokens (e.g., the central wallet associated with the data processing system 105), a number of tokens to mint, a type of token to mint, and/or a base URI that for all generated tokens.”)
adding the smart contract identification field and the token identification field to the record of the product master data for the one of the products in the plurality of products in the database based on the request to add the smart contract identification field, wherein the storing of the transaction identification of the NFT further comprises storing a smart contract identification of the NFT in the smart contract identification field and a token identification of the NFT in the token identification field (Col.14, lines 44-48 “Once token minter 135 has determined that the token(s) have been minted on the blockchain, the metadata manager 145 can generate and/or store token metadata 185 for each minted token at a location in the database 115 corresponding to the identifier of the token.”, col.6, lines 20-22 “Token metadata 185 for a token can be stored in association with, and may be accessed based on, a corresponding token identifier for the token.”, col.6, lines 34-44 “The token metadata 185 may include any information relating to the token to which it corresponds. The token metadata 185 may be stored, for example, in the JavaScript Object Notation (JSON) format. The token metadata 185 for a token may include, but is not limited to, a token name, a token description, an image … creator information, date of creation, edition information … rarity information”)”, col.13, lines 59-61 “The smart contract may be previously provided on the blockchain network 125 by the data processing system 105 or another computing system.”)
23. As per claims 4, 12, and 20:
Mordan et al. discloses the following limitations:
adding the smart transaction identification field to the record of the sales order in the database based on the request to add the smart transaction identification field, wherein the storing of the transaction identification of the NFT comprises storing the transaction identification of the NFT in the smart transaction identification field (Col.14, lines 16-20 “Once the transaction request to mint the one or more tokens has been transmitted to the blockchain network 125, the blockchain network 125 may return a transaction hash, which can be a unique identifier for the transaction on the blockchain.”, col.14, lines 44-48 “Once token minter 135 has determined that the token(s) have been minted on the blockchain, the metadata manager 145 can generate and/or store token metadata 185 for each minted token at a location in the database 115 corresponding to the identifier of the token.”)
Mordan et al. does not explicitly disclose, however, Fay et al., as shown, teaches the following limitations:
receiving, from a computing device, a request to add a smart transaction identification field to a record of the sales order in the database ([0038] “At step 236, computer device A transmits an electronic data message to the exchange computing system 100. The electronic data message includes a data transaction request for the exchange computer system 100 to carry out one or more tasks based on the content of the electronic data message…”, [0039] “…The order may also include information that indicates the trading party (i.e., the trading party account on whose behalf the order is submitted); this information may be or include a reference to a particular digital wallet of the trading party (e.g., Joe's wallet), and/or a specific walletID (e.g., a cryptographically generated identifier that is stored in the wallet)…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system that communicates with a distributed blockchain computing system that includes multiple computing nodes and the exchange stores an order book and a plurality of digital wallets associated with different clients of Fay et al. (‘672, abstract) with teaching of Mordan et al. for addressing minting new NFTs by providing a smart contract that mints NFTs using a shared, or “base” uniform resource identifier (URI) in place of the metadata for minted tokens (‘874, col.1, lines 25-28) for transmitting an electronic data message that includes a data transaction request for the exchange computer system to carry out one or more tasks based on the content of the electronic data message and wherein tasks include information that indicates the trading party and a specific walletID (‘672, [0038], [0039]).
24. As per claims 6 and 14:
Mordan et al. discloses the following limitations:
wherein the causing of the NFT to be minted on the decentralized blockchain comprises calling an application programming interface (API) to send a request to a blockchain management system to mint the NFT (Col.13, lines 42-46 “the token minter 135 can initiate the minting of one or more tokens, for example, by creating and broadcasting a transaction on the blockchain network 125 that calls a minting function of a smart contract to mint various tokens (e.g., NFTs such as ERC-721 tokens, etc.)”, col.16, lines 59-67 “The API calls may include the metadata URI 180 for the token, and may be initiated, in some implementations, by corresponding software associated with the database 115 that is executed on the data processing system 105. In some implementations, the token metadata 185 of a token may be modified using a corresponding web request, such a hyper-text transfer protocol (HTTP), a secure hyper-text transfer protocol (HTTPS), a file transfer protocol (FTP), or a secure file transfer protocol (FTPS)”, col.6, lines 12-15 “The contents of the database 115 may be accessed or using one or more application programming interfaces (APIs) (e.g., a REST API) or software using the URI.”)
25. As per claims 8 and 16:
Mordan et al. does not explicitly disclose, however, Fay et al., as shown, teaches the following limitations:
receiving a request to view the sales order from a computing device of a user ([0071] “In FIG. 3D, data (e.g., market data) regarding orders or electronic messages that are in the order book 104 may be produced by exchange computing system 100 and delivered to remote computing clients via market data hub 314…”, [0063] “…each trading party monitors the blockchain and updates the view that the respective wallets provide of the blockchain to indicate the assets now held by the corresponding trading party.”, [0068] “…a view of a digital wallet is provided on a client computer system (e.g., a smart phone) and the digital wallet (e.g., that contains public/private keys, identifiers, etc. . . . ) is stored on exchange computing system 100…”)
causing data of the sales order to be displayed on the computing device, the data of the sales order comprising the transaction identification of the NFT ([0071] “In FIG. 3D, data (e.g., market data) regarding orders or electronic messages that are in the order book 104 may be produced by exchange computing system 100 and delivered to remote computing clients via market data hub 314…”, [0087] “In FIG. 3I, after a transaction(s) is recognized on the block chain, the corresponding contents of a wallet are updated… software that interfaces with the digital wallet storage may update a wallet view with the settled trade information.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system that communicates with a distributed blockchain computing system that includes multiple computing nodes and the exchange stores an order book and a plurality of digital wallets associated with different clients of Fay et al. (‘672, abstract) with teaching of Mordan et al. for addressing minting new NFTs by providing a smart contract that mints NFTs using a shared, or “base” uniform resource identifier (URI) in place of the metadata for minted tokens (‘874, col.1, lines 25-28) for transmitting orders or electronic messages that are in the order book to remote computing clients and transactions ares recognized on the blockchain, and interfaces with the digital wallet storage updates a wallet view with the settled trade information (‘672, [0071], [0087]).
26. Claims 5, 7, 13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US11973874B1 to Mordan et al. in view of US20160292672A1 to Fay et al. and “Building an event-based application with Amazon Managed Blockchain”, by Emile Baizel (further - Baizel).
27. As per claims 5 and 13:
Mordan et al. discloses the following limitations:
the causing of the NFT to be minted on the decentralized blockchain … (Col.13, lines 42-46 “the token minter 135 can initiate the minting of one or more tokens, for example, by creating and broadcasting a transaction on the blockchain network 125 that calls a minting function of a smart contract to mint various tokens (e.g., NFTs such as ERC-721 tokens, etc.)”)
Neither Mordan et al. nor Fay et al. disclose, however, Baizel, as shown, teaches the following limitations:
the publishing of the first event message in the event-driven architecture comprises storing the first event message in a first message queue (Baizel, p.2 “The event listener publishes these events to an SQS queue”, p.5 “To provide durability of the blockchain events, the event listener writes blockchain events to an SQS queue that queues the events for a Lambda function to process. Storing the events as messages in an SQS queue facilitates error handling if the Lambda function fails to process the message.”
[the causing] …comprises consuming the first event message stored in the first message queue and sending a request to a blockchain management system to mint the NFT based on the consuming of the first event message (Baizel, p.6 “Each blockchain event on the SQS queue triggers the Lambda function. The function parses the event data and publishes a corresponding message to Amazon SNS.”, p.1 “You can also stream to purpose-built Amazon Aurora, or use A Hyperledger Fabric blockchain network can produce AWS Lambda for event-triggered applications”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system that communicates with a distributed blockchain computing system that includes multiple computing nodes and the exchange stores an order book and a plurality of digital wallets associated with different clients of Fay et al. (‘672, abstract) and description of Lambda functions consume messages from the SQS queue and publishing an event message and storing the event message in a message queue of Baizel with teaching of Mordan et al. for addressing minting new NFTs by providing a smart contract that mints NFTs using a shared, or “base” uniform resource identifier (URI) in place of the metadata for minted tokens (‘874, col.1, lines 25-28) for publishes these events to an SQS queue, writing blockchain events and storing the events as messages in an SQS queue using Lambda functions (Baizel, pp. 2, 5-6).
28. As per claims 7 and 15:
Mordan et al. discloses the following limitations:
the storing of the transaction identification of the NFT in the database in association with the sales order… storing the transaction identification of the NFT in the database in association with the sales order … (Col.14, lines 44-48 “Once token minter 135 has determined that the token(s) have been minted on the blockchain, the metadata manager 145 can generate and/or store token metadata 185 for each minted token at a location in the database 115 corresponding to the identifier of the token.”)
Neither Mordan et al. nor Fay et al. disclose, however, Baizel, as shown, teaches the following limitations:
the publishing of the second event message in the event-driven architecture comprises storing the second event message in a second message queue (Baizel, p.2 “The event listener publishes these events to an SQS queue”, p.5 “To provide durability of the blockchain events, the event listener writes blockchain events to an SQS queue that queues the events for a Lambda function to process… You can send the blockchain event directly to an SNS topic, which removes the need for an SQS queue and reduces cost.”)
[the storing] … comprises consuming the second event message stored in the second message queue and … based on the consuming of the second event message (Baizel, p.6 “you can write the blockchain event data to DynamoDB or Amazon Simple Storage Service (Amazon S3) to deliver faster query times and drive Amazon QuickSight dashboards… Each blockchain event on the SQS queue triggers the Lambda function. The function parses the event data and publishes a corresponding message to Amazon SNS.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system that communicates with a distributed blockchain computing system that includes multiple computing nodes and the exchange stores an order book and a plurality of digital wallets associated with different clients of Fay et al. (‘672, abstract) and description of Lambda functions consume messages from the SQS queue and publishing an event message and storing the event message in a message queue of Baizel with teaching of Mordan et al. for addressing minting new NFTs by providing a smart contract that mints NFTs using a shared, or “base” uniform resource identifier (URI) in place of the metadata for minted tokens (‘874, col.1, lines 25-28) for publishes these events to an SQS queue, writing blockchain events and storing the events as messages by utilizing multiples database and storages and using Lambda functions (Baizel, pp. 2, 5-6).
Response to Arguments
29. Applicant filed the Request for Continued Examination on 01/12/2026. Claims 1-20 are pending. Claims 1, 9, and 17 are amended. Claims 1-20 are rejected. After careful consideration of applicant arguments, the examiner finds them to be not persuasive.
Rejection under 35 USC § 101
30. Applicant’s arguments toward 35 U.S.C. § 101 rejection is not persuasive. Amended independent claim 1 do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
31. Applicant is of the opinion that the claims are not directed to an abstract idea, but to “a specific, technical integration of an ERP system and a blockchain management system using an event-driven architecture”.
Examiner respectfully disagrees.
Claims as a whole directed to processing a sales order for an object (“a sales order has been created in a database”), creating the object (“causing a non-fungible token (NFT) corresponding to the sales order to be minted”) and registering the object (“receiving an indication that the NFT has been minted on the decentralized blockchain”) which is grouped under “Certain methods of organizing human activity (e.g., commercial or legal interactions)”.
32. Applicant is of the opinion that the claims are integrated into a practical application, “because they recite a specific event-driven architecture that enables real-time, automated integration between ERP and blockchain management systems. This architecture is not conventional, as it avoids the need for upgrading or replacing the ERP system, and provides technical benefits such as minimizing service interruption and electronic resource consumption”.
Examiner respectfully disagrees.
Mentioned above the elements of the claims performed by using the computer components. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field. An ordered combination of the limitations – determining and publishing a first message that a sales order has been created, minting an NFT corresponding to the sales order, publishing a second message than an NFT has been minted, and storing the NFT in a database – merely implement an abstract idea (commercia/legal interaction) using the additional elements such as database, message broker, NFT as tools. The claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claim is directed to the abstract idea.
33. Applicant is of the opinion that the claims recite significantly more than the judicial exception, and concludes that “[t]he claimed event-driven architecture, message broker, and integration of ERP and blockchain systems are not well-understood, routine, or conventional”.
Examiner respectfully disagrees.
Applicant’s argument is not persuasive for the reasons already discussed above – the additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field. As per the identification of the “additional elements” under Step 2A Prong Two and Step 2B, the rejection properly identifies the elements which are recited in the claim beyond the abstract idea, including “determining that a sales order has been created in a database”, “an event-driven architecture”, “causing a non-fungible token (NFT) corresponding to the sales order to be minted on a decentralized blockchain”, and “storing the transaction identification of the NFT in the database”. Under Step 2A Prong Two, the “additional elements” have been identified and the limitations are not indicative of integration into a practical application. Under Step 2B, the additional elements have been evaluated and do not amount to “significantly more”. Note that Revised Step 2A overlaps with Step 2B, and thus, many of the considerations need not be reevaluated in Step 2B because the answer will be the same. The identification of the additional elements in the claim from Step 2A Prong Two is carried over as well as the conclusion from Step 2A Prong Two on the considerations discussed in MPEP 2106.05(a)-(c), (e), (f), and (h).
Additionally, the rejection was not based on well-understood, routine, or conventional elements. To the contrary, the claim is directed to the abstract idea of processing a sales order for an object (e.g., (claim 1) “determining that a sales order has been created …”; (PGPub, para 10) “… a computer-implemented method comprising determining that a sales order has been created in a database, and then publishing, in an event-driven architecture, a first event message indicating that the sales order has been created based on the determining that the sales order has been created”) and does not improve functioning of a computer or computer technology.
The claims are not patent eligible.
Conclusion
34. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20220383303A1 – Mullen et al. – Discloses a non-fungible token (NFT) multiple ledger processing environment, in which a public processing platform providing a public ledger for processing functions (e.g., ownership transactions) associated with the NFT provides entities identifiable on the public processing platform with an ownership transaction function to a public processing platform identity with a private processing platform providing a private ledger.
US20140222523A1 – Vairavan et al. – Discloses that certain example embodiments tie the business process governance and Service Oriented Architecture (SOA) governance processes together through the use of Business Process Model and Notation (BPMN) and Event Driven Architecture (EDA) based messaging.
US20230274244A1 – Quigley et al. – Discloses systems and methods that generate data representing an analytic result relating to at least one of a state, a workflow, or an event in a digital token system, including a digital token system that cryptographically links a set of digital tokens to instances of a set of real-world entities.
US20240154814A1 – Singh – Discloses an architecture for submission and recordation of application programmer interfaces (APIs) using non-fungible tokens (NFTs) inserted into a blockchain, wherein the API-NFT pairings are validated by nodes of the network.
US20230079195A1 – Matheson et al. – Discloses an ecommerce platform implementing blockchain technologies for tracking, managing, and predicting purchasing behavior, wherein the blockchain mints NFTs representing various aspects and data values of a purchase, such as a ticket NFT.
US20250005544A1 – Albrechtsen – Discloses a method, a system, and computer program product for managing distribution of non-fungible tokens (NFTs) representing receipts for transactions, wherein a request for a transaction is received over a blockchain network.
35. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/RYAN D DONLON/ Supervisory Patent Examiner, Art Unit 3692
Prosecution Insights