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 . Claims 1-20 are pending.
Claims 1-20 have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 2/10/25 is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,212,102 and claims 1-18 of U.S. Patent No. 12,015,714. Although the claims at issue are not identical, they are not patentably distinct from each other since the instant application is fully disclosed in the patent and the application and are claiming common subject matter.
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, 3-11 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Maria U.S. 10,448,251 (hereinafter Maria) in view of Fletcher U.S. 2020/0074450 (hereinafter Fletcher).
With respect to claim 1, Maria discloses a computer implemented system for communicating data messages between a verifier computing device and a portable client computing device, the data messages establishing authentication of one or more characteristics of a client associated with the portable client computing device, the system comprising:
the portable client computing device including at least a client computing device processor and data storage, the data storage storing one or more token data objects received from or computed jointly in a multiparty protocol with an issuer computing device, the one or more token data objects generated using at least an issuer computing device private issuance key, the one or more token data objects each including one or more signed data elements representing at least one of the one or more characteristics of the client associated with the portable client computing; and the client computing device processor configured to receive a verification request data message from the verifier computing device and, using a combination of the one or more token data objects and the verification request data message, generate one or more proof data messages without sending any data messages or requests to the issuer computing device (e.g. Maria, col. 1, line 38-col. 2, line 26; Fig. 3 and 4, blockchain or token, “a database configure to store blockchain for authenticating mobile devices…granting access of mobile device to the public wireless network when the blockchain record corresponds to the blockchain associated with the mobile device; Fig. 3, col. 7, lines 12-62, “…appends a new block to the blockchain to create a new blockchain to authenticate the mobile device at future time…the blockchain documents all network access by the mobile device over time; Fig. 4, col. 7, line 63-col. 8, line 35, “mobile device 102 receives a signal from public wireless network…mobile device 102 accesses the current blockchain record stored …flash memory…to send the blockchain record to the MME…the blockchain record is compared to blockchain stored in the carrier’s system...).
Maria does not explicitly mentions the one or more token data object (blockchain) is received from or computed jointly in a multiparty protocol. However, Fletcher mentions a similar feature (e.g. Fletcher, paragraph 0175, “protocol that supports the second blockchain network may be layered on top of an existing proof-of-work public blockchain protocol such as bitcoin, without permission since it interacts through the construction of digital signatures via a multiple protocol external to the mainchain…”). Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement multiparty protocol to the blockchain taught by Maria since blockchain protocol itself need not be modified to accommodate the further protocol (Fletcher, paragraph 0175).
With respect to claim 3, Maria and Fletcher disclose the computer implemented system of claim 1, wherein the one or more token data objects are pre-loaded into the data storage such that the generation of the proof can be conducted at a time temporally separated from when the one or more token data objects were generated or preloaded (e.g. Fig. 3-4, col. 7, line 12-col. 8, line 35, new blockchain preload and append to prior blockchain before it’s use).
With respect to claim 4, Maria and Fletcher disclose the computer implemented system of claim 1, wherein the one or more proof data messages are generated such that the one or more proof data messages can be validated using an issuer computing device public encryption key corresponding to the issuer computing device private issuance key (e.g. Maria, col. 7, lines 13-35).
With respect to claim 5, Maria and Fletcher disclose the computer implemented system of claim 1, wherein g.sup.cR=C.sub.x.sup.z.sup.1h.sup.z.sup.2 indicates that a condition established in the verification request data message is met without having to present the underlying one or more characteristics of the client associated with the portable client computing device (e.g. Maria, col. 1, lines 38-59, association of blockchain with user device)
With respect to claim 6, Maria and Fletcher disclose the computer implemented system of claim 1, wherein the verification request data message includes a blacklist data structure and the one or more proof data messages are generated to establish that the client associated with the portable client computing device does not match one or more identities stored in the blacklist data structure, or wherein the verification request data message includes a whitelist data structure and the one or more proof data messages are generated to establish that the client associated with the portable client computing device matches one or more identities stored in the blacklist data structure (e.g. Maria, Fig. 3 and 4, col. 7, line 12-col. 8, line 35, comparing and verifying blockchain record).
Maria does not explicitly mention include a blacklist data structure. However, Maria teaches the blockchain associating user of device profile. Blacklist and whitelist are known feature of identifying authorized user or unauthorized user. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to identity authorized user or unauthorized user in the blockchain structure that is associated with authorized or unauthorized user for speedier process.
With respect to claim 7, Maria and Fletcher disclose the computer implemented system of claim 1, wherein the provisioning of access to the secured resource includes transmitting an electronic signal to a physical lock actuator, or to a digital challenge-response mechanism (e.g. Maria, col. 4, lines 43-51).
With respect to claim 8, Maria and Fletcher disclose the computer implemented system of claim 1, wherein the client computing device processor is a secure enclave processor or a trusted execution environment that is segregated from a general execution environment of the client computing device or the data storage is a secure enclave memory region that is segregated from a general memory region of the client computing device, the secure enclave memory region not accessible by general execution environment of the client computing device (e.g. Maria, col. 8, lines 10-44, “…blockchain record being stored in secure enclave within processor”).
With respect to claim 9, Maria and Fletcher disclose the system of claim 8, wherein the secure enclave processor or the trusted execution environment is computationally restricted from the general execution environment of the client computing device (e.g. Maria, Fig. 1, item 110)
With respect to claim 10, Maria and Fletcher disclose the system of 8, wherein the secure enclave processor or the trusted execution environment is computationally isolated from the general execution environment of the client computing device (e.g. Maria, Fig. 1, item 110).
With respect to claim 11, Maria discloses a computer implemented method for communicating data messages between a verifier computing device and a portable client computing device, the data messages establishing authentication of one or more characteristics of a client associated with the portable client computing device, the method comprising: storing one or more token data objects received from an issuer computing device, the one or more token data objects generated using at least an issuer computing device private issuance key, the one or more token data objects each including one or more signed data elements representing at least one of the one or more characteristics of the client associated with the portable client computing device; receiving a verification request data message from the verifier computing device, the verification request data message including at least a nonce cy; and generating a proof data message by conducting a modular inverse based at least on an attribute value from the one or more token data objects, generating a first random number and a second random number, computing a first group exponentiation and a second group exponentiation based on the first random number and the second random number, and a group multiplication including at least the first group exponentiation and the second group exponentiation, the group multiplication utilized to establish proof responses in a sigma protocol that are encapsulated into the proof data message (e.g. Maria, col. 1, line 38-col. 2, line 26; Fig. 3 and 4, blockchain or token, “a database configure to store blockchain for authenticating mobile devices…granting access of mobile device to the public wireless network when the blockchain record corresponds to the blockchain associated with the mobile device; Fig. 3, col. 7, lines 12-62, “…appends a new block to the blockchain to create a new blockchain to authenticate the mobile device at future time…the blockchain documents all network access by the mobile device over time; Fig. 4, col. 7, line 63-col. 8, line 35, “mobile device 102 receives a signal from public wireless network…mobile device 102 accesses the current blockchain record stored …flash memory…to send the blockchain record to the MME…the blockchain record is compared to blockchain stored in the carrier’s system...).
Maria does not explicitly mentions the one or more token data object (blockchain) is received from or computed jointly in a multiparty protocol. However, Fletcher mentions a similar feature (e.g. Fletcher, paragraph 0175, “protocol that supports the second blockchain network may be layered on top of an existing proof-of-work public blockchain protocol such as bitcoin, without permission since it interacts through the construction of digital signatures via a multiple protocol external to the mainchain…”). Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement multiparty protocol to the blockchain taught by Maria since blockchain protocol itself need not be modified to accommodate the further protocol (Fletcher, paragraph 0175).
With respect to claim 13, Maria discloses the method of claim 11, wherein the client computing device processor is a secure enclave processor or a trusted execution environment that is segregated from a general execution environment of the client computing device (e.g. Maria, Fig. 1, item 110).
With respect to claim 14, Maria discloses the method of claim 11, wherein the data storage is a secure enclave memory region that is segregated from a general memory region of the client computing device, the secure enclave memory region not accessible by general execution environment of the client computing device (e.g. Maria, Fig. 1, item 110).
With respect to claim 15, Maria discloses the method of claim 11, wherein the one or more proof data messages are generated such that the one or more proof data messages can be validated using an issuer computing device public encryption key (e.g. Maria, col. 5, lines 10-26).
With respect to claim 16, Maria discloses the method of claim 11, wherein g.sup.cR=C.sub.x.sup.z.sup.1h.sup.z.sup.2 indicates that a condition established in the verification request data message is met without having to present the underlying one or more characteristics of the client associated with the portable client computing device (e.g. Maria, col. 1, lines 38-59).
With respect to claim 17, Maria discloses the method of claim 11, wherein the verification request data message includes a blacklist data structure and the one or more proof data messages are generated to establish that the client associated with the portable client computing device does not match one or more identities stored in the blacklist data structure (e.g. Maria, Fig. 3 and 4, col. 7, line 12-col. 8, line 35, comparing and verifying blockchain record).
Maria does not explicitly mention include a blacklist data structure. However, Maria teaches the blockchain associating user of device profile. Blacklist and whitelist are known feature of identifying authorized user or unauthorized user. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to identity authorized user or unauthorized user in the blockchain structure that is associated with authorized or unauthorized user for speedier process.
With respect to claim 18, Maria discloses the method of claim 11, wherein the verification request data message includes a whitelist data structure and the one or more proof data messages are generated to establish that the client associated with the portable client computing device does match one or more identities stored in the whitelist data structure (e.g. Maria, col. 4, lines 34-56).
With respect to claim 19, Maria discloses the method of claim 11, wherein the proof message, upon validation, is used to generate a determination to grant access to a protected resource (e.g. Maria, col. 4, lines 49-56).
With respect to claim 20, Maria discloses a non-transitory computer readable medium storing machine interpretable instructions, which when executed, cause a processor to perform the steps of a method for communicating data messages between a verifier computing device and a portable client computing device, the data messages establishing authentication of one or more characteristics of a client associated with the portable client computing device, the method comprising: storing one or more token data objects received from an issuer computing device, the one or more token data objects generated using at least an issuer computing device private issuance key, the one or more token data objects each including one or more signed data elements representing at least one of the one or more characteristics of the client associated with the portable client computing device; receiving a verification request data message from the verifier computing device, the verification request data message including at least a nonce cy; and generating a proof data message by conducting a modular inverse based at least on an attribute value from the one or more token data objects, generating a first random number and a second random number, computing a first group exponentiation and a second group exponentiation based on the first random number and the second random number, and a group multiplication including at least the first group exponentiation and the second group exponentiation, the group multiplication utilized to establish proof responses in a sigma protocol that are encapsulated into the proof data message (e.g. Maria, col. 1, line 38-col. 2, line 26; Fig. 3 and 4, blockchain or token, “a database configure to store blockchain for authenticating mobile devices…granting access of mobile device to the public wireless network when the blockchain record corresponds to the blockchain associated with the mobile device; Fig. 3, col. 7, lines 12-62, “…appends a new block to the blockchain to create a new blockchain to authenticate the mobile device at future time…the blockchain documents all network access by the mobile device over time; Fig. 4, col. 7, line 63-col. 8, line 35, “mobile device 102 receives a signal from public wireless network…mobile device 102 accesses the current blockchain record stored …flash memory…to send the blockchain record to the MME…the blockchain record is compared to blockchain stored in the carrier’s system...).
Maria does not explicitly mentions the one or more token data object (blockchain) is received from or computed jointly in a multiparty protocol. However, Fletcher mentions a similar feature (e.g. Fletcher, paragraph 0175, “protocol that supports the second blockchain network may be layered on top of an existing proof-of-work public blockchain protocol such as bitcoin, without permission since it interacts through the construction of digital signatures via a multiple protocol external to the mainchain…”). Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement multiparty protocol to the blockchain taught by Maria since blockchain protocol itself need not be modified to accommodate the further protocol (Fletcher, paragraph 0175).
Allowable Subject Matter
Claims 2 and 12 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, and if the Double Patenting rejection is overcome.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wagner U.S. 2022/0084014 discloses method for secured, encrypted transaction processing.
Anwer et al. U.S. 2020/0007445 discloses enhanced service function chain.
Agarwal et al. U.S. 2019/0392423 discloses method for processing purchase transactions using a mobile device.
Nicolas et al. U.S. 2020/0328895 discloses private issuance of assets and application and generating the zero-knowledge proof that is verifiable using a public key corresponding to a system issuing the asset token to the client.
Camenisch et al. U.S. 2019/0020480 discloses establishing trust in an attribute authentication system.
Camenisch et al. U.S. 2017/0033934 discloses privacy-preserving attribute-based credentials.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIN HON (ERIC) CHEN whose telephone number is (571)272-3789. The examiner can normally be reached Monday to Thursday 9am- 7pm.
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, Lynn Feild can be reached at 571-272-2092. 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.
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431