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 Amendment filed on December 15, 2025.
Claims 1-13 are pending.
Claims 13 is withdrawn.
Claims 1-12 are examined.
This Office Action is given Paper No. 20260207 for references purposes only.
Claim Objections
Claim 1 is objected to for the following reasons:
Claim 1 recites “hashes a respective transaction data.” Examiner assumes that Applicant intended “hashes the respective transaction data.”
Claim 1 recites “receptive of respective homomorphically encrypted transaction data and respective hashed transaction data.” Examiner assumes that Applicant intended “receptive of the respective homomorphically encrypted transaction data and the respective hashed transaction data.”
Claim 1 recites “receiving respective homomorphically encrypted transaction data from the client devices.” Examiner assumes that Applicant intended “receiving the respective homomorphically encrypted transaction data from the client devices.”
Appropriate correction is required on the above objections.
Claim 2 recites “validates the authenticity.” Examiner assumes that Applicant intended “validates an authenticity.” Appropriate correction is required.
Claim 7 recites “designate respective homomorphically encrypted.” Examiner assumes that Applicant intended “designate the respective homomorphically encrypted.” Appropriate correction is required.
Claim 12 is objected to for the following reasons:
Claim 12 recites “hashes a respective transaction data.” Examiner assumes that Applicant intended “hashes the respective transaction data.”
Claim 12 recites “receptive of respective homomorphically encrypted transaction data and respective hashed.” Examiner assumes that Applicant intended “receptive of the respective homomorphically encrypted transaction data and the respective hashed.”
Claim 12 recites “receiving respective homomorphically encrypted transaction data.” Examiner assumes that Applicant intended “receiving the respective homomorphically encrypted transaction data.”
Claim Rejections - 35 USC § 112b
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-12 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 pre-AIA the applicant regards as the invention.
Claim 1 recites “wherein the self-executing code performs at least one mathematical operation on the respective homomorphically encrypted transaction data without accessing the respective transaction data in its unencrypted form”; “wherein the self-executing code performs the at least one mathematical operation on the initial homomorphically encrypted transaction data and the updated homomorphically encrypted transaction data”; and “wherein the self-executing code will not permit processing of any further updated homomorphically encrypted transaction data from any client device for the given transaction after the time limit.”
These phrases render the claim vague and indefinite because it is unclear whether the scope of the claim is drawn to the system alone (i.e. a first client-server network including a plurality of client devices connected to at least one server, and a network interface), or drawn to the combination of the system and a distributed ledger network running a self-executing code.
Because a potential infringer of claim 1 would not know whether direct infringement required creation or possession of the system alone (i.e. a first client-server network including a plurality of client devices connected to at least one server, and a network interface), or the possession of the system and a distributed ledger network running a self-executing code, the claim is indefinite under 35 U.S.C. §112b.
Claim 1 recites “stores a corresponding plurality of hashed transaction data on the distributed ledger network.” This phrase is vague and indefinite because it is unclear whether this refers to “the plurality of respective hashed transaction data” previously recited, or to “a new plurality of hashed transaction data.” For purposes of applying the prior art only, Examiner will interpret as “a new plurality of hashed transaction data.” Claim 12 is similarly rejected.
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-12 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 homomorphically encrypting transaction data, hashing the transaction data, and storing the transaction data, 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 12, representative of claim 1, includes the following limitations:
Entering a plurality of transaction data for a given transaction;
Homomorphically encrypting the transaction data to create a homomorphically encrypted transaction data;
Hashing the transaction data to create a hashed transaction data;
Providing the homomorphically encrypted transaction data to the network;
Performing a mathematical operation on the homomorphically encrypted transaction data without accessing the transaction data in its unencrypted form;
Implementing a time limit for receiving homomorphically encrypted transaction data from a client device;
Performing the mathematical operation on initial homomorphically encrypted transaction data and updated homomorphically encrypted transaction data;
Not processing of further homomorphically encrypted transaction data after the time limit.
Step 2A Prong 2: The claim limitations recite the following additional elements that are beyond the judicial exception:
A first client-server network including a plurality of client devices;
At least one server;
A network interface;
A distributed ledger network;
Storing a plurality of hashed transaction data;
Storing a corresponding plurality of hashed transaction data.
These additional elements are not indicative of integration into a practical application because:
They add the words “apply it” (or an equivalent) with the judicial exception, or are mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. See MPEP 2106.05(f).
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).
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 of “a first client-server network including a plurality of client devices”, “at least one server”, “a network interface”, and “a distributed ledger network” are mere instructions to apply an exception, 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 first client-server network including a plurality of client devices”, “at least one server”, “a network interface”, and “a distributed ledger network” are re-evaluated to determine whether they constitute significantly more. Examiner finds that the additional elements of “a first client-server network including a plurality of client devices”, “at least one server”, “a network interface”, and “a distributed ledger network” are simply the use of a computer in its ordinary capacity and does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262 and MPEP 2106.05(f). For example, the additional elements only provide a result-oriented solution and lack details as to how the computer performs the modifications, which is equivalent to “apply it”. See Alice Corp. v. CLS Bank, 134 S. Ct. 2347, 2357 and MPEP 2106.05(f).
As discussed with respect to step 2A prong 2 above, the additional elements of “storing a plurality of hashed transaction data” and “storing a corresponding plurality of hashed transaction data” 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 “storing a plurality of hashed transaction data” and “storing a corresponding plurality of hashed transaction data” are re-evaluated to determine whether they constitute well-understood, routine, and conventional activity in the field. The “storing 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 “storing a plurality of hashed transaction data” and “storing a corresponding plurality of hashed transaction data” are well-understood, routine, and conventional is supported under Berkheimer.
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 utilizing a private key and public key and validating the authenticity of the homomorphically encrypted transaction data, 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 the code is a smart contract, which is merely describing data and further defining the abstract idea.
Claim 4 recites the encryption comprises polymorphic encryption and the server control the network interface, which is merely describing data and further defining the abstract idea.
Claim 5 recites the data includes a transaction identification, which is merely describing data and further defining the abstract idea.
Claim 6 recites the data includes a client device identification, which is merely describing data and further defining the abstract idea.
Claim 7 recites the client device can designate the transaction data as final prior to the end of the time limit, which is insignificant extra-solution activity (e.g. mere data gathering). See CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, and MPEP 2106.05(g).
Claim 8 recites receiving a client device identification for an initiated transaction, which is insignificant extra-solution activity (e.g. mere data gathering). See CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, and MPEP 2106.05(g).
Claims 9-10 recite storing various data, 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).
Claim 11 recites the transaction is a vote for a resolution, which is merely describing data and further defining the abstract idea.
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-3, 5, 7, and 10-12 are rejected under 35 U.S.C. 103(a) as being unpatentable over Agrawal et al. (US 2019/0164153) in view of Cash et al. (US 10,762,506).
Claims 1, 12
Agrawal discloses:
a first client-server network (blockchain network, see [0029]) including a plurality of client devices (computing devices, see [0029]) connected to at least one server (server, see [0027]) for entering a plurality of respective transaction data (transaction data, see [0030]) relating to a given transaction;
a network interface (interface, see [0026]) controlled by the at least one server, receptive of respective homomorphically (homomorphic encryption, see [0086]) encrypted transaction data (transaction data, see [0030]) and respective hashed transaction data from the client devices, and interfacing with a distributed ledger network (ledger in blockchain network, see [0029]) running a self-executing code (smart contract, see [0078]) related to the given transaction and storing a plurality of respective hashed transaction data (stores validated transaction data records, see [0078]) in accordance with the self-executing code;
wherein the self-executing code implements a time limit (sign-up phase to the final tally, see [0223-0224]) for receiving respective homomorphically encrypted transaction data from the client devices for the given transaction such that each client device can provide initial homomorphically encrypted transaction data (sign-up phase, see [0224]) and updated homomorphically encrypted transaction data (voting stage, see [0224]) for the given transaction until the end of the time limit (final tally, see [0223]);
wherein the self-executing code performs the at least one mathematical operation (e.g. encrypted, see [0086]) on the initial homomorphically encrypted transaction data and the updated homomorphically encrypted transaction data;
wherein the self-executing code will not permit processing of any further updated homomorphically encrypted transaction data (lock status, ZSC will process the transfer because it is locked to PC, see [0082, 0221]) from any client device for the given transaction after the time limit.
Agrawal does not disclose:
Wherein each… data;
Wherein the network… form;
Stores… network.
Cash teaches:
wherein each of said plurality of client devices homomorphically encrypts a respective transaction data for said given transaction to create a respective homomorphically encrypted transaction data (homomorphic encryption of transactions, see C22 L20-48) and hashes a respective transaction data to create a respective hashed transaction data (transaction data hashes, see C7 L4-43);
wherein the network interface provides the respective homomorphically encrypted transaction data from the client devices to the distributed ledger network wherein the self-executing code performs at least one mathematical operation (e.g. processed correctly by the smart contracts, see C22 L20-48) on the respective homomorphically encrypted transaction data without accessing the respective transaction data in its unencrypted form;
stores a corresponding plurality of hashed transaction data (transaction data hashes, see C7 L4-43) on the distributed ledger network (added to blockchain, see C7 L4-43).
Agrawal discloses a first client-server network including a plurality of client devices, a network interface receptive of homomorphically encrypted transaction data, self-executing code implementing a time limit, the code performs a mathematical function, and does not permit processing after the time limit. Agrawal does not disclose homomorphically encrypting transaction data, performing a mathematical operation on the homomorphically encrypted transaction data, and storing the hashed transaction data, but Cash 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 blockchain system for confidential and anonymous smart contracts of Agrawal with the homomorphically encrypting transaction data, performing a mathematical operation on the homomorphically encrypted transaction data, and storing the hashed transaction data of Cash because 1) a need exists for implementing confidential and anonymous token transfer in a blockchain system (see Agrawal [0004]); and 2) a need exists for a system to perform settlement that is not costly, cumbersome, and overly reliant on third parties (see Cash C1 L5-25). Homomorphically encrypting transaction data, performing a mathematical operation on the homomorphically encrypted transaction data, and storing the hashed transaction data ensures security of the data.
Claim 2
Furthermore, Agrawal discloses:
the homomorphic encryption utilizes a private key and a public key (private and public key pair, see [0086]) and wherein the distributed ledger network validates the authenticity (validate the cryptographic proof, see [0087]) of the respective homomorphically encrypted transaction data using the public key (using public keys, see [0087]) of the corresponding client device.
Claim 3
Furthermore, Agrawal discloses:
the self-executing code is a smart contract (smart contract, see [0078]).
Claim 5
Furthermore, Agrawal discloses:
the respective homomorphically encrypted transaction data includes a transaction identification (record identifier, see [0019]).
Claim 7
Furthermore, Agrawal discloses:
each client device can designate respective homomorphically encrypted transaction data for the given transaction as final prior to the end of the time limit (e.g. Alice cashes out at any time, see [0218]).
Claim 10
Furthermore, Agrawal discloses:
the distributed ledger network stores a homomorphically encrypted (homomorphic encryption, see [0086]) client device identification, a public key for a client device (public key, see [0086]), and whether the homomorphically encrypted transaction data is initial (e.g. Fund function, see [0086]), updated or final.
Claim 11
Furthermore, Agrawal discloses:
the given transaction is a vote (vote, see [0223-0224]) for a resolution and wherein the self-executing code adds the total votes (votes summed up, see [0223]) for the resolution from each client device as the votes are updated.
Claims 4, 6, and 8 are rejected under 35 U.S.C. 103(a) as being unpatentable over Agrawal et al. (US 2019/0164153), in view of Cash et al. (US 10,762,506), and further in view of Umezurike (US 10,999,276).
Claim 4
Agrawal in view of Cash discloses the limitations above. Agrawal in view of Cash does not disclose:
The homomorphic… encryption;
Wherein the server… transaction.
Umezurike teaches:
the homomorphic encryption comprises polymorphic encryption (polymorphic encryption, see claim 1); and
wherein the server controls the network interface to selectively homomorphically encrypt transaction data for the given transaction.
Agrawal in view of Cash discloses a first client-server network including a plurality of client devices, homomorphically encrypting transaction data, a network interface receptive of homomorphically encrypted transaction data, performing a mathematical operation on the homomorphically encrypted transaction data, self-executing code implementing a time limit, the code performs a mathematical function, and storing the hashed transaction data. Agrawal in view of Cash does not disclose polymorphic encryption, but Umezurike 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 blockchain system for confidential and anonymous smart contracts of Agrawal, in view of Cash, with the polymorphic encryption of Umezurike because a need exists for a more efficient, robust, comprehensive cryptography system (see Umezurike C2 L20-25). Using polymorphic encryption allows for more security.
Claim 6
Agrawal in view of Cash discloses the limitations above. Agrawal in view of Cash does not disclose:
The respective… identification.
Umezurike teaches:
the respective homomorphically encrypted transaction data includes a client device identification (international mobile equipment identity (IMEI) number, see claim 2).
Agrawal in view of Cash discloses a first client-server network including a plurality of client devices, homomorphically encrypting transaction data, a network interface receptive of homomorphically encrypted transaction data, performing a mathematical operation on the homomorphically encrypted transaction data, self-executing code implementing a time limit, the code performs a mathematical function, and storing the hashed transaction data. Agrawal in view of Cash does not disclose a client device identification, but Umezurike 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 blockchain system for confidential and anonymous smart contracts of Agrawal, in view of Cash, with the client device identification of Umezurike because a need exists for a more efficient, robust, comprehensive cryptography system (see Umezurike C2 L20-25). A client device identification allows for more security.
Claim 8
Agrawal in view of Cash discloses the limitations above. Furthermore, Agrawal discloses:
a description of the initiated transaction (e.g. send payment every time Alice tweets about Bob, see [0218]), and a time deadline (expiration date, see [0218]).
Agrawal in view of Cash does not disclose:
The self-executing code… transaction.
Umezurike teaches:
the self-executing code receives a client device identification (international mobile equipment identity (IMEI) number, see claim 2) for an initiated transaction.
Agrawal in view of Cash discloses a first client-server network including a plurality of client devices, homomorphically encrypting transaction data, a network interface receptive of homomorphically encrypted transaction data, performing a mathematical operation on the homomorphically encrypted transaction data, self-executing code implementing a time limit, the code performs a mathematical function, and storing the hashed transaction data. Agrawal in view of Cash does not disclose a client device identification, but Umezurike 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 blockchain system for confidential and anonymous smart contracts of Agrawal, in view of Cash, with the client device identification of Umezurike because a need exists for a more efficient, robust, comprehensive cryptography system (see Umezurike C2 L20-25). A client device identification allows for more security.
Response to Arguments
101 arguments
Applicant argues that the claimed invention has a practical application and/or is significantly more.
Examiner disagrees. Please see revised 101 rejection above. The claims recite an abstract idea of homomorphically encrypting transaction data, hashing the transaction data, and storing the transaction data, which is a certain method of organizing human activity. The additional elements merely use a computer as a tool to perform an abstract idea, or add insignificant extra-solution activity to the judicial exception.
103 arguments
Applicant argues that the prior art does not teach the amendments.
Please see revised rejection.
Claim Interpretation
Applicant is reminded that functional recitation(s) using the word and/or phrases “for”, “adapted to”, or other functional language (e.g. see claims 1 and 12 which recite “each client device can provide”) have been considered but are given little patentable weight because they fail to add any structural limitations and are thereby regarded as intended use language. To be especially clear, all limitations have been considered. However, a recitation of the intended use of the claimed product must result in a structural difference between the claimed product and the prior art in order to patentably distinguish the claimed product from the prior art. If the prior art structure is capable of performing the intended use, then it reads on the claimed limitation. In re Casey, 370 F.2d 576, 152 USPQ 235 (CCPA 1967) ("The manner or method in which such a machine is to be utilized is not germane to the issue of patentability of the machine itself.”); In re Otto, 136 USPQ 458, 459 (CCPA 1963). See also MPEP §§ 2106 II (C.), 2114 and 2115. Unless expressly noted otherwise by Examiner, the claim interpretation principles in the paragraph apply to all examined claims currently pending.
Conclusion
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 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 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