DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to communication filed on 03/17/2025.
Status of claims in the instant application:
Claims 1-20 are pending.
Priority
This application is a CON of PCT/CN2022/120646 filed on 09/22/2022.
Information Disclosure Statement
Information Disclosure Statements (IDS) filed on 03/17/2025 have been considered, and a signed copies of the IDS forms have been attached to this office action.
Drawings
Drawings filed on 03/17/2025 have been inspected, and it’s in compliance with MPEP 608.02.
Specification
Specification filed on 03/17/2025 has been inspected and it’s in compliance with MPEP 608.01.
Claim Objections
Claim 17 is objected due to the following:
Claim 17 recites, “A key verification method, applied to the verification device according to claim 1 and comprising: …”. The claim recites all the steps from claim 1, as well as referring back to claim 1. This appears to be duplication.
Applicant is requested to amend claim 17 to correct the duplication as below: “A key verification method, applied to the verification device the method comprising:”
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, 8-12 and 17-20 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 the limitation “… the zero-knowledge proof information comprises first proof information and/or second proof information, the first proof information is determined based on the ciphertext information, the second proof information is determined based on the ciphertext information and/or the key negotiation parameter of the first terminal …”
The use of “and/or” in the same claim limitation makes the claim ambiguous/indefinite; “and” requires both (all) the terms, but “or” requires only one of the terms making the other term(s) optional and the boundary of the claim ambiguous/indefinite.
Therefore, claim 1 is 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.
The dependent claims 2-7 are also rejected as they inherit the issue from the base claim.
Claims 8-12 and 17-20 are also similarly rejected asl claim 1-7.
Appropriate corrections required.
*** Note: For Examination purposes Examiner interprets the claims to recite only “and” instead of “and/or”.
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.
Claims 17, 1, 8, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. NPL: “Identity-Based Remote Data Integrity Checking With Perfect Data Privacy Preserving for Cloud Storage” to Yu et al. (hereinafter “Yu”) in view of Pub. NPL: “Modification of Diffie–Hellman Key Exchange Algorithm for Zero Knowledge Proof” to Mahmood Khalel Ibrahem (hereinafter “Ibrahem”), and further in view of Pub. No.: US 20230352189 A1 to SUN et al. (hereinafter “SUN”).
Regarding Claim 17. Yu discloses A key verification method (Yu, Abstract, Introduction, Section III, IV, Fig. 1, 2: … We provide detailed security proofs of the new protocol, including the soundness and zero-knowledge privacy of the stored data. Our security proofs are carried out in the generic group model [35]. This is the first correct security proof of ID-based RDIC protocol. Thus, the new security proof method itself may be of independent interest … Third Party Auditor – TPA …), [applied to the verification device according to claim 1] and comprising:
receiving, by the verification device, first information (Yu, Abstract, Section III-A, IV, Fig. 1, 2: … audit request … TPA has expertise and capabilities that cloud users do not have and is trusted to check the integrity of the cloud data on behalf of the cloud user upon request …);
wherein the first information comprises a key negotiation parameter of a first terminal, ciphertext information and zero-knowledge proof information (Yu, Section IV: …TagGen: Given a file M named fname, the data owner firstly divides it into n blocks m 1, • • , mn , where mi E Zq and then picks a random n E Z*q and computes r = gn. For each block mi, the data owner computes ai = s mi H2(f namelli)n. The tag for mi is ai. The data owner stores the file M together with (r, {ai }, IDS(r II fname)), to the cloud, where IDS(r II fname) is an identity-based signature [39], [40] from the data owner on the value r II fname and Challenge Q …);
the ciphertext information is derived based on a public key of a supervisory device, [a communication key determined by negotiation between the first terminal and a second terminal], and a first random number generated by the first terminal (Yu, Section IV: … To generate a challenge, the verifier picks a random p E Z*q , computes Z = e(H1 (ID), Ppub) and does the following. 1) Compute c1 = gp, c2 = Zp . 2) Generate a proof that :pf= POK {(p) : c1= gp I\ c2 = Zp}. …);
the zero-knowledge proof information comprises first proof information and/or second proof information (Yu, Sectiom IV: … Compute c1 = gp, c2 = Zp . 2) …; Note: C1 and C2 are ciphertext proofs), the first proof information is determined based on the ciphertext information (Yu, Sectiom IV: … proof is based on m …), the second proof information is determined based on the ciphertext information and/or the key negotiation parameter of the first terminal (Yu, Section III: … ProofGen: For a file F of which a TagGen query has been made, the adversary can undertake executions of the ProofGen algorithm by specifying an identity I D of the data owner and the file name Fn. The challenger plays the role of the TPA and the adversary A behaves as the prover during the proof generation. Finally, the adversary can get the output of P from the challenger when a protocol execution completes. Output: Finally, the adversary chooses a file name Fn† and a user identity I D†. I D† must not have appeared in key extraction queries and there exists a TagGen query with input F† and I D†. The adversary outputs the description of a prover P† which is _-admissible defined below … We say the cheating prover P† is _-admissible if it convincingly answers an _ fraction of integrity challenges. That is, Pr[(V(param, I D†, Fn†) _ P†) = 1] ≥ _. The probability here is over the coins of the verifier and the prover. The adversary wins the game if it can successfully output a_-admissible prover P† …), the first proof information is used for verifying whether a private key of the supervisory device is capable of decrypting the ciphertext information (Yu, Section III: … Extract Queries: The adversary can query the private key of any identity I Di . The challenger computes the private key ski by running the Extract algorithm and forwards it to the adversary.2) TagGen Queries: The adversary can request tags of any file Funder the identity I Di . The challenger runs the Extract algorithm to obtain the private key ski , and runs the TagGen algorithm to generate tags of the file F. Finally, the challenger returns the set of tags to the adversary …), [the second proof information is used for verifying whether a key decrypted in the ciphertext information is the communication key determined by negotiation between the first terminal and the second terminal]; and the first terminal and the second terminal perform sidelink communication via a relay terminal (Yu, Section III, Iv, Fig. 1-2: … the TPA's job is to perform the data integrity checking w.r.t to the cloud server on behalf the user …).
However, Yu does not explicitly teach, but Ibrahem from same or similar field of endeavor teaches:
“a communication key determined by negotiation between the first terminal and a second terminal … the second proof information is used for verifying whether a key decrypted in the ciphertext information is the communication key determined by negotiation between the first terminal and the second terminal (Ibrahem , Section V, FIG. 5: … The proposed ZKP based on D-H key exchange algorithm in the sense that both parties (the prover and the verifier) exchange non secret information and did not revealing secrets to get one identical secret key. This means that the prover can prove to the verifier that he knows the secret … Proposed ZKP - To protect the proposed algorithm from the man-in-the-middle attack an encrypted replies (R1 and R2), and mutual authentication between the prover (Alice) and the verifier (Bob) is required. The prover (Alice) proves to the verifier (Bob) that she knows a secret by calculating the key (K) and resend Bob’s reply (R2) to the verifier (Bob) encrypted with the generated secret key (K). Bob will encrypt his own reply (R2) with the generated secret key (K) and match the two encrypted information, if matched then Alice is verified, otherwise it is rejected. The verifier also needs to prove to the prover that he is honest by sending his reply R1togather with encrypted R1, then the verifier decrypt R1' by his key and match R1 and R1', if they matched then the verifier is honest. Figure-5 shows the procedure of the proposed protocol …)”.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ibrahem into the teachings of Yu, because it discloses that, “There are networks and entity groupings that require entity authentication while preserving the privacy of the entity being authenticated. Zero-knowledge proof (ZKP) plays an important role in authentication without revealing secret information. Diffie Hellman (D-H) key exchange algorithm was developed to exchange secret keys through unprotected channels. In this paper D-H algorithm has been modified into an interactive zero-knowledge proof protocol. The proposed protocol is designed to satisfy the zero knowledge proof properties and resists the known attacks (Ibrahem: Abstract)”.
However, the combination of Yu-Ibrahem does not explicitly teach, but SUN from same or similar field of endeavor teaches:
“verification device (SUN, Para [0064]: … The NIC-VDCT architecture 600 is based on a sender-receiver-verifier (SRV) model and the communication system 100 of FIG. 1, which comprises a plurality of mobile devices including mobile devices 10A and 10B belonging to users Alice and Bob, respectively. The NIC-VDCT architecture 600 comprises sending/proving computing devices (“senders”) 610, receiving computing devices 620 (“receivers”), and a verifier network (“verifier”) 630, at least some of which may not be trusted parties. A sending computing device 610 is an entity that uploads (or sends) private to-be verified information to a third party data server 50 for downloading/retrieval (or receipt) by a receiving computing device 620. The receiving computing device 620 is the intended recipient of the to-be private to-be verified information. The verifier network 630 verifies the private to-be verified information using a non-interactive zero-knowledge cryptographic protocol such as ZK-SNARK. The sending computing device 610 and receiving computing device 620 may each be a mobile device 10, a data server 50, or a healthcare center server 30. The verifier network 630 comprises a blockchain network 40 comprising the blockchain nodes 42. The private to-be verified information may be (i) a close contact of a respective user with another user, wherein the private information comprises a contact ID (tracing key) of the other user and a time of the close contact, which is uploaded by a mobile device 10 of the other user, (ii) a positive infection status of the respective user, wherein the private information comprises a contact ID of the respective user, the positive infection status and a time of the determination of the positive infection status, which is uploaded by a healthcare center server 30, or (iii) or a positive contact of the respective user, wherein the private information comprises a contact ID (tracing key) of the other user and a time of the positive contact, which is uploaded by a data server 50. When the private to-be verified information is verified by the verifier network 630, the private information is downloaded by the receiving computing device 620 …)”.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SUN into the teachings of Yu-Ibrahem, because it discloses that, “The digital contact tracing of the present disclosure may be used to achieve verifiable digital contact tracing with zero-knowledge of user identity and zero-knowledge of the information being verified. Advantageously, the solution is privacy preserving (SUN: Para [0008])”.
Regarding Claim 1. This claim contains all the same or similar limitations as claim 17, and hence similarly rejected as claim 17.
SUN also discloses a verification device (SUN, Para [0062, 0052]: … The blockchain node 40 also comprises a bus (not shown) providing communication among components of the blockchain node 40, including the processors 202, I/O devices 204, communication subsystem 206, RAM 208, ROM 210, and memory 212 … number of application programs 158 executable by the processing system are also stored in the persistent memory 112 …)
Regarding Claim 8. This claim contains all the same or similar limitations as claim 1, and hence similarly rejected as claim 1.
Regarding Claim 13. This claim contains all the same or similar limitations as claim 1, and hence similarly rejected as claim 1.
Regarding Claim 14. The combination of Yu-Ibrahem-SUN discloses the supervisory device according to claim 13, SUN further discloses, “wherein the supervisory device performs: receiving the ciphertext information via a blockchain (SUN, Abstract, Para [0042]: … A proof of the private information is generated using a proof function of a non-interactive zero-knowledge cryptographic protocol and added to a contact tracing blockchain for the respective user … The mobile devices 10, healthcare center servers 30, and blockchain nodes 42 may communicate securely using, for example, Transport Layer Security (TLS) or its predecessor Secure Sockets Layer (SSL). TLS and SSL are cryptographic protocols which provide communication security over the Internet. TLS and SSL encrypt network connections above the transport layer using symmetric cryptography for privacy and a keyed message authentication code (MAC) for message reliability …).”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine the teachings of SUN, because it discloses that, “The present disclosure provides a solution which provides a method of non-interactive zero-knowledge crowd verifiable digital contact tracing which addresses at least some of the accuracy, security and/or privacy concerns of digital contact tracing applications. The method may be implementing using a blockchain storing non-interactive zero-knowledge proofs, the blockchain being maintained by a blockchain network comprising a plurality of nodes, thereby providing blockchain based digital contact tracing (SUN: Para [0008])”.
Allowable Subject Matter
Claims 2-7, 9-12, 15-16 and 18-20 are 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.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a). Applicant’s response shall address all the objections and rejections issued in this office action..
Examiner further notes that all the independent claim be made similar in scope.
Reasons for allowance will be furnished upon allowance.
Pertinent Prior Arts
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
US 20230351035 A1; DAI; et al.: DAI discloses system and method for user-controllable sharing of authorization for private data, wherein the system at least comprises: a blockchain node, for recording and verifying transaction information and/or completing payment, a client, for encrypting a symmetric key into a re-encryption key to be sent to an IPFS node, so that after a re-encryption request it sends to the IPFS node is verified as valid, the client sends the symmetric key to a server; the IPFS node, for calling a zero-knowledge proof verification contract from the blockchain node in response to the re-encryption request from the client, and performing authorization and verification; a server, for sending first encrypted data involving user authorization to the IPFS node, and/or acquiring the symmetric key sent by the client and capable of decrypting authorization data. In the present invention, the control of authorized contents is transferred to the user from the service provider, enabling the user to control authorization. Besides, during authorization, authorization data contents, data flows and user behaviors are hidden, making use of the data protected from pry of service providers.
WO 2011041962 A1; ZHANG et al.: ZHANG discloses A method and system for end-to-end session key negotiation which support lawful interception are disclosed. The method includes: a first terminal carries out a session root key negotiation with a first Identification Location Register (ILR) to which said first terminal belongs, generates a session root key K.sub.as for the session and saves it; said first terminal then generates a session key according to a first parameter including a first self-generated random number and K.sub.as, and initiates an end-to-end session key request to a second terminal; the key negotiating parameters carried in said request include a first ciphertext containing the first random number information encrypted by K.sub.as and a first identification information of the session. The second terminal sends the received key negotiating parameters to the first ILR; using K.sub.as, said first ILR obtains the first random number from decryption of the first ciphertext, generates the session key in the same way as the first terminal and saves the key, then sends it to the second terminal in ciphertext. The second terminal then decrypts the ciphertext and acquires the session key contained within it. The first terminal then carries out a session with the second terminal by using the session key, said session key including the session encryption key.
The present invention relates to the field of the Internet, and in particular, to an end-to-end session key negotiation method and system for supporting lawful interception.
CN 106911513 A; HAO et al.: HAO discloses a device networking management field/method, aiming at the problem of the existing technology, claims a reliable device management method based on de-centralized network. the method uses distributed center network, the management device and the managed device is coupled. The management command and the encrypted management data, managed device by actively or passively obtained from distributed network management instruction and writing the feedback information, the management device and the managed security device of asynchronous communication. The invention node obtains management information of target node through lightweight, lightweight node filtering the node message, to the destination node address matching the message forwarding destination node and the destination node using the source node public key to verify the message signature, and by local private key to decrypt the session key and decrypts the message, acquiring the management information and processing.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHABUB S AHMED whose telephone number is (571)272-0364. The examiner can normally be reached on 9AM-5PM EST M-F.
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, Ali Shayanfar can be reached on 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAHABUB S AHMED/Examiner, Art Unit 2434
/TESHOME HAILU/Primary Examiner, Art Unit 2434
Prosecution Insights