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 .
Detail action
Claims 1, 3, 5, 6, 10-12, 15 and 17-24 are pending and being considered.
Claims 1, 3, 10, and 17 -21 are amended.
Response to 103
Applicant’s arguments filed on 05/21/2026 have been fully considered and are not persuasive.
In response to applicant’s arguments on page 9-10 of remarks that the steps of claim 1 are performed by “associating entity”, in contrast Sherman describes a framework in which roles are separated i.e., registrar storing credential and CSPs that verify the credential. Therefore, Sherman fails to teach one entity performing the feature of claim 1. The examiner acknowledges applicant’s pint of view but respectfully disagrees because Sherman discloses system comprised of five components registrar, source CSP, receiving CSP, user and web browser as show in the Fig. 3 performs the steps verifying user data, associating verified user data with firs set of data, storing the association, creating the authenticated certificate and providing the authenticated certificate. The examiner notes that all the above steps are performed by the system as shown in Fig 3. Sherman fails to disclose performing encryption of the first set of data using public key. The prior art Stefan overcomes the deficiency by encrypting the identity information using public key. The steps of claim 1 are taught by Sherman in view of Stefan. Thus, claim 1 is rendered obvious by the combination of Sherman and Stefan.
Claim Objections
Claims 1, 3, 5, 10 and 17-20 objected to because of the following informalities:
Claim 1 recites “providing …….the authenticated certificate for the generation of the certified user data”, the claim fails to positively recite “generating” certified user data based on the authenticated certificate. The examiner suggests to clarify/amend the above limitation such that it recites an active step of “generating” the certified user data.
Claim 1 recites associating the verified data with a first set of data and “storing by the associating entity the association” the examiner suggests to clarify what is the purpose of storing the association.
Claim 3 and 5 recites “the re-randomizable portion” should read as “the modifiable portion” to be consistence with “modifiable portion” recited in claim 1.
Claim 10 recites steps of “providing, to one or more trustee systems, an indication of the certified user data; decrypting, by the one or more trustee systems, the re-randomized portion using a private key of the one or more trustee systems to obtain the first set of data; receiving, from the one or more trustee systems, the first set of data; providing, to the associating entity, the first set of data; and receiving, from the associating entity, verified user data comprising personal information of the unknown user” it appears that the above steps in the claims are not in proper sequence/order. For example, the last step in the claim recites “receiving, from the associating entity, verified user data comprising personal information of the unknown user”. Since the trusted system already decrypts the re-randomized portion to obtain the first set of data, therefore, it is unclear what is the purpose of the trusted system receiving personal information of the user from the associating entity.
Claims 17-20 are neither proper independent claims nor proper dependent claims. Claims 17 and 19 calls for “a computer readable medium” being dependent on method claims 1 and 10 respectively. Claims 18 and 20 calls for “a processor” being dependent on claims 1 and 10 respectively. It’s unclear whether the claims should be treated as independent claims as being directed towards “computer readable medium” and “processor” or should be treated as dependent claims as being dependent on method claim 1 and 10. For examination purpose the claims are treated as dependent claims. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 10 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The claim recites “identifying the associating entity based on the identifier in the authenticated certificate and the certified user data”. The spec fails to disclose that the associating entity being identifies using the identifier and the certified user data.
Claim 10 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The claim recites “wherein the verified user data is retrieved by the associating entity using the first set of data based on a stored association between the first set of data and the verified user”. The spec fails to disclose the associating entity retrieving the verified user data. The spec on [page 7 lines 4-10] discloses “If the digital identity provider 200 is responsible for verifying the identity of multiple users, each user's verified user data 220A, 220B, 220C may be stored with a corresponding association to a serial number 300A, 300B, 300C respectively (not shown). The storage of the association permits the digital identity provider 200 in possession of the serial number 300 or the verified user data 220 to retrieve the other of the serial number 300 or the verified user data 220, using the association. In the present example, knowledge of serial number 300 enables the retrieval of the personal information 150 contained within the user's driving license, via the verified user data 220”
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 1, 4, 6, 12, 14, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sherman et al (hereinafter Sherman) (SPICE—Simple privacy-preserving identity-management for cloud environment “2012” NPL) in view of Stefan et al (hereinafter Stefan) (Revocable Anonymity “2006” NPL).
Regarding claim 1 Sherman teaches a computer-implemented method of providing an authenticated certificate to be modified by a user in the generation of certified user data, the method comprising the steps of: (Sherman on [page 530 2nd para] teaches method of applying randomization to the signatures (which acts as the certificates in our DIM system) to make them look different (i.e., modified) are known to be re-randomization. See also on [section 3.1] creating an authentication certificate);
verifying, by an associating entity, user data to determine verified user data, wherein the verified user data comprises authenticated personal information of the user (Sherman on [page 529 2nd para] teaches source CSP verifying the user credentials (i.e., user personal information/identities). See also on Fig 2 [page 535] re-randomization of certificate/signature having personal information of the user);
associating, by the associating entity, the verified user data with a first set of data (Sherman on [page 536 section 4.2] teaches each members identities (i.e., verified user data) are mapped (i.e., associating by the system) to integer ID (i.e., first set of data) a unique value which will be stored);
storing, by the associating entity, the association between the first set of data and the verified user data (Sherman on [page 536 section 4.2] teaches each members identities are mapped to integer ID a unique value which will be stored);
creating, by the associating entity, the authenticated certificate, wherein the authenticated certificate comprises a modifiable portion including the indication of the first set of data (Sherman on [page 532 section 3.1] teaches generating an authentication certificate. See also on [page 538 and 539 section 5.1] teaches the registrar is third-party which generates source certificate for each user based on user’s credentials and re-randomizing the certificate i.e., authenticated certificate to be modified);
and providing, by the associating entity, the authenticated certificate for the generation of the certified user data, wherein the modifiable portion is configured to be re-randomized by the user such that, when re-randomized, the authenticated certificate can no longer be associated with the verified user data (Sherman on [page 530 para 2 and page 535 section 4.1] teaches re-randomization of the signature which act as certificate. See also on [page 533 section 3.3] teaches adding two algorithms: randomization algorithm (GS.Rand), and hiding algorithm (GS.Hide) to make the signature re-randomizable (i.e., modifiable portion of signature in view of [page 3 line 3-5] which discloses modification is a re-randomization) and some blocks (i.e., indicating certificate having plurality of portions) of the signatures can be hidden (sanitized i.e., equivalent to unmodifiable portion of certificate). Further teaches the re-randomizable property prevents the certificates from the same user from being linked. See also on [page 539 section 5.1] teaches when a user receives the authentication request, the functions GS.Rand and GS.Hide will be used to randomize and sanitize a certificate. The user uploads the randomized certificate to source CSP through web browser. The source CSP uses function GS.Ver’ to authenticate the certificate. If successful, source CSP provides the service to user).
Sherman fails to explicitly teach encrypting the first data using public key, however Stefan from analogous art teaches
encrypting, by the associating entity, the first set of data using a public key of a trustee system to form an encrypted first set of data, and wherein the encrypted first set of data forms an indication of the first set of data (Stefan on [page 212 line 1-5 and page 213 step 2-8] teaches encrypting identity information using public key).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Stefan into the teaching of Sherman by encrypting data in certificate using public key. One would be motivated to do so in order to protect identity of the user from being exposed to unauthorized entity by encrypting the identity information within the authenticated certificate using public key (Stefan [abstract]).
Regarding claim 3 the combination of Sherman and Stefan teaches all the limitations of claims 1 above, Stefan further teaches wherein the re-randomizable portion of the created authenticated certificate comprises an identifier of the associating entity creating the authenticated certificate (Stefan on [page 212, last 2 lines and page 213 steps 2-8] teaches self-signed certificate includes address ID of the user who created the certificate, user selects random pseudonym Y and contacts third party I for blinded signature on data containing the address ID, SIGid and (Y, ID)).
The motivation for combining is same as set for the above in claim 1.
Regarding claim 5 the combination of Sherman and Stefan teaches all the limitations of claims 1 above, Sherman further teaches further comprising the step of re-randomizing the re-randomizable portion of the authenticated certificate to generate the certified user data (Sherman on [page 530 para 2 and page 535 section 4.1] teaches re-randomization of the signature which act as certificate. See also on [page 533 section 3.3] teaches adding two algorithms: randomization algorithm (GS.Rand), and hiding algorithm (GS.Hide) to make the signature re-randomizable (i.e., modifiable portion of signature in view of [page 3 line 3-5] which discloses modification is a re-randomization) and some blocks (i.e., indicating certificate having plurality of portions) of the signatures can be hidden (sanitized i.e., equivalent to unmodifiable portion of certificate). Further teaches the re-randomizable property prevents the certificates from the same user from being linked. See also on [page 539 section 5.1] teaches when a user receives the authentication request, the functions GS.Rand and GS.Hide will be used to randomize and sanitize a certificate. The user uploads the randomized certificate to source CSP through web browser. The source CSP uses function GS.Ver’ to authenticate the certificate. If successful, source CSP provides the service to user).
Regarding claim 6 the combination of Sherman and Stefan teaches all the limitations of claims 1 above, Stefan further teaches further comprising the step of storing auxiliary data, wherein the auxiliary data comprises an association between the verified user data and an encrypted version of an indication of the certified user data (Stefan on [page 213 step 2-8 and page 216] selecting random pseudonym Y (i.e., auxiliary data) for each blinded message and re-encrypt the certificate containing user data).
The motivation for combining is same as set for the above in claim 1.
Regarding claim 10 Sherman teaches a computer-implemented method of characterizing an unknown user from certified user data, the method comprising the steps of: receiving an indication of certified user data, the certified user data comprising a re-randomized portion of an authenticated certificate (Sherman on [page 530 para 2 and page 535 section 4.1] teaches re-randomization of the signature which act as certificate. See also on [page 533 section 3.3] teaches adding two algorithms: randomization algorithm (GS.Rand), and hiding algorithm (GS.Hide) to make the signature re-randomizable (i.e., modifiable portion of signature in view of [page 3 line 3-5] which discloses modification is a re-randomization) and some blocks (i.e., indicating certificate having plurality of portions) of the signatures can be hidden (sanitized i.e., equivalent to unmodifiable portion of certificate). Further teaches the re-randomizable property prevents the certificates from the same user from being linked);
the re-randomized portion comprising a first set of data encrypted (Sherman on [page 530 para 2 and page 535 section 4.1] teaches re-randomization of the signature which act as certificate. See also on [page 533 section 3.3] teaches adding two algorithms: randomization algorithm (GS.Rand), and hiding algorithm (GS.Hide) to make the signature re-randomizable (i.e., modifiable portion of signature in view of [page 3 line 3-5] which discloses modification is a re-randomization) and some blocks (i.e., indicating certificate having plurality of portions) of the signatures can be hidden (sanitized i.e., equivalent to unmodifiable portion of certificate). Further teaches the re-randomizable property prevents the certificates from the same user from being linked);
wherein the first set of data was associated with verified user data by the associating entity prior to re-randomization, the verified user data comprising authenticated personal information of the unknown user (Sherman on [page 536 section 4.2] teaches each members identities (i.e., verified user data) are mapped to integer ID (i.e., verified user data) a unique value which will be stored i.e., mapping is done prior to re-randomization. See on [page 529 2nd para] teaches source CSP verifying the user credentials (i.e., user personal information/identities). See also on Fig 2-page 535 re-randomization of certificate/signature having personal information of the user);
providing, to one or more trustee systems, an indication of the certified user data (Sherman on [page 536 section 4.2] teaches each members identities (i.e., verified user data) are mapped to integer ID (i.e., first set of data) a unique value which will be stored);
receiving, from the one or more trustee systems, the first set of data; providing, to the associating entity, the first set of data (Sherman on [page 536 section 4.2] teaches each members identities (i.e., verified user data) are mapped to integer ID (i.e., first set of data) a unique value which will be stored);
and receiving, from the associating entity, verified user data comprising authenticated personal information of the unknown user (Sherman on [page 529 2nd para] teaches source CSP verifying the user credentials (i.e., user personal information/identities). See also on Fig 2-page 535 re-randomization of certificate/signature having personal information of the user);
wherein the verified user data is retrieved by the associating entity using the first set of data based on a stored association between the first set of data and the verified user (Sherman on [page 536 section 4.2] teaches each members identities (i.e., verified user data) are mapped to integer ID (i.e., verified user data) a unique value which will be stored for later opening purpose i.e., retrieval of verified data based on stored mapping);
Sherman fails to explicitly teach a first set of data that has been encrypted using a public key of one or more trustee systems, the authenticated certificate and certified user data further comprising an identifier of an associating entity and providing, to one or more trustee systems, an indication of the certified user data; decrypting, by the one or more trustee systems, the re-randomized portion using a private key of the one or more trustee systems to obtain the first set of data, however Stefan from analogous art teaches
the re-randomized portion comprising a first set of data encrypted using a public key of one or more trustee systems (Stefan on [page 212 line 1-5 and page 213 step 2-8] teaches encrypting identity information using public key);
and the authenticated certificate and certified user data further comprising an identifier of an associating entity (Stefan on [page 212, last 2 lines and page 213 steps 2-8] teaches self-signed certificate includes address ID of the user who created the certificate, user selects random pseudonym Y and contacts third party I for blinded signature on data containing the address ID, SIGid and (Y, ID));
identifying the associating entity based on the identifier in the authenticated certificate and the certified user data (Stefan on [page 212, last 2 lines and page 213 steps 2-8] teaches self-signed certificate includes address ID of the user who created the certificate, user selects random pseudonym Y and contacts third party I for blinded signature on data containing the address ID, SIGid and (Y, ID). See on [page 215 last para] discloses authenticating the user based on group signature key and the address identity ID);
decrypting, by the one or more trustee systems, the re-randomized portion using a private key of the one or more trustee systems to obtain the first set of data (Stefan on [page 212 line -15] teaches the law enforcement agency decrypts the encrypted ID in certificate using private key. See also on Fig 4 and [page 214 step 1-10] teaches V sends certificate containing encrypted ID, SIGid etc. to law enforcement agency L which then decrypts the encrypted portion using private key and verifies the signature).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Stefan into the teaching of Sherman by encrypting and decrypting data in certificate using public key and private key respectively. One would be motivated to do so in order to protect identity of the user from being exposed to unauthorized entity by encrypting the identity information within the authenticated certificate using public key (Stefan [abstract]).
Regarding claim 11 the combination of Sherman and Stefan teaches all the limitations of claim 10 above, Sherman further teaches wherein the identifier of the associating entity comprises one or more of: a signature signed using the associating entity's private key; and a public key of the associating entity comprised within the authenticated certificat(Sherman on [page 531 section 2.2] signature using private key);
Regarding claim 12 the combination of Sherman and Stefan teaches all the limitations of claim 1 above, Sherman further teaches wherein the first set of data comprises one or more of a token, a database reference, or a serial number (Sherman on [page 536 section 4.2] teaches each members identities (i.e., verified user data) are mapped to integer ID (i.e., first set of data) a unique value which will be stored i.e., integer ID as toke, database reference or serial number).
Regarding claim 15 the combination of Sherman and Stefan teaches all the limitations of claim 10 above, Sherman further teaches wherein the personal information comprises identifying information and the method is a method of identifying an unknown user from certified user data (Sherman on [page 528] teaches anonymity of user such that user anonymously authenticate as authorized user without letting the CSP know about real identity of user).
Regarding claim 17 the combination of Sherman and Stefan teaches all the limitations of claim 1 above, Stefan teaches a computer-readable medium comprising instructions that, when executed, cause one or more processor(s) to perform the method of claim 1 (Stefan on [page 527] teaches computer device and storage i.e., computers know to have processor for executing instructions).
Regarding claim 18 the combination of Sherman and Stefan teaches all the limitations of claim 1 above, Stefan further teaches a processor configured to execute the method of claim 1 (Stefan on [page 527] teaches computer device and storage i.e., computers know to have processor for executing instructions).
Regarding claim 19 the combination of Sherman and Stefan teaches all the limitations of claim 10 above, Stefan further teaches a computer-readable medium comprising instructions that, when executed, cause one or more processor(s) to perform the method of claim 10 (Stefan on [page 527] teaches computer device and storage i.e., computers know to have processor for executing instructions).
Regarding claim 20 the combination of Sherman and Stefan teaches all the limitations of claim 10 above, Stefan further teaches a processor configured to execute the method of claim 10 (Stefan on [page 527] teaches computer device and storage i.e., computers know to have processor for executing instructions).
Regarding claim 21 the combination of Sherman and Stefan teaches all the limitations of claim 3 above, Sherman further teaches wherein the identifier comprises a signature signed using the entity's private key (Sherman on [page 531 section 2.2] signature using private key);
Regarding claim 22 the combination of Sherman and Stefan teaches all the limitations of claim 6 above, Sherman further teaches wherein the encryption to create the encrypted version of an indication of the certified user data occurs using a public key of a trustee system (Stefan on [page 212 line 1-5 and page 213 step 2-8] teaches encrypting identity information using public key).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Stefan into the teaching of Sherman by encrypting data in certificate using public key. One would be motivated to do so in order to protect identity of the user from being exposed to unauthorized entity by encrypting the identity information within the authenticated certificate using public key (Stefan [abstract]).
Regarding claim 23 the combination of Sherman and Stefan teaches all the limitations of claim 11 above, Sherman further teaches wherein the identifier of the associating entity comprises the signature signed using the associating entity's private key (Sherman on [page 531 section 2.2] signature using private key);
and wherein the signature is comprised within the re-randomized portion (Sherman on [page 533 section 3.3] teaches re-randomizing certificate containing signature. Certificate with randomized and original signature (see Fig 2)).
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Sherman et al (hereinafter Sherman) (SPICE—Simple privacy-preserving identity-management for cloud environment “2012” NPL) in view of Stefan et al (hereinafter Stefan) (Revocable Anonymity “2006” NPL) and further in view of Wang (US 20210051027).
Regarding claim 24 the combination of Sherman and Stefan teaches all the limitations of claim 1 above, the combination fails to teach wherein the identifier of the associating entity comprises the public key of the associating entity comprised within the authenticated certificate, wherein the public key is comprised within an unmodified portion of the authenticated certificate, however Wang from analogous art teaches
wherein the identifier of the associating entity comprises the public key of the associating entity comprised within the authenticated certificate, wherein the public key is comprised within an unmodified portion of the authenticated certificate (Wang on [0098-0101] teaches certificate containing content portion and signature portion and wherein content portion includes public key i.e., content portion containing public key is not modified).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Wang into the combined teaching of Sherman and Stefan by certificate having public key portion. One would be motivated to do so in order to validate digital signature of the certificate using the public key included in the certificate (Wang [0019]).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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, Shewaye Gelagay can be reached at (571)272-4219. 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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436
Prosecution Insights