Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This application claims priority to U.S. Provisional Patent Application Serial No. 63/358,487, which was filed 07/05/ 2022.
This office action is in response to the RCE filed on 11/24/2025.
Claims 1-20 are presented for examination.
Continued Examination under 3 7 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/24/2025 has been entered.
Claim Rejections - 35 USC§ 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 and 17,
Step 1: Statutory Category
The claims are directed to “a system” and “a method”, which are directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter.
Step 2A - Prong One:
The claims recite the following limitations directed to an abstract idea:
“select…to validate…; pre-minting…; pre-minting…; placing…; responsive…generating…; a pre-transaction…; minting…, putting…; determine… ”, are process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement, but for the recitation of generic computer components. That is nothing in the claim element precludes the steps from practically being performed in a human mind.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the "Mental Processes" grouping of abstract ideas.
Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two:
This judicial exception is not integrated into a practical application. The claim recites the additional elements:
“receive …”, amount to data gathering steps which is considered to be insignificant extra-solution activity. (See MPEP 2106.05(g).
“update…” which represent(s) an extra solution activity because it is a mere nominal or tangential addition to the claim, a mere generic transmission and presenting of collected and analyzed data. (See MPEP 2106.05(g)).
At Step 2B:
“receive…; update…”. These are identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remains insignificant extra-solution activity that does not provide significantly more.
“route…, transmit…to perform…;cause…; store…; causing…to perform…”. This is identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334; i. … transmitting data over a network, …Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350,
“a memory system comprising one or more memories, the memory system coupled with the processing system, the memory system comprising stored program code instructions; processing system; data engine; mutable data engine; immutable data engine”, amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, as demonstrate by: relevant court decision: the followings are example of the court decisions demonstrating well-understood, routine and conventional activities, See e.g., MPEP 2106.05(d)(II) and MPEP 2106.05(f)(2): computer readable storage media comprising instructions to implement a method, e.g., see versata Dev. Group, Inc. v SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
Looking at the claim(s) as a whole does not amount to significantly more than the abstract idea itself and the claims are not eligible under the 35 USC § 101.
- Claims 2-16 and 18-20, are depending on claims 1 and 17. They are recited additional limitations, which are rejected under the same rational as claims 1 and 17 above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-11, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Vityaz (US 2022/0100554), hereinafter “Vityaz”, in view of Sen et al., (US 12/155764 B2), hereinafter “Sen”, and further in view of Ow et al., (US 2021/0319436 A1), hereinafter “Ow”.
As per claim 1, Vityaz discloses a system comprising: a processing system comprising:
one or more processors (par. [0183], hardware processor); and
a memory system comprising one or more memories, the memory system coupled with processing system (par. [0126] and [0252], a storage medium such as a database, or in memory, wherein the memory comprises a plurality of embodiments... such as,... volatile memory, non-volatile memory, and semi-volatile memory),
the memory system comprising stored program code instructions that when executed causes the processing system to (par. [0183], defining the code includes specifying one or more data files containing executable code, wherein the defined code may comprise code executable by a microprocessor, and the code comprises one or more executable files that, when executed, cause a hardware processor to perform particular actions):
- receive, at an endpoint, a message associated with a database action from a client device (par. [0099], [0102], [0111], [0116] conceptualized as a collection of one or more interconnected universal computing elements, arbitrarily complex, including... multiple endpoints, establishing connections to external systems, calling or modifying other processes, asking for input from a user, a user interface may enable a user to configure the API call, a point of input for the TPI marketplace may accept command messages);
- route the message to an action queue in response to receiving a message via the endpoint (par. [0102], combining together into collections of UCEs that form a process, wherein objects routes among UCEs, passing through their respective queues, wherein their parameters are operated upon and modified by the UCEs' respective functions);
- transmit the message from the action queue to a plurality of data engines corresponding to a plurality of data storage systems that store data (par. [0099], [0102], [0111] and [0116]), the plurality of data engines including (i) a mutable data engine corresponding to a mutable data storage system, causing the plurality of data engines to perform the database action based on the message (par. [0099], [0102], [0111] and [0116], [0126] and [0216], platform and elements thereof... are implemented in a storage medium such as a database, or in memory..., wherein the platform or aspects thereof may be hosted one or more physical or virtual servers, cloud computing services, blockchain platforms, or distributed computing platforms); and
However, Vityaz does not disclose the limitation “an immutable data engine corresponding to an immutable data storage system; select a number of mutable or immutable data engines based on action performance speed of the plurality of data engines”.
Meanwhile, Sen discloses an immutable data engine corresponding to an immutable data storage system (col. 5 lines 6-13, a transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain; and col. 6 lines 14-25, endorser nodes are selected randomly or based on network distance, wherein the benefits of identifying optimal endorser peers is that clients understand which peers to request endorsement from to reduce the cost/time of committing a transaction, wherein the system can identify the optimal set of peers based on actual transaction history and current load. Given a chaincode endorsement policy, the optimizer described herein can identify an optimal (and minimal) set of peers to collect endorsements);
-select a set of data engines including at least one mutable data engine and at least one immutable data engine based on action performance speed of the plurality of data engines (col. 5 lines 6-13, a transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain; and col. 6 lines 14-25, endorser nodes are selected randomly or based on network distance, wherein the benefits of identifying optimal endorser peers is that clients understand which peers to request endorsement from to reduce the cost/time of committing a transaction, wherein the system can identify the optimal set of peers based on actual transaction history and current load. Given a chaincode endorsement policy, the optimizer described herein can identify an optimal (and minimal) set of peers to collect endorsements);
- cause each of the selected number of mutable and immutable data engines to (i) determine whether to accept or reject the database action, and (b) perform the database action in response to the database action being accepted, wherein a selected mutable data engine is configured to apply rule enforcement emulating rule enforcement of a selected immutable data engine, and to reject the database action when the selected immutable data engine rejects the database action (col. 4 lines 34-45, an endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement, wherein a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks; col. 5 lines 6-13, a transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain; and col. 6 lines 14-25, endorser nodes are selected randomly or based on network distance, wherein the benefits of identifying optimal endorser peers is that clients understand which peers to request endorsement from to reduce the cost/time of committing a transaction, wherein the system can identify the optimal set of peers based on actual transaction history and current load. Given a chaincode endorsement policy, the optimizer described herein can identify an optimal (and minimal) set of peers to collect endorsements);
- track the action queue to determine an action performance speed of each of the selected mutable and immutable data engines based on performance of the database action (col. 4 lines 34-45, an endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks); and
- store the action performance speed of each of the selected mutable and immutable data engines in a log store (col. 5 lines 6-13, a transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain).
Therefore, one having ordinary skill in the art would have been obvious before the effective filing date of the claimed invention to have modified the system of Vityaz to include the features as disclosed by Sen to select a number of mutable or immutable data engines based on action performance speed of the plurality of data engines and consensus requirements in order to improves the configuration and deployment of blockchain.
Even though Sen discloses a consensus protocol. However, Sen does not disclose the limitation “consensus requirements, wherein consensus requirements include a required number or type of data engines to validate the database action before the database action is deemed committed”.
On the other hand, Ow discloses consensus requirements, wherein consensus requirements include a required number or type of data engines to validate the database action before the database action is deemed committed (par. [0046] and [0040], the witness mechanism will select a group of nodes from the AXEL blockchain using a randomized algorithm. The selected group of nodes will perform the consensus calculation against a transaction. Once consensus has been reached by the selected witness group (nodes), the witness(es) will digitally sign the transaction and the ledger (chain) will be updated with a new block (or blocks) reflecting the transaction being recorded. Each node (witness) participating in the consensus of the subject transaction will create a mirror-block on their own private chain to reflect the transaction in which they participated).
Therefore, one having ordinary skill in the art would have been obvious before the effective filing date of the claimed invention to have modified the system of cited references to include the features as disclosed by Ow to include a required number or type of data engines to validate the database action before the database action is deemed committed in order to user with appropriate permission.
As per claim 2, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Vityaz discloses the mutable data engine comprises at least one of an in memory database, a relational database, a NoSQL database, or a timeseries database (par. [0126], a database, or in memory).
As per claim 3, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Vityaz discloses the immutable data engine comprises a blockchain (par. [0216], blockchain platforms).
As per claim 4, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Vityaz discloses the action is at least one of a POST action, a GET action, a DELETE action, or a PATCH action (par. [0125], API platform enables the creating, modifying, and deleting processes).
As per claim 5, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Vityaz discloses the instructions to cause the immutable data engine further comprises stored instructions that when executed causes the processing system to:
- compress a plurality of actions comprising the action into a single action (par [0102], UCEs are combined together into collections of UCEs that form a process);
- cause the single action to be performed by the immutable data engine (par [0102] and [0164], the dashboard displaying such metrics as: successful process completions over the past 24 hours, current number of users in a queue of a particular node and process failures due to API call errors over a particular two week period);
- perform the single action by the immutable data engine in response to the immutable data engine being caused to generate a confirmation indicating that the single action has been carried out (par. [0102], [0126] and [0164]); and
- receive a confirmation from the immutable data engine in response to an update being the action queue based on the confirmation (par. [0102], [0126], [0164]) and [0178], awaiting the results of that communication, e.g., successful or unsuccessful).
As to claim 6, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Sen discloses the plurality of data engines comprises a plurality of immutable data engines ranked based on corresponding priorities, each of the plurality of immutable data engines comprised of stored instructions that when executed cause the processor system to: select the data associated with the action recorded in a first immutable data engine in response to determining that the first immutable data engine having a first priority and a second immutable data engine having a second priority lower than the first priority contain inconsistent data associated with an action (col. 6 lines 14-25, endorser nodes are selected randomly or based on network distance, wherein the benefits of identifying optimal endorser peers is that clients understand which peers to request endorsement from to reduce the cost/time of committing a transaction, wherein the system can identify the optimal set of peers based on actual transaction history and current load. Given a chaincode endorsement policy, the optimizer described herein can identify an optimal (and minimal) set of peers to collect endorsements from). Vityaz also discloses similar the above limitations (par. [0102], [0175], [0176] and [0216], attempts to get an object from a customer re-call queue at the higher priority and also attempts to get an object from a new customer call queue at , lower priority, where the system determines which object to select based on the desired priority of the engine).
Therefore, one having ordinary skill in the art would have been obvious before the effective filing date of the claimed invention to have modified the system of cited references to include the features as disclosed by Vityaz and/ Sen to provide a ranked list or suggested list of optimal peers to a client.
As per claim 8, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Sen discloses priorities of the plurality of immutable data engines are determined based in part on corresponding processing speeds (col. 6 lines 14-25, endorser nodes are selected randomly or based on network distance, wherein the benefits of identifying optimal endorser peers is that clients understand which peers to request endorsement from to reduce the cost/time of committing a transaction, wherein the system can identify the optimal set of peers based on actual transaction history and current load. Given a chaincode endorsement policy, the optimizer described herein can identify an optimal (and minimal) set of peers to collect endorsements from)
Vityaz also discloses similar the above limitations (par. [0121], [0140] and [0175], user interface display upon selection of a particular node other pertinent options for the functioning of the node, such as whether to send system information, whether and what to send with respect to header information, cryptographic signature, limiting the time of a task in the node).
Therefore, one having ordinary skill in the art would have been obvious before the effective filing date of the claimed invention to have modified the system of cited references to include the features as disclosed by Vityaz and/ Sen to provide a ranked list or suggested list of optimal peers to a client.
As per claim 9, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Sen discloses the immutable data engine is further caused to compress a plurality of actions into a single action and perform the single action to improve a transaction speed (col. 4 lines 34-45, an endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks).
Vityaz also discloses the above limitations (par. [0031], [0102], [0166] and [0225], providing a no-code/low-code functionality that enhances the efficiency, speed, or division of labor in software and process development using a soft microprocessor cores on a single field programmable gate array, such as semiconductor intellectual property cores that employ by the plurality of the CPU cores but not limited to Instruction-level parallelism and superscalar pipelining, and Thread-level parallelism while each of the metrics selected in example implementation are from a single process).
As to claim 10, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Sen discloses tracking the action queue to determine an action performance speed of each of the plurality of data engines comprises tracking a lag of a specific data engine relative to a most up-to-date data engine (col. 4 lines 34-45, an endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks). Vityaz also discloses the above limitations tracking the action queue to determine an action performance speed of each of the plurality of data engines comprises tracking a lag of a specific data engine relative to a most up-to-date data engine (par. [0121], [0140], [0145] and [0167], tracking the number of objects in that end node's queue, maintaining the queue of customer calls by tracking changes in the state of calls, and having a dashboard to indicate the time it takes for a task to be processed through the nodes and how far behind some tasks are compared to other engines).
As per claim 11, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Vityaz discloses the instructions to track the action queue to determine an action performance speed of each of the plurality of data engines further comprises stored instructions that when executed causes the processing system to track-a last state identifier of each of the plurality of data engines, a last state identifier of a data engine increasing incrementally responsive to completion of an action (par. [0108], [0110], [0113] and [0175], setting a node identifier parameter to precipitate the release of the object from the first queue to the last queue subsequently and while a caller's initial call timestamp stay the same throughout a process, a parameter signifying the number of times the caller has been transferred is incrementing). Sen also discloses the above limitations (col. 4 lines 34-45, an endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks).
As per claim 15, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Vityaz discloses the message is routed to the action queue among a plurality of action queues based in part of a set of rules (par. [0102] and [0156], upon making an API call, the external system applies the rules to the submitted query and take action thereupon).
Claims 7, 12-14 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Vityaz, Sen, in view of Ow, and further in view of Cella et al., (US 2022/0198562), hereinafter “Cella”.
As per claim 7, the combination of Vityaz, Sen, and Ow discloses the invention as claimed. In addition, Vityaz discloses wherein priorities of the plurality of immutable data engines are determined (par. [0102], [0176] and [0216]).
However, the combination of Vityaz, Sen, and Ow fails to disclose the limitation “priorities of the plurality of immutable data engines are determined based in part on trustworthiness scores of the plurality of immutable data engines”.
Meanwhile, Cella discloses priorities of the plurality of immutable data engines are determined based in part on trustworthiness scores of the plurality of immutable data engines (par. [1013], acquiring data associated with blockchain addresses and determine a variety of trust scores based on the acquired data and determine whether the blockchain address with which they are transacting is trustworthy).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of cited references to determine based in part on trustworthiness scores of the plurality of immutable data engines priorities of the plurality of immutable data engines, in order to allow the system to synchronize the engines to achieve consistent data, as specified by the tenant application.
As to claim 12, the combination of Vityaz, Sen, and Ow discloses the invention as claimed, except for “the message comprises a request to achieve a specific level of consensus among the plurality of data engines”.
On the other hand, Cella discloses wherein the message comprises a request to achieve a specific level of consensus among the plurality of data engines (par. [0492], [0943], [1012], generating content for a contact event, such as an email, text message, or a post to a network, or a machine-to-machine message, such as communicating via an API or a peer-to-peer system, request the consensus trust score from the trust network before engaging in a transaction in which funds are transacted on the blockchain and wherein the consensus trust score determines whether the blockchain address with which they are transacting is trustworthy).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of cited references to include a determined amount of consensus, as taught by Cella to allow the engines to be synchronized, as specified by the tenant application.
As to claim 13, the combination of the combination of Vityaz, Sen, Ow, and Cella discloses the invention as claimed. In addition, Cella discloses the specific level of consensus includes a minimum number of data engines (par. [0943] and [1013], facilitating the performance operations that are defined in the smart contract and verifying that the one or more conditions defined in the smart contract are met and achieving the consensus with respect to one or more required conditions, the management of digital knowledge via the knowledge distribution system progress to a next phase in the workflow, and the minimum number of data engines are the transacting parties that must be met the desired consensus to complete a transaction). Vityaz discloses return a same confirmation responsive to performing the action (par. [0102], [0126], [0164] and [0178]).
As to claim 14, the combination of Vityaz, Sen, Ow, and Cella discloses the invention as claimed. In addition, Vityaz discloses a mixture of immutable and mutable data engines (par. [0126] and [0216]). Cella discloses the specific level of consensus (par. [0943 and [1013]) to return a same confirmation responsive to performing the action (par. [1029],verifying the transaction depending on the ledger network parameters the nodes, wherein the transaction is verified immediately, or placed in a queue with other transactions and the nodes to determine if the transactions are valid based on a set of network rules). The same motivation as claim 12 above.
As per claim 16, the combination of Vityaz, Sen, and Ow discloses the invention as claimed, except for “each of the plurality of data engines is associated with a trustworthiness score, and when the plurality of the data engines are not in consensus, a data engine associated with a highest trustworthiness score controls”.
Meanwhile, Cella disclose each of the plurality of data engines is associated with a trustworthiness score, and when the plurality of the data engines are not in consensus, a data engine associated with a highest trustworthiness score controls (par. [1011]-[1015] and [10355]-[1036], determining by the trust network the authority of a node in function of its consensus trust score and reputation, and using a consensus trust score to determine whether the blockchain address with which they are transacting is trustworthy).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of cited references as it would allow the system to synchronize the engines based on this authority, as specified by the tenant application.
Claims 17-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Goldstein (US 2022/0027896), hereinafter “Goldstein”, in view of Ow et al., (US 2021/0319436 A1), hereinafter “Ow”, and in further view of Sen et al., (US 12/155764 B2, hereinafter “Sen”
As per claim 17, Goldstein discloses a method for minting tokens at data system having both a mutable database and an immutable database, the method comprising:
- pre-minting a token by the mutable database (par. [0027] and [0031], campaign information which is a remote databases includes informational descriptions, digital video files, audio files and other data that a potential token acquirer may access and use to consider whether or not to acquire tokens of a particular specification), pre-minting the token comprising:
- receiving, by the mutable database, a user indication, creating the token (par. [0027], [0032], receiving a campaign information that includes details that each issuer about the issuer's token specifications to share with potential buyers, lenders or others who may acquire tokens that conform to those specifications in exchange for assets of value, wherein the campaign information data store is one or more remote databases from which the server serves information to a user's electronic device where user accesses the campaign information using a digital wallet application, a browser, or other application on the device);
- pre-minting the token at the mutable database (par. [0027] and [0031], campaign information which is a remote databases includes informational descriptions, digital video files, audio files and other data that a potential token acquirer may access and use to consider whether or not to acquire tokens of a particular specification);
- placing the pre-minted token in a marketplace for transaction (par. [0076], transferring some or all of the tokens to another user of the platform upon received tokens in the system or minted new tokens according to a specification);
- responsive to receiving a transaction request, generating a transaction table for a pre-transaction associated with the token (par. [0027], [0073] and [0076], resolving question (s) of whether parameters are equal by comparing their values or their characteristics having ranked priorities in a lookup table or other reference set); and
- passing the transaction request to the immutable database (par. [0030] and [0036], allowing simultaneous access, validation, and record updating in an immutable manner by multiple users and allowing public review, or for private review received by authorized users of the system to define a token specification for a token set that users of the system exchange for goods, services or other items of value, and used in payment transactions, lending arrangements and other exchanges of goods, services, or other items of value);
- minting the token by the immutable database in response to receiving the transaction request, the minting comprising:
minting the token at a partner wallet (par. [0092], interacting with the ledge using a wallet application to initiate smart contracts related to buying, selling, transferring, destroying, issuing, minting, buying back, etc., wherein tokens and, or creating token class specifications);
putting the token for transaction at a log processing service (LPS) (par. [0092], interacting with the ledge using a wallet application to initiate smart contracts related to buying, selling, transferring, destroying, issuing, minting, buying back, etc., wherein tokens and, or creating token class specifications),
- the plurality of data engines comprising at least one mutable data engine and causing the mutable database to update a status of the transaction request as successful (par. [0045], implementing the redemption request and complete the transfer by writing a transfer record to the digital ledger or there is no execution of the redemption request).
However, Goldstein does not disclose the limitation “wherein consensus requirements include a required number of data engines to validate the transaction action before the transaction action is deemed committed”.
On the other hand, Ow discloses wherein consensus requirements include a required number or type of data engines to validate the transaction action before the transaction action is deemed committed (par. [0046] and [0040], the witness mechanism will select a group of nodes from the AXEL blockchain using a randomized algorithm. The selected group of nodes will perform the consensus calculation against a transaction. Once consensus has been reached by the selected witness group (nodes), the witness(es) will digitally sign the transaction and the ledger (chain) will be updated with a new block (or blocks) reflecting the transaction being recorded. Each node (witness) participating in the consensus of the subject transaction will create a mirror-block on their own private chain to reflect the transaction in which they participated); the LPS comprising at least an action queue configured to route each transaction-related message to one of a plurality of data engines corresponding to a plurality of data storage systems that store data, causing the plurality of data engines to perform a transaction action based on the transaction-related message (par. [0070] and [0077], receiving address that is visible to the blockchain and to other users, wherein once the blockchain confirms and logs the transaction, the received token can be transferred either through direct action of the wallet user or automatically, in certain instances participants simply select and receive a number of tokens without taking any specific action);
Therefore, one having ordinary skill in the art would have been obvious before the effective filing date of the claimed invention to have modified the system of cited references to include the features as disclosed by Ow to include a required number or type of data engines to validate the database action before the database action is deemed committed in order to user with appropriate permission.
However, the combination of Goldstein and Ow does not disclose the limitation “and at least one immutable data engine; selecting a number of data engines based on consensus requirements associated with the transaction action”.
On the other hand, Sen discloses and at least one immutable data engine; selecting a set of data engines including at least one mutable data engine and at least one immutable data engine based on consensus requirements associated with the transaction action (col. 5 lines 6-13, a transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain; and col. 6 lines 14-25, endorser nodes are selected randomly or based on network distance, wherein the benefits of identifying optimal endorser peers is that clients understand which peers to request endorsement from to reduce the cost/time of committing a transaction, wherein the system can identify the optimal set of peers based on actual transaction history and current load. Given a chaincode endorsement policy, the optimizer described herein can identify an optimal (and minimal) set of peers to collect endorsements from )
- causing each of the selected mutable and immutable data engines to: (a) determine whether to accept or reject the transaction action associated with the transaction request; and (b) perform the transaction action in response to the transaction being accepted, wherein a selected mutable (col. 4 lines 34-45, an endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement, wherein a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks; and col. 6 lines 14-25, endorser nodes are selected randomly or based on network distance, wherein the benefits of identifying optimal endorser peers is that clients understand which peers to request endorsement from to reduce the cost/time of committing a transaction, wherein the system can identify the optimal set of peers based on actual transaction history and current load. Given a chaincode endorsement policy, the optimizer described herein can identify an optimal (and minimal) set of peers to collect endorsements from);
- responsive to the transaction being successful at each of the selected number of data engines, transferring the token to a buyer's wallet (col. 5 lines 6-13, a transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain; and col. 6 lines 14-25, endorser nodes are selected randomly or based on network distance, wherein the benefits of identifying optimal endorser peers is that clients understand which peers to request endorsement from to reduce the cost/time of committing a transaction, wherein the system can identify the optimal set of peers based on actual transaction history and current load. Given a chaincode endorsement policy, the optimizer described herein can identify an optimal (and minimal) set of peers to collect endorsements from).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of cited references to include a determined amount of consensus, as taught by Sen to select a number of mutable or immutable data engines based on action performance speed of the plurality of data engines and consensus requirements in order to improves the configuration and deployment of blockchain.
As per claim 18, the combination of Goldstein, Ow, and Sen discloses the invention as claimed. In addition, Goldstein discloses responsive to the transaction being failed, burning, by the immutable database, the token to avoid reporting (par. [0045], [0092] and [0100], the record cannot be committed to the ledger, then the transaction fails and nothing happens).
As per claim 20, the combination of Goldstein, Ow, and Sen discloses the invention as claimed. In addition, Goldstein discloses token comprises one or more transaction conditions, the mutable database puts the token for sale based on the one or more transaction conditions (par. [0032], [0045 ] and [0076], creating a smart contract in which the system would automatically execute the smart contract, wherein the sales contracts have conditions that must be met in order to facilitate a transaction on a distributed ledger and the immutable database puts the token for sale based on the one or more transaction conditions).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Goldstein, Ow, Send, and in further view of Leonard et al., (US 2022/002798), hereinafter “Leonard”.
As per claim 19, the combination of Goldstein, Ow, and Sen discloses the invention as claimed. In addition, Goldstein discloses determining, by the immutable database, whether an LPS (par. [0066] and [0073], tracking two ledger entries with common information, and identifying the new activity by comparing the two entries and identifying the information that appears on one entry but not the other); and creating, by the immutable database, an LPS in response to determining that no LPS (par. [0066] and [0037], generating a record that includes a class-specific token specification, and saving the record class-specific token specification to a digital ledger).
However, the combination of Goldstein, Ow, and Sen discloses fails to disclose the limitation “with specified characters exists, with the specified characters exists”
Meanwhile, Leonard discloses the specified characters-exists and with the specified characters exists (par. [0076] and [0120] memorializing similar a record exist within the Blockchain, wherein actions arising from an Obligation, such as a loan. According to the present invention, a record of a call may include one or more of an audio file, a transcript of a conversation, a video file, or other record, providing a multiple-character identifier that includes at least first, second, and third portions and determine if the identified information exists in the blockchain).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of cited references to include the features as disclosed by Leonard it would allow the system to determine if the record exists, as specified by the tenant application.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LOAN T NGUYEN whose telephone number is (571)-270-3103. . If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aleksandr Kerzhner can be reached on (571) 270-1760. The fax phone number for the organization where this application or proceeding is assigned is 571-270-4103. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
01/05/2026
/LOAN T NGUYEN/Examiner, Art Unit 2165