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 .
This initial written action is responding to the communication dated on 03/31/2025.
Claim 1 is canceled
Claims 2-16 are submitted for examination.
Claims 2-16 are pending.
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.
Priority
This application Claim priority of continuation of U.S. patent application Ser. No. 18/539,095, filed 13 Dec. 2023, which is a continuation of U.S. patent application Ser. No. 17/678,926, filed 23 Feb. 2022, which is a continuation of U.S. patent application Ser. No. 16/772,136, filed 11 Jun. 2020, which is a 371 National Stage of International Patent Application No. PCT/IB2018/059918, filed 12 Dec. 2018, which claims priority to United Kingdom Patent Application No. 1813772.9, filed 23 Aug. 2018, which claims priority to United Kingdom Patent Application No. 1813770.3, filed 23 Aug. 2018, which claims priority to United Kingdom Patent Application No. 1720768.9, filed 13 Dec. 2017.
Claim Objections
Claims 15 is objected for following reason.
The claims 15 is written in a form, so it cannot be identified as an independent claim or a dependent claim. In addition, Claim 15 is a system claim while Claim 2 is a method claim, and thus both claims are from different statutory classes. Examiner suggest writing the claim in a proper independent/dependent form with all the required limitations.
For the purpose of examination Claim 15 will be considered as an independent claim.
Claims 16 is objected for following reason.
The claims 16 is written in a form, so it cannot be identified as an independent claim or a dependent claim. In addition, Claim 16 is a non-transitory computer-readable storage medium claim while Claim 2 is a method claim, and thus both claims are from different statutory classes. Examiner suggest writing the claim in a proper independent/dependent form with all the required limitations.
For the purpose of examination Claim 16 will be considered as an independent claim.
Claims 2-14 objected to because of the following informalities: Claim 2-14 recites “A method according to….”. Examiner suggest writing the claim as “The method according to……”. Appropriate correction is required.
Claim 6 objected to because of the following informalities: Claim 6 recites a limitation, “…wherein the secret is shared between the first computing entity and the second computing entity without using a cryptographically protected communications channel”. There is an insufficient antecedent basis. Appropriate correction is required.
Claim 7 objected to because of the following informalities: Claim 7 recites, “A method according to claim 2, wherein the first computing entity and the second computing entity collectively determine the first digital asset and the second digital asset.”. There is an insufficient antecedent basis. Appropriate correction is required.
Claim 11 objected to because of the following informalities: Claim 11 recites, “A method according to claim 2, wherein the smart contract comprises a P2SH type unlocking script that allows the third computing entity to unlock the first digital asset and the second digital asset in response to providing a proof of correct execution.”. There is an insufficient antecedent basis. Appropriate correction is required.
Claim 13 objected to because of the following informalities: Claim 13 recites, “A method according to claim 2, wherein the second polynomial is inaccessible to the first computing entity.”. There is an insufficient antecedent basis. Appropriate correction is required.
Claim 11 objected to because of the following informalities: Claim 11 recites, “A method according to claim 2, wherein the smart contract comprises a P2SH type unlocking script that allows the third computing entity to unlock the first digital asset and the second digital asset in response to providing a proof of correct execution.”. Applicant is reminded that any acronym introduced for the first time is required to be specified in its entirety. Appropriate correction is required.
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 2-16 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15 of U.S. Patent No. 11,271,729. Although the claims at issue are not identical, they are not patentably distinct from each other. Please refer to comparison table below.
Instant Application 19/095,993
US PAT. # US 11,271,729 (App. # 17/710,112)
SYSTEM AND METHOD FOR MULTI-PARTY GENERATION OF BLOCKCHAIN-BASED SMART CONTRACT
SYSTEM AND METHOD FOR MULTI-PARTY GENERATION OF BLOCKCHAIN-BASED SMART CONTRACT
2
A computer-implemented method comprising, at a first computing entity: determining, based at least in part on a first polynomial and at least two elliptic curve points, a set of elliptic curve points for a second computing entity; making a subset of the set of elliptic curve points available to the second computing entity; determining, a common reference string comprising a verification key and an evaluation key, wherein the common reference string is also determinable by the second computing entity as a result of the first computing entity providing the subset to the second computing entity. and generating a smart contract comprising a first transaction input provided by the first computing entity and a second transaction input provided by the second computing entity, wherein correct execution of the smart contract by a third computing entity results in the third computing entity being able to generate a blockchain transaction using an output of the smart contract.
1
A computer-implemented method comprising, at a first computing entity: determining, based at least in part on a first polynomial and at least two elliptic curve points, a first set of elliptic curve points for a second computing entity; making a subset of the first set of elliptic curve points available to the second computing entity; receiving a second set of elliptic curve points generated using a second polynomial; determining a power of a secret based at least in part on the first set and the second set; determining, based at least in part on the power of the secret, a common reference string comprising a verification key and an evaluation key, wherein the common reference string is also determinable by the second computing entity as a result of the first computing entity providing the subset to the second computing entity; and generating a smart contract comprising a first transaction input provided by the first computing entity and a second transaction input provided by the second computing entity, wherein correct execution of the smart contract by a third computing entity results in the third computing entity being able to generate a blockchain transaction using an output of the smart contract.
3
A method according to claim 2, wherein the set of elliptic curve points comprises corresponding elliptic curve points for powers of the first polynomial.
2
The method according to claim 1, wherein the first set of elliptic curve points comprises corresponding elliptic curve points for powers of the first polynomial.
4
A method according to claim 2, wherein the first polynomial is of at least order 2.
3
The method according to claim 1, wherein the first polynomial is of at least order 2.
5
A method according to claim 2, wherein the subset is the set of elliptic curve points.
4
The method according to claim 1, wherein the subset is the first set of elliptic curve points.
6
A method according to claim 2, wherein the secret is shared between the first computing entity and the second computing entity without using a cryptographically protected communications channel.
5
The method according to claim 1, wherein the secret is shared between the first computing entity and the second computing entity without using a cryptographically protected communications channel.
7
A method according to claim 2, wherein the first computing entity and the second computing entity collectively determine the first digital asset and the second digital asset.
6
The method according to claim 1, wherein the first computing entity and the second computing entity collectively determine a first digital asset and a second digital asset to be transferred by the blockchain transaction.
8
A method according to claim 2, further comprising: determining, based on a third polynomial and the at least two elliptic curve points, a third set of elliptic curve points for the second computing entity; making a second subset of the third set of elliptic curve points available to the second computing entity; receiving a fourth set of elliptic curve points; determining a parameter based at least in part on the third set and the fourth set, the parameter also determinable by the second computing entity as a result of the first computing entity providing the second subset to the second computing entity; and wherein the determining of the common reference string is based further at least in part on the parameter.
7
The method according to claim 1, further comprising: determining, based on a third polynomial and the at least two elliptic curve points, a third set of elliptic curve points for the second computing entity; making a second subset of the third set of elliptic curve points available to the second computing entity; receiving a fourth set of elliptic curve points; determining a parameter based at least in part on the third set and the fourth set, the parameter also determinable by the second computing entity as a result of the first computing entity providing the second subset to the second computing entity; and wherein the determining of the common reference string is based further at least in part on the parameter.
9
A method according to claim 2, further comprising sharing an elliptic curve parameter between the first computing entity and the second computing entity using Shamir's Secret Sharing Scheme.
8
The method according to claim 1, further comprising sharing an elliptic curve parameter between the first computing entity and the second computing entity using Shamir's Secret Sharing Scheme.
10
A method according to claim 2, further comprising exchanging a scalar parameter between the first computing entity and the second computing entity using a Diffie-Hellman scheme.
9
The method according to claim 1, further comprising exchanging a scalar parameter between the first computing entity and the second computing entity using a Diffie-Hellman scheme.
11
A method according to claim 2, wherein the smart contract comprises a P2SH type unlocking script that allows the third computing entity to unlock the first digital asset and the second digital asset in response to providing a proof of correct execution.
10
The method according to claim 1, wherein the smart contract comprises a P2SH type unlocking script that allows the third computing entity to unlock a first digital asset and a second digital asset in response to providing a proof of correct execution.
12
A method according to claim 2, wherein the first computing entity makes the subset available to the second computing entity via an off-chain communications channel.
11
The method according to claim 1, wherein the first computing entity makes the subset available to the second computing entity via an off-chain communications channel.
13
A method according to claim 2, wherein the second polynomial is inaccessible to the first computing entity.
12
The method according to claim 1, wherein the second polynomial is inaccessible to the first computing entity.
14
A method according to claim 2, wherein the at least two elliptic curve points are two different elliptic curve points.
13
The method according to claim 1, wherein the at least two elliptic curve points are two different elliptic curve points.
15
A system, comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method according to claim 2.
14
A system, comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, cause the system to perform the computer-implemented method according to claim 1.
16
A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to at least perform the computer-implemented method according to claim 2.
15
A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to at least perform the computer-implemented method according to claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 9-10 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (US PGPUB. # US 2017/0070485, hereinafter “Kumar”), and further in view of Parno et al. (NPL-“Pinocchio: Nearly Practical Verifiable Computation”., hereinafter “Parno”), and further in view of Sheng et al. (US PGPUB. # US 2017/0221052, hereinafter “Sheng”).
Referring to Claims 2, 15 and 16:
Regarding Claim 2, Kumar teaches,
A computer-implemented method comprising, at a first computing entity: determining, based at least in part on a first polynomial and at least two elliptic curve points, a set of elliptic curve points for a second computing entity; (Fig. 7A, ¶46, “may use elliptic curve cryptography (ECC) to generate corresponding keys”, “The elliptic curve point multiplication may be an operation of successively adding a point along an elliptic curve to itself repeatedly“, Fig. 7B(753), ¶48, i.e. set of elliptic curve points are determined by a first entity)
making a subset of the set of elliptic curve points available to the second computing entity; (Fig. 7B(754), ¶48, “transmit the first elliptic curve multiplication value from the first entity to a second entity”, i.e. subset of elliptic curve points, made available to second entity)
Kumar does not teach explicitly,
determining, a common reference string comprising a verification key and an evaluation key, wherein the common reference string is also determinable by the second computing entity as a result of the first computing entity providing the subset to the second computing entity. and
generating a smart contract comprising a first transaction input provided by the first computing entity and a second transaction input provided by the second computing entity, wherein correct execution of the smart contract by a third computing entity results in the third computing entity being able to generate a blockchain transaction using an output of the smart contract.
However, Parlo teaches,
determining, a common reference string comprising a verification key and an evaluation key, wherein the common reference string is also determinable by the second computing entity as a result of the first computing entity providing the subset to the second computing entity. (Abstract, “the client creates a public evaluation key to describe her computation; this setup is proportional to evaluating the computation once. The worker then evaluates the computation on a particular input and uses the evaluation key to produce a proof of correctness”, Page-103, Column-2, “the client chooses a function and generates a public evaluation
key and a (small) public verification key. Given the evaluation key, a worker verifiably computes the function on an input and produces a proof (or signature) to accompany the result. Anyone (not just the client) can then use the verification
key to check the correctness of the worker’s result for the specific input used”, Page-104, Cloumn-2, “Public verifiable computation”, Page-106, Column 1 and Column 2, Page-107).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Parlo with the invention of Kumar.
Kumar teaches, selecting set of elliptical curve points and sharing subset of the elliptic curve points with a second entity. Parlo teaches, generating verification key and evaluation key based on elliptic curve points. Therefore, it would have been obvious to generate verification key and evaluation key based on elliptic curve points of Parlo with selecting set of elliptical curve points and sharing subset of the elliptic curve points with a second entity of Kumar for efficiently verifying general computations while making only cryptographic assumptions.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Combination of Kumar and Parlo does not teach explicitly,
generating a smart contract comprising a first transaction input provided by the first computing entity and a second transaction input provided by the second computing entity, wherein correct execution of the smart contract by a third computing entity results in the third computing entity being able to generate a blockchain transaction using an output of the smart contract.
However, Sheng teaches,
generating a smart contract comprising a first transaction input provided by the first computing entity and a second transaction input provided by the second computing entity, wherein correct execution of the smart contract by a third computing entity results in the third computing entity being able to generate a blockchain transaction using an output of the smart contract. (Fig. 8 (844, 846, 848), ¶181, Fig. 41, ¶340, ¶343, ¶346, i.e. smart contract is generated based on a first transaction provided by a first entity and second transaction provided by a second entity. A blockchain transaction is generated by a third entity).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sheng with the invention of Kumar in view of Parlo.
Kumar in view of Parlo teaches, selecting set of elliptical curve points and sharing subset of the elliptic curve points with a second entity and generating verification key and evaluation key based on elliptic curve points. Sheng teaches generating a blockchain transaction based on a smart contract with input from a first entity and a second entity. Therefore, it would have been obvious to generate a blockchain transaction based on a smart contract with input from a first entity and a second entity of Sheng into the teachings of Kumar in view of Parlo for securely Electronic Funds Transfer with Protection of Transmitted Data by Encryption and Decryption and Verification.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 15, it is a system claim of above method Claim 1 and therefore Claim 15 is rejected with the same rationale as applied against Claim 1 above.
Regarding Claim 16, it is a non-transitory computer-readable storage medium claim of above method Claim 1 and therefore Claim 16 is rejected with the same rationale as applied against Claim 1 above.
Regarding Claim 9 rejection of Claim 2 is included and for the same motivation combination of Kumar and Parlo does not teach explicitly,
A method according to claim 2, further comprising sharing an elliptic curve parameter between the first computing entity and the second computing entity using Shamir's Secret Sharing Scheme.
However, Sheng teaches,
A method according to claim 2, further comprising sharing an elliptic curve parameter between the first computing entity and the second computing entity using Shamir's Secret Sharing Scheme. (¶471).
Regarding Claim 10 rejection of Claim 2 is included and for the same motivation Kumar teaches,
A method according to claim 2, further comprising exchanging a scalar parameter between the first computing entity and the second computing entity using a Diffie-Hellman scheme. (¶47).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (US PGPUB. # US 2017/0070485, hereinafter “Kumar”), and further in view of Parno et al. (NPL-“Pinocchio: Nearly Practical Verifiable Computation”., hereinafter “Parno”), and further in view of Sheng et al. (US PGPUB. # US 2017/0221052, hereinafter “Sheng”), and further in view of Smith et al. (US PGPUB. # US 2017/0317997, hereinafter “Smith”).
Regarding Claim 11, rejection of Claim 2 is included and combination of Kumar, Parno and Sheng does not teach explicitly,
A method according to claim 2, wherein the smart contract comprises a P2SH type unlocking script that allows the third computing entity to unlock the first digital asset and the second digital asset in response to providing a proof of correct execution.
However, Smith teaches,
A method according to claim 2, wherein the smart contract comprises a P2SH type unlocking script that allows the third computing entity to unlock the first digital asset and the second digital asset in response to providing a proof of correct execution. (¶17, ¶138, ¶186, ¶196).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Smith with the invention of Kumar in view of Parlo and Sheng.
Kumar in view of Parlo and Sheng teaches, selecting set of elliptical curve points and sharing subset of the elliptic curve points with a second entity and generating verification key and evaluation key based on elliptic curve points and generating a blockchain transaction based on a smart contract with input from a first entity and a second entity. Smith teaches, inserting P2SH script in the smart contract. Therefore, it would have been obvious to insert P2SH script in the smart contract of Smith into the teachings of Kumar in view of Parlo and Sheng for protecting the use of user identity and for securely providing personal information.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Claims 3-8 and 12-14: Objected
Claims 3-8 and 11-14 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Kumar teaches, Encrypted data transmitted from a second entity to a first entity may be received. The encrypted data may be encrypted by a location based public key based on a public key and a location associated with the second entity. A location associated with the first entity may be identified. A location based private key may be generated based on a private key that corresponds to the public key and the location associated with the first entity. Furthermore, the encrypted data may be decrypted with the location based private key when the location associated with the first entity matches the location associated with the second entity. (Abstract). As shown in FIG. 7A, the environment 700 may include a first entity 610 with a first location aware cryptography module 615 and a second entity 620 with a second location aware cryptography module 625. Each of the first entity 610 and the second entity 620 may generate or derive a key. In some embodiments, the key generated by the first entity 610 and the key generated by the second entity 620 may be identical when the first entity 610 and the second entity 620 are associated with the same location information. Alternatively, the key generated by the first entity 610 and the key generated by the second entity 620 may be different when the first entity 610 and the second entity 620 are not associated with the same location information. The first entity 610 may transmit data 710 to the second entity 620 and the second entity 620 may transmit data 720 to the first entity 610. Furthermore, the first entity 610 may then generate a key based on location information determined or generated by the first entity 610, additional data associated with the first entity 610, and the data 720 received from the second entity 620. Additionally, the second entity 620 may generate a corresponding key based on location information determined or generated by the second entity 620, additional data of the second entity 620, and the data 710 that is received from the first entity 610. In some embodiments, the data 710 and the data 720 may each be based on a random number and a value corresponding to a point on an elliptic curve. For example, the entity 610 and the entity 620 may use elliptic curve cryptography (ECC) to generate corresponding keys. ECC may refer to public-key cryptography that is based on algebraic structure of elliptic curves over finite fields. The entity 610 may generate a first random number and the entity 620 may generate a second random number. The entity 610 may perform elliptic curve point multiplication based on the first random number and a point on an elliptic curve to generate a first elliptic curve point multiplication value (e.g., the data 710) and the entity 620 may also perform elliptic curve point multiplication based on the second random number and the same point on the elliptic curve to generate a second elliptic curve point multiplication value (e.g., the data 720). The elliptic curve point multiplication may be an operation of successively adding a point along an elliptic curve to itself repeatedly (e.g., based on the first or second random numbers). The first entity 610 may then generate or derive a first key based on first information determined by the first entity 610, the first random number, and the second elliptic curve point multiplication value that is received from the second entity 620 from the data 720. Furthermore, the second entity 620 may then generate or derive a second key based on second location information determined by the second entity 620, the second random number, and the first elliptic curve point multiplication value received from the first entity 610 from the data 710. If the first location information is identical to the second location information, then the first key and the second key may then be identical and each of the first entity 610 and the second entity 620 may encrypt data to be transmitted to the other entity and decrypt data received from the other entity. (Fig. 7A, ¶44-46). FIG. 7B illustrates an example flow diagram of a method 750 corresponding to a first entity using location aware cryptography with a key derivation technique to transmit data with a second entity. In general, the method 750 may be performed by processing logic that may comprise hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some embodiments, the method 750 may be performed by the location aware cryptography module 130 or 400 of FIGS. 1 and 4 or by the location aware cryptography module 615 of a first entity 610 initiating a request to transmit data to a second entity 620 of FIG. 7A. The method 750 may be referred to as a Diffie-Hellman key exchange used to exchange a cryptographic key between entities. The Diffie-Hellman key exchange method 750 allows two entities (e.g., the first and second entities 610 and 620) that have no prior knowledge of each other to jointly establish a shared secret key (e.g., the session key) that may be used encrypt and decrypt subsequent communications or data with a symmetric key. As shown in FIG. 7B, the method 750 may begin with the processing logic receiving a value corresponding to a point on an elliptic curve (block 751). The processing logic may further generate a first random number and a first location information associated with a first entity (block 752). The processing logic may generate first elliptic curve multiplication value based on a combination of the first value and the first random number (block 753). For example, an elliptic curve multiplication operation may be performed on the first random number and the point on the elliptic curve. The processing logic may further transmit the first elliptic curve multiplication value from the first entity to a second entity (block 754). Additionally, the processing logic may receive, from the second entity, a second elliptic curve multiplication value that is based on a combination of the value corresponding to the point on the elliptic curve and a second random number (block 755). For example, the second entity may generate a second random number independently from the first entity and may perform an elliptic curve multiplication operation based on the second random number and the point on the elliptic curve. Furthermore, the processing logic may generate a first key based on the first location information, the first random number, and the second elliptic curve multiplication value that is received from the second entity (block 756). Furthermore, the second entity may also generate a second key based on the second location information determined by the second entity, the second random number determined by the second entity, and the first elliptic curve multiplication value received from the first entity. If the first location information is the same as the second location information, then the first key and the second key may be identical. (Fig. 7B, ¶47-¶48).
Parlo teaches, To instill greater confidence in computations outsourced to the cloud, clients should be able to verify the correctness of the results returned. To this end, we introduce Pinocchio, a built system for efficiently verifying general computations
while relying only on cryptographic assumptions. With Pinocchio, the client creates a public evaluation key to describe her computation; this setup is proportional to evaluating the computation once. The worker then evaluates the computation on a particular input and uses the evaluation key to produce a proof of correctness. The proof is only 288 bytes, regardless of the computation performed or the size of the IO. Anyone can check the proof using a public verification key. Crucially, our evaluation on seven applications demonstrates that Pinocchio is efficient in practice too. Pinocchio’s
verification time is a fixed 10 ms plus 0.4–15 μs per IO element: 5–7 orders of magnitude less than previous work23; indeed, Pinocchio is the first general-purpose system to demonstrate verification cheaper than native execution (for some apps). The worker’s proof effort is still expensive, but Pinocchio reduces it by 19×–60× relative to prior work. As an additional feature, Pinocchio allows the worker to include private inputs in the computation and prove that she performed the computation correctly without revealing any information about the private inputs to the client. Finally,
to aid development, Pinocchio provides an end-to-end tool chain that compiles a subset of C into programs that implement the verifiable computation protocol. (Abstract).
Pinocchio is a concrete system for efficiently verifying general computations while making only cryptographic assumptions. In particular, Pinocchio supports public
verifiable computation (VC),9, 20 which allows an untrusted worker to produce signatures of computation. Initially, the client chooses a function and generates a public evaluation key and a (small) public verification key. Given the evaluation key, a worker verifiably computes the function on an input and produces a proof (or signature) to accompany the result. Anyone (not just the client) can then use the verification
key to check the correctness of the worker’s result for the specific input used.
As an additional feature, Pinocchio supports zero-knowledge VC, in which the worker convinces the client that it knows one or more private inputs with a particular
property, without revealing any information about the input. For example, Pantry4 uses Pinocchio to compute Map-Reduce jobs (e.g., image matching) over private data (e.g.,
DMV photos) held by a server. Recent work also employs Pinocchio to anonymize Bitcoin transactions by proving, in zero knowledge, that the transactions do not create or destroy money.2, 8. (Page-103, Column 2).
To construct a VC protocol from a quadratic program, we
map each polynomial—for example, vk(x)—of the quadratic
program to an element gv
k
( s) in an elliptic curve group G,
where s is a secret value selected by the client, and g is a generator
of G. These group elements are given to the worker.
For a given input, the worker evaluates the circuit directly
to obtain the output and the values of the internal circuit
wires. These values correspond to the coefficients ci of
the quadratic program. Thus, the VC worker can evaluate
v(s) = Sk∈[m] ck × vk(s) “in the exponent” to get g v(s); it computes
w(s) and y(s), in the exponent, similarly.
To allow the worker to prove that Equation (1) holds, we
also, as part of the evaluation key, give the worker g (si) terms.
The worker computes , and then
uses the hi, along with g(si) terms, to compute gh(s). To oversimplify,
the proof consists of ( g v(s), g w(s), g y(s), g h(s)). To check
that p(s) = h(s)t(s), the verifier uses a bilinear map that allows
him to take two elliptic curve elements and “multiply” their
exponents together to create an element in a new group. The
actual protocol10 is a bit more complex, because additional
machinery is needed to ensure that the worker incorporates
the client’s input u correctly, and that the worker indeed
generates (say) v(s) in the exponent as some linear function
of the vk(s) values.
Regarding efficiency, GGPR10 show that the one-time
setup of KeyGen runs in time linear in the original circuit
size, O(|C|). The worker performs O(|C|) cryptographic
work, but he must also perform O(|C|log2|C|) non-cryptographic
work to calculate h(x). To achieve this performance,
the worker exploits the fact that the evaluation
vectors (vk(r1), . . ., vk(rd) ) are all very sparse (also for the w
and y polynomials). The proof itself is constant size, with
only 9 group elements for QAPs, though the verifier’s work
is still linear, O(N), in the size of the inputs and outputs of
the function.
In terms of security, GGPR10 show this VC scheme is
sound under the d-PKE and q-PDH assumptions, which are
weak versions of assumptions in prior work.
Zero Knowledge. Making the VC scheme zero-knowledge
is remarkably simple. One simply includes the target polynomial
t(x) itself in the polynomial sets , , and . This
allows the worker to “randomize” its proof by adding δvt(s) in
the exponent to vmid(s), δwt(s) to w(s), and δyt(s) to y(s) for random
δv, δw, δy, and modifying the other elements of the proof
accordingly. The modified value of p(x) remains divisible by (Page-106, Column 1).
Sheng teaches, When the buyer and seller meet, the seller may then offer the goods for inspection by the buyer (step 836). The buyer then confirms that the item is acceptable (step 838). The seller then sends a virtual currency address from the seller's wallet to the Buyer via the SOCOACT (step 840). Responsively, the SOCOACT forwards the address to the buyer (step 842). The buyer then sends the agreed-upon denomination of virtual currency from the buyer's wallet address to the seller's address (step 844). Once the transaction is confirmed, for example, by auditing the SOCOACT blockchain according to FIG. 7, the seller gives the goods to the buyer (step 846). The transaction then ends (step 848). (Fig. 8, ¶181). Agreement of contract parties may be obtained at 4125. In one implementation, contract parties may provide cryptographic signatures to indicate that they agree to the smart contract. The smart contract may be generated in a format compatible with a permissioned ledger at 4129 and submitted to the block chain at 4133 (e.g., stored in contracts database 5819r). In one embodiment, the smart contract may be generated by converting the determined contract data into the compatible format (e.g., via an API). In one implementation, the smart contract may be stored in an arbitrary 80-byte header one may be allowed to send in a blockchain transaction. For example, the 80-byte header containing smart contract information recorded in the blockchain may take the following form in an XML-enabled format: (Fig. 41, ¶346).
However, none of the arts teaches the recited claim limitation(s).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Husen Wang (US PGPUB. # US 2020/0184557) discloses, a blockchain-based resource transfer method, includes: when a resource transfer condition is satisfied, determining a first amount of a to-be-transferred first resource; determining a second amount of a to-be-transferred second resource according to the first amount of the first resource, wherein a type of the first resource is different from a type of the second resource; initiating, by a resource transferor, a transaction request to a blockchain, to transfer the to-be-transferred second resource to a resource transferee, wherein the transaction request comprises first encrypted amount information obtained by encrypting the second amount of the second resource based on a first encrypting function, wherein inputs of the first encrypting function include the second amount of the second resource and a public key of the resource transferee; and after the blockchain verifies the transaction request, executing the transaction request, transferring the to-be-transferred second resource to the resource transferee, and recording an execution result of the transfer on the blockchain. Therefore, privacy information of both a resource transferor and transferee can be protected during resource transfer.
Lee et al. (US PGPUB. # US 2019/0180276) discloses, a system for using block chain technology to verify transaction data are described herein. A computing platform may receive data about events related to transactions, personal or corporate information, supply chains, and other relevant information about a person or corporate entity. The event information may be received, aggregated, and processed to determine metadata about the person or corporate entity. The metadata may indicate, for example, a trustworthiness of the person or corporate entity for various purposes. Such event information and/or metadata may be stored as transactions in a block chain that may be accessible by counterparties to a potential transaction involving the person or corporate entity. The automated event processing computing platform may further use automated techniques to implement smart transactions between the person/entity and counterparty based on the trust metadata.
Stradling et al. (US PGPUB. # US 2018/0089758) discloses, a method of creating a smart contract on a blockchain. The approach includes receiving, from a user, one or more parameters via a user interface, each of the one or more parameters being associated with a creation of a customized smart contract. The approach also includes authenticating the one or more parameters via a public/private key associated with the user, and deploying the customized smart contract onto a blockchain in a provably honest fashion. The customized smart contract runs without a custodial risk and can be established between a first party and a second party with no third party holding custody of any assets associated with the customized smart contract.
Cusden et al. (US PGPUB. # US 2017/0344988) discloses, a blockchain-based validation of a bearer of a private key used to register a record on a blockchain may be facilitated. In some embodiments, reference information associated with a user and with a blockchain record may be obtained. The reference information may be based on a blockchain address associated with the user and with the record. The blockchain address may be based on a public key corresponding to a private key used to register the record, where the keys are a key pair associated with the user. A smart contract may be caused to be generated based on the reference information and provided on a blockchain. The smart contract may be configured to automatically validate a transaction using the public key. A notification indicating that the user registered the record may be obtained responsive to the smart contract validating a transaction signed using the private key.
Bringer et al. (US PGPUB. # US 2016/0105414) discloses, an authentication method for authenticating a client device having an authentication token generated by means of a pseudo-homomorphic function and based on a secret element (PIN) known only by the client device, to a server, comprising: the generation (A1), by the client device, of proof of knowledge of the secret element based on a proof generation key masked with a first mask data item, said masked proof generation key being dependent on said secret element, the transmission to the server by the client device, of said generated proof of knowledge of the secret element (A2) and of the authentication token (J) masked using the mask data item (A3), the verification of the validity of the masked authentication token (A4) and of the validity of the proof of knowledge by the server (A6) by a zero-knowledge proof, proving the knowledge of said secret element by the client device without revealing it.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARSHAN I DHRUV whose telephone number is (571)272-4316. The examiner can normally be reached M-F 9:00 AM-5:00 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/DARSHAN I DHRUV/Primary Examiner, Art Unit 2498
Prosecution Insights