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 .
Status of the Claims
2. Applicant filed the amendment on 07/08/2026. Claims 1-20 are pending. Claims 1, 9, and 17 are amended.
Claim Rejections - 35 USC § 112
3. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
4. Claims 2, 5-6, 10, 13-14, and 18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Unclear scope
5. “An essential purpose of patent examination is to fashion claims that are precise, clear, correct, and unambiguous. Only in this way can uncertainties of claim scope be removed, as much as possible, during the administrative process.” Zletz, 893 F.2d at 322, 13 USPQ2d at 1322.
6. Claims 2, 10, and 18 recite “wherein the database is located within an enterprise resource planning (ERP) software system and stores product master data for a plurality of products…”.
It is not clear whether underlined “an enterprise resource planning (ERP) software system” is the same “an enterprise resource planning (ERP) software system” that claims 1, 9, and 17, from those claims 2, 10, and 18 depend respectively, and recite in paragraph starting with “determining…” or different one.
7. Claims 5 and 13 recite “the causing… sending a request to a blockchain management system to mint the NFT…”.
It is not clear whether underlined “a blockchain management system” is the same “a blockchain management system” that claims 1 and 9 from those claims 5 and 13 depend respectively, and recite in paragraph starting with “publishing …” or different one. The specification appears to only describe one blockchain management system (see figs 2-4).
8. Claims 6 and 14 recite “wherein … send a request to a blockchain management system to mint the NFT”.
It is not clear whether underlined “a blockchain management system” is the same “a blockchain management system” that claims 1 and 9 from those claims 6 and 14 depend respectively, and recite in paragraph starting with “publishing …” or different one. The antecedent basis of “the NFT” suggests this is referring to the ”a blockchain management system” of claims 1 and 9, but the term “a” creates confusion.
9. “For example, if the language of a claim, given its broadest reasonable interpretation, is such that a person of ordinary skill in the relevant art would read it with more than one reasonable interpretation, then a rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph is appropriate.” MPEP 2173.02 I.
9b. Claims 1, 9 and 17 recite the step “decoupling” however the scope of this limitation is unclear in this context. For context Wikipedia describes “coupling” as
In software engineering, coupling is the degree of interdependence between software modules, a measure of how closely connected two routines or modules are, and the strength of the relationships between modules. Coupling is not binary but multi-dimensional.
…
Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong").
…
It is apparent to an ordinary artisan that the term “coupling” is a term a relative “degree of interdependence”. Therefore, the step (or functional language) of “decoupling” in the instant claims is a relative term. The claims themselves also appear to be inconsistent with the use of this term. It has been established that the claim required “decoupling”, (or said another way reducing the “degree of interdependence”), between the ERP software system and the blockchain management system, however the claims requires an interdependence including the steps of “publishing, by the blockchain management system, in the event-driven architecture, a second event message… storing, by the ERP software system based on consumption of the second event message”. So not only is it unclear if what is intended by the term “decoupling”, but it is also unclear if the claims as recited demonstrate a system capable of “decoupling”.
9c. Claims 1, 9 and 17 recite the limitation “without modification of the ERP software system”, however it is unclear the scope of this phrase means. The claim itself requires “storing, by the ERP software system […] the transaction identification of the NFT in the database” the claims also require it to be “a database of the ERP software system”. Therefore, it is unclear how a “storing” could occur “without modification” of the “database”. Arguendo, if one were to make the argument that the claimed database is not a part of the “ERP software system”, the scope of the term “ERP software system” would be unclear.
Dependent claims are rejected by virtue of their dependency.
Claim Rejections - 35 USC §101
10. 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.
11. 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.
12. 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”.
13. Claim 1 recites “processing a sales order for an object, creating the object, and registering the object”. Specifically, claim recites (the abstract ideas are emphasized in bold) “determining, by an enterprise resource planning (ERP) software system that performs calculations on product master data for a plurality of products stored in a database of the ERP software system, that a sales order has been created in the database;
publishing, by the ERP software system, 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, the event-driven architecture being external to the ERP software system and decoupling the ERP software system from a blockchain management system;
causing, by the blockchain management system based on consumption of the first event message by an event consumer of the one or more event consumers, 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;
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;
publishing, by the blockchain management system, 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; and
storing, by the ERP software system based on consumption of the second event message, the transaction identification of the NFT in the database in association with the sales order based on the publishing of the second event message, the event-driven architecture enabling integration between the ERP software system and the blockchain management system without modification of the ERP software system, thereby avoiding service interruption associated with modifying the ERP software system”. 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)).
14. 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 “an enterprise resource planning (ERP) software system”, “a database of the ERP software system”, “a sales order has been created in the database”, “an event-driven architecture”, “a blockchain management system”, and “a non-fungible token (NFT) corresponding to the sales order to be minted on a decentralized blockchain” 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, by the ERP software system based on consumption of the second event message, 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)).
15. 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)).
16. Hence, claim 1 is not patent eligible.
17. Claims 9 and 17 also recite “creating a sales order for an 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)).
18. 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”, “an enterprise resource planning (ERP) software system”, “a sales order has been created in the database”, “an event-driven architecture”, “a blockchain management system”, “a non-fungible token (NFT) corresponding to the sales order to be minted on a decentralized blockchain”, “a non-transitory machine-readable storage medium” and “a database of the ERP software system” 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, by the ERP software system based on consumption of the second event message, the transaction identification of the NFT in the database in association with the sales order based on the publishing of the second event message” 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)).
19. When analyzed under step 2B (MPEP 2106.04 II), the claims do 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 claims 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)).
20. Hence, claims 9 and 17 are not patent eligible.
21. 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
22. 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.
23. 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
24. 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.
25. 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.
26. 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.
27. Claims 1-2, 6, 8-10, 14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over US20220051261A1 to Vetas in view of US20230274268A1 to Hahn and US11973874B1 to Mordan et al.
28. As per claim 1:
Vetas discloses the following limitations:
A computer-implemented method comprising: ([0064] “…The platform can be built on a software application, which can incorporate, integrate with or share information with other third-party applications…”)
determining, by an enterprise resource planning (ERP) software system that performs calculations on product master data for a plurality of products ([0060] “…The platform can include ERP, SaaS a modular Supply Chain Management (SCM) system and Data Analytics platform…”, [0055] “…Material Requirements Planning (MRP) or Demand-Driven Material Requirements Planning (DDMRP) SCM may be included…”) stored in a database of the ERP software system ([0050] “…link back to a centralized database where inventory transactions and attributes are stored. Centralized data may include the following: specific inventory attributes, dates, locations, geo-coordinates, and any other data necessary for the correct classification of inventory being transferred…), that a sales order has been created in the database ([0042] “… inventory management, logistics, and order management…”, [0106] “… ‘Order Microservice’ places the ‘Order Placed’ event on the asynchronous event message hub …”)
publishing, by the ERP software system, in an event-driven architecture, a first event message indicating that the sales order has been created ([0106] “… ‘Order Microservice’ places the ‘Order Placed’ event on the asynchronous event message hub…”) based on the determining that the sales order has been created ([0106] “…After successful payment ‘Place Order’ orchestration microservice invokes ‘Order Microservice.’ ‘Order Microservice’ places the ‘Order Placed’ event on the asynchronous event message hub…”), the event-driven architecture comprising a message broker to which events are published asynchronously ([0095] “The Asynchronous Event Hub is a centerpiece in the event-driven architecture…”, [0103] “…event based: Asynchronous in nature and microservices communicate by publishing and subscribing events to Event Hub…”), the message broker subsequently distributing the events to one or more event consumers ([0095] “…Events flow through the asynchronous event hub, on which event publishers and subscribers (abstract and domain microservices) are sourcing and ingesting events in real time…”, [0106] “…’Inventory Microservice’ captures the ‘Order Placed’ event ), the event-driven architecture being external to the ERP software system ([0095] “…Microservices talk to the asynchronous event hub to interchange events following event-driven messaging.”) and decoupling the ERP software system from a blockchain management system ([0114] “…An event-driven approach decouples services by broadcasting messages over an event bus, avoiding the coupling within solution.”, [0106] “…The platform may use the blockchain internally to change the status of required quantities of products to reserved…”)
causing, by the blockchain management system based on consumption of the first event message by an event consumer of the one or more event consumers ([ 0106] “… ‘Inventory Microservice’ captures the ‘Order Placed’ event and reserves the quantity of product for further order processing. The platform may use the blockchain internally to change the status of required quantities of products to reserved…”)… based on the publishing of the first event message ([0106] “… ‘Inventory Microservice’ captures the ‘Order Placed’ event and reserves the quantity of product for further order processing…”)
publishing, by the blockchain management system, in the event-driven architecture, a second event message indicating that the NFT has been minted on the decentralized blockchain ([0106] “… The system sends an event called ‘Inventory reserved’… The ‘Inventory’ microservice then sends ‘Inventory Updated’ event) based on the indication that the NFT has been minted on the decentralized blockchain ([0106] “…The service would use blockchain internally for inventory update. The ‘Inventory’ microservice then sends ‘Inventory Updated’ event…”)
storing, by the ERP software system based on consumption of the second event message ([0106] “…Order Microservice once captures ‘Inventory reserved’ event from Inventory microservice, the system performs further processing and sends ‘Order confirmed’ event…”), the transaction identification of the NFT in the database in association with the sales order ([0050] “…Inventory transfers may be interlinked through a blockchain transaction protocol that includes smart contracts designed to store IDs or hashes of data/media/IDs that link back to a centralized database where inventory transactions and attributes are stored… which transactions and smart contracts and other blockchain assets gave provenance to said inventory…”) based on the publishing of the second event message ([0106] “…Order Microservice once captures ‘Inventory reserved’ event from Inventory microservice…”), the event-driven architecture enabling integration between the ERP software system and the blockchain management system without modification of the ERP software system ([0039] “…using microservices and web-services to blockchain-enable a wide range of legacy client-server supply chain applications…”, [0054] “…PaaS/Oracles may tie existing Enterprise Resource Planning (ERP) or Supply Chain Management (SCM) outside the ERP platform (i.e., SAP, Oracle, IBM, and similar providers) into the track and trace technology…”, [0114] “…enforcing a loosely-coupled design. This is supported by this architectures' use of a fully event driven architecture (“EDA”) paradigm…” ), thereby avoiding service interruption associated with modifying the ERP software system ([0113] “…Releasing micro-frontends become smooth by delivering small pieces of the application separately at any time without affecting others… So, even if one feature faces the issue, it doesn't affect the rest of the web app…”)
Vetas does not disclose, however, Hahn, as shown, teaches the following limitations:
[causing]… a non-fungible token (NFT) corresponding to the sales order to be minted … ([0094] “…a mobile application to generate a non-fungible token (NFT) based on a transaction of a real, tangible product…”, [0100] “…information necessary to generate an NFT associated with the watch 201 being sold…”)
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 method for generating non-fungible tokens (NFTs) based on sales of physical items such as an item purchased in a store using a QR code and a private key of Hahn (‘268, [0001]) with the teaching of Vetas for securing data through blockchains being transmitted between a consortium of stakeholders (‘261, [0002]) for enhancing the method for securing data through blockchains of Vitas with features of generating the non-fungible token corresponding to the specific sale based on the record of a sale transaction (‘268, [0094], [0100]).
Neither Vetas nor Hahn disclose, however, Mordan et al., as shown, teaches the following limitations:
[causing]… on decentralized blockchain … (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 (col.14, lines 20-22 “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 30-31 “Events may include information about the successful minting of tokens“), the indication comprising a transaction identification corresponding to the NFT on the decentralized blockchain (col.14, lines 18-20 “the blockchain network 125 may return a transaction hash, which can be a unique identifier for the transaction on the blockchain”)
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 method for generating non-fungible tokens (NFTs) based on sales of physical items such as an item purchased in a store using a QR code and a private key of Hahn (‘268, [0001]) and method for improving the performance of minting and managing metadata for NFTs on a blockchain of Mordan et al. (‘874, col.3, lines 55-57) with the teaching of Vetas for securing data through blockchains being transmitted between a consortium of stakeholders (‘261, [0002]) for enhancing the system for securing data through blockchains of Vitas with features of including a decentralized system of nodes, wherein each node maintaining a copy of the entire blockchain, and receiving an indication of successful minting on the blockchain and transaction hash identifies the minting transaction on the blockchain and is used to confirm the mint (‘874, col.9, lines 27-29, col.14, lines 18-22, 30-31).
Claims 9 and 17 are rejected using the same rationale that was used for the rejection of claim 1.
As per claim 9 Vetas additionally discloses the following limitations:
at least one hardware processor ([0013] “…a management system has a blockchain structure, the system includes a consortium of stakeholder computers connected to a platform…”)
a database ([0065] “The blockchain database can include an Elasticsearch cluster, a master database, and multiple replica databases…”)
a non-transitory computer-readable medium ([0072] “…the platform can have access to a large volume, variety and location of data storage. The data storage should also have security measures that are sufficient for the confidentiality and sensitivity of data being stored…”)
As per claim 17 Vetas additionally discloses the following limitations:
A non-transitory machine-readable storage medium ([0072] “…the platform can have access to a large volume, variety and location of data storage. The data storage should also have security measures that are sufficient for the confidentiality and sensitivity of data being stored…”)
29. As per claim 2:
Vetas discloses the following limitations:
wherein the database is located within an enterprise resource planning (ERP) software system ([0060] “…The platform can include ERP, SaaS a modular Supply Chain Management (SCM) system and Data Analytics platform…”, [0050] “… link back to a centralized database where inventory transactions and attributes are stored…”) and stores product master data for a plurality of products ([0050] “…Centralized data may include the following: specific inventory attributes, dates, locations, geo-coordinates, and any other data necessary for the correct classification of inventory being transferred…”), wherein one or more software applications in the ERP system perform calculations on the product master data ([0055] “Material Requirements Planning (MRP) or Demand-Driven Material Requirements Planning (DDMRP) SCM may be included…”)
Claims 10 and 18 are rejected using the same rationale that was used for the rejection of claim 2.
30. As per claim 6:
Neither Vetas nor Mordan et al. disclose, however, Hahn, as shown, teaches 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 ([0094] “…Moreover, the mobile application can connect to API, or the mobile app can be replaced by a website…”, [0100] “The mobile application the transmits to a marketplace 213 information necessary to generate an NFT associated with the watch 201 being sold…”, [0101] “From the marketplace smart contract 213, an NFT smart contract 222 can be generated using the 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 method for generating non-fungible tokens (NFTs) based on sales of physical items such as an item purchased in a store using a QR code and a private key of Hahn (‘268, [0001]) and method for improving the performance of minting and managing metadata for NFTs on a blockchain of Mordan et al. (‘874, col.3, lines 55-57) with the teaching of Vetas for securing data through blockchains being transmitted between a consortium of stakeholders (‘261, [0002]) for enhancing the method for securing data through blockchains of Vitas with features of generating the non-fungible token based on connection with API and information obtained in the marketplace (‘268, [0094], [0100], [0101]).
Claim 14 is rejected using the same rationale that was used for the rejection of claim 6.
31. As per claim 8:
Vetas discloses the following limitations:
receiving a request to view the sales order from a computing device of a user ([0052] “Consortium members and extra-consortium participants can use a web portal or native mobile portal or email service or any other Application Programming Interface (API) service or Graphical User Interface (GUI) portal…”, [0106] “…shows details to the user regarding order has been placed…”)
causing data of the sales order to be displayed on the computing device ([0106] “…shows details to the user regarding order has been placed…”), the data of the sales order comprising the transaction identification of the NFT ([0052] “…Consortium members and extra-consortium participants can view the hierarchical linking of transactions through the methods and data.”)
Claim 16 is rejected using the same rationale that was used for the rejection of claim 8.
32. Claims 3-4, 11-12, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US20220051261A1 to Vetas in view of US20230274268A1 to Hahn, US11973874B1 to Mordan et al., and US20120023130A1 to Schlarb et al.
33. As per claim 3:
Neither Vetas nor Hahn or Mordan et al. disclose, however, Schlarb et al., as shown, teaches 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 ([0049] “A customer may operate key user tool 830 to add an extension field to user interface 814 based on reference field bundle 817…”, [0031] “Client 120 may execute a Web browser to access services 116 via HyperText Transport Protocol (HTTP) communication…”, [0002] “…A business object may also represent master data objects such as a product…”)
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 ([0049] “…Upon receipt of input from key user tool 830, customer layer 820 creates appropriate metadata describing the extension field.”, [0064] “…a ‘field persistency’ object containing the field definition and to which business object node it is logically attached…”), 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 ([0029] “…an extension field that is modeled within the metadata of a business object allows services 116 to store and retrieve data associated with the extension field.”) and a token identification of the NFT in the token identification field ([0029] “…allows services 116 to store and retrieve data associated with the extension field.”)
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 method for generating non-fungible tokens (NFTs) based on sales of physical items such as an item purchased in a store using a QR code and a private key of Hahn (‘268, [0001]), method for improving the performance of minting and managing metadata for NFTs on a blockchain of Mordan et al. (‘874, col.3, lines 55-57), and a method for inclusion of extension fields within consuming business entities of a business process platform of Schlarb et al. (‘130, [0001]) with the teaching of Vetas for securing data through blockchains being transmitted between a consortium of stakeholders (‘261, [0002]) for enhancing the method for securing data through blockchains of Vitas with features of including customer's input through the key user tool as a request to add a field to a business object (e.g., product master data) as the extension field, storing values in the added extension field (e.g., a smart contract identification) (‘130, [0002], [0029], [0031], [0049]).
Claims 11 and 19 are rejected using the same rationale that was used for the rejection of claim 3.
34. As per claim 4:
Neither Vetas nor Hahn or Mordan et al. disclose, however, Schlarb 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 ([0004] “…a customer may wish to change a user interface associated with a SALES_ORDER business object by adding a ‘Sub-Product Identifier’ field next to an existing ‘Product Identifier’ field.”, [0049] “A customer may operate key user tool 830 to add an extension field to user interface 814…”)
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 ([0005] “…the SALES_ORDER business object is modified to include the extension field ‘Sub-Product Identifier’…”), wherein the storing of the transaction identification of the NFT comprises storing the transaction identification of the NFT in the smart transaction identification field ([0029] “…allows services 116 to store and retrieve data associated with the extension field.”)
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 method for generating non-fungible tokens (NFTs) based on sales of physical items such as an item purchased in a store using a QR code and a private key of Hahn (‘268, [0001]), method for improving the performance of minting and managing metadata for NFTs on a blockchain of Mordan et al. (‘874, col.3, lines 55-57), and a method for inclusion of extension fields within consuming business entities of a business process platform of Schlarb et al. (‘130, [0001]) with the teaching of Vetas for securing data through blockchains being transmitted between a consortium of stakeholders (‘261, [0002]) for enhancing the method for securing data through blockchains of Vitas with features of fulfilling received customer's request for changing an identifier field to the SALES_ORDER record and storing data in the added sales order field associated with the transaction identification (‘130, [0004], [0005], [0029], [0049]).
Claims 12 and 20 are rejected using the same rationale that was used for the rejection of claim 4.
35. Claims 5, 7, 13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US20220051261A1 to Vetas in view of US20230274268A1 to Hahn, US11973874B1 to Mordan et al., and US20230088674A1 to Lee.
36. As per claim 5:
Vetas discloses 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 ([0095] “…Events flow through the asynchronous event hub, on which event publishers and subscribers (abstract and domain microservices) are sourcing and ingesting events in real time…”, [0094] “…use event sourcing to communicate between them…”)
the causing of the NFT to be minted on the decentralized blockchain comprises consuming the first event message stored in the first message queue… ([0106] “…‘Inventory Microservice’ captures the ‘Order Placed’ event…”)
Neither Vetas nor Hahn or Mordan et al. disclose, however, Lee et al., as shown, teaches the following limitations:
[the causing] … and sending a request to a blockchain management system to mint the NFT based on the consuming of the first event message ([0080] “… NFT generation requests may be grouped together in one batch transaction…”, [0083] “Once the batch blockchain transaction has been generated, it is propagated on the blockchain network…”)
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 method for generating non-fungible tokens (NFTs) based on sales of physical items such as an item purchased in a store using a QR code and a private key of Hahn (‘268, [0001]), method for improving the performance of minting and managing metadata for NFTs on a blockchain of Mordan et al. (‘874, col.3, lines 55-57), and a method for blockchain network congestion-adaptive creation or transfer of digital assets of Lee (‘674, [0001]) with the teaching of Vetas for securing data through blockchains being transmitted between a consortium of stakeholders (‘261, [0002]) for enhancing the method for securing data through blockchains of Vitas with features of sending to the blockchain network the NFT generation request based on consuming the queued inquiry (‘674, [0080], [0081]).
Claim 13 is rejected using the same rationale that was used for the rejection of claim 5.
37. As per claim 7:
Vetas discloses the following limitations:
[the storing] … and storing the transaction identification of the NFT in the database in association with the sales order based on the consuming of the second event message ([0106] “…Order Microservice once captures “Inventory reserved” event from Inventory microservice, the system performs further processing…”
Neither Vetas nor Hahn or Mordan et al. disclose, however, Lee et al., 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 ([0109] “…update events may be queued and processed asynchronously from a state change that triggered them…”)
the storing of the transaction identification of the NFT in the database in association with the sales order comprises consuming the second event message stored in the second message queue … ([0109] “… A subscription model may be used to provide applications 142A-B with events as they occur…”)
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 method for generating non-fungible tokens (NFTs) based on sales of physical items such as an item purchased in a store using a QR code and a private key of Hahn (‘268, [0001]), method for improving the performance of minting and managing metadata for NFTs on a blockchain of Mordan et al. (‘874, col.3, lines 55-57), and a method for blockchain network congestion-adaptive creation or transfer of digital assets of Lee (‘674, [0001]) with the teaching of Vetas for securing data through blockchains being transmitted between a consortium of stakeholders (‘261, [0002]) for enhancing the method for securing data through blockchains of Vitas with features of updating the event message that stored in their own queue, separate from the request queue of a second message queue for the second event message and consumed by subscribing applications (‘674, [0109]).
Claim 15 is rejected using the same rationale that was used for the rejection of claim 7.
Response to Arguments
38. After careful consideration of applicant arguments, the examiner finds them to be not persuasive. Claims 1-20 are rejected.
Rejection under 35 USC § 101
39. Applicant’s arguments toward 35 U.S.C. § 101 rejection is not persuasive. Amended independent claims 1, 9, and 17 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.
40. Applicant is of the opinion that the claims are not directed to an abstract idea, but to “[it] is a specific technical method for integrating two disparate back- end computer systems (an ERP software system and a blockchain management system) through an intermediary event-driven architecture comprising a message broker”.
Examiner respectfully disagrees.
Claims as a whole directed to processing a sales order for an object (“a sales order has been created in the 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)”.
41. Applicant is of the opinion that the claims are integrated into a practical application. “Specifically, the amended claims recite ‘wherein the event-driven architecture comprising the message broker enables integration between the ERP software system and the blockchain management system without modification of the ERP software system, thereby avoiding service interruption associated with modifying the ERP software system’.”
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 – the event-driven architecture being external to the ERP software system and decoupling the ERP software system from a blockchain management system and the event-driven architecture enabling integration between the ERP software system and the blockchain management system without modification of the ERP software system, thereby avoiding service interruption associated with modifying the ERP software system – merely implement an abstract idea (commercia/legal interaction) using the additional elements such as the enterprise resource planning (ERP) software system, the database, the event-driven architecture, and the blockchain management system 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.
42. Applicant is of the opinion that “[the] Claims Provide a Specific Technical Improvement to Computer Technology Under Enfish, LLC V. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), claims directed to a specific improvement in the way computers operate are patent-eligible. Under Ancora Technologies, Inc. V. HTC America, Inc., 908 F.3d 1343 (Fed. Cir. 2018), claims directed to a non-abstract improvement in computer functionality are patent-eligible”.
Examiner finds this unpersuasive.
Unlike Enfish, that created a new self-referential table to enable faster searching, the claimed invention does not describe any comparable new data structure that leads to performance improvement. And Ancora Technologies which covers a method for restricting software use on a particular computer by verifying license data stored in the Basic Input/Output System (BIOS) ROM , the invention focused on a specific technological solution to a computer vulnerability—preventing hackers from tampering with license software by anchoring verification to a specific component (the BIOS memory).
43. Applicant is of the opinion that “[the] amended claims clearly amount to significantly more than any alleged abstract idea … The specification expressly describes the claimed implementation as involving ‘a non- generic, unconventional, and non-routine operation or combination of operations’.” and continues “Under Berkheimer V. HP Inc., 881 F.3d 1360, 1368 (Fed. Cir. 2018), whether additional elements represent well-understood, routine, or conventional activity is a factual question”.
Examiner respectfully disagrees.
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.
Berkheimer does not stand for the proposition that every claim limitation in combination is required to be significantly more. Rather Berkheimer requires that only the additional elements, beyond the abstract idea, must be more than well-understood, routine and conventional. See MPEP 2106.05(a) (“It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements.”).
The claims are not patent eligible.
Rejection under 35 USC § 103
44. Applicant argues that prior art references Mordan et al. in view of Fay et al. do not teach and suggest amended claims limitations.
Applicant arguments are no longer applicable because they are moot in light of the new ground of rejection.
Conclusion
45. 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.
46. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
47. 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
October 9, 2026
