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 .
Claims 1-29 were cancelled by preliminary amendment and claims 30-42 were added as new claims, claims 30-42 are pending.
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.
Claim 39 recites the limitation " receiving a device identifier of the communication device and a request for the service from the DI wallet entity”; and sending a token for key replacement to the DI wallet entity " in line 2. There is insufficient antecedent basis for this limitation in the claim.
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 30,33-36, 41 are rejected under 35 U.S.C. 103 as being unpatentable over Wei et al. (CN 115549958 A:IDS supplied) in view of Salmela et al(US 11296878 B2).
With regards to claim 30, Wei discloses, A method for key replacement in a communication device, wherein the method is performed by the communication device, and wherein the method comprises:
receiving a trigger for the communication device to perform the key replacement (Page 2 line 0-10; obtaining the key exchange operation input by the user; the key exchange operation is used for requesting to change the first key pair into a second key pair; Note: user device as communication device initiate key replacement);
providing a request to a Digital Identity (DI) wallet entity for a feedback for the communication device to perform the key replacement (Page 2 line 40-50; an operation obtaining module, used for obtaining the key exchange operation input by the user; the key exchange operation is used for requesting to change the first key pair into a second key pair; Note: user device(communication device) sending request with identity to DI unit(service system) for a feedback to change the key pair, service system return feedback after authentication);
receiving the Feedback from the DI wallet entity, (Page 2 line 10-20; obtaining the feedback information of the first key change result fed back by the service system; the first key change result feedback information is used for representing the user identity authentication result generated based on the first information sent to the service system by the block chain system; page 5; In the embodiment of the specification, the user triggers the key exchange operation, the service system can respond to the key exchange operation to send the user identity verification page or for generating the user identity verification page of the page data to the client, the client can display the user identity verification page. the user identity verification page may include verifying the preamble information, the user can input the first information according to the verification preamble information. the first information can be understood as the information to be verified, can be verified by the user of the change key by the first information.; page 6 line 8; after the service system obtains the first information, the first information can be submitted to the block chain system, the block chain system can verify the user identity based on the first information, and generate the verification result, and can feed back the information representing the verification result to the service system, so that the service system can pass the verification, determining the second key pair in the enabled state, using the second key in the enabled state to process the service related to the user in the service system Note: as user device(communication device) received authentication result feedback in collaboration with blockchain system);
obtaining a new key pair, and replacing an existing key pair with the new key pair upon communication device successfully authenticated(Page 2 line 10-20; if the first key change result feedback information indicates that the first information verification is passed, then determining that the second key pair is in an enabled state. page 5; In the embodiment of the specification, the user client may also include a program or a plug-in for generating a key pair, which can generate a key pair locally at the user client according to the user requirement. Note: user device(communication device) obtains second key pair based on verification is passed ); and
communicating with a Service Provider (SP) entity, wherein the new key pair is used as part of the communication device communicating with the SP entity (page 6 para 5;; In practical application, the private key in the key pair can be automatically stored by the user, when processing the service, the user needs to perform service processing by the private key, for example, the transaction of digital collections by means of private key signature. The second key pair may indicate that the user can use the private key in the second key pair to perform service processing in the enabled state).
Wei does not exclusively but Salmela teaches,
receiving the verifiable presentation from the DI wallet entity, wherein the verifiable presentation comprises attributes of one or more verifiable credentials (Col 12 line 20-40; S303: The key issuer 300 sends the public key to the host entity 200; Col 10 line 10-40; S204a: The key issuer 300 verifies authentication of the host entity 200 using the public key and the current private key; S204d: The key issuer 300 negotiates parameters for the new private key with the host entity 200; Col 1line 45-50; Assume that a host entity uses asymmetric key based credentials, which means that the public key (or equivalently a representation or reference of the public key (such as a hash of the public key, or a certificate of the public key)) acts as the identity of the host entity and the private key acts as the authentication credentials Note: Issuer (DI wallet) send host(communication device ) public key (verifiable presentation) which is a credential later used for authentication).
communication device having successfully verified the verifiable presentation (Col 10 60-col11 line 10; With respect to any of steps S206a, S206b, the host entity 200 may send its private key (or parameters of it) to the key issuer 300 so that the key issuer 300 can just compare the private key (or parameters) to the private keys (or parameters) on the private key revocation list. If there is no match and the private key does in fact produce the signature or authentication response used for authentication (the key issuer 300 could, for example, perform signature calculations or calculate the response to the authentication challenge with the received private key and verify that it produces the same signature or authentication response as used by the host entity 200 for authentication with the key issuer 300; col 5line 25-30; The key issuer 300 could be implemented as a service provided by the service provider 500 or it could e.g. be implemented as an application running in an entity of the owner 600 of the host entity 200. Col 5 line 60-65; This could require the host entity 200 to sign a message with its private key and the service provider 500, after verifying the signature with the public key, Note: Key issuer can be implement in host and can verify signature as verifiable presentation ).
Salmela also teaches, communicating with a Service Provider (SP) entity(Col 5line 25-50; (13) The key issuer 300 is configured to generate a new group/identity by creating the group public key. The key issuer 300 could be implemented as a service provided by the service provider 500 or it could e.g. be implemented as an application running in an entity of the owner 600 of the host entity 200. The key issuer 200 is further configured to support the host entity 200 to generate private keys linked to the (group) public key and to maintain a private key revocation list, which contains all private keys that have been revoked, or at least information identifying such private keys. The key issuer 300 is configured to share the private key revocation list to the service provider 500, such as pushing the revocation list to the service every time the private key revocation list is updated, or on a regular basis, such once every 10 minutes, once every hour, or once every 24 hours, or the like. Alternatively, as will be further disclosed below, the service provider 500 can pull the private key revocation list from the key issuer 300. Yet alternatively, the service provider 500, and/or other entities, could be configured to enquire the key issuer 300 to check whether the private key is already revoked or not. If so, the service provider 500 needs to send the authentication response of the host entity 200 to the key issuer 300 to have it checked against the private key revocation list. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify Wei’ method/system with teaching of Salmela in order to improve security by updating of a key of a host entity (Col 1line 60-63; Salmela).
With regards to claim 33, Wei in view of Salmela discloses, wherein the method further comprises: receiving a verification of successful key replacement from the SP entity (Col 5 line 25-35; The key issuer 300 is configured to generate a new group/identity by creating the group public key. The key issuer 300 could be implemented as a service provided by the service provider 500 or it could e.g. be implemented as an application running in an entity of the owner 600 of the host entity 200.; S204a: The key issuer 300 verifies authentication of the host entity 200 using the public key and the current private key; ). Motivation would be same as stated in claim 30.
With regards to claim 34, Wei in view of Salmela discloses, wherein new key is obtained by being received from the DI wallet entity (Salmela FIG 6 s303 and associated text; Col 9 line 40-50; S204: The key issuer 300 performs a private key update procedure with the host entity 200 using the public key and the current private key. Parameters for the new private key are negotiated with the host entity 200. ; Col 5 line 25-35; The key issuer 300 is configured to generate a new group/identity by creating the group public key. The key issuer 300 could be implemented as a service provided by the service provider 500 or it could e.g. be implemented as an application running in an entity of the owner 600 of the host entity 200. ). Motivation would be same as stated in claim 30.
With regards to claim 35, Wei further discloses, wherein the new key pair is obtained by being generated by the communication device (Page 7; In the embodiment of the specification, after the user input key replacement operation, the client may also be based on the key replacement operation, generating the second key pair. wherein the second key pair can be generated by the client local, also avoids the key to pass through too much transmission, also can ensure the security of the newly generated key pair.).
With regards to claim 36, Wei further discloses, wherein the attributes of the verifiable credentials comprise a device identifier of the communication device, a device identifier of the DI wallet entity, and either a public key of the new key pair or an indication that the new key pair is to be generated by the communication device (Page 2: if the first key change result feedback information indicates that the first information verification is passed, then determining that the second key pair is in an enabled state.).
Claim 41 is device claim corresponding to method claim 30, also rejected accordingly.
Note: Wei discloses Communication device, the Communication device comprising processing circuitry (FIG 1, 10 and associated text; page 20 para 3; The system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function. A typical implementation device is a computer. Specifically, the computer can be personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game console, a flat computer, a wearable device or any combination of devices in the device.)
Claim 31, 37 is rejected under 35 U.S.C. 103 as being unpatentable over Wei et al(CN 115549958 A) in view of Salmela et al(US 11296878 B2) and further in view of MILAN et al(WO 2024095032 A1).
With regards to claim 31, Wei in view Salmela do not MILAN teaches, sending a device identifier of the communication device to the DI entity ([0033] FIG. 1 depicts a scenario in which the officer 112 has to carry an officer ID-scanning device 114 up to the side of the driver vehicle 104 that is driven by a driver 106. The officer 112 may use the officer ID-scanning device 114 to scan a QR code on, or engage in NFC communication with, a driver mobile device 108 of the driver 106. The mDL of the driver 106 may be stored on the driver mobile device 108. As described above, this arrangement is less than ideal for reasons including convenience and safety. Note: mDL is transmitted to Scanner) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify Wei in view of Salmela’ method with teaching of MILAN in order for deterministic and handsfree engagement for data transfer of mobile identification (MILAN Abstract).
With regards to claim 37, Wei in view Salmela and MILAN teaches, wherein the communication device utilizes either an ISO/IEC18013-5 protocol, an ISO/IEC18013-7 protocol, or an OpenID4VP protocol for communication with the DI wallet entity(MILAN [0018] In the field of digital IDs, there are several standards that have been promulgated by an organization known as the International Standardization Organization, or ISO for short. Moreover, a number of these standards are developed via collaboration between ISO and another organization known as the International Electrotechnical Commission (IEC). Two such series of these standards are the ISO/IEC 18013 series and the ISO/IEC 23220 series. Included in the former is a standard called “ISO/IEC 18013-5: Personal Identification - ISO- Compliant Driving License - Part 5: Mobile Driving License (MDL) Application.” Included in the latter is a standard (currently under development) called “ISO/IEC 23220-4: Cards and Security Devices for Personal Identification — Building Blocks for Identity Management via Mobile Devices — Part 4: Protocols and Services for Operational Phase.”). Motivation would be same as stated in claim 31.
Claim 32, is rejected under 35 U.S.C. 103 as being unpatentable over Wei et al(CN 115549958 A) in view of Salmela et al(US 11296878 B2) and further in view of Sekiya(US 20080195736 A1).
With regards to claim 32, Wei in view Salmela do not Sekiya teaches, wherein the method further comprises: sending an acknowledgement of the key replacement to the DI entity(Sekiya 0049] Moreover, in the wireless network in which a key is periodically renewed, a case occurs in which an ACK (Acknowledgement) has to be transmitted to a key to be renewed.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify Wei in view of Salmela’ method with teaching of MILAN in order to provide support for connecting operations according to results of trials of connections to wireless networks and analysis of wireless packets (Sekiya[0001]).
Claim 38-40, 42 are rejected under 35 U.S.C. 103 as being unpatentable over Wei et al. (CN 115549958 A:IDS supplied) in view of Salmela et al(US 11296878 B2) and further in view of Lewis (US 5761306 A).
With regards to claim 38, Wei discloses, A method for key replacement in a communication device, wherein the method is performed by a Service Provider (SP) entity (FIG. 1, the architecture comprises: client 10, service system 20; page 20 para3; ), and wherein the method comprises:
receiving a report of successful key replacement of a key pair at the communication device (Page 6; obtaining the feedback information of the first key change result fed back by the service system; Note: key change result feedback information as report received by user device(communication device))
communicating with the communication device(page 6 para 5; In practical application, the private key in the key pair can be automatically stored by the user, when processing the service, the user needs to perform service processing by the private key, for example, the transaction of digital collections by means of private key signature. The second key pair may indicate that the user can use the private key in the second key pair to perform service processing in the enabled state.)
Wei does not exclusively but Salmela teaches,
receiving a new public key of the key pair from a Digital Identity (DI) wallet entity (Col 13 line 15-20; (100) S314: The key issuer 300 makes the private key revocation list accessible to the service provider(s) 500 registered for this identity/public key. );
replacing a public key of a key pair at the SP entity with the new public key (Col 12 line 35-50; The identity of the host entity 200, i.e. the public key, is configured to the service provider(s) 500 where the identity will be used. This configuration comprises providing the public key and information of the key issuer 300 to the service provider 500. The latter is needed in order for the service provider 500 to know from where the private key revocation list is accessible. The key issuer 300 can be configured with information about the service provider(s) 500 of the service(s) where the identity will be used so that the key issuer 300 knows for what service provider(s) 500 the private key revocation list is to be made accessible. Col 55-62 ; The host entity 200 is registered at the service provider and is identified with the assigned public key. When the host entity 200 authenticates itself to the service provider 500, the service provider 500 can be configured to verify the private key is not on the private key revocation list, Col 13 line 15-20; (100) S314: The key issuer 300 makes the private key revocation list accessible to the service provider(s) 500 registered for this identity/public key. Note: Service provider with updated provocation list authenticate Host suggest public key corresponding to private key is replaced); and It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify Wei’ method/system with teaching of Salmela in order to improve security by updating of a key of a host entity (Col 1line 60-63; Salmela).
Wei In view of Salmela do not exclusively but Lewis teaches, communicating with the communication device, wherein the new public key is used as part of the Central server(SP entity) communicating with the communication device (Abstract : To replace the active public key with the replacement public key, a key replacement message is sent to the node. The key replacement message contains the replacement public key and contains the mask of the next replacement key.; FIG 2 S2, S3 and associated text;). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify Wei in view of Salmela’s method with teaching of Lewis in order to provide secure transaction over a possible insecure network (Lewis Abstract).
With regards to claim 39, Examiner taking Official Notice that “ receiving a device identifier of the communication device and a request for the service from the DI wallet entity; and sending a token for key replacement to the DI wallet entity” is well known in the art as client send device ID to authenticator/server for token to get service(key replacement) with the token.
With regards to claim 40, Wei further discloses, wherein the method further comprises: verifying successful key replacement to the communication device upon having received a report of successful key replacement of a key pair at the communication device (Page 2; obtaining the feedback information of the first key change result fed back by the service system; the first key change result feedback information is used for representing the user identity authentication result generated based on the first information sent to the service system by the block chain system; if the first key change result feedback information indicates that the first information verification is passed, then determining that the second key pair is in an enabled state.).
Claim 42 is a device claim corresponding method claim 38, Also rejected accordingly.
Note: Wei discloses SP Entity, the SP entity comprising processing circuitry (FIG 20 and associated text; page 20 para 3; The system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function. A typical implementation device is a computer. Specifically, the computer can be personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game console, a flat computer, a wearable device or any combination of devices in the device.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 6240187 B1, US 20190037395 A1, WO 2024095032 A1.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMED WALIULLAH whose telephone number is (571)270-7987. The examiner can normally be reached 8.30 to 430 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 1-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.
/MOHAMMED WALIULLAH/Primary Examiner, Art Unit 2498