DETAILED ACTION
Continued Examination Under 37 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 XXXXXXXXXXXXXX has been entered.
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 .
Status of Claims
Claims X are canceled.
Claims X are new.
Claims 1-20 are pending, claims 12 and 13 are withdrawn, and claims 1-11 and 14-20 have been examined.
This action is in reply to the papers filed on 06/06/2024 (originally filed papers) and 03/02/2026 (claim amendment) (effective filing date 05/24/2021).
Information Disclosure Statement
The information disclosure statement(s) submitted: 06/10/2024, has/have been considered by the Examiner and made of record in the application file.
Amendment
The present Office Action is based upon the original patent application filed on 06/06/2024 as modified by the amendment filed on 03/02/2026.
Terminal Disclaimer
The terminal disclaimer filed on 03/02/2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Pat. No. 12,051,062 has been reviewed and has been placed in the file.
Double Patenting - Withdrawn
The double patenting rejection is withdrawn per the filed terminal disclaimer noted above.
Claim Objection
Regarding Claims 1, 14, and 19, Applicant should correct typographical error by amending “in which the third part was a participant” to “in which the third party was a participant”.
Claim Rejections - 35 USC §112
The following is a quotation 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.
Claims 1-11 and 14-20 (Claims 14 and 19 contain features similar to Claim 1) are rejected under 35 U.S.C. §112(a) 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 had possession of the claimed invention.
New Matter Rejection - Regarding Claims 1-11 and 14-20 (Claims 14 and 19 contain features like Claim 1), Applicant’s originally filed specification (PGPub. 2024/0320663) fails to disclose the amended claimed features as follows: wherein the verified block is also stored on the second blockchain but is not stored on the third blockchain.
Applicant is directed to address each rejected claim individually by specifically indicating support, in the originally filed specification (i.e., page, paragraph, and line), for the rejected claimed feature(s).
Reasons For Allowance
Prior-Art Rejection withdrawn
Claims xxx are allowed. The closest prior art (See PTO-892, Notice of References Cited) does not teach the claimed:
The closest prior-art (xxx) teach the features as disclosed in Non-final Rejection (xxxx), however, these cited references do not teach and the prior-art does not teach at least the following:
Claim Rejections - 35 USC §101 - Withdrawn
Per Applicant’s amendments and arguments and considering new guidance in the MPEP, the rejections are withdrawn. Specifically, in Applicant’s Remarks (dated 03/14/2017, pgs. 8-11), Applicant traverses the 35 USC §101 rejections arguing that the amended claims recite new limitations that are not abstract, amount to significantly more, are directed to a practical application, etc… For example, Applicant argues….
In support of their arguments, Applicant cites to the following recent Fed. Cir. court cases (i.e., Alice Corp. v. CLS Bank Int’l, SRI Int’l, Inc. v. Cisco Systems, Inc., Ultramercial, Inc. v. Hulu, LLC, Berkheimer, Core Wireless, McRO, Enfish, Bascom, DDR, etc…).
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-11 and 14-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more. These claims recite a method, system, and computer readable medium for blockchain secured transaction workflows.
Claim 1 recites [a] computer-implemented method comprising: receiving, by a first node of a first party to a transaction, transaction data for the transaction, the first node having a first node data store, wherein the first node data store includes a first blockchain storing information about transactions in which the first party was a participant; determining a second party to the transaction based on the transaction data; validating, by the first node, the transaction data; in response to validating the transaction data, generating a block for the transaction on the first blockchain, the block including the transaction data, a hash generated using the transaction data, and a hash of a previous block in the first blockchain of the first node data store of the first node; sending the block to a second node of the second party to the transaction without sending the block to a second node of the second party, third party not being a participant in the transaction, wherein the second node has a second node data store, the second node data store including a second blockchain storing information about transactions in which the second party was a participant, and the third node has a third node data store, the third node data store including a third blockchain storing information about transactions in which the third part was a participant; receiving, by the first node, an indication that the second node has verified the block; and storing the verified block on the first blockchain in the first node data store, wherein the verified block is also stored on the second blockchain but is not stored on the third blockchain.
The claims are being rejected according to the 2019 Revised Patent Subject Matter Eligibility Guidance (Federal Register, Vol. 84, No. 5, p. 50-57 (Jan. 7, 2019)).
Step 1: Does the Claim Fall within a Statutory Category?
Yes. Claims 1-11 recite a method and, therefore, are directed to the statutory class of a process. Claims 14-18 recite a system/apparatus and, therefore, are directed to the statutory class of machine. Claims 19-20 recite a non-transitory computer readable medium/computer product and, therefore, are directed to the statutory class of a manufacture.
Step 2A, Prong One: Is a Judicial Exception Recited?
Yes. The following tables identify the specific limitations that recite an abstract idea. The column that identifies the additional elements will be relevant to the analysis in step 2A, prong two, and step 2B.
Claim 1: Identification of Abstract Idea and Additional Elements, using Broadest Reasonable Interpretation
Claim Limitation
Abstract Idea
Additional Element
1. A computer-implemented method comprising:
No additional elements are positively claimed.
receiving, by a first node of a first party to a transaction, transaction data for the transaction, the first node having a first node data store, wherein the first node data store includes a first blockchain storing information about transactions in which the first party was a participant;
This limitation includes the step(s) of: receiving, by a first node of a first party to a transaction, transaction data for the transaction, the first node having a first node data store, wherein the first node data store includes a first blockchain storing information about transactions in which the first party was a participant.
But for the data store, this limitation is directed to communicating (e.g., receiving) and/or storing known information to facilitate blockchain secured transaction workflows which may be categorized as any of the following:
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
receiving, by a first node of a first party to a transaction, transaction data for the transaction, the first node having a first node data store, wherein the first node data store includes a first blockchain storing information about transactions …
determining a second party to the transaction based on the transaction data;
This limitation includes the step(s) of: determining a second party to the transaction based on the transaction data.
No additional elements are positively claimed.
This limitation is directed to processing known information to facilitate blockchain secured transaction workflows which may be categorized as any of the following:
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
No additional elements are positively claimed.
validating, by the first node, the transaction data;
This limitation includes the step(s) of: validating, by the first node, the transaction data.
No additional elements are positively claimed.
This limitation is directed to processing known information to facilitate blockchain secured transaction workflows which may be categorized as any of the following:
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
No additional elements are positively claimed.
in response to validating the transaction data, generating a block for the transaction on the first blockchain, the block including the transaction data, a hash generated using the transaction data, and a hash of a previous block in the first blockchain of the first node data store of the first node;
This limitation includes the step(s) of: in response to validating the transaction data, generating a block for the transaction on the first blockchain, the block including the transaction data, a hash generated using the transaction data, and a hash of a previous block in the first blockchain of the first node data store of the first node.
But for the data store, this limitation is directed to communicating (e.g., receiving) and/or storing known information to facilitate blockchain secured transaction workflows which may be categorized as any of the following:
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
in response to validating the transaction data, generating a block for the transaction on the first blockchain, the block including the transaction data, a hash generated using the transaction data, and a hash of a previous block in the first blockchain of the first node data store of the first node…
sending the block to a second node of the second party to the transaction without sending the block to a second node of the second party, third party not being a participant in the transaction, wherein the second node has a second node data store, the second node data store including a second blockchain storing information about transactions in which the second party was a participant, and the third node has a third node data store, the third node data store including a third blockchain storing information about transactions in which the third part was a participant;
This limitation includes the step(s) of: sending the block to a second node of the second party to the transaction without sending the block to a second node of the second party, third party not being a participant in the transaction, wherein the second node has a second node data store, the second node data store including a second blockchain storing information about transactions in which the second party was a participant, and the third node has a third node data store, the third node data store including a third blockchain storing information about transactions in which the third part was a participant.
But for the data store(s), this limitation is directed to communicating (e.g., receiving) and/or storing known information to facilitate blockchain secured transaction workflows which may be categorized as any of the following:
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
sending the block to a second node … the second node has a second node data store, the second node data store including a second blockchain storing information about transactions in which the second party was a participant, and the third node has a third node data store, the third node data store including a third blockchain storing information about transactions in which the third part was a participant
receiving, by the first node, an indication that the second node has verified the block; and
This limitation includes the step(s) of: receiving, by the first node, an indication that the second node has verified the block.
No additional elements are positively claimed.
This limitation is directed to receiving known information to facilitate blockchain secured transaction workflows which may be categorized as any of the following:
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
No additional elements are positively claimed.
storing the verified block on the first blockchain in the first node data store, wherein the verified block is also stored on the second blockchain but is not stored on the third blockchain.
This limitation includes the step(s) of: storing the verified block on the first blockchain in the first node data store, wherein the verified block is also stored on the second blockchain but is not stored on the third blockchain.
But for the data store, this limitation is directed to communicating (e.g., receiving) and/or storing known information to facilitate blockchain secured transaction workflows which may be categorized as any of the following:
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
storing the verified block on the first blockchain in the first node data store …
As shown above, under Step 2A, Prong One, the claims recite a judicial exception (an abstract idea). The claims are directed to the abstract idea of implementing blockchain secured transaction workflows, which, pursuant to MPEP 2106.04, is aptly categorized as a method of organizing human activity. Therefore, under Step 2A, Prong One, the claims recite a judicial exception.
The claims also recite additional technical elements including: a “data store” for implementing the method, a “non-transitory computer readable medium” for storing executable instructions and “processor” for implementing/executing the code. These limitations are recited at a high level of generality and appear to be nothing more than generic computer components. Claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp., 134 S. Ct. at 2358, 110 USPQ2d at 1983. See also 134 S. Ct. at 2389, 110 USPQ2d at 1984.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application?
No. The judicial exception is not integrated into a practical application. The additional elements listed above that relate to computing components are recited at a high level of generality (i.e., as generic components performing generic computer functions such as communicating, receiving, processing, analyzing, and outputting/displaying data) such that they amount to no more than mere instructions to apply the exception using generic computing components. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, the claims do not purport to improve the functioning of the computer itself. There is no technological problem that the claimed invention solves. Rather, the computer system is invoked merely as a tool. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, these claims are directed to an abstract idea.
Furthermore, looking at the elements individually and in combination, under Step 2A, Prong Two, the claims as a whole do not integrate the judicial exception into a practical application because they fail to: improve the functioning of a computer or a technical field, apply the judicial exception in the treatment or prophylaxis of a disease, apply the judicial exception with a particular machine, effect a transformation or reduction of a particular article to a different state or thing, or apply the judicial exception beyond generally linking the use of the judicial exception to a particular technological environment. Rather, the claims merely use a computer as a tool to perform the abstract idea(s), and/or add insignificant extra-solution activity to the judicial exception, and/or generally link the use of the judicial exception to a particular technological environment.
Step 2B: Does the Claim Provide an Inventive Concept?
Next, under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. Simply put, as noted above, there is no indication that the combination of elements improves the functioning of a computer (or any other technology), and their collective functions merely provide conventional computer implementation. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements relating to computing components amount to no more than applying the exception using a generic computing components. Mere instructions to apply an exception using a generic computing component cannot provide an inventive concept. Furthermore, the broadest reasonable interpretation of the claimed computer components (i.e., additional elements) includes any generic computing components that are capable of being programmed to communicate, receive, send, process, analyze, output, or display data. Furthermore, Applicant’s Specification (PGPub. 2024/0320663 [0108]) refers to a general computer system, but they do not include any technically-specific computer algorithm or code.
Additionally, pursuant to the requirement under Berkheimer, the following citations are provided to demonstrate that the additional elements, identified as extra-solution activity, amount to activities that are well-understood, routine, and conventional. See MPEP 2106.05(d).
Capturing an image (code) with an RFID reader. Ritter, US Patent No. 7734507 (Col. 3, Lines 56-67); “RFID: Riding on the Chip” by Pat Russo. Frozen Food Age. New York: Dec. 2003, vol. 52, Issue 5; page S22.
Receiving or transmitting data over a network. Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362; 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).
Storing and retrieving information in memory. Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.
Outputting/Presenting data to a user. Mayo, 566 U.S. at 79, 101 USPQ2d at 1968; OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1092-93 (Fed. Cir. 2015); MPEP 2106.05(g)(3).
Using a machine learning model to determine user segment characteristics for an ad campaign. https://whites.agency/blog/how-to-use-machine-learning-for-customer-segmentation/.
Thus, taken alone and in combination, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea), and are ineligible under 35 USC 101.
Independent system claim 14 and CRM claim 19 also contains the identified abstract ideas, with the additional elements of a processor and storage medium, which are a generic computer components, and thus not significantly more for the same reasons and rationale above.
Dependent claims 2-11, 15-18, and 20 further describe the abstract idea. The additional elements of the dependent claims fail to integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea. Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
As such, the claims are not patent eligible.
Invention Could be Performed Manually
It is conceivable that the invention could be performed manually without the aid of machine and/or computer. For example, Applicant claims receiving transaction data, determining parties to the transaction, validating the transaction, generating a block for the transaction, sending the block of information, verifying the block, and storing the block. Each of these features could be performed manually and/or with the aid of a simple generic computer to facilitate the transmission of data.
See also Leapfrog Enterprises, Inc. v. Fisher-Price, Inc., and In re Venner, which stand for the concept that automating manual activity and/or applying modern electronics to older mechanical devices to accomplish the same result is not sufficient to distinguish over the prior art. Here, applicant is merely claiming computers to facilitate and/or automate functions which used to be commonly performed by a human.
Leapfrog Enterprises, Inc. v. Fisher-Price, Inc., 485 F.3d 1157, 82 USPQ2d 1687 (Fed. Cir. 2007) "[a]pplying modern electronics to older mechanical devices has been commonplace in recent years…"). The combination is thus the adaptation of an old idea or invention using newer technology that is commonly available and understood in the art.
In In re Venner, 262 F.2d 91, 95, 120 USPQ 193, 194 (CCPA 1958), the court held that broadly providing an automatic or mechanical means to replace manual activity which accomplished the same result is not sufficient to distinguish over the prior art. MPEP 2144.04, III Automating a Manual Activity.
MPEP 2144.04 III - Automating a Manual Activity and In re Venner, 262 F.2d 91, 95, 120 USPQ 193, 194 (CCPA 1958) further stand for and provide motivation for using technology, hardware, computer, or server to automate a manual activity.
Therefore, the Office finds no improvements to another technology or field, no improvements to the function of the computer itself, and no meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Therefore, based on the two-part Alice Corp. analysis, there are no limitations in any of the claims that transform the exception (i.e., the abstract idea) into a patent eligible application.
Claim Rejections - Not an Ordered Combination
None of the limitations, considered as an ordered combination provide eligibility, because taken as a whole, the claims simply instruct the practitioner to implement the abstract idea with routine, conventional activity.
Claim Rejections - Preemption
Allowing the claims, as presently claimed, would preempt others from implementing blockchain secured transaction workflows. Furthermore, the claim language only recites the abstract idea of performing this method, there are no concrete steps articulating a particular way in which this idea is being implemented or describing how it is being performed.
Claim Rejections - 35 USC § 101 – software per se
Per Applicants’ amendments/arguments, the rejection(s)/objection(s) is/are withdrawn.
Claim Rejections - 35 USC § 103
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.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 14, 15, 19 are rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233.
18/736,017 – Claim 1. (Currently Amended) Yang et al. 2020/0118096 teaches A computer-implemented method comprising (Yang et al. 2020/0118096 [0025 - a system for implementing blockchain-based private transactions] According to other embodiments, a system for implementing blockchain-based private transactions comprises one or more processors and one or more non-transitory computer-readable memories coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system to perform operations. The system may be associated with a first blockchain node to a private transaction. The operations may comprise: determining one or more second blockchain nodes to the private transaction according to a blockchain contract in a public blockchain; transmitting transaction information to the one or more second blockchain nodes, the transaction information comprising one or more senders of the private transaction, one or more recipients of the private transaction, and one or more transaction amounts of the private transaction; obtaining a signature from each of a number of the one or more second blockchain nodes certifying receipt of the transaction information; and in response to obtaining the number of the signatures over a threshold, storing at least a representation of the private transaction and the signatures in the public blockchain.): receiving, by a first node of a first party to a transaction (Yang et al. 2020/0118096 [0055] The proposer node may represent a first blockchain node. The first blockchain node may belong to a first party (private transaction first party). The first party is one of the parties that is aware of the transaction information, which may include information of the sender (e.g., sender account address), receiver (e.g., receiver account address), and transaction amount. The first party can be a party that initiates the private transaction, a sender or receiver party to the private transaction, etc. Private transactions may need to hide one or more elements of the transaction information from non-participating parties. The first party may use an account that can be accessed from a device (e.g., mobile phone, computer) to order the private transaction. The device may constitute a lightweight node or a full node. [0068] In some embodiments, the method 510 is performed by first blockchain node (e.g., a blockchain node of a first party) to a private transaction. The first blockchain node may correspond to the proposer node described above. The first party may be a party that initiates the transaction, a sender or receiver party to the transaction, etc. The private transaction also involves one or more second blockchain nodes (e.g., blockchain nodes of second parties). In some embodiments, the private transaction may involve only the first and second blockchain nodes. When a step is described as performed by the first or second party, a person of ordinary skill in the art will understand that the step may be performed by a blockchain node associated with the corresponding party. The first party and the second party may belong to the same entity or different entities. The first and the second blockchain nodes may belong to the same party or different parties. In some embodiments, the party may be a sender and/or a receiver (of an asset, a token, etc.) to the private transaction. That is, for the private transaction, a party may send something to and/or receive something from another party to the private transaction. Notwithstanding, a party may be an observer and does not send and/or receive anything from the private transaction.), transaction data for the transaction (Yang et al. 2020/0118096 [0049] In some embodiments, a blockchain contract may start with its construction in source code. For example, a user A may program a blockchain contract in source code and input the source code to an interface of a user-end application 211. In this figure, the user-end application 211 is installed in Node A. To deploy the blockchain contract, Node A may compile the blockchain contract source code using a corresponding compiler, which converts the source code into bytecode. After receiving the bytecode, the user-end application may generate a blockchain transaction A including the bytecode and submit the blockchain transaction A to one or more of the blockchain nodes. For example, the blockchain transaction A may comprise information such as nonce (e.g., transaction serial number), from (e.g., an address of user A's account), to (e.g., empty if deploying a blockchain contract), GasLimit (e.g., an upper limit of transaction fee consumed for the transaction), GasPrice (e.g., a transaction fee offered by the sender), value (e.g., transaction amount), data (e.g., the bytecode), etc. Node A may sign the blockchain transaction A with various encryption methods to represent endorsement by Node A. Node A may send the blockchain transaction A to a blockchain node (e.g., Node 1) through a remote procedure call (RPC) interface 213. RPC is a protocol that a first program (e.g., user-end application) can use to request a service from a second program located in another computer on a network (e.g., blockchain node) without having to understand the network's details. When the first program causes a procedure to execute in a different address space (e.g., on Node 1), it is as if a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction.), the first node having a first node data store, wherein the first node data store includes a first blockchain storing information (Yang et al. 2020/0118096 [0025] According to other embodiments, a system for implementing blockchain-based private transactions comprises one or more processors and one or more non-transitory computer-readable memories coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system to perform operations. The system may be associated with a first blockchain node to a private transaction. The operations may comprise: determining one or more second blockchain nodes to the private transaction according to a blockchain contract in a public blockchain; transmitting transaction information to the one or more second blockchain nodes, the transaction information comprising one or more senders of the private transaction, one or more recipients of the private transaction, and one or more transaction amounts of the private transaction; obtaining a signature from each of a number of the one or more second blockchain nodes certifying receipt of the transaction information; and in response to obtaining the number of the signatures over a threshold, storing at least a representation of the private transaction and the signatures in the public blockchain. [0026] According to yet other embodiments, a non-transitory computer-readable storage medium for implementing blockchain-based private transactions, the storage medium configured with instructions executable by one or more processors to cause the one or more processors to perform operations. The storage medium may be associated with a first blockchain node to a private transaction. The operations may comprise: determining one or more second blockchain nodes to the private transaction according to a blockchain contract in a public blockchain; transmitting transaction information to the one or more second blockchain nodes, the transaction information comprising one or more senders of the private transaction, one or more recipients of the private transaction, and one or more transaction amounts of the private transaction; obtaining a signature from each of a number of the one or more second blockchain nodes certifying receipt of the transaction information; and in response to obtaining the number of the signatures over a threshold, storing at least a representation of the private transaction and the signatures in the public blockchain. [0027] According to still other embodiments, an apparatus for implementing blockchain-based private transactions may be associated with a first blockchain node to a private transaction and may comprise: a determining module for determining one or more second blockchain nodes to the private transaction according to a blockchain contract in a public blockchain; a transmitting module for transmitting transaction information to the one or more second blockchain nodes, the transaction information comprising one or more senders of the private transaction, one or more recipients of the private transaction, and one or more transaction amounts of the private transaction; an obtaining module for obtaining a signature from each of a number of the one or more second blockchain nodes certifying receipt of the transaction information; and a storing module for, in response to obtaining the number of the signatures over a threshold, storing at least a representation of the private transaction and the signatures in the public blockchain.) about transactions in which the first party was a participant (Yang et al. 2020/0118096 [0055 - The first blockchain node may belong to a first party (private transaction first party)] The proposer node may represent a first blockchain node. The first blockchain node may belong to a first party (private transaction first party). The first party is one of the parties that is aware of the transaction information, which may include information of the sender (e.g., sender account address), receiver (e.g., receiver account address), and transaction amount. The first party can be a party that initiates the private transaction, a sender or receiver party to the private transaction, etc. Private transactions may need to hide one or more elements of the transaction information from non-participating parties. The first party may use an account that can be accessed from a device (e.g., mobile phone, computer) to order the private transaction. The device may constitute a lightweight node or a full node. [0054] Various entities relevant to the method and shown in the top blocks in FIG. 3 and FIG. 4 are first introduced. In some embodiments, a private transaction may involve a number of parties. Each party to a private transaction may have one or more corresponding blockchain nodes to implement the private transaction. For example, one party may transfer a payment to one or more other parties. A party may be, but is not limited, a person, an entity, an account, or the like. The private transaction may involve one or more proposer nodes and one or more member nodes. The proposer and member nodes may be blockchain nodes. [0056] The member node may represent a second blockchain node. The second blockchain node may belong to a second party (private transaction second party). The second part(ies) shown may represent a portion or all of the parties to the private transaction other than the first party.); determining a second party to the transaction based on the transaction data (Yang et al. 2020/0118096 [0056 - The second blockchain node may belong to a second party (private transaction second party)] The member node may represent a second blockchain node. The second blockchain node may belong to a second party (private transaction second party). The second part(ies) shown may represent a portion or all of the parties to the private transaction other than the first party. [0071 - blockchain nodes of the second parties] Block 511 includes determining one or more second blockchain nodes to the private transaction according to a blockchain contract in a public blockchain. In one embodiment, the blockchain contract comprises an address of each of the first and second blockchain nodes to the private transaction; and determining the one or more second blockchain nodes to the private transaction (e.g., blockchain nodes of other parties to the private transaction, such as blockchain nodes of the second parties) according to the blockchain contract in the public blockchain comprises: determining the one or more second blockchain nodes to the private transaction according to the address of each of the one or more second blockchain nodes to the private transaction. For example, each party to the private transaction may be associated with a blockchain node, and the blockchain node's address may be used to identify the corresponding party. As described above, a blockchain node to the private transaction or its associated party to the private transaction may refer to a blockchain node or party directly involved in the private transaction as a sender or recipient, or indirectly involved in the private transaction only as a verifier. The verifier may verify the private blockchain. The sender may be a sender who does not verify the private transaction or a sender-verifier who also verifies the private transaction. The recipient may be a recipient who does not verify the private transaction or a recipient-verifier who also verifies the private transaction. A blockchain node or party indirectly involved in the private transaction only as a verifier may not simultaneously be a sender or receiver. In some embodiments, the blockchain contract comprises an address of each of all blockchain nodes to the private transaction. In one example, the private transaction involves only a first blockchain node and one or more second blockchain nodes. The first blockchain node may initiate a financial transaction to the one or more second blockchain nodes.); validating, by the first node, the transaction data (Yang et al. 2020/0118096 [0003] Blockchain provides data storage in a decentralized fashion, by keeping the data in a series of data blocks having precedence relationship between each other. The chain of blocks is maintained and updated by a network of nodes, which are also responsible for validating the data. The stored data may involve transactions among various parties, and the blockchain storing the data may be also referred to as a shared ledger that keeps track of these transactions.); in response to validating the transaction data (Yang et al. 2020/0118096 [0036] FIG. 1 shows an example of a blockchain network 100, in accordance with some embodiments. As shown, the blockchain network 100 may comprise one or more client devices (e.g., Node A, Node B, etc.) coupled to a blockchain system 112. The client devices may include lightweight nodes. A lightweight node may not download the complete blockchain, but may instead just download the block headers to validate the authenticity of the blockchain transactions. Lightweight nodes may be served by and effectively dependent on full nodes (e.g., those in the blockchain system 112) to access more functions of the blockchain. The lightweight nodes may be implemented in electronic devices such as laptops, mobile phones, and the like by installing an appropriate software. [0065] At step 324, the proposer node may, in response to obtaining the number of the signatures over a threshold, storing in the public blockchain at least a representation of the private transaction, the signatures, and the identification of the group comprising the each blockchain node to the private transaction. The threshold can be a pre-configured value, such as 50% or all participating blockchain nodes. The threshold can be increased to improve the level of safety by requiring more participating blockchain nodes to the private transaction to confirm the transaction information. In one embodiment, the proposer node may broadcast a third transaction comprising the transaction hash of the private transaction and the signatures in the public blockchain network for packing into the public blockchain. For example, the proposer node may concatenate the transaction hash and the signatures to add to the third transaction. In one embodiment, the private transaction cannot be packed into the public blockchain until the threshold condition is satisfied. At step 325a and step 325b, through consensus verification, the blockchain nodes of the public blockchain may pack the private transaction into a new block of the public transaction. The proposer node and the member nodes, as a part the blockchain nodes of the public blockchain, may also see the new block. At step 326, the user receives a receipt for the successful execution of the private transaction.), generating a block for the transaction on the first blockchain, the block including the transaction data (Yang et al. 2020/0118096 [0050; 0052; 0065]), a hash generated using the transaction data (Yang et al. 2020/0118096 [0065; 0076]), and a hash of a previous block in the first blockchain of the first node data store of the first node (Yang et al. 2020/0118096 [0047] In some embodiments, the blockchain system 112 comprises blockchain nodes maintaining a public blockchain. In one embodiment, a public transaction submitted to the blockchain system 112 for adding to the public blockchain is visible to all blockchain nodes for verification and execution. In another embodiment, a private transaction may only involve a number of the blockchain nodes representing the parties to the private transaction. For such private transaction, though a representation of the private transaction may still be submitted like the public transaction for adding to the public blockchain, transaction information of the private transaction may be kept away from non-participating parties and their blockchain nodes. In that case, the transaction information of the private transaction may be transmitted among a limited number of blockchain nodes (e.g., blockchain nodes of the parties to the private transaction). That is, unlike public transactions, a private transaction may keep at least a portion of its transaction information (e.g., the sender, receiver, and transaction information) known to parties of the transactions for these parties' corresponding blockchain nodes to verify and execute, without broadcasting to non-participating parties. The public blockchain as visible to all blockchain nodes may record a proof of the private transaction such as a transaction hash of the private transaction and an encryption of the transaction information, but not explicitly storing at least the portion of the transaction information. The transaction hash is a hash value which may be the numeric result of applying a hash algorithm to the data of the transactions (e.g., transaction information). For example, a transaction hash of a private transaction between Node 1 and Node 2 may be recorded to a public blockchain and visible to Node 1, Node 2, Node 3, Node 4, and so on, while transaction information of the private transaction may be only known to Node 1 and Node 2. To that end, Node 1 and Node 2 may communicate off the blockchain and keep the transaction information of the private transaction private, or communicate on the blockchain but only allow visibility to certain nodes (e.g., through public-private key encryption).); sending the block to a second node of the second party to the transaction (Yang et al. 2020/0118096 [0060] In some embodiments with respect to blockchain contract calling, at step 315, the administrator may transmit one or more second transactions for invoking the deployed blockchain contract to the proposer node. The second transaction may be for adding data (e.g., the identification of a group comprising each proposer or member node (associated with the corresponding party) to the private transaction, the public keys of the group members, and/or the addresses of the group members) to the deployed blockchain contract. Each second transaction may add information of the proposer and member nodes (associated with the corresponding parties) to the private transaction. Thus, a private transaction conducted among a group and stored to the public blockchain may show the corresponding identification of the group (see step 324, 325a, and 325b below), so that the group members (e.g., the proposer and member nodes associated with the parties to the private transaction) will be notified to obtain transaction information of the private transaction and execute the private transaction. The public keys and addresses will be publicly available for facilitating communications among the proposer and member nodes to the private transaction as described below. At step 316, the proposer node may broadcast each of the second transactions in the public blockchain network for invoking the blockchain contract in the public blockchain to add the data. At step 317, through consensus verification, the blockchain nodes of the public blockchain successfully add the data to the deployed blockchain contract, for example, with the creation of a new block to the public blockchain. Details of the blockchain contract calling can be referred to FIG. 1 and FIG. 2 described above. At step 318, the administrator receives a receipt for the successful addition.) without sending the block to a second node of the second party, third party not being a participant in the transaction (Yang et al. 2020/0118096 [0005 - non-participating parties] Private transactions on the other hand need to hide one or more elements from non-participating parties. One existing proposal for offering privacy protection is the Quorum private transaction. In a private transaction among an initiating party and one or more participating parties, for each participating party, the sender party needs to encrypt the transaction with a symmetric key, encrypt the symmetric key with a public key of the participating party, send both encryptions to the participating party. The initiating party and participating parties conduct the private transaction through their corresponding blockchain nodes. Then, the hash of the transaction may be consensus-verified by the blockchain nodes and packed into the blockchain. [0047 - unlike public transactions, a private transaction may keep at least a portion of its transaction information (e.g., the sender, receiver, and transaction information) known to parties of the transactions for these parties' corresponding blockchain nodes to verify and execute, without broadcasting to non-participating parties.] In some embodiments, the blockchain system 112 comprises blockchain nodes maintaining a public blockchain. In one embodiment, a public transaction submitted to the blockchain system 112 for adding to the public blockchain is visible to all blockchain nodes for verification and execution. In another embodiment, a private transaction may only involve a number of the blockchain nodes representing the parties to the private transaction. For such private transaction, though a representation of the private transaction may still be submitted like the public transaction for adding to the public blockchain, transaction information of the private transaction may be kept away from non-participating parties and their blockchain nodes. In that case, the transaction information of the private transaction may be transmitted among a limited number of blockchain nodes (e.g., blockchain nodes of the parties to the private transaction). That is, unlike public transactions, a private transaction may keep at least a portion of its transaction information (e.g., the sender, receiver, and transaction information) known to parties of the transactions for these parties' corresponding blockchain nodes to verify and execute, without broadcasting to non-participating parties. The public blockchain as visible to all blockchain nodes may record a proof of the private transaction such as a transaction hash of the private transaction and an encryption of the transaction information, but not explicitly storing at least the portion of the transaction information. The transaction hash is a hash value which may be the numeric result of applying a hash algorithm to the data of the transactions (e.g., transaction information). For example, a transaction hash of a private transaction between Node 1 and Node 2 may be recorded to a public blockchain and visible to Node 1, Node 2, Node 3, Node 4, and so on, while transaction information of the private transaction may be only known to Node 1 and Node 2. To that end, Node 1 and Node 2 may communicate off the blockchain and keep the transaction information of the private transaction private, or communicate on the blockchain but only allow visibility to certain nodes (e.g., through public-private key encryption).), wherein the second node has a second node data store, the second node data store including a second blockchain storing information about transactions in which the second party was a participant (Yang et al. 2020/0118096 [0040] In one embodiment, the submitted blockchain transaction may comprise a financial transaction between various parties. In another embodiment, the submitted blockchain transaction may comprise a data update event that updates the data store. For example, the submitted blockchain transaction may comprise a blockchain contract (e.g., smart contract) for deployment on the blockchain. For another example, the submitted blockchain transaction may comprise a request to invoke a deployed blockchain contract. In this specification, the term “blockchain transaction” may be implemented via a blockchain system and recorded to the blockchain. The blockchain transaction may include, for example, a financial transaction, a blockchain contract transaction for deploying or invoking a blockchain contract, a blockchain transaction that updates a state (e.g., world state) of the blockchain, etc. The blockchain transaction does not have to involve a financial exchange. The financial transaction may be blockchain-based and may be a private or public transaction. Thus, private transactions, public transactions, and related terms (such as transaction amounts, transaction information, etc.) may refer to corresponding financial transactions. [0069] In some embodiments, some steps may be performed before the step in block 511 for deploying a blockchain contract in a public blockchain and adding information of the various blockchain nodes (associated with various parties) to the private transaction. In one embodiment, before determining the one or more second blockchain nodes to the private transaction according to the blockchain contract in the public blockchain (block 511), the method further comprises: storing blockchain node information in the public blockchain, the blockchain node information comprising a public key associated with each of the first and second blockchain nodes (e.g., a public key of each party) to the private transaction and an address of each of the first and second blockchain nodes (e.g., an address of the each party). [0077] Block 514 includes, in response to obtaining the number of the signatures over a threshold, storing at least a representation of the private transaction and the signatures in the public blockchain. The threshold can be a preconfigured value, such as 50% of participating parties, 80% participating parties, or all participating parties. In other embodiments, in response to obtaining the number of the signatures over a threshold, storing at least the representation of the private transaction and the signatures in the public blockchain comprises: in response to respectively obtaining signatures of all of the second blockchain nodes (e.g., blockchain nodes of all of the second parties) to the private transaction, storing at least the representation of the private transaction and the signatures in the public blockchain.), and the third node has a third node data store, the third node data store including a third blockchain storing information about transactions in which the third part was a participant (Yang et al. 2020/0118096 [0065 – third transaction][0071] Block 511 includes determining one or more second blockchain nodes to the private transaction according to a blockchain contract in a public blockchain. In one embodiment, the blockchain contract comprises an address of each of the first and second blockchain nodes to the private transaction; and determining the one or more second blockchain nodes to the private transaction (e.g., blockchain nodes of other parties to the private transaction, such as blockchain nodes of the second parties) according to the blockchain contract in the public blockchain comprises: determining the one or more second blockchain nodes to the private transaction according to the address of each of the one or more second blockchain nodes to the private transaction. For example, each party to the private transaction may be associated with a blockchain node, and the blockchain node's address may be used to identify the corresponding party. As described above, a blockchain node to the private transaction or its associated party to the private transaction may refer to a blockchain node or party directly involved in the private transaction as a sender or recipient, or indirectly involved in the private transaction only as a verifier. The verifier may verify the private blockchain. The sender may be a sender who does not verify the private transaction or a sender-verifier who also verifies the private transaction. The recipient may be a recipient who does not verify the private transaction or a recipient-verifier who also verifies the private transaction. A blockchain node or party indirectly involved in the private transaction only as a verifier may not simultaneously be a sender or receiver. In some embodiments, the blockchain contract comprises an address of each of all blockchain nodes to the private transaction. In one example, the private transaction involves only a first blockchain node and one or more second blockchain nodes. The first blockchain node may initiate a financial transaction to the one or more second blockchain nodes. [0074] Block 512 includes transmitting transaction information to the one or more second blockchain nodes, the transaction information comprising one or more senders of the private transaction, one or more recipients of the private transaction, and one or more transaction amounts of the private transaction. In some embodiments, the blockchain contract further comprises a public key associated with each of the first and second blockchain nodes (e.g., a public key of the each first or party) to the private transaction; and transmitting the transaction information to the one or more second blockchain nodes comprises: for each of the one or more second blockchain nodes, encrypting the transaction information with the corresponding public key; and transmitting the encrypted transaction information to each of the one or more second blockchain nodes according to the address of each of the one or more second blockchain nodes. By encrypting the transaction information with the recipient's public key, only the recipient can decrypt the encryption with its private key, as long as it keeps the private key as a secret. [0078 - first, second, and third blockchain transactions may be transmitted to the same or different blockchain nodes of the public blockchain] In some embodiments, storing at least the representation of the private transaction and the signatures in the public blockchain comprises: transmitting a third blockchain transaction comprising a transaction hash of the private transaction and the signatures to one or more blockchain nodes of the public blockchain for packing into the public blockchain, wherein the transaction hash is a hash value of at least the transaction information. The first, second, and third blockchain transactions may be transmitted to the same or different blockchain nodes of the public blockchain.); receiving, by the first node, an indication that the second node has verified the block (Yang et al. 2020/0118096 [0043; 0050; 0052][0050] On receiving the blockchain transaction A, as described earlier, Node 1 may verify if the blockchain transaction A is valid. For example, the signature of Node A and other formats may be verified. If the verification succeeds, Node 1 may broadcast the blockchain transaction A to the blockchain network including various other blockchain nodes. Some blockchain nodes may participate in the mining process of the blockchain transactions. The blockchain transaction A may be picked by a certain node for consensus verification to pack into a new block. The certain node may create a contract account for the blockchain contract in association with a contract account address. The certain node may trigger its local VM to execute the blockchain contract, thereby deploying the blockchain contract to its local copy of the blockchain and updating the account states in the blockchain. If the certain node succeeds in mining the new block, the certain node may broadcast the new block to other blockchain nodes. The other blockchain nodes may verify the new block as mined by the certain blockchain node. If consensus is reached, the blockchain transaction A is respectively packed to the local copies of the blockchain maintained by the blockchain nodes. The blockchain nodes may similarly trigger their local VMs (e.g., local VM 1, local VM i, local VM 2) to execute the blockchain contract, thus invoking the blockchain contract deployed on the local copies of the blockchain (e.g., local blockchain copy 1, local blockchain copy i, local blockchain copy 2) and making corresponding updates. The hardware machine of each blockchain node may have access to one or more virtual machines, which may be a part of or couple to the corresponding blockchain node. Each time, a corresponding local VM may be triggered to execute the blockchain contract in the blockchain transaction A. Likewise, all other blockchain transactions in the new block will be executed. Lightweight nodes may also synchronize to the updated blockchain. [0052] On receiving the blockchain transaction B, Node 2 may verify if the blockchain transaction B is valid. For example, the signature of Node B and other formats may be verified. If the verification succeeds, Node 2 may broadcast the blockchain transaction B to the blockchain network including various other blockchain nodes. The blockchain transaction B sent by Node B may be picked by a certain node for consensus verification to pack into a new block. The certain node may trigger its local VM to execute the blockchain contract, thereby invoking the blockchain contract deployed on its local copy of the blockchain and updating the account states in the blockchain. If the certain node succeeds in mining the new block, the certain node may broadcast the new block to other blockchain nodes. The other blockchain nodes may verify the new block as mined by the certain blockchain node. If consensus is reached, the blockchain transaction B is respectively packed to the local copies of the blockchain maintained by the blockchain nodes. The blockchain nodes may similarly trigger their local VMs to execute the blockchain contract, thus invoking the blockchain contract deployed on the local copies of the blockchain and making corresponding updates. The hardware machine of each blockchain node may have access to one or more virtual machines, which may be a part of or couple to the corresponding blockchain node. Each time, a corresponding local VM may be triggered to execute the blockchain contract in the blockchain transaction B. Likewise, all other blockchain transactions in the new block will be executed. Lightweight nodes may also synchronize to the updated blockchain.); and storing the verified block on the first blockchain in the first node data store (Yang et al. 2020/0118096 [0042] The blockchain may be maintained by the blockchain nodes each comprising or coupling to a memory. In some embodiments, the memory may store a pool database. The pool database may be accessible to the plurality of blockchain nodes in a distributed manner. For example, the pool database may be respectively stored in the memories of the blockchain nodes. The pool database may store a plurality of blockchain transactions submitted by the one or more client devices similar to Node A. [0043] In some embodiments, after receiving a blockchain transaction request of an unconfirmed blockchain transaction, the recipient blockchain node may perform some preliminary verification of the blockchain transaction. For example, Node 1 may perform the preliminary verification after receiving the blockchain transaction from Node A. Once verified, the blockchain transaction may be stored in the pool database of the recipient blockchain node (e.g., Node 1), which may also forward the blockchain transaction to one or more other blockchain nodes (e.g., Node 3, Node 4). The one or more other blockchain nodes may repeat the process done by the recipient node.), wherein the verified block is also stored on the second blockchain but is not stored on the third blockchain (Yang et al. 2020/0118096 [0043; 0070; 0079]).
Yang et al. 2020/0118096 may not expressly disclose the following, however, Jang et al. 2019/0179801 teaches generating a block for the transaction on the first blockchain, the block including the transaction data, a hash generated using the transaction data, and a hash of a previous block in the first blockchain of the first node data store of the first node (Jang et al. 2019/0179801 [0007] According to a first aspect of the present invention, there is provided a file management/search system for managing/searching for a data or a file stored in a plurality of nodes by utilizing a block chain, wherein each of the nodes includes: a block chain configured so that blocks including a hash value and a nonce value of a current block, a hash value and a time stamp of a previous block are linked; an IP list that stores IP addresses and port numbers for all the nodes having the block chain; a transaction transmission module that generates a transaction including information on a data, owner information, and a digital signature information when the data or the file is stored or deleted in or from a preset folder and transmits the generated transaction to other nodes having the block chain; and a block chain execution module that, when the transaction is received from another node having the block chain and the block for the received transaction is first generated, transmits a block hash value and a nonce value to other nodes, and when a block hash value and a nonce value are received from another node, generates a block by using received information and links the block to the block chain, wherein each block of the block chain is generated for each data or file stored in a plurality of the nodes, and the block hash value of each block is a hash value generated by applying a preset hash algorithm to information on the data, information on an owner of the data, and the nonce value, wherein the information on the data in the transaction includes a data name, and wherein the information on the owner of the data in the transaction includes the IP address and the port number of the node in which the data is stored. [0012] According to a second aspect of the present invention, there is provided a file management/search method in each node for managing/searching for a data stored in a plurality of nodes by utilizing a block chain, including steps of: (a) storing a block chain of blocks, the block chain including a hash value and a nonce value of a current block, a hash value and a time stamp of a previous block; (b) configuring an IP list storing IP addresses and port numbers for all the nodes having the block chain; (c) generating a transaction including information on the data, owner information, and a digital signature information when the data or the file is stored or deleted in or from a preset folder and transmitting the generated transaction to other nodes having the block chain; and (d) when the transaction is received from other nodes having the block chain, generating a block for the received transaction and linking the block to the block chain; wherein each block of the block chain is generated for each data or file stored in a plurality of the nodes, and the block hash value of each block is a hash value generated by applying a preset hash algorithm to information on the data, information on an owner of the data, and the nonce value, wherein the information on the data in the transaction includes a data name, and wherein the information on the owner of the data in the transaction includes the IP address and the port number of the node in which the data is stored.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Jang et al. 2019/0179801. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Yang et al. 2020/0118096 may not expressly disclose the “not stored on the … blockchain” features, however, Alt et al. 2021/0166233 teaches these features as follows (not stored on the blockchain [0080; 0082; 0084]). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Alt et al. 2021/0166233. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
18/736,017 – Claim 14. (Currently Amended) Yang et al. 2020/0118096 further teaches A system, comprising: a blockchain system including a plurality of nodes (Yang et al. 2020/0118096 [0037 - blockchain system may comprise a plurality of blockchain nodes (e.g., Node 1, Node 2, Node 3, Node 4, Node i, etc.)] The blockchain system 112 may comprise a plurality of blockchain nodes (e.g., Node 1, Node 2, Node 3, Node 4, Node i, etc.), which may include full nodes. Full nodes may download every block and blockchain transaction and check them against the blockchain's consensus rules. The blockchain nodes may form a network (e.g., peer-to-peer network) with one blockchain node communicating with another. The order and the number of the blockchain nodes as shown are merely examples and for the simplicity of illustration. The blockchain nodes may be implemented in servers, computers, etc. For example, the blockchain nodes may be implemented in a cluster of servers. The cluster of servers may employ load balancing. Each blockchain node may correspond to one or more physical hardware devices or virtual devices coupled together via various types of communication methods such as TCP/IP. Depending on the classifications, the blockchain nodes may also be referred to as full nodes, Geth nodes, consensus nodes, etc.), each node being a computing device comprising a processor and a memory (Yang et al. 2020/0118096 [0038; 0067; 0080]), the plurality of nodes including a first node of a first party to a transaction (Yang et al. 2020/0118096 [0055; 0068; 0069; 0071; 0074]), the first node configured to: … receive transaction data for the transaction, the first node having a first node data store, wherein the first node data store includes a first blockchain in the first node’s memory storing information about transactions in which the first party was a participant (Yang et al. 2020/0118096 [0025]); … determine a second party to the transaction based on the transaction data; validate the transaction data; in response to the transaction data being validated (Yang et al. 2020/0118096 [0003; 0036]), … generate a block for the transaction on the first blockchain, the block including the transaction data, a hash generated using the transaction data, and a hash of a previous block in the first blockchain of the first node data store of the first node; send the block to a second node of the second party to the transaction without sending the block to a third node of a third party not being a participant in the transaction, wherein the second node has a second node data store, the second node data store including a second blockchain in the second node’s memory (Yang et al. 2020/0118096 [0025]) … storing information about transactions in which the second party was a participant, and the third node has a third node data store, the third node data store including a third blockchain storing information about transactions in which the third part was a participant; receive an indication that the second node has verified the block; and store the verified block on the first blockchain in the first node data store, wherein the verified block is also stored on the second blockchain but is not stored on the third blockchain.
The remaining features/limitations of Claims 14, have similar features/limitations as of Claim 1, therefore those features/limitations and the claims are REJECTED under the same rationale as Claim 1.
18/736,017 – Claim 19. (Currently Amended) Yang et al. 2020/0118096 further teaches A non-transitory computer readable medium comprising stored program code (Yang et al. 2020/0118096 [0008; 0024; 0026]), the program code when executed by one or more processors (Yang et al. 2020/0118096 [0038; 0088-0089]) of a first node of a blockchain system causing the first node to perform operations including (Yang et al. 2020/0118096 [0025]): … receiving, by a first node of a first party to a transaction, transaction data for the transaction, the first node having a first node data store, wherein the first node data store includes a first blockchain storing information about transactions in which the first party was a participant; determining a second party to the transaction based on the transaction data; validating, by the first node, the transaction data; in response to validating the transaction data, generating a block for the transaction on the first blockchain, the block including the transaction data, a hash generated using the transaction data, and a hash of a previous block in the first blockchain of the first node data store of the first node; sending the block to a second node of the second party to the transaction without sending the block to a third node of a third party, the third party not being a participant in the transaction, wherein the second node has a second node data store, the second node data store including a second blockchain storing information about transactions in which the second party was a participant, and the third node has a third node data store, the third node data store including a third blockchain storing information about transactions in which the third part was a participant; receiving, by the first node, an indication that the second node has verified the block; and storing the verified block on the first blockchain in the first node data store, wherein the verified block is also stored on the second blockchain but is not stored on the third blockchain.
The remaining features/limitations of Claims 19, have similar features/limitations as of Claim 1, therefore those features/limitations and the claims are REJECTED under the same rationale as Claim 1.
18/736,017 – Claim 2. (Original) The computer-implemented method of claim 1, Yang et al. 2020/0118096 may not expressly disclose the following, however, Jang et al. 2019/0179801 teaches further comprising enabling, by the first node and after receiving the indication that the second node has verified the block, execution of the transaction by one or more servers (Jang et al. 2019/0179801 [0010] In the file management/search system according to the first aspect, it is preferable that the block chain execution module executes proof of work on the information of the received transaction to generate the block hash value and the nonce value, and transmits the generated block hash value and the generated nonce value to other nodes when the transaction is received from another node, and verifies validity of the received transaction by using the received block hash value and the received nonce value when the block hash value and the nonce value are received from another node, and generates the block when the validity is verified, and links the generated block to the block chain. [0015] In the file management/search method according to the second aspect, it is preferable that the step (d) includes: when the transaction is received from another node, executing proof of work on the information of the received transaction to generate the block hash value and the nonce value, and when the block hash value and the nonce value are first generated among all the nodes, generating the block by using the block hash value and the nonce value, and transmitting the generated block hash value and the generated nonce value to other nodes; and when the block hash value and the nonce value are received from another node, verifying validity of the received transaction by using the received block hash value and the received nonce value and generating the block when the validity is verified; and linking the generatedblock to the block chain. [0048] When the block hash value and the nonce value are received from the proof-of-work succeeding node, the block chain execution module verifies the validity of the transaction, the received block hash value, and the received nonce value by using the validity verification algorithm. After that, when the verification of validity is completed, the block chain execution module generates an additional block by using the received block hash value and the received nonce value and links the additional block to the block chain. [Claim 6] 6. The file management/search system according to claim 1, wherein the block chain execution module executes proof of work on the information of the received transaction to generate the block hash value and the nonce value, and transmits the generated block hash value and the generated nonce value to other nodes when the transaction is received from another node, and verifies validity of the received transaction by using the received block hash value and the received nonce value when the block hash value and the nonce value are received from another node, and generates the block when the validity is verified, and links the generated block to the block chain.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Jang et al. 2019/0179801. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
18/736,017 – Claim 15. The system of claim 14, further comprising one or more servers, and wherein the first node is further configured to, after receiving the indication that the second node has verified the block, enable execution of the transaction by the one or more servers.
Claim 15, has similar limitations as of Claim 2, therefore it is REJECTED under the same rationale as Claim 2.
Claim 3 rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Balinsky et al. 2022/0083936.
18/736,017 – Claim 3. (Original) Yang et al. 2020/0118096 further teaches The computer-implemented method of claim 2, wherein: enabling execution of the transaction by the one or more servers comprises providing the transaction data to a workflow engine that executes on the one or more servers (Yang et al. 2020/0118096 [0045] A certain blockchain node that successfully verifies its batch of blockchain transactions in accordance with consensus rules may pack the blockchain transactions into its local copy of the blockchain and multicast the results to other blockchain nodes. The certain blockchain node may be a blockchain node that has first successfully completed the verification, that has obtained the verification privilege, or that has been determined based on another consensus rule, etc. Then, the other blockchain nodes may execute the blockchain transactions locally, verify the execution results with one another (e.g., by performing hash calculations), and synchronize their copies of the blockchain with that of the certain blockchain node. By updating their local copies of the blockchain, the other blockchain nodes may similarly write such information in the blockchain transaction into respective local memories. As such, the blockchain contract can be deployed on the blockchain. If the verification fails at some point, the blockchain transaction is rejected. [0062] Referring to FIG. 4, though the figure shows the proposer node initiating the private transaction, the private transaction may be initiated by any blockchain node to the private transaction. In some embodiments, at step 321, the user may send to the proposer node a private transaction (e.g., transaction information) to be conducted by the group members. In one embodiment, the private transaction received by the proposer node may comprise the identification of the group for executing the private transaction. In another embodiment, the proposer node may identify the group for executing the private transaction from a plurality of groups whose group identifications are available from the blockchain. The private transaction to be executed by a particular group is kept private from members of other groups (except for overlapping members). The proposer node may choose a group comprising the sender(s) and/or recipient(s) to the private transaction to execute the private transaction. In one example, the proposer node is involved in three different groups: group 1 including itself and nodes M and N, group 2 including itself and nodes M, N, and P, and group 3 including itself and nodes M and P. For a private transaction among the proposer node and nodes M and N, the proposer node may choose group 1 if it wants to minimize the number of participants, or may choose group 2 if it does not mind having node P to know about the private transaction or needs node P to be a verifier (described below). The proposer node may not choose group 3 because it does not comprise node N. If there is no appropriate group available according to the blockchain, the proposer node may create a group for executing the private transaction as described above.); and the computer-implemented method further comprises:
Yang et al. 2020/0118096 may not expressly disclose the following, however, Balinsky et al. 2022/0083936 teaches generating tasks of the transaction that are executable by a plurality of workflow workers that execute on the one or more servers; and executing the tasks by the plurality of workflow workers (Balinsky et al. 2022/0083936 [Abstract - assigning workflow tasks to workers… workflow is granted to a worker to perform a workflow task and enforcing access control on execution of the workflow task according to the transaction encoded to the secure ledger] In an example, there is provided a method for creating a workflow, comprising workflow tasks. The method comprises assigning workflow tasks to workers, according to an access control policy. The method comprises encoding as a transaction to a secure ledger that access to the workflow is granted to a worker to perform a workflow task and enforcing access control on execution of the workflow task according to the transaction encoded to the secure ledger.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Balinsky et al. 2022/0083936. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Claim 4 rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Balinsky et al. 2022/0083936; in even further view of Vasudevan et al. 2022/0014377.
18/736,017 – Claim 4. (Original) Yang et al. 2020/0118096 further teaches The computer-implemented method of claim 3, wherein executing the tasks includes generating second transaction data and the computer-implemented method further comprises: generating a second block including the second transaction data and a second hash generated using the second transaction data (Yang et al. 2020/0118096 [0047] In some embodiments, the blockchain system 112 comprises blockchain nodes maintaining a public blockchain. In one embodiment, a public transaction submitted to the blockchain system 112 for adding to the public blockchain is visible to all blockchain nodes for verification and execution. In another embodiment, a private transaction may only involve a number of the blockchain nodes representing the parties to the private transaction. For such private transaction, though a representation of the private transaction may still be submitted like the public transaction for adding to the public blockchain, transaction information of the private transaction may be kept away from non-participating parties and their blockchain nodes. In that case, the transaction information of the private transaction may be transmitted among a limited number of blockchain nodes (e.g., blockchain nodes of the parties to the private transaction). That is, unlike public transactions, a private transaction may keep at least a portion of its transaction information (e.g., the sender, receiver, and transaction information) known to parties of the transactions for these parties' corresponding blockchain nodes to verify and execute, without broadcasting to non-participating parties. The public blockchain as visible to all blockchain nodes may record a proof of the private transaction such as a transaction hash of the private transaction and an encryption of the transaction information, but not explicitly storing at least the portion of the transaction information. The transaction hash is a hash value which may be the numeric result of applying a hash algorithm to the data of the transactions (e.g., transaction information). For example, a transaction hash of a private transaction between Node 1 and Node 2 may be recorded to a public blockchain and visible to Node 1, Node 2, Node 3, Node 4, and so on, while transaction information of the private transaction may be only known to Node 1 and Node 2. To that end, Node 1 and Node 2 may communicate off the blockchain and keep the transaction information of the private transaction private, or communicate on the blockchain but only allow visibility to certain nodes (e.g., through public-private key encryption).);
Yang et al. 2020/0118096 may not expressly disclose the following, however, Vasudevan et al. 2022/0014377 teaches sending the second block to the second node; receiving a second indication that the second node has verified the second block; and storing the verified second block in the node data store of the first node(Vasudevan et al. 2022/0014377 [0023] Each of the web browsers 114 and 154 is configured to access information on the world wide web (e.g., the Internet). For example, when a user operating the first computing node 110 requests a web page from a website, the web browser 114 retrieves the necessary web assets from a web server 180 and renders the web page based on the retrieved web assets for display on a display screen of the first computing node 110. Examples of web assets that are needed to render a web page include Java Script (JS) files, Cascading Style Sheet (CSS) files, images and the like. The downloading of the digital files for rendering the web page triggers the blockchain manager 118 to generate a new block of the blockchain 132 in order to record the downloading as a new transaction. The blockchain manager 118 generates a unique hash for the new block and adds the generated hash to the block. Additionally, the blockchain manager 118 adds a hash of the previous block and data relating to the new transaction to the new block. The data relating to the new transaction as added to the new block may include identities (e.g., IP addresses) of the first computing node 110 and the web server 180 used to download the digital files and information identifying the downloaded digital files. The blockchain manager 118 may also add a timestamp of the download transaction to the new block that identifies a time at which the download transaction took place. Once the new block is verified by other computing nodes of the blockchain infrastructure 130 as described above, the blockchain manager 118 adds the new block to the blockchain 132 and updates the copy of blockchain 132 stored in the ledger 124 to reflect the new block. Additionally, each other computing node of the blockchain infrastructure 130 updates its copy of the blockchain 132 locally stored in their respective memory devices. For example, the blockchain manager 158 updates the copy of the blockchain 132 persisted in the ledger 164 of the second computing node 150 to add the new block. Furthermore, the first computing node 110 stores the digital files downloaded form the web server 180 in a local cache 126 (e.g., a web browser cache assigned for the web browser 114). As shown, the cache 126 may be stored in the memory device 112. [0036] At step 208, a new block is generated for the blockchain 132 to record the download transaction from the web server 180 and the blockchain ledger is updated accordingly to add the new block to the blockchain 132. For example, the downloading of the digital files by the first computing node 110 for rendering the web page triggers the blockchain manager 118 to generate a new block of the blockchain 132 in order to record the downloading as a new transaction. The blockchain manager 118 generates a unique hash for the new block and adds the generated hash to the new block. Additionally, the blockchain manager 118 adds a hash of the previous block and data relating to the new transaction to the new block. The data relating to the new transaction as added to the new block may include identities (e.g., IP addresses) of the first computing node 110 and the web server 180 used to download the digital files and information identifying the downloaded digital files. The blockchain manager 118 may also add a timestamp of the download transaction to the new block that identifies a time at which the download transaction took place. Once the new block is verified by other computing nodes of the blockchain infrastructure 130, the blockchain manager 118 adds the new block to the blockchain 132 and updates the copy of blockchain 132 stored in the ledger 124 to reflect the new block. Additionally, each other computing node of the blockchain infrastructure 130 updates its copy of the blockchain 132 locally stored in their respective memory devices. For example, the blockchain manager 158 updates the copy of the blockchain 132 persisted in the ledger 164 of the second computing node 150 to add the new block.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Vasudevan et al. 2022/0014377. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Claim 5 rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Chapman et al. 2018/0225660.
18/736,017 – Claim 5. (Original) The computer-implemented method of claim 1, further comprising Yang et al. 2020/0118096 may not expressly disclose the following, however, Chapman et al. 2018/0225660 teaches receiving a document for the transaction, and wherein the block includes document metadata for the document, the document metadata including a hash of document content of the document (Chapman et al. 2018/0225660 [0033] In some embodiments, document records stored on the system database 105 may comprise a data field containing document-identifying hash values generated by an application server 103 according to a hashing algorithm implemented by a system blockchain, when a new document record containing a machine-readable computer file (e.g., PDF, DOC, XSL), such as transaction documents, is generated or updated. The hash value may be generated using one or more data fields that describe the computer file, which may be uploaded by a user via a website portal or pulled from the document record within the system database 105. The hash value may be a unique identifier for the particular document record, and may be used by various computing devices of the system 100, such as the system database 105, to reference the computer file or metadata describing the computer file, which may be stored in the system database 105 and/or on blocks of the system blockchain that is hosted on network nodes 111.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Chapman et al. 2018/0225660. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Claim 6 rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Chapman et al. 2018/0225660; in even further view of Kumar et al. 2019/0020725.
18/736,017 – Claim 6. (Original) The computer-implemented method of claim 5, Yang et al. 2020/0118096 may not expressly disclose the following, however, Kumar et al. 2019/0020725 wherein the document metadata includes one or more of: a document name; a document type; a document version; and document audit history (Kumar et al. 2019/0020725 [0062] Referring back to FIG. 5, at 520, it may be determined that the message is indicative of an occurrence of an event outside the messaging platform. For example, the message and/or the document may be input to a machine learning model to determine whether the message is indicative of the occurrence of the event outside of the messaging platform. In such an example, an output of the machine learning model may be a classification of whether the event occurred outside of the messaging platform (e.g., that the document indicates an occurrence of the event). For example, metadata associated with the document, a document type, a document name, or the like may be used by the machine learning model to classify the document. For another example, multiple documents that are indicative of an occurrence of an event may be used as training data for a machine learning model such that the machine learning model may classify documents as indicative of an occurrence of an event. In such an example, multiple documents that are not indicative of an occurrence of an event may also be used as input (with labels indicating which documents are indicative and which documents are not indicative of an event) for training the machine learning model. By having documents with corresponding labels, the machine learning model may learn how to distinguish between documents that indicate an occurrence of an event and documents that do not indicate an occurrence of an event. In one illustrative example, the machine learning model may be used to recognize receipts. In some examples, instead of a machine learning model, a set of one or more criteria may be used to determine whether the message is indicative of the occurrence of the event outside the messaging platform. The one or more criteria may be similar to that which the machine learning model uses in its determination.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Kumar et al. 2019/0020725. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Claim 7 rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Chapman et al. 2018/0225660; in even further view of Vintila 2019/0050856.
18/736,017 – Claim 7. (Original) The computer-implemented method of claim 5, Yang et al. 2020/0118096 may not expressly disclose the following, however, Vintila 2019/0050856 teaches further comprising, by the first node: in response to validating the transaction data, storing the document in a node object store of the first node; and sending the document to the second node (Vintila 2019/0050856 [0061] In some embodiments, a blockchain implementation is described wherein distributed ledger blocks corresponding to conditions of an electronic document are stored on a series of decentralized devices acting as node computing devices each having a copy of the distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to the satisfaction or failure of a conduction of the electronic document. The blockchain implementation provides improvements in event ordering (e.g., transactions are ordered based on their timestamp, in a FIFO queue), block creation (e.g., transactions are stored in immutable corresponding blocks), block chaining (e.g., blocks are chained using the previous block hash, before being codified in a system chain, improving the integrity of the events stored in the blockchain and permits for easy queries by way of traversal), ability to register transactions by various parties.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Vintila 2019/0050856. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Claim 9 rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Marlow et al. 2010/0174658.
18/736,017 – Claim 9. (Original) The computer-implemented method of claim 1, Yang et al. 2020/0118096 may not expressly disclose the following, however, Marlow et al. 2010/0174658 teaches wherein the transaction data includes property data for a real estate property, a loan amount, a purchase price for the property, and fee data (Marlow et al. 2010/0174658 [Abstract] A computer system and method for real estate transactions concerning the purchase or sale of real property is provided. The method comprises engaging a realtor and a mortgage originator to participate in the real estate transaction, providing unified communication among a client, the realtor and the mortgage originator, whereby the mortgage originator may be the realtor, providing a simplified loan process for the client by the coordination between the realtor and the mortgage originator due to the unified communication among the client, the realtor and the mortgage originator, upon the sale of property, distributing to the client, from the real estate commission received by the realtor, a predetermined portion of money from the purchase price, the loan amount and the listing fee, then, distributing to the realtor a portion of the mortgage origination proceeds typically received by the mortgage originator to compensate for the portion of the purchase price, loan amount and listing fee distributed to the client, and, upon the purchase of property, distributing to the client, from the real estate commission received by the realtor, a predetermined portion of money from the purchase price, the loan amount and the listing fee, then, distributing to the realtor a portion of the mortgage origination proceeds typically received by the mortgage originator to compensate for the portion of the purchase price, loan amount and listing fee distributed to the client, such that, upon a sale, a purchase, and any combination of sales and purchases, the client receives a predetermined portion of money from the purchase price of the property, the loan amount and the listing fee, the realtor receives the full amount of the predetermined real estate commission for the sale consummated and the mortgage originator receives a proportionately smaller portion of the mortgage origination proceeds.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Marlow et al. 2010/0174658. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Claim 10 rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Graff 2005/0114151.
18/736,017 – Claim 10. (Original) The computer-implemented method of claim 1, Yang et al. 2020/0118096 may not expressly disclose the following, however, Graff 2005/0114151 teaches wherein receiving the transaction data includes: receiving property data from a property data source; and receiving fee data from a fee estimation source (Graff 2005/0114151 [0222] The Logic Means 30 additionally has Input Property Valuation 92 for receiving input data representing a property valuation of the real estate; Input Extra Fees 94 is for receiving input data representing fees and expenses incurred in structuring the separated purchase transaction. The securitization and separation of a property into components often entails greater costs than a traditional real estate sale.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Graff 2005/0114151. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Claim 11 rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Cooper 2022/0327570.
18/736,017 – Claim 11. (Original) The computer-implemented method of claim 1, Yang et al. 2020/0118096 may not expressly disclose the following, however, Cooper 2022/0327570 teaches further comprising, in response to receiving the indication that the second node has verified the block: providing the block to a notary node of the for notary verification; and receiving an indication that the notary node has verified the block, wherein the block is stored in the node data store of the first node in response to the block being verified by the notary node (Cooper 2022/0327570 [0038] A set of software that tracks individuals that are linked by the chain of blocks may be referred to as a blockchain network notary software module where a processor executing instructions of this notary software module may act as a gateway that is responsible for reading information on the blockchain network 175 and secondary blockchain computer 195 and may route cross-chain transactions as required. Data from the secondary blockchain computer 195 may be stored and verified on the blockchain network 175. A set of blockchain network notary nodes may be computers at blockchain network 175 that execute instructions of a blockchain verification protocol in order to verify that any given transaction within the secondary blockchain computer 195 is verified and/or confirmed. Information identifying that this verification and/or confirmation may be provided to other computers of blockchain network 175. Secondary blockchain computer 195 may store any digital record that utilizes the foreminded blockchain protocol, a derivative protocol, or any combination thereof. [0061] Step 370 may perform an evaluation that identifies whether the second set of blockchain data is valid or is consistent with requirements of an MLM organization. Step 370 may be referred to as generating a consensus between different sets of blockchain data. This consensus may be generated by compute nodes that act as a notary that validate consistency of different sets of blockchain data. A computer may include sets of notary software program instructions or software modules. The execution of a set of blockchain network notary module instructions may allow a processor to identify whether there is a consensus among different blockchain network notary nodes. This consensus may be generated by accessing either in a particular data-block or a set of data-blocks as a whole. Such a consensus may be an agreement between more than 50% of all blockchain network notary nodes, two-thirds of all blockchain network notary nodes, or some other threshold based a required level of fidelity. A Byzantine fault tolerance (BFT) algorithm may be used for notary services, but other algorithms, such as RAFT, Istanbul BFT, Simplified BFT, Redundant BFT, Crash Fault Tolerant, any other algorithm, or any combination of algorithms may be used in various possible embodiments. When there is a consensus, a blockchain network notary computer may record verified blocks or blocks of data in the blockchain network. This may occur simultaneously on one or more nodes within a blockchain network. Once verified data blocks or entrie sets of blockchain data may be copied or moved to another blockchain computer.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Cooper 2022/0327570. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
Claims 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over: Yang et al. 2020/0118096; in view of Jang et al. 2019/0179801; in further view of Alt et al. 2021/0166233; in further view of Balinsky et al. 2022/0083936.
18/736,017 – Claim 16. (Original) Yang et al. 2020/0118096 further teaches The system of claim 15, wherein: the first node configured to enable execution of the transaction by the one or more servers comprises providing the transaction data to a workflow engine that executes on the one or more servers (Yang et al. 2020/0118096 [0045] A certain blockchain node that successfully verifies its batch of blockchain transactions in accordance with consensus rules may pack the blockchain transactions into its local copy of the blockchain and multicast the results to other blockchain nodes. The certain blockchain node may be a blockchain node that has first successfully completed the verification, that has obtained the verification privilege, or that has been determined based on another consensus rule, etc. Then, the other blockchain nodes may execute the blockchain transactions locally, verify the execution results with one another (e.g., by performing hash calculations), and synchronize their copies of the blockchain with that of the certain blockchain node. By updating their local copies of the blockchain, the other blockchain nodes may similarly write such information in the blockchain transaction into respective local memories. As such, the blockchain contract can be deployed on the blockchain. If the verification fails at some point, the blockchain transaction is rejected. [0062] Referring to FIG. 4, though the figure shows the proposer node initiating the private transaction, the private transaction may be initiated by any blockchain node to the private transaction. In some embodiments, at step 321, the user may send to the proposer node a private transaction (e.g., transaction information) to be conducted by the group members. In one embodiment, the private transaction received by the proposer node may comprise the identification of the group for executing the private transaction. In another embodiment, the proposer node may identify the group for executing the private transaction from a plurality of groups whose group identifications are available from the blockchain. The private transaction to be executed by a particular group is kept private from members of other groups (except for overlapping members). The proposer node may choose a group comprising the sender(s) and/or recipient(s) to the private transaction to execute the private transaction. In one example, the proposer node is involved in three different groups: group 1 including itself and nodes M and N, group 2 including itself and nodes M, N, and P, and group 3 including itself and nodes M and P. For a private transaction among the proposer node and nodes M and N, the proposer node may choose group 1 if it wants to minimize the number of participants, or may choose group 2 if it does not mind having node P to know about the private transaction or needs node P to be a verifier (described below). The proposer node may not choose group 3 because it does not comprise node N. If there is no appropriate group available according to the blockchain, the proposer node may create a group for executing the private transaction as described above.);
Yang et al. 2020/0118096 may not expressly disclose the following, however, Balinsky et al. 2022/0083936 teaches the workflow engine is configured to generate tasks of the transaction that are executable by a plurality of workflow workers that execute on the one or more servers; and the plurality of workflow workers is configured to execute the tasks to generate a document and second transaction data for the transaction (Balinsky et al. 2022/0083936 [Abstract - assigning workflow tasks to workers… workflow is granted to a worker to perform a workflow task and enforcing access control on execution of the workflow task according to the transaction encoded to the secure ledger] In an example, there is provided a method for creating a workflow, comprising workflow tasks. The method comprises assigning workflow tasks to workers, according to an access control policy. The method comprises encoding as a transaction to a secure ledger that access to the workflow is granted to a worker to perform a workflow task and enforcing access control on execution of the workflow task according to the transaction encoded to the secure ledger.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Balinsky et al. 2022/0083936. One of ordinary skill in the art would have been motivated to do so to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
18/736,017 – Claim 17. (Original) Yang et al. 2020/0118096 further teaches The system of claim 16, wherein the plurality of workflow workers configured to generate the document includes the plurality of workflow workers being configured to obtain an electronic signature for the document (Yang et al. 2020/0118096 [Abstract] Methods, systems, and apparatus, including computer programs encoded on computer storage media, for implementing blockchain-based private transactions are provided. One of the methods is performed by a first blockchain node to a private transaction, the method including: determining one or more second blockchain nodes to the private transaction according to a blockchain contract in a public blockchain; transmitting transaction information to the one or more second blockchain nodes, the transaction information comprising one or more senders of the private transaction, one or more recipients of the private transaction, and one or more transaction amounts of the private transaction; obtaining a signature from each of a number of the one or more second blockchain nodes certifying receipt of the transaction information; and in response to obtaining the number of the signatures over a threshold, storing at least a representation of the private transaction and the signatures in the public blockchain.).
No Prior-art Rejection / Potentially Allowable
Claims 8, 18, 20 cannot be rejected with prior-art. Individual claimed features are taught in the prior-art, however, the unique combination of features and elements are not taught by the prior-art without hindsight reasoning. These claims are further rejected to as being dependent upon a rejected base claim but might possibly be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
18/736,017 – Claim 8. The computer-implemented method of claim 7, further comprising, by the second node: storing the document in a second node object store of the second node; and storing the verified block in a second node data store of the second node.
18/736,017 – Claim 18. The system of claim 14, wherein: the first node is further configured to: Yang et al. 2020/0118096 may not expressly disclose the following, however, Chapman et al. 2018/0225660 teaches receive a document for the transaction, and wherein the block includes document metadata for the document, the document metadata including a hash of document content of the document (Chapman et al. 2018/0225660 [0033] In some embodiments, document records stored on the system database 105 may comprise a data field containing document-identifying hash values generated by an application server 103 according to a hashing algorithm implemented by a system blockchain, when a new document record containing a machine-readable computer file (e.g., PDF, DOC, XSL), such as transaction documents, is generated or updated. The hash value may be generated using one or more data fields that describe the computer file, which may be uploaded by a user via a website portal or pulled from the document record within the system database 105. The hash value may be a unique identifier for the particular document record, and may be used by various computing devices of the system 100, such as the system database 105, to reference the computer file or metadata describing the computer file, which may be stored in the system database 105 and/or on blocks of the system blockchain that is hosted on network nodes 111.);
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Yang et al. 2020/0118096 to include the features as taught by Chapman et al. 2018/0225660. One of ordinary skill in the art would have been motivated to do so in order to utilize well known blockchain tools and techniques to implement secured transaction workflows which should prove to improve user experience, maximize profits, and optimize revenue.
validate transaction data; in response to validating the transaction data, store the document in a node object store of the first node; and send the document to the second node of the blockchain system; and the second node is further configured to: store the document in a second node object store of the second node; and store the verified block in a second node data store of the second node.
18/736,017 – Claim 20. The non-transitory computer readable medium of claim 19, wherein the operations further include: receiving a document for the transaction, and wherein the block includes document metadata for the document, the document metadata including a hash of document content of the document; validating the transaction data; in response to validating the transaction data, storing the document in a node object store of the first node; and sending the document to the second node.
Examiner’s Response to Arguments
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC § 103
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping prior-art rejection including Applicant’s amendments and arguments and unique combination of features and elements not taught by the prior-art without hindsight reasoning.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claim X, on page(s) 8-9 of Applicant’s Remarks / After Final Amendments (dated 07/15/2011), Applicant(s) argues that the cited reference(s) (Ellis and Vandermolen) fails to teach, describe, or suggest the amended features. Specifically, Applicant(s) argues that cited reference(s) do not teach, describe, or suggest the following: . With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
Examiner’s Response: Claim Rejections – 35 USC §112
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC §101
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping 35 USC 101 rejection including Applicant’s amendments, arguments, lack of abstract idea, and practical integration.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claims 1-11 and 14-20, on page(s) 11-13 of Applicant’s Remarks (dated 03/02/2026), Applicants traverse the 35 USC §101 rejections arguing the following: the claims are not abstract. Respectfully, the Office disagrees, and the claim remain subject matter ineligible under 35 USC §101.
As noted in the rejection above, under Step 2A, Prong One, the claims recite a judicial exception (an abstract idea). The claims are directed to the abstract idea of implementing blockchain secured transaction workflows, which, pursuant to MPEP 2106.04, is aptly categorized as a method of organizing human activity. Therefore, under Step 2A, Prong One, the claims recite a judicial exception.
The claims recite additional technical elements including: a “data store” for implementing the method, a “non-transitory computer readable medium” for storing executable instructions and “processor” for implementing/executing the code. These limitations are recited at a high level of generality and appear to be nothing more than generic computer components. Claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.
The judicial exception is not integrated into a practical application. The additional elements listed above that relate to computing components are recited at a high level of generality (i.e., as generic components performing generic computer functions such as communicating, receiving, processing, analyzing, and outputting/displaying data) such that they amount to no more than mere instructions to apply the exception using generic computing components. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, the claims do not purport to improve the functioning of the computer itself. There is no technological problem that the claimed invention solves. Rather, the computer system is invoked merely as a tool. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, these claims are directed to an abstract idea.
Furthermore, looking at the elements individually and in combination, under Step 2A, Prong Two, the claims as a whole do not integrate the judicial exception into a practical application because they fail to: improve the functioning of a computer or a technical field, apply the judicial exception in the treatment or prophylaxis of a disease, apply the judicial exception with a particular machine, effect a transformation or reduction of a particular article to a different state or thing, or apply the judicial exception beyond generally linking the use of the judicial exception to a particular technological environment. Rather, the claims merely use a computer as a tool to perform the abstract idea(s), and/or add insignificant extra-solution activity to the judicial exception, and/or generally link the use of the judicial exception to a particular technological environment.
Next, under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. Simply put, as noted above, there is no indication that the combination of elements improves the functioning of a computer (or any other technology), and their collective functions merely provide conventional computer implementation. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements relating to computing components amount to no more than applying the exception using a generic computing components. Mere instructions to apply an exception using a generic computing component cannot provide an inventive concept. Furthermore, the broadest reasonable interpretation of the claimed computer components (i.e., additional elements) includes any generic computing components that are capable of being programmed to communicate, receive, send, process, analyze, output, or display data. Furthermore, Applicant’s Specification (PGPub. 2024/0320663 [0108]) refers to a general computer system, but they do not include any technically-specific computer algorithm or code.
Thus, taken alone and in combination, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea), and are ineligible under 35 USC 101.
Independent system claim 14 and CRM claim 19 also contains the identified abstract ideas, with the additional elements of a processor and storage medium, which are a generic computer components, and thus not significantly more for the same reasons and rationale above.
Dependent claims 2-11, 15-18, and 20 further describe the abstract idea. The additional elements of the dependent claims fail to integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea. Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
As such, the claims are not patent eligible.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
PERTINENT PRIOR ART – Patent Literature
The prior-art made of record and considered pertinent to applicant's disclosure.
Kochura et al. 2021/0342855 [0025 - blockchain network 120 is a Peer to Peer (P2P) network in which participants of the blockchain network 120 that process requested transactions and store records of the requested transactions are referred to as respective blockchain nodes]
Davis 2018/0183600 [0051 - a data file may be generated that includes each of the deterministic inputs, which may be hashed to generate the transaction value. … the transaction value may also include (e.g., be based on) a reference to a smart contract and/or a template. In step 308, the third party system 104 may electronically transmit (e.g., via a transmitting device 220) the transaction value to a blockchain node 108 associated with the blockchain network 106 for inclusion in a block to be verified and posted to the blockchain]
PERTINENT PRIOR ART – Non-Patent Literature (NPL)
The NPL prior-art made of record and considered pertinent to applicant's disclosure.
Secured Electronic Voting System Using the Concepts of Blockchain, Sudharsan, B. et al. 2019 IEEE 10th Annual Information Technology, Electronics and Mobile Communication Conference, IEMCON 2019: 675-681. Institute of Electrical and Electronics Engineers Inc. (Oct 2019).
Preservation Authentication and Authorization on Blockchain, Ali, Wasan Ahmed, et al. 2019 2nd International Conference on Engineering Technology and its Applications, IICETA 2019: 83-88. Institute of Electrical and Electronics Engineers Inc. (Aug 2019).
THIS ACTION IS MADE FINAL
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
THIS ACTION IS MADE FINAL
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW T. SITTNER whose telephone number is (571) 270-7137 and email: matthew.sittner@uspto.gov. The examiner can normally be reached on Monday-Friday, 8:00am - 5:00pm (Mountain Time Zone). Please schedule interview requests via email: matthew.sittner@uspto.gov
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah M. Monfeldt can be reached on (571) 270-1833.
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.
/MATTHEW T SITTNER/
Primary Examiner, Art Unit 3629b