DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 04/08/2026.
Claims 1, 58 and 59 are amended.
Claims 6, 8-10, 14-20, 22-26, 28, 30-46, 48, 50, 53, 55-57, and 60-74 are canceled.
Claims 1-5, 7, 11-13, 21, 27, 29, 47, 49, 51, 52, 54, 58, and 59 are pending.
Claims 1-5, 7, 11-13, 21, 27, 29, 47, 49, 51, 52, 54, 58, and 59 have been examined.
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 .
Response to Arguments
Applicant's arguments filed 04/08/2026 have been fully considered but they are not persuasive.
101
Applicant argues “a technical method for protecting the data security of potentially sensitive information that may be incorporated into blockchain transactions while simultaneously preserving the integrity and functionality of transaction validation. As amended, the claims require cryptographic process, namely the "generat[ion] of a state Merkle tree".” Examiner disagrees.
First, protecting data security is a business process. The blockchain environment does not appear to be improved. Applicant has just described the automated abstract idea of mitigating risks in a transaction, leaning more into improving a business process, “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int’l v. IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology.” MPEP 2106.05(a) (II).
Secondly, the step positively recited and claimed states “generating a first state data… the first state data is based on an output of a one-way function…”, the “wherein” clause description of creating a hash tree does not explain how the application achieves “protecting the data security of potentially sensitive information that may be incorporated into blockchain transactions while simultaneously preserving the integrity and functionality of transaction validation.” Additionally, reciting generating a Merkle tree, currently recited as a description, does not automatically guarantee data security. Especially, as written, it does not affect the actual positively recited claim limitations or bring about improvements to the technical environment. The rejection is maintained.
103
Lee discloses wherein the first state data is a first Merkle tree root of a state Merkle tree and wherein the step of generating the first state data comprises; wherein the state Merkle tree comprises a first data item as a leaf node; wherein the first data item is based on any one or more of: data received from a client, a set of metadata about the set of transactions, a version number, and a salt. (¶ 65, 131, 258, 641-671),
Claim Interpretation- According to the disclosure (¶ 46) “Advantageously, a Merkle tree root hides the contents of the Merkle tree but allows for reconstruction of the Merkle tree for verification of its contents. Therefore, this allows those with a Merkle tree proof to verify a Merkle tree was constructed using the same data.”
Lee –each transaction in a writechain can contain a deterministic link to at least one of the root node, minting transaction and database establishment transaction or contain information, that enables such a link to be determined e.g. using a Merkle proof….The blanks can be completed using at least one of: providing an identification and a public key; a countersignature of a third party; and a Merkle proof that it is part of a Merkle tree and further providing (i) a Merkle proof that the identification is one of a Merkle tree identifications and (ii) a script that can solve the Merkle root. At least a portion of a body of the form can be a hash of its string and/or content. as an input to a transaction, such that it can be processed by script. Additionally or alternatively, the template of the body can be provided in an establishment transaction or a set-up record. The template of the body can be provided as part of the database establishment transaction…The node allocates these tokens to one or more outputs in a transaction called the ‘Coinbase’ which is the first transaction in the block's merkle tree…Checking the alias can be performed by (i) an agent which countersigns the script, or (ii) using a merkle tree of known aliases, wherein the user would supply the alias and a merkle proof that shows that it is included in a merkle tree of valid aliases, followed by script that can interpret and solve the merkle root, thereby proving the alias is a member of the tree. (¶ 94, 131, 357, 641)
Ma teaches generating the state Merkle tree (Figure 2-4; column 8, line 44-65; claim 1)
Ma - Correspondingly, in the present step, the leaf nodes of the Merkle tree data in the authorization metadata token may be disordered, that is, when the authorization metadata token is generated each time, the positions of the above pieces of information in the leaf nodes of the Merkle tree data may be different, that is, the information of each endpoint, the user information, the project information, the role information, the authorization time information and the creation time information have no fixed arrangement sequence, and the processor may generate the Merkle tree data by using, as the leaf nodes of the Merkle tree, hash values corresponding to the information of each endpoint, the user information, the project information, the role information, the authorization time information and the creation time information, respectively (column 8, line 44-65)
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-5, 7, 10-13, 21, 27, 29, 47, 49, 51, 52, 54, 58, and 59 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, claims 58 and 59 are directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “generating… data… generating… transaction… and submitting … transaction….” The recited limitations fall within the certain methods of organizing human activity grouping of abstract ideas, specifically, commercial interactions, for example, creating terms for a transaction, ex. a contract and submitting the contract. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application. The use of a distributed ledger or blockchain does not preclude the claim from reciting an abstract idea as the blockchain recites functions of a generic computer component, such as storing records.
Accordingly, even in combination, these elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “generating… data… generating… transaction… and submitting … transaction….” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of organizing human activity as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Claims 2-5, 7, 10-13, 21, 27, 29, 47, 49, 52, and 54 provide descriptive language surrounding the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
Claim 51 discusses functions in more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 2-5, 7, 10-13, 21, 27, 29, 47, 49, 51, 52, and 54 are also rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-5, 7, 11-13, 21, 27, 29, 47, 49, 51, 52, 54, 58, and 59 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 58 and 59 recite “the first state data is based on an output of a one-way function taking the first transaction reference and/or the second transaction reference as an input… wherein the first state data is a first Merkle tree root of a state Merkle tree and wherein the step of generating the first state data comprises generating the state Merkle tree; wherein the state Merkle tree comprises a first data item as a leaf node….” According to the disclosure(¶ 43-52, 195-197), “Optionally, the first state data is based on an output of a one-way function… Advantageously, this disallows a malicious third parties to reverse the data stored… Optionally, the first state data is a first Merkle tree root of a state Merkle tree and wherein the step of generating the first state data comprises generating the state Merkle tree…Advantageously, a Merkle tree root hides the contents of the Merkle tree but allows for reconstruction of the Merkle tree for verification of its contents. Therefore, this allows those with a Merkle tree proof to verify a Merkle tree was constructed using the same data….” The disclosure provides the use of the one-way function and a Merkle tree as options with their separate advantages. The disclosure does not provide for the use of the one-way function on a single reference input whose output is the first state data, and also generating the same first state data by generating a Merkle tree, and a Merkle tree with leaf nodes that uses entirely different data input(s). The disclosure does not provide support for “the first state data is based on an output of a one-way function taking the first transaction reference and/or the second transaction reference as an input” and also “wherein the first state data is a first Merkle tree root of a state Merkle tree and wherein the step of generating the first state data comprises generating the state Merkle tree; wherein the state Merkle tree comprises a first data item as a leaf node….” There does not appear to be written description for the claim limitations. Dependent claims 2-5, 7, 10-13, 21, 27, 29, 47, 49, 51, 52, and 54 are also rejected.
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.
Claims 1-5, 7, 11-13, 21, 27, 29, 47, 49, 51, 52, 54, 58, and 59 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.
Claims 1, 58 and 59 recite “the first state data is based on an output of a one-way function taking the first transaction reference and/or the second transaction reference as an input… wherein the first state data is a first Merkle tree root of a state Merkle tree and wherein the step of generating the first state data comprises generating the state Merkle tree; wherein the state Merkle tree comprises a first data item as a leaf node….” The claim is unclear and indefinite. The claims are unclear whether Applicant is attempting to claim the generation of the “first state data” by using different hashing methods, one being a one-way function on a single reference input whose output is the first state data and the second being generating the same first state data by generating a Merkle tree, and a Merkle tree with leaf nodes that uses entirely different data input(s), or whether Applicant is claiming the combination of the one-way function and the use of a Merkle tree. The claims are unclear and indefinite. Dependent claims 2-5, 7, 10-13, 21, 27, 29, 47, 49, 51, 52, and 54 are also rejected.
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.
Claim(s) 1-5, 7, 10-13, 21, 27, 29, 47, 49, 51, 52, 54, 58, and 59 are rejected under 35 U.S.C. 103 as being unpatentable over Lee (US 20230214792) (“Lee”), and further in view of Ma (US 12500760) (“Ma”).
Regarding claims 1, 58 and 59, Lee discloses generating a first state data, wherein the first state data is based on a first transaction reference to a first transaction and/or a second transaction reference to a second transaction, (¶ 34-42, 51-66, 88-94, 108-131, 331, 350, 362, 389-399, 700-710, 756-760),
Lee –The transaction has one or more token-related outputs, each of which represents a respective token issued by a Token Issuer and specifies a quantity of a) token units and b) token-related cryptocurrency associated with the respective token…an existing token can be updated, wherein the token is spent into a transaction that is signed by the signature of the at least one of the inaugural transaction, token definition transaction and the token issuance transaction, such that the authenticity of the token is refreshed. An update includes a re-mint without destruction of the token and/or its linear transaction history. …. By processing the token with a second or subsequent one of the set of transactions a recipient of the token only needs to determine the validity of the token by referring to one or more of the most recent inaugural, definition or issuance transactions. Each subsequent transaction by a token can be referred to as a child transaction, the preceding transaction referred to as a parent transaction. The parent and child transactions define, at least in part, a writechain of transactions that have output, or written, data to the ledger, such as a cryptocurrency ledger e.g. a cryptocurrency blockchain… The or each transaction in a writechain can contain a deterministic link to at least one of the root node, minting transaction and database establishment transaction or contain information, that enables such a link to be determined e.g. using a Merkle proof. (¶ 34, 35, 60, 93, 94)
wherein the first transaction reference and/or the second transaction reference are hidden from public view on the blockchain and (¶ 282, 334, 491, 525, 631, 824)
Claim Interpretation – According to the disclosure(¶ 61), “the client data is hidden from public view on the blockchain. Advantageously, hiding the data from public view on the blockchain stops malicious third parties from seeing it, thereby increasing the security of the system. Optionally, a representation of the client data is stored immutably on the blockchain.”
Lee- As minting information is not attached to, or carried forward by, the transfer transactions a user is required to verify the authenticity of a particular token by tracing its history back to the minting transaction and checking the information from there. This provides the technical advantage that authenticity and verification of source can be assured, and security of tokens improved, because if minting/issuer related information was carried forward with the token on each exchange a malicious third party could exploit that to counterfeit the token … All token transfers are conducted on-chain and so the cryptographic enforcement, consensus mechanisms and security of the blockchain network are harnessed, plus the immutable, inspectable, timestamped record of events is secured on-chain. … This also provides the advantage that tokens can be mixed, and ownership obfuscated. This can provide security benefits because a malicious party cannot identify the owner of a particular token and thus target an attack. Therefore, a transaction can be used to take token inputs from multiple users and send different tokens to the desired receivers other than the ones signed by the spending party. …However, databases which hold private information may contain encrypted data and instructions. In these cases, the database management system would be required to have knowledge of the encryption keys needed to build a valid database. During the determination of a database the management system can accept information from a writechain derived from at least one of a write token, admin token and master token. By way of example, writechains of transactions are created from a chain of addresses having a linear history that represents the token. A writechain is an unbroken chain of linked token transactions. (¶ 282, 334, 525, 824)
the first state data is based on an output of a one-way function taking the first transaction reference and/or the second transaction reference as an input (¶ 159-165, 760-764)
Claim Interpretation – According to the disclosure(¶ 45), “the first state data is based on a hash-based data structure based on the first transaction reference and/or the second transaction reference. Advantageously, a hash based data structure enables the data to be hidden (as a result of the one-way nature of the hash function)”
Lee- serial numbers may be a hash of the TX used to create the tokens e.g. the TX combined with the Vout indices used to create the tokens. …Token transactions can output data, such as script including instructions. The linear transaction history, which determines a relationship with the set of transactions that created the token, can be referred to as a writechain….The blockchain transaction includes one or more token-related outputs, each of which represents a respective token issued by a Token Issuer and specifies a quantity of token units, which represent access to the asset to be controlled, token-related cryptocurrency (TRC) associated with the respective token (T). The token transaction can also include at least one Issuer-related output comprising issuance data associated with the Token Issuer, or a proof that the token is derived from the Issuer… (¶ 162, 165, 762)
generating the current transaction comprising the first state data; and (¶ 42-58, 66-81, 92-102, 527-530),
Lee – generating a blockchain transaction (TokenTx) comprises an input which includes a token. The token can be linked in a linear transaction history on the blockchain to a token-issuing blockchain transaction. The token-issuing blockchain transaction include, or be derived from at least one Issuer-related output (I-UTXO) associated with issuance data (IData) relating to a Token Issuer (TI) that Issued the token (T), which can be part of the set of transactions that established and/or refreshed the token. (¶ 44)
submitting the current transaction to a blockchain (¶ 50, 132, 179, 248, 266, 362, 566),
Lee –submitting the blockchain transaction (MTx) to a blockchain network. (¶ 50)
wherein the first state data is a first Merkle tree root of a state Merkle tree and wherein the step of generating the first state data comprises; wherein the state Merkle tree comprises a first data item as a leaf node; wherein the first data item is based on any one or more of: data received from a client, a set of metadata about the set of transactions, a version number, and a salt. (¶ 65, 131, 258, 641-671),
Claim Interpretation- According to the disclosure (¶ 46) “Advantageously, a Merkle tree root hides the contents of the Merkle tree but allows for reconstruction of the Merkle tree for verification of its contents. Therefore, this allows those with a Merkle tree proof to verify a Merkle tree was constructed using the same data.”
Lee –each transaction in a writechain can contain a deterministic link to at least one of the root node, minting transaction and database establishment transaction or contain information, that enables such a link to be determined e.g. using a Merkle proof….The blanks can be completed using at least one of: providing an identification and a public key; a countersignature of a third party; and a Merkle proof that it is part of a Merkle tree and further providing (i) a Merkle proof that the identification is one of a Merkle tree identifications and (ii) a script that can solve the Merkle root. At least a portion of a body of the form can be a hash of its string and/or content. as an input to a transaction, such that it can be processed by script. Additionally or alternatively, the template of the body can be provided in an establishment transaction or a set-up record. The template of the body can be provided as part of the database establishment transaction…The node allocates these tokens to one or more outputs in a transaction called the ‘Coinbase’ which is the first transaction in the block's merkle tree…Checking the alias can be performed by (i) an agent which countersigns the script, or (ii) using a merkle tree of known aliases, wherein the user would supply the alias and a merkle proof that shows that it is included in a merkle tree of valid aliases, followed by script that can interpret and solve the merkle root, thereby proving the alias is a member of the tree. (¶ 94, 131, 357, 641)
Lee teaches a merkle tree but Lee does not explicitly recite generating the state Merkle tree.
Ma teaches generating the state Merkle tree (Figure 2-4; column 8, line 44-65; claim 1)
Ma - Correspondingly, in the present step, the leaf nodes of the Merkle tree data in the authorization metadata token may be disordered, that is, when the authorization metadata token is generated each time, the positions of the above pieces of information in the leaf nodes of the Merkle tree data may be different, that is, the information of each endpoint, the user information, the project information, the role information, the authorization time information and the creation time information have no fixed arrangement sequence, and the processor may generate the Merkle tree data by using, as the leaf nodes of the Merkle tree, hash values corresponding to the information of each endpoint, the user information, the project information, the role information, the authorization time information and the creation time information, respectively (column 8, line 44-65)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Lee and Ma in order to provide secure access control with the use of tokens and a merkle tree (Ma; column 1, line 16-67).
Regarding claim 2, Lee discloses wherein the first transaction reference is based on an output of the first transaction (¶ 51-55, 61, 71, 285-287, 341-345, 426-429).
Regarding claim 3, Lee discloses wherein the first transaction reference is based on a second state data of the first transaction (¶ 51-57, 79-81, 335, 362-370, 374, 500).
Regarding claim 4, Lee discloses wherein the second transaction reference is based on a reference to an input of the second transaction and/or the second transaction reference to a sender account address and a nonce (¶ 24, 51, 292, 525, 604-611).
Regarding claim 5, Lee discloses wherein the second transaction reference comprises an unspent transaction outpoint (¶ 49, 60, 278-299, 312-319, 362).
Regarding claim 7, Lee discloses wherein the first state data is of a known state size irrelevant of data the first state data is based on (¶ 331, 332, 513, 514, 631).
Regarding claim 10, Lee discloses wherein the first transaction reference and/or the second transaction reference are hidden from public view on the blockchain (¶ 312, 777-779, 858).
Regarding claim 11, Lee discloses wherein the current transaction is indistinguishable from any other transactions on the blockchain (¶ 34, 88-90, 107, 269, 334, 424).
Regarding claim 12, Lee discloses wherein the first state data is a first Merkle tree root of a state Merkle tree and wherein generating the first state data comprises generating the state Merkle tree (¶ 15, 65, 94, 95, 131, 161, 330-332, 350-357, 641-671).
Regarding claim 13, Lee discloses wherein the first state data is PUSHDATA encoded (¶ 513, 580-597).
Regarding claim 21, Lee discloses wherein the one-way function is a hashing function (¶ 131, 152, 728, 762, 813).
Regarding claim 27, Lee discloses wherein the first state data is stored on an output of the current transaction (¶ 51-55, 61, 71, 285-287, 341-345, 426-429).
Regarding claim 29, Lee discloses wherein the current transaction comprises a second data item (¶ 42-58, 66-81, 92-102).
Regarding claim 47, Lee discloses wherein the current transaction belongs to a second set of transactions and a third state data is generated based on a third transaction reference and/or a fourth transaction reference (¶ 51-55, 61, 71, 285-287, 341-345, 426-429).
Regarding claim 49, Lee discloses wherein the current transaction belongs to a second set of transactions and the first state data is further based on a third transaction reference and/or a fourth transaction reference (¶ 34-42, 51-66, 88-94, 131, 331, 350).
Regarding claim 51, Lee discloses determining the second transaction reference before the second transaction is generated (¶ 42-58, 66-81, 92-102, 527-530).
Regarding claim 52, Lee discloses wherein the first transaction reference comprises data indicative that that the current transaction is a first transaction in the set of transactions and/or the second transaction reference comprises data indicative that the current transaction is a last transaction in the set of transactions (¶ 137, 476, 510-529, 543-547, 587).
Regarding claim 54, Lee discloses wherein the first transaction reference is a null reference and/or the second transaction reference is a null reference (¶ 103-105, 137-140, 474, 503).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Paul et al., (US 20210374121).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
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, NEHA H PATEL can be reached on (571) 270-1492. 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699
Prosecution Insights