DETAILED ACTION
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 .
Acknowledgements
The reply filed 12/10/2025 is acknowledged. Claims 1, 3-8, and 10-14 have been amended. Claims 1-14 are pending and presented for examination.
Priority
Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e).
Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Examiner acknowledges Applicant’s submission for full recognition of the foreign priority under 35 U.S.C. 119(a)-(d). However, MPEP 2304.01(c) states “A certified translation of every foreign benefit application or Patent Cooperation Treaty (PCT) application not filed in English is required. See 35 U.S.C. 119(b)(3) and 372(b)(3) and 37 CFR 1.55(g)(3)(i) and 41.154(b). If no certified translation is in the official record for the application, the examiner must require the applicant to file a certified translation. The applicant should provide the required translation if applicant wants the application to be accorded benefit of the non-English language application. Any showing of priority that relies on a non-English language application is prima facie insufficient if no certified translation of the application is on file. See 37 CFR 41.154(b) and 41.202(e).”
Response to Arguments
Applicant’s amendments, filed 12/10/2025, to claims 1, 3, 6-8, 13-14, have overcome the 35 U.S.C. 112(b) rejection (not related to the invocation of 35 U.S.C. 112(f)). Therefore, the 35 U.S.C. 112(b) (not related to the invocation of 35 U.S.C. 112(f)) rejection of claims 1-14 has been withdrawn.
Applicant’s amendments, filed 12/10/2025, to claims 5 and 12-13 have overcome the claim objections. Therefore, the objections to claims 5 and 12-13 has been withdrawn. However, other minor informalities in claims 8 and 14 were not addressed in the amendments. Furthermore, to remain consistent with the amendments, other minor informalities are noted. Please see below.
Applicant's arguments, filed 12/10/2025, with respect to the 35 U.S.C. 112(f) invocation and the related 112(a)/(b) rejections, have been fully considered, but they are not persuasive.
In response to Applicant’s remarks that the terms connote sufficiently definite structure to one of ordinary skill in the blockchain arts, the Examiner has not found any of the nonce terms (“transaction packer,” “transaction aggregator,” “transaction executor,” and “ledger manager”) to have known structural meaning in the art. The Applicant has also failed to provide any evidence to suggest as such. Furthermore, the instant specification does not disclose or suggest that the claimed invention is using the Hyperledger Fabric platform. Therefore, one of ordinary skill in the art would not know that the nonce terms should be analogous to any terminology present in the Hyperledger Fabric platform.
In response to the Applicant’s remarks regarding the specification disclosing detailed algorithms, MPEP 2181(II)(b) defines an algorithm as “a finite sequence of steps for solving a logical or mathematical problem or performing a task.” Each citation provided by the Applicant will be addressed according to the definition of an “algorithm” as provided by the MPEP.
Transaction packer - pg. 30, line 15 – pg. 31, line 10, Fig. 16, S200: Fig. 16, S200 discloses the function itself of adding key information to transaction proposal, it does not disclose “a finite sequence of steps” for performing “add key information corresponding to the transaction request to the generated transaction proposal” as recited in claim 1. The provided page and line numbers are analogous to paragraphs [155]-[158]. [155] discloses generation of an eTP, which is an encapsulated transaction (Tx) proposal as defined in [63], but it does not disclose “a finite sequence of steps” for generating a transaction proposal and/or adding key information to the generated transaction proposal. According to the instant specification, an encapsulated Tx proposal is not the same as a Tx proposal, see [58] and [63]. [156] describes Fig. 2, however, Fig. 2 does not illustrate any steps for performing the claimed functions. [157]-[158] describes the data within the transaction proposal and key information, not a finite sequence of steps. Therefore, the citations failed to disclose any special purpose computer programmed to carry out an algorithm for performing the claimed functions.
Transaction aggregator – pg. 31, line 11 – pg. 37, line 5, Figs. 3-13: Figs. 3-13 do not illustrate or suggest any finite sequence of steps for performing the claimed functions of generating common transaction batch information and common keyset information…and transmitting the common transaction batch information and the common keyset information to each execution node group…The provided page and line numbers correspond to the paragraphs [158]-[182] describing the provided figures. However, the paragraphs do not describe a finite sequence of steps for performing the claimed functions, instead, they describe the content of information for the key information and the encapsulated transaction proposal(s). Therefore, the citations failed to disclose any special purpose computer programmed to carry out an algorithm for performing the claimed functions.
Transaction executor – pg. 41, line 15 – pg. 48, line 10: Examiner acknowledges that the transaction executor is equipped with at least one cache memory, which suggests presence of a computer [216]. Since ‘receiving’ data, ‘storing’ data, and ‘processing’ data are functions that are considered coextensive with a microprocessor or general purpose computer, disclosure of a microprocessor or general purpose computer lends sufficient structure only to basic functions see MPEP 2181(II)(b). Therefore, the 35 U.S.C. 112(a) and (b) rejections of claims 6-7, related to the following limitations: “the transaction executor is configured to store state information resulting from simulation execution of the transaction proposals in a cache memory” in claim 6, “the transaction executor is configured to receive the pieces of key value information from the ledger manager,” in claim 7, and “the transaction executor is configured to store the received pieces of key value information in the cache memory” in claim 7 are withdrawn.
The provided page and line numbers correspond to paragraphs [199]-[229]. [199]-[212] does not discuss any subject matter related to the transaction executor. [213]-[215] introduces the claimed functions without describing any finite sequence of steps for performing the claimed functions. [216]-[217] describes the hardware contained within the transaction executor, but does not describe a finite sequence of steps. [218]-[226] does not disclose a finite sequence of steps for executing a simulation regarding the one or more transaction proposals and transferring the common keyset information. [227]-[229] relates to the ledger manager, not the transaction executor. Therefore, the citations failed to disclose any special purpose computer programmed to carry out an algorithm for performing the claimed functions.
Ledger manager – pg. 38, line 1 – pg. 41, line 14, Fig. 15: The provided page and line numbers correspond to paragraphs [185]-[199]. These paragraphs are not related to the ledger manager. [226]-[246] discusses the ledger manager and Fig. 15. However, neither the paragraphs nor the figure discloses a finite sequence of steps for retrieving pieces of key value information and transferring the retrieved pieces of key value information to the transaction executor. While “storing” data is a coextensive function with a microprocessor or general purpose computer (“store a plurality of partial blocks”, the instant specification is devoid of any disclosure related to a microprocessor or general purpose computer for the ledger manager. Furthermore, pg. 40, lines 1-15 correspond to the end of paragraph [193] to [197], which does not discuss the “stop retrieval when most-recent block hit” rule. Such “rule” is disclosed in at least [240]-[241], however, these paragraphs and the rest of the instant specification do not disclose a finite sequence of steps for performing the “stop an operation of retrieving the key value information…” Therefore, the citations failed to disclose any special purpose computer programmed to carry out an algorithm for performing the claimed functions.
As such, the 35 U.S.C. 112(a) and (b) rejections, as related to the 35 U.S.C. 112(f) invocation, stands, unless otherwise noted above.
Applicant's arguments, filed 12/10/2025, with respect to the prior art rejections, have been fully considered, but they are not persuasive.
Applicant’s remarks state –
“Bekiyants never splits a single blockchain block across multiple storage locations. Bekiyants describes a file-level or document-level data-splitting technique (see Title, Abstract,
¶¶ [0004], [0072]) in which an entire file or data object is partitioned into chunks and stored in multiple Data Vault Services (DVS). However, there is no disclosure whatsoever that a one blockchain block (i.e., a set of ordered transactions that form a single unit on the chain) is fragmented and its constituent transaction pieces are distributed across multiple storage spaces.”
In response to Applicant’s remarks, the claimed invention does not claim splitting or fragmenting a single blockchain block across multiple storage locations. At most, the claimed invention claims storing a plurality of partial blocks (claims 1 and 8). Storing a plurality of partial blocks and splitting/fragmenting a single blockchain block are not the same.
“Bekiyants does not retrieve "pieces of key-value information corresponding to the common keyset information" from the distributed storage spaces. Bekiyants reconstructs an entire original file from chunks (Para. [0087], Fig. 11 steps 22-23). It does not teach or suggest retrieving individual key-value pairs that belong to different transactions of the same blockchain block from a plurality of storage spaces in response to a common keyset.”
In response to Applicant’s remarks, the claimed invention does not claim retrieving individual key-value pairs. Claims 1 and 8 recite “retrieve…pieces of key value information…” Key value information and individual key-value pairs are not the same. Key value information is merely data, and Bekiyants discloses retrieving data from multiple data vault services in [0072].
“Bekiyants operates outside the blockchain execution flow. The data splitting in Bekiyants is performed for long-term secure storage or privacy purposes, not to accelerate simulation/execution of batched blockchain transactions as required by the claims. There is no disclosure in Bekiyants of a "transaction executor" that sends a common keyset to a ledger manager, nor of the ledger manager returning only the needed key-value pieces to speed up transaction simulation.”
In response to Applicant’s remarks, the claimed invention itself does not operate within the blockchain execution flow. Therefore, the remark stating that Bekiyants operates outside the blockchain execution flow is not relevant to what is being claimed. Tangentially reciting a ”blockchain” in claims 1 and 8 does not mean that the claimed invention is operating within the blockchain execution flow. Furthermore, it is unclear what is meant by a “blockchain execution flow.” The claimed invention also does not require accelerating simulation/execution of batched blockchain transactions as asserted. The claim language does not suggest such process or outcome and Applicant has failed to provide any evidence to support such conclusion. In response to Applicant's remarks against Bekiyants individually with respect to Bekiyants not disclosing a transaction executor, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Primary reference Sun et al. U.S. 2021/0349854 discloses the transaction executor as claimed in claims 1 and 8, which was noted in the previous Non-Final Rejection 09/19/2025 and below.
“No motivation to combine exists that would yield the claimed invention. Even assuming, arguendo, that a POSITA would look to Bekiyants to improve Sun, the proposed motivation ("to provide increased security for sensitive information", Office Action p. 17 & p. 20) does not explain why one would split individual blockchain blocks and store their transaction pieces separately. Sun already achieves security through endorsement and ordering mechanisms. Fragmenting blocks would actually introduces complexity and risk of inconsistency-exactly the opposite of what a blockchain designer normally desires. Therefore, the proposed combination is the product of impermissible hindsight.”
In response to Applicant's remarks that the Examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). A motivation from Bekiyants was provided in the Non-Final Rejection 09/19/2025 on pg. 21, lines 9-10. Furthermore, as noted above, the claimed invention does not claim splitting the individual blockchain blocks. At most, it claims storing a plurality of partial blocks. The remarks related to fragmenting blocks introducing complexity and risk of inconsistency is not relevant because the claimed invention is not fragmenting any blockchain blocks.
“Further, claims 5 and 12 depend from claims 1 and 8, and are allowable for at least their dependency on an allowable base claim. In addition, these claims require the ledger manager to stop retrieving from remaining storage spaces once it has found the needed key value information in the most recent block in any one storage space. Neither Sun, Bekiyants, nor the tertiary reference Langseth discloses or suggests this specific optimization applied to partial block storage. Langseth merely stops unnecessary queries in a completely different (non-blockchain, non-partial-block) context. Accordingly, claims 5 and 12 are also not obvious.”
In response to Applicant's remarks against Langseth et al. U.S. 2018/0173767 individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Langseth was introduced to disclose the stop operation, therefore, it is the combination of Sun in view of Bekiyants and Langseth that teach claims 5 and 12, not Langseth alone.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-4, 6-11, and 13-14 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2, 4-9, and 11-12 of U.S. Patent No. 12,360,979 in view of Bekiyants U.S. 2022/0405765.
Current App. 18/724,140
Reference Patent 12,360,979
Current App. 18/724,140
Reference Patent 12,360,979
1
1
8
7
2
1
9
7
3
6
10
8
4
2
11
9
6
4
13
11
7
5
14
12
Claim 1 of Current App. 18/724,140
Claim 1 of Reference Patent 12,360,979
A ledger information access system having a plurality of storage spaces, comprising:
A system for accessing ledger information by using common keyset information, comprising:
a transaction packer configured to generate a transaction (Tx) proposal indicating transaction information according to a user's transaction request and add key information corresponding to the transaction request to the generated transaction proposal;
a transaction packer that generates a transaction (Tx) proposal indicating transaction information according to a user's transaction request and adds key information corresponding to the transaction request to the generated transaction proposal;
a transaction aggregator configured to generate common transaction batch information and common keyset information corresponding to the transaction proposal according to the key information included in the transaction proposal received from the transaction packer, and transmit the common transaction batch information and the common keyset information to each execution node group distinguished and predesignated with regard to the common
transaction batch information;
a transaction aggregator that generates common transaction batch information and common keyset information corresponding to the transaction proposal according to the key information included in the transaction proposal received from the transaction packer, and transmits the common transaction batch information and the common keyset information to each execution node group distinguished and predesignated with regard to the common transaction batch information;
at least one transaction executor configured to execute a simulation regarding the one or more transaction proposals included in the common transaction batch information transmitted from the transaction aggregator, which belongs to the execution node group, and transfer the common keyset information; and
at least one transaction executor that executes a simulation regarding the transaction proposals included in the common transaction batch information transmitted from the transaction aggregator, which belongs to the execution node group, and transfers the common keyset information; and
a ledger manager configured to comprise a plurality of storage spaces that respectively store a plurality of partial blocks, in which pieces of transaction information constituting a single block connected to blockchain are distributed, retrieve, from the plurality of storage spaces, pieces of key value information corresponding to the common keyset information received from the transaction executor, and transfer the retrieved pieces of key value information to the transaction executor.
a ledger manager that receives the common keyset information from the transaction executor, retrieves key value information corresponding to the common keyset information from blockchain ledger information and transfers same to the transaction executor, wherein the key information includes partial key information in an indetermined form including an array or composite key.
As shown above, U.S. Patent 12,360,979 discloses claim 1 of the pending application 18,724,140 except for “the plurality of storage spaces” and “configured to comprise a plurality of storage spaces that respectively store a plurality of partial blocks, in which pieces of transaction information constituting a single block connected to blockchain are distributed.” Furthermore, U.S. Patent 12,360,979 recites “transfers same to the transaction executor,” while the instant application recites “transfer the retrieved pieces of key value information.” The “same” and the “retrieved pieces of key value information” are interpreted to be the same information being transferred to the transaction executor.
Bekiyants discloses in [0072] – using a Data Splitter (DS) and a Data Builder (DB) for “partitioning transaction information across multiple data vault services (DVS),” i.e. a plurality of storage spaces that store partial data/pieces of transaction information.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 1 of the U.S. Patent 12,360,979 with the teachings of data partitioning and storing the partitioned data across multiple DVS, i.e. plurality of storage spaces, in Bekiyants. One would be motivated to make the combination to provide increased security for sensitive information Bekiyants, [0085]. Since independent claim 8 recites similar distinguishing features as claim 1, similar reasoning shall apply to claim 8 of the pending application.
Claim Objections
Claim 1 is objected to because of the following informalities:
-line 3: “generate a transaction (Tx) proposal” should be “generate one or more transaction
-line 5: “generated transaction proposal” should be “the one or more generated transaction proposal”
-lines 7 and 8: “the transaction proposal” should be “the one or more transaction proposal”
Appropriate correction is required.
Claim 6 is objected to because of the following informalities: “the next transaction proposal” on line 4 should be “a next transaction proposal.”
Claim 8 is objected to because of the following informalities:
-line 3: “generate a transaction (Tx) proposal” should be “generate one or more transaction
-line 5: “generated transaction proposal” should be “the one or more generated transaction proposal”
-lines 7 and 8: “the transaction proposal” should be “the one or more transaction proposal”
-line 11: “at least one transaction executor” should be “at at least one transaction executor”
-line 13: “ledge” should be “ledger”
Appropriate correction is required.
Claim 14 is objected to because of the following informalities: “ledge” on line 6 should be “ledger.” Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
-a transaction packer configured to generate a transaction (Tx) proposal indicating transaction information according to a user’s transaction request in claim 1.
-a transaction packer configured to add key information corresponding to the transaction request to the generated transaction proposal in claim 1.
-a transaction aggregator configured to generate common transaction batch information and common keyset information corresponding to the transaction proposal according to the key information included in the transaction proposal received from the transaction packer in claim 1.
-a transaction aggregator configured to transmit the common transaction batch information and the common keyset information to each execution node group distinguished and predesignated with regard to the common transaction batch information in claim 1.
-at least one transaction executor configured to execute a simulation regarding the transaction proposals included in the common transaction batch information transmitted from the transaction aggregator, which belongs to the execution node group in claim 1.
-at least one transaction executor configured to transfer the common keyset information in claim 1.
- a ledger manager configured to comprise a plurality of storage spaces that respectively store a plurality of partial blocks, in which pieces of transaction information constituting a single block connected to blockchain are distributed in claim 1.
-a ledger manager configured to retrieve, from the plurality of storage spaces, pieces of key value information corresponding to the common keyset information received from the transaction executor in claim 1.
-a ledger manager configured to transfer same to the transaction executor in claim 1.
- the ledger manager is configured to, when having retrieved at least one key value information stored in the most recent block among the pieces of key value information corresponding to the common keyset information from any one of the plurality of storage spaces, stop an operation of retrieving the key value information from the other storage spaces excluding the one storage space in claim 5.
-the transaction executor is configured to store state information resulting from simulation execution of the transaction proposals in a cache memory in claim 6.
-the transaction executor is configured to use the stored state information as a value for simulation of the next transaction proposal in claim 6.
-the transaction executor is configured to, for simulation for the transaction proposal, first access the cache memory to reference the state information in claim 7.
-the transaction executor is configured to transfer the common keyset information to the ledger manager in claim 7.
-the transaction executor is configured to receive the pieces of key value information from the ledger manager in claim 7.
-the transaction executor is configured to store same in the cache memory in claim 7.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claim limitations invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function.
-a transaction packer configured to generate a transaction (Tx) proposal indicating transaction information according to a user’s transaction request in claim 1.
-a transaction packer configured to add key information corresponding to the transaction request to the generated transaction proposal in claim 1.
-a transaction aggregator configured to generate common transaction batch information and common keyset information corresponding to the transaction proposal according to the key information included in the transaction proposal received from the transaction packer in claim 1.
-a transaction aggregator configured to transmit the common transaction batch information and the common keyset information to each execution node group distinguished and predesignated with regard to the common transaction batch information in claim 1.
-at least one transaction executor configured to execute a simulation regarding the transaction proposals included in the common transaction batch information transmitted from the transaction aggregator, which belongs to the execution node group in claim 1.
-at least one transaction executor configured to transfer the common keyset information in claim 1.
- a ledger manager configured to comprise a plurality of storage spaces that respectively store a plurality of partial blocks, in which pieces of transaction information constituting a single block connected to blockchain are distributed in claim 1.
-a ledger manager configured to retrieve, from the plurality of storage spaces, pieces of key value information corresponding to the common keyset information received from the transaction executor in claim 1.
-a ledger manager configured to transfer same to the transaction executor in claim 1.
- the ledger manager is configured to, when having retrieved at least one key value information stored in the most recent block among the pieces of key value information corresponding to the common keyset information from any one of the plurality of storage spaces, stop an operation of retrieving the key value information from the other storage spaces excluding the one storage space in claim 5.
-the transaction executor is configured to use the stored state information as a value for simulation of the next transaction proposal in claim 6.
-the transaction executor is configured to, for simulation for the transaction proposal, first access the cache memory to reference the state information in claim 7.
-the transaction executor is configured to transfer the common keyset information to the ledger manager in claim 7.
The specification is devoid of adequate structure to perform the claimed functions. The specification does not provide sufficient details such that one of ordinary skill in the art would understand which structure or structures perform(s) the claimed functions. For a computer-implemented means-plus-function claim limitation invoking 35 U.S.C. 112(f), the Federal Circuit has stated that "a microprocessor can serve as structure for a computer-implemented function only where the claimed function is ‘coextensive’ with a microprocessor itself." Such coextensive functions include ‘receiving’ data, ‘storing’ data, and ‘processing’ data, otherwise, all other computer-implemented functions require disclosure of an algorithm. An algorithm is defined as “a finite sequence of steps” for performing a task. See MPEP 2181(II)(B). The specification has failed to disclose any special purpose computer programmed to carry out an algorithm for performing the claimed functions above. Therefore, the claims are indefinite and are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claims 2-7 depend from rejected base claim 1. They do not cure the deficiencies presented above. Therefore, they are also rejected under 35 U.S.C. 112(b) for at least based on their dependency from their rejected base claim.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-7 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As described above, the disclosure does not provide adequate structure to perform the claimed functions. The specification does not demonstrate that applicant has made an invention that achieves the claimed functions because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claims 1-4, 6-11, and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Sun et al. U.S. 2021/0349854 (herein as “Sun”) in view of Bekiyants U.S. 2022/0405765.
Re Claim 1, a ledger information access system having a plurality of storage spaces Fig. 1 – plurality of nodes suggests a plurality of storage spaces, comprising:
a transaction packer configured to generate a transaction (Tx) proposal indicating transaction information according to a user's transaction request and add key information corresponding to the transaction request to the generated transaction proposal ([0070] – “generate a transaction proposal” based on “the client node 260 (i.e. transaction packer) initiates the transaction 291 by constructing and sending a request to the peer node 281,” [0071] – regarding the transaction proposal, “verify…(c) the signature is valid, and (d) that the submitter (client 260, in the example) is properly authorized to perform the proposed operation on that channel,” i.e. key information);
a transaction aggregator configured to generate common transaction batch information and common keyset information corresponding to the transaction proposal according to the key information included in the transaction proposal received from the transaction packer, and transmit the common transaction batch information and the common keyset information to each execution node group distinguished and predesignated with regard to the common
transaction batch information ([0087] – “the processor 104 (i.e. transaction aggregator) may select transactions from the plurality of the transactions that are most likely to be conflicting based on common factors…may combine the selected transactions into a batch,” common factors are analogous to common keyset information, [0088] – “may provide the batch to an endorser peer node,” “the common factors used in the method are any of: a channel name, a chain code name, a chain code function and a chain code parameter list pattern,” [0070] – “The proposal is a request to invoke a chaincode function,” i.e. according to the key information included in the transaction proposal);
at least one transaction executor configured to execute a simulation regarding the one or more transaction proposals included in the common transaction batch information transmitted from the transaction aggregator, which belongs to the execution node group, and transfer the common keyset information ([0098] – “endorsing nodes (i.e. transaction executor) hold smart contracts which simulate the transaction proposals,” “Endorsed transactions are forward[ed] by the client application to ordering service 610,” transactions includes the common factors [0104], i.e. transfer the common keyset information, [0054] – a transaction execution is simulated using relevant key-values, i.e. using the received key value information (Claim 8)).
However, Sun does not expressly disclose
a ledger manager configured to comprise a plurality of storage spaces that respectively store a plurality of partial blocks, in which pieces of transaction information constituting a single block connected to blockchain are distributed, retrieve, from the plurality of storage spaces, pieces of key value information corresponding to the common keyset information received from the transaction executor, and transfer the retrieved pieces of key value information to the transaction executor.
Bekiyants discloses a system for decentralized private blockchains network. Specifically, Bekiyants discloses
a ledger manager configured to comprise a plurality of storage spaces that respectively store a plurality of partial blocks, in which pieces of transaction information constituting a single block connected to blockchain are distributed ([0072] – using a Data Splitter (DS) and a Data Builder (DB) for “partitioning transaction information across multiple data vault services (DVS),” i.e. a plurality of storage spaces), retrieve, from the plurality of storage spaces, pieces of key value information corresponding to the common keyset information received from the transaction executor [0072] – “retrieve data from multiple DVS,” and transfer same to the transaction executor ([0087] – “return the data portion 204 to the DB 305,” [0086] – “Multi-signature requests of the smart contract 303 may be one of the conditions to retrieve data,” thereby suggesting the reconstructed data is returned or transferred to the smart contract that made the request).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sun’s batch processing of transactions with the teachings of data partitioning and storing the partitioned data across multiple DVS in Bekiyants to arrive at the claimed invention. One would be motivated to make the combination to provide increased security for sensitive information Bekiyants, [0085].
Re Claim 2, Sun in view of Bekiyants teach the ledger information access system of claim 1, and Sun in view of Bekiyants further teach wherein the key information includes partial key information in an indetermined form including an array or composite key (Sun, [0071] – the signature, proposed operation, channel, proposal inputs, etc. are all analogous to key information in a composite form, i.e. made up of various parts).
Re Claim 3, Sun in view of Bekiyants teach the ledger information access system of claim 1, and Sun in view of Bekiyants further teach wherein the common keyset information represents a keyset for keys that are identical among pieces of key information included in the one or more transaction proposals (Sun, [0087] – “the processor 104 (i.e. transaction aggregator) may select transactions from the plurality of the transactions that are most likely to be conflicting based on common factors…may combine the selected transactions into a batch,” common factors are analogous to common keyset information that are identical among pieces of key information, [0088] – “the common factors used in the method are any of: a channel name, a chain code name, a chain code function and a chain code parameter list pattern,” the names are reasonably analogous to keys).
Re Claim 4, Sun in view of Bekiyants teach the ledger information access system of claim 1, and Sun in view of Bekiyants further teach wherein the common transaction batch information represents the one or more transaction proposals respectively corresponding to pieces of key information included in the common keyset information (Sun, [0087] – “may select transactions from the plurality of the transactions that are most likely to be conflicting based on common factors…may combine the selected transactions into a batch,” the selected transactions are analogous to a set of transaction proposals, and the common factors are analogous to pieces of key information included in the common keyset information).
Re Claim 6, Sun in view of Bekiyants teach the ledger information access system of claim 1, and Sun in view of Bekiyants further teach wherein the transaction executor is configured to store state information resulting from simulation execution of the one or more transaction proposals in a cache memory and use the stored state information as a value for simulation of the next transaction proposal (Sun, [0098] – “Endorsing nodes hold smart contracts which simulate the transaction proposals,” [0054] – “Every endorsing peer maintains a working world state…The endorsing peer may take a snapshot of the relevant key-values from the local world state to produce a working world state,” relevant key-values from the local world state are analogous to stored state information resulting from simulation execution, and using the local world state to produce a working world state is analogous to using the stored state information in a cache memory as a value for simulation of the next transaction proposal, [0156] – “The system memory 806 can include…cache memory 812”).
Re Claim 7, Sun in view of Bekiyants teach the ledger information access system of claim 6, Sun further teaches wherein the transaction executor is configured to, for the simulation of the transaction proposal, first access the cache memory to reference the state information (Sun, [0054] – “When a transaction execution is simulated, if a corresponding key-value is in the working world state, it will be updated,”) and when the state information for the simulation of the transaction proposal does not exist in the cache memory, […] receive the pieces of key value information […], and store the received pieces of key value information in the cache memory ([0054] – “Otherwise, a new key-value will be picked up from the local world state and the update will be put into the working world state,” i.e. store the received pieces of key value information in the cache memory).
However, Sun does not expressly disclose the following limitations in italics
the transaction executor is configured to transfer the common keyset information to the ledger manager,
receive the pieces of key value information from the ledger manager
Bekiyants discloses a system for decentralized private blockchains network. Specifically, Bekiyants discloses
the transaction executor is configured to transfer the common keyset information to the ledger manager (Fig. 11 – Step 6, request file with various key information, e.g. fileID, accessSchemeID, accessPeriod, from MDDV 202, requesting file with various key information is analogous to transferring the information),
receive the pieces of key value information from the ledger manager (Fig. 11 – Steps 22-23, receive chunks of data and reconstruct data from DVS 402, [0095] – “The DVS 402 may communicate with the…(MDDV DL) network 202,” therefore, the DVS and MDDV are collectively analogous to the ledger manager).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sun’s batch processing of transactions with the teachings of requesting and receiving partitioned data in Bekiyants to arrive at the claimed invention. One would be motivated to make the combination to provide increased security for sensitive information, and decrease risk for data theft or data misappropriation Bekiyants, [0082], [0085].
Re Claims 8-11 and 13-14, they are the method claims of system claims 1-4 and 6-7, respectively. They recite similar distinguishing features as the method claims 1-4 and 6-7. Therefore, they are also rejected for the same reasons above.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Sun et al. U.S. 2021/0349854 (herein as “Sun”) in view of Bekiyants U.S. 2022/0405765 as applied to claims 1 and 8 above, and further in view of Langseth et al. U.S. 2018/0173767 (herein as “Langseth”).
Re Claim 5, Sun in view of Bekiyants teach the ledger information access system of claim 1, however, Sun in view of Bekiyants do not explicitly teach wherein the ledger manager is configured to, when having retrieved at least one key value information stored in a most recent block among the pieces of key value information corresponding to the common keyset information from any one of the plurality of storage spaces, stop an operation of retrieving the key value information from the other storage spaces excluding the one storage space.
Langseth discloses facilitating queries via request-prediction-based temporary storage of query results. Specifically, Langseth discloses
wherein the ledger manager is configured to, when having retrieved at least one key value information stored in the most recent block among the pieces of key value information corresponding to the common keyset information from any one of the plurality of storage spaces, stop an operation of retrieving the key value information from the other storage spaces excluding the one storage space ([0071] – “query subsystem 112 may cause the performance of queries to stop prior to obtaining the other subsets of related data. The performance of the queries may be stopped after at least the subset of the related data is obtained”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sun’s batch processing of transactions with the teachings of stopping performance of a query when related data is obtained in Langseth to arrive at the claimed invention. One would be motivated to make the combination to ensure the computer resources are saved so they can handle other tasks Langseth, [0072].
Re Claim 12, it is the method claim of system claim 5. It recites similar distinguishing features as the method claim 5. Therefore, it is also rejected for the same reasons above.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINE DANG whose telephone number is (571)270-5880. The examiner can normally be reached M-F 9-5pm MT.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698