Detailed Action
Acknowledgements
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the application filed on July 7, 2025.
Claims 1-20 are pending.
Claims 1-20 are examined.
This Office Action is given Paper No. 20250831 for references purposes only.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The Information Disclosure Statement filed on October 2, 2025 has been considered. An initialed copy of the Form 1449 is enclosed herewith.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 2A Prong 1: The claims recite an abstract idea of performing a first and second verification of a local transaction, which is a certain method of organizing human activity (e.g. fundamental economic principles or practices including hedging, insurance, mitigating risk; commercial or legal interactions including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, business relations; managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions).
Claim 1, representative of claims 16 and 20, includes the following limitations:
Receiving a to-be-processed local transaction and first verification information;
Receiving block headers corresponding to a plurality of local blocks;
Performing first verification of the block headers;
Performing second verification based on the to-be-processed local transaction, first verification information, and a block header of the local block;
Generating a to-be-processed global transaction based on the first and second verifications and the to-be-processed local transaction.
Step 2A Prong 2: The claim limitations recite the following additional elements that are beyond the judicial exception:
A local block recorded on a local blockchain;
Recording the to-be-processed global transaction into a global blockchain.
These additional elements are not indicative of integration into a practical application because:
They add insignificant extra-solution activity to the judicial exception. Note that “extra-solution activity” can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim. Extra-solution activity can include both pre-solution and post-solution activity. An example of pre-solution activity is a step of gathering data for use in a claimed process. An example of post-solution activity is an element that is not integrated into the claim as whole. See MPEP 2106.05(g).
They generally link the use of the judicial exception to a particular technological environment or field of use. See MPEP 2106.05(h).
Step 2B: The claim limitations do not recite additional elements, or an ordered combination of additional elements, that are sufficient to amount to significantly more than the judicial exception.
As discussed with respect to step 2A prong 2 above, the additional elements are extra solution activity that do not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the 2019 PEG, a conclusion that an additional element is insignificant extra solution activity under step 2A should be re-evaluated at step 2B. The limitations “a local block recorded on a local blockchain” and “recording the to-be-processed global transaction into a global blockchain” are re-evaluated to determine whether they constitute well-understood, routine, and conventional activity in the field. The “recording of data” is well-understood, routine, and conventional in the field. See Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 and MPEP 2106.05(d). Thus, a conclusion that the limitations “a local block recorded on a local blockchain” and “recording the to-be-processed global transaction into a global blockchain” are well-understood, routine, and conventional is supported under Berkheimer.
As discussed with respect to step 2A prong 2 above, the additional elements of “a local blockchain” and “a global blockchain” generally link the use of the judicial exception to a particular technological environment or field of use, and do not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the 2019 PEG, a conclusion that an additional element is mere instructions to apply an exception under step 2A should be re-evaluated at step 2B. Thus, the additional elements of “a local blockchain” and “a global blockchain” are re-evaluated to determine whether they constitute significantly more. Examiner finds that the additional elements of “a local blockchain” and “a global blockchain” are merely an attempt to limit the use of the abstract idea to a particular technological environment. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 and MPEP 2106.05(h).
Therefore, when considering all the additional claim elements both individually and as an ordered combination, Examiner finds that the claim does not amount to significantly more than the exception.
The dependent claims fail to cure this deficiency and are rejected accordingly.
Claim 2 recites obtaining a first body digest value, obtaining a second body digest value, and comparing the two values, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 3 recites identifying a local block, checking a local transaction, and obtaining the local transaction as the to-be-processed transaction, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 4 recites adding a first mark, which is insignificant extra-solution activity (e.g. mere data gathering). See Ultramercial, Inc. v. Hulu, 772 F.3d 709, 715.
Claims 5-6 recite generating a first tree, generating a feature, obtaining a first bypass feature, determining a digest value, determining a second tree root feature, and comparing the second tree root feature with the first body digest value, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 7 recites transmitting the local transaction, which is well-understood, routine, and conventional. See Intellectual Ventures v. Symantec, 838 F.3d 1307, 1321 and MPEP 2106.05(d).
Claim 8 recites obtaining the local transaction from a queue, which is insignificant extra-solution activity (e.g. mere data gathering). See Ultramercial, Inc. v. Hulu, 772 F.3d 709, 715. Claim 8 also recites transmitting the local transaction based upon a time difference, which is well-understood, routine, and conventional. See Intellectual Ventures v. Symantec, 838 F.3d 1307, 1321 and MPEP 2106.05(d).
Claims 9-10 recite determining a first score, determining a second score, determining a total score, determining a processing sequence based on the total score, receiving a notification, and obtaining a block header, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g). Claim 10 also recites transmitting the block header, which is well-understood, routine, and conventional. See Intellectual Ventures v. Symantec, 838 F.3d 1307, 1321 and MPEP 2106.05(d).
Claims 11-12 recite obtaining a transaction type, calling a global contact, executing a service contract, allocating a first identifier, and receiving the first identifier, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g). Claims 11-12 also recite recording the global transaction, which is well-understood, routine, and conventional. See Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 and MPEP 2106.05(d).
Claims 13-14 recite receiving a first authentication request, receiving a second token, comparing the first and second tokens, receiving a second authentication request, receiving a fourth token, and comparing the third and fourth tokens, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g). Claims 13-14 also recite transmitting a first and third token, which is well-understood, routine, and conventional. See Intellectual Ventures v. Symantec, 838 F.3d 1307, 1321 and MPEP 2106.05(d).
Claim 15 recites receiving a registration request, calling a blockchain contract, determining the local consensus network, calling the first verification contract, and performing a second verification, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
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, 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.
Claims 1-12 and 15-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Feng et al. (US 2023/0090296) in view of Augustine et al. (US 2021/0065070).
Claims 1, 16, 20
Feng discloses:
receiving a to-be-processed local transaction (transaction-to-be-verified, see [0031]) and first verification information (transaction verification information, see [0031]) corresponding to the to-be-processed local transaction, the to-be-processed local transaction being located in a to-be-processed local block (block, see figure 2) recorded on a local blockchain (blockchain network, see [0028]);
receiving block headers (block headers, see [0031], figure 2) corresponding to a plurality of local blocks recorded on the local blockchain, the plurality of local blocks including the to-be-processed local block;
performing first verification of the block headers (matching a block identifier in a block header chain, check two sets to obtain a first check result, see [0031]) corresponding to the plurality of local blocks;
performing second verification (check legitimacy of the transaction-to-be-verified, see [0031]) based on the to-be-processed local transaction, the first verification information, and a block header of the to-be-processed local block to authenticate the local transaction;
generating a to-be-processed global transaction (transaction 2x, see figure 2) based on the to-be-processed local transaction and the first verification and the second verification succeeding; and
recording the to-be-processed global transaction into a global blockchain (blockchain 2b, see figure 2).
Feng does not explicitly disclose:
multiple blockchain networks.
Augustine teaches:
multiple blockchain networks (see [0139]).
Feng disclose receiving a to-be-processed local transaction and verification information, receiving block headers, performing first verification, performing second verification, generating a to-be-processed global transaction, and recording the to-be-processed global transaction. Feng does not disclose multiple blockchain networks, but Augustine does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the transaction verification of a transaction based on a blockchain network with the multiple blockchain networks of Augustine because 1) a need exists for determining whether an asset transfer party has sufficient credit without overloading a block generation node (see Feng [0003]); and 2) a need exists for having a decentralized computing platform that is permissionless, yet allows for security (see Augustine [0004]). Having multiple blockchain networks allows for a layer of security.
Claim 2
Furthermore, Feng discloses:
the block header of the local block includes a first block body digest value (block hash, see [0028]) of the local block and a second block body digest value (parent block hash, see [0028]) of a previous local block of the local block on the local blockchain; and
the performing the first verification comprises:
obtaining the first block body digest value (block hash, see [0028]) from the block header of the to-be-processed local block;
obtaining the second block body digest value (parent block hash, see [0028]) from a block header of a subsequent local block of the to-be-processed local block in the plurality of local blocks in a transaction sequence; and
comparing (e.g. matching a block identifier, see [0031]) the obtained first block body digest value with the obtained second block body digest value in the transaction sequence, to complete the first verification.
Claims 3, 17
Furthermore, Feng discloses:
the receiving the to-be-processed local transaction and the first verification information includes receiving the to-be-processed local transaction and the first verification information from a first relay node (block generation node, see [0031]); and
the first relay node is configured to:
identify a local block (target block, see [0031]) added to the local blockchain;
check a local transaction (transaction-to-be-verified, see [0031]) in the added local block; and
obtain the local transaction as the to-be-processed local transaction based on the local transaction having a first mark (execution result, see [0031]), wherein the first mark indicates that the local transaction is to be included in the to-be-processed global transaction.
Claim 4
Furthermore, Feng discloses:
the first mark is added to the local transaction by a local consensus network based on the local transaction belonging to a specified transaction type (e.g. asset transfer transaction, see [0033]).
Claims 5, 18
Furthermore, Feng discloses:
generating a first tree (tree structure, see [0053]), wherein the first tree includes a plurality of layers of features, the features on a lowest layer (leaf node, see [0053]) of the plurality of layers of the first tree includes digest values of a plurality of local transactions in the to-be-processed local block, and the plurality of local transactions includes the to-be-processed local transaction;
generating a feature on a higher layer (branch node, see [0053]) of the plurality of layers of the first tree until a first tree root feature of the first tree is generated based on two adjacent connected features (child node, see [0053]) of each layer of the plurality of layers of the first tree, wherein the first tree root feature is a first block body digest value; and
obtaining the first verification information that includes a first bypass feature (hash pointer, see [0059]) of a first path, wherein the first path is from a digest value of the to-be-processed local transaction to the first tree root feature on the first tree, and the first bypass feature is on a next layer to which another feature on the first path other than the digest value of the to-be-processed local transaction is connected.
Claims 6, 19
Furthermore, Feng discloses:
determining the digest value (first state data, see [0064]) of the to-be-processed local transaction;
determining a second tree root feature (expansion node, see figure 5) of the first tree based on the digest value of the to- be-processed local transaction and the first verification information; and
comparing the second tree root feature with the first block body digest value to complete the second verification (see figure 5).
Claim 7
Furthermore, Feng discloses:
the to-be-processed local transaction is transmitted to a global consensus network by the first relay node (block generation node, see [0031]), wherein the global consensus node is located in the global consensus network (blockchain network, see figure 1).
Claim 8
Furthermore, Augustine teaches:
the to-be-processed local transaction is obtained from a queue (queue, see [0035]) and transmitted to the global consensus network based on a quantity (number, see [0035]) of to-be-processed local transactions in the queue of a predefined transaction type reaching a first threshold; and
based on the quantity of the to-be-processed local transactions in the queue not reaching the first threshold,
a time difference (FIFO, see [0035]) between a current time and a time at which the to-be-processed local transaction is transmitted to the global consensus network most recently to the current time is determined; and
the to-be-processed local transaction is obtained from the queue and the to-be-processed local transaction is transmitted to the global consensus network based on the time difference reaching a second threshold (e.g. state recordation schedule, see [0035]).
Claim 9
Furthermore, Feng discloses:
the to-be-processed local transaction is transmitted to a global consensus network by the first relay node, the global consensus node being located in a global consensus network: a transaction priority and a timestamp (maximum generation timestamp, see [0035]) of the to-be-processed local transaction is obtained to determine a processing sequence of the to-be-processed local transaction based on the transaction priority and the timestamp, wherein the determining comprises.
Furthermore, Augustine teaches:
determining a first score (e.g. length of queue, see [0035]) of the to-be-processed local transaction based on the transaction priority;
determining a second score (e.g. FIFO, see [0035]) of the to-be-processed local transaction based on a difference between the timestamp and a current time;
determining a total score (a measured central tendency value, see [0035]) of the to-be-processed local transaction based on the first score and the second score; and
determining the processing sequence of the to-be-processed local transaction based on the total score (see [0035]);
the to-be-processed local transaction in a local transaction queue is placed (transaction executed, see [0035]) according to the processing sequence; and
the to-be-processed local transaction is obtained from the local transaction queue according to the processing sequence and the to-be-processed local transaction is transmitted to the global consensus network (blockchain, see [0035]).
Claim 10
Furthermore, Feng discloses:
the receiving the block headers includes receiving, from a second relay node (user node, see [0030]), the block headers respectively corresponding to the plurality of local blocks recorded on the local blockchain; and
obtain the block header (header, see [0031]) of the to-be-processed local block that has been transmitted; and transmit the block header to the global consensus network (blockchain, see [0031]) in response to the first transmission notification.
Furthermore, Augustine teaches:
the second relay node is configured to: receive a first transmission notification (messages, see [0057]) of the to-be-processed local block from the first relay node, wherein the first transmission notification is transmitted after the first relay node transmits the to-be-processed local transaction to the global consensus network.
Claim 11
Furthermore, Feng discloses:
the generating the to-be-processed global transaction comprises: obtaining a transaction type (e.g. asset transfer transaction, see [0033]) of the to-be-processed local transaction after both the first verification and the second verification succeed.
Furthermore, Augustine teaches:
calling a global consensus service contract (smart contract, see [0053]) corresponding to the transaction type; and
executing (execute, see [0029]) the global consensus service contract to generate the to-be-processed global transaction based on the to-be-processed local transaction; and
the recording includes recording (recorded to the blockchain network, see [0050]) the to-be-processed global transaction into the global blockchain.
Claim 12
Furthermore, Feng discloses:
the local blockchain includes a plurality of local blockchains, and the global blockchain includes a plurality of global blockchains corresponding to the plurality of local blockchains (multiple branches, see figure 5);
a local blockchain startup request is received from a local consensus network, a blockchain management contract is called to allocate a first identifier (block identifier, see [0037]) to the local blockchain in response to the local blockchain startup request, and the first identifier is transmitted to the local consensus network,
the receiving the to-be-processed local transaction (transaction-to-be-verified, see [0031]) and the first verification information (transaction verification information, see [0031]) includes receiving the to-be-processed local transaction, the first verification information, and a first identifier of the local blockchain; and
the recording the to-be-processed global transaction includes recording the to-be-processed global transaction into a global blockchain (blockchain 2b, see figure 2) that corresponds to the first identifier of one of the plurality of global blockchains.
Claim 15
Furthermore, Feng discloses:
determining the local consensus network (blockchain network, see [0047]) in which the plurality of local blocks are recorded into the local blockchain; and
calling the first verification contract corresponding to the local consensus network, to perform the first verification (hash calculation on transaction, see [0047]) based on the block headers respectively corresponding to the plurality of local blocks; and
the performing the second verification includes calling the second verification contract corresponding to the local consensus network, to perform the second verification (compare first summary information with second summary information, see [0049]) based on the to-be-processed local transaction, the first verification information, and the block header of the to-be-processed local block.
Furthermore, Augustine teaches:
receiving a registration request (registration, see [0067]) from a local consensus network; and
calling a blockchain management contract to deploy a first verification contract and a second verification contract (smart contracts that verify, see [0081]) associated with the local consensus network, wherein the performing the first verification comprises.
Claim Interpretation
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure (see attached form PTO-892).
Augustine et al. (US 2022/0138640) discloses surge protection for scheduling minting of cryptographic tokens.
Conclusion
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from Examiner should be directed to Chrystina Zelaskiewicz whose telephone number is 571-270-3940. Examiner can normally be reached on Monday-Friday, 9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Neha Patel can be reached at 571-270-1492.
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://portal.uspto.gov/external/portal/pair <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).
/CHRYSTINA E ZELASKIEWICZ/Primary Examiner, Art Unit 3699
Prosecution Insights