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 . 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.
Claims 1-7, 20 and 23 are pending.
Claims 8-19 and 21-22 are cancelled.
Claims 1-3, 5-7, 20 and 23 are amended.
Claim Objections
Claims 1, 20, and 23 objected to because of the following informalities: Claims 1, 20, and 23 recite the limitations "wherein the certificate chain is a multi-level certificate chain…". Examiner considering that it is a typographical mistake of missing a word “pre-constructed” and assuming that applicant intends these to be the same certificate chain i.e “pre-constructed certificate chain”.
Appropriate correction is required.
Response to Arguments
Applicant’s arguments, see page 8, filed 06/18/2026, with respect to claims 1-7, 20 and 23 have been fully considered and are persuasive. The objections of 03/18/2026 has been withdrawn.
Applicant’s arguments, see page 9, filed 06/18/2026, with respect to claims 1-7, 20 and 23 have been fully considered and are persuasive. The rejection under 35 USC 112(a) and 112(b) of 03/18/2026 has been withdrawn.
Applicant’s arguments, see page 10-11, filed 03/18/2026, with respect to the rejection(s) of claim(s) 1, 20 and 23 under 35 USC § 103 have been fully considered.
However, upon carefully reviewing previously applied prior arts, examiner believes that Buniyan and Zhao Ming still teaches limitations amended portions of claim 1.
Applicant argues on page 10:
“Bunyan is directed to a real-time, server-dependent authorization system for fleet management. In Bunyan, the portable device does not store any pre-shared certificates or keys. It obtains the vehicle identity from the on-board computer and immediately sends a request to a remote authentication server. The server checks a centralized database and returns a response. There is no certificate chain whatsoever in Bunyan, and certainly no multi-level certificate chain that binds the server, the terminal, and the vehicle. Bunyan also does not use a predetermined key of the terminal device to verify anything; the verification is performed solely by the remote server. Bunyan does not involve encryption of control instructions by the portable device using target verification information; instead, it merely sends a "go ahead" signal.
Examiner respectfully disagree because Zhao ming disclosed in paragraph [0127] that the The multi-level certificate chain technology is a security protection mechanism adopted to prevent a final certificate inside the handheld terminal from being forged/falsified. An implementation principle is that the checking is carried out level by level from a root certificate provided by a certificate authority, and a vehicle factory certificate, the server certificate and the on-vehicle terminal certificate are verified in sequence, so that a purpose of checking security and reliability of the on-vehicle terminal certificate is achieved”. Bunyan reference was not cited for generating certificate chain limitation. Additionally Zhao Ming disclosed the claim limitation “sending the encrypted vehicle control instruction to the in-vehicle device, wherein the in-vehicle device is enabled to decrypt the encrypted vehicle control instruction based on the target verification information and the certificate chain” in paragraph [0128] teaches encrypted control instructions is sent to the vehicle terminal…and [0150] teaches decrypting encrypted control instructions by in-vehicle device as required by claimed limitation.
Furthermore, Applicant argues:
“Zhao Ming also does not generate a certificate chain based on identification information and predetermined keys of all three entities (server, terminal, vehicle).”
Examiner respectfully disagree because claim 1 recites “wherein the certificate chain is a multi-level certificate chain generated based on server identification information of the first server, a predetermined key of the first server, device information of the terminal device, the predetermined key of the terminal device, device information of the in-vehicle device, and a predetermined key of the in-vehicle device;” Zhao Ming disclose [0127], The multi-level certificate chain technology is a security protection mechanism adopted to prevent a final certificate inside the handheld terminal from being forged/falsified. An implementation principle is that the checking is carried out level by level from a root certificate provided by a certificate authority, and a vehicle factory certificate, the server certificate (=first server info and predetermined key of the first server) and the on-vehicle terminal certificate (=in-vehicle device info and predetermined key of the in-vehicle device terminal + handheld terminal device information and predetermined key of the handheld terminal device ) are verified in sequence, so that a purpose of checking security and reliability of the on-vehicle terminal certificate is achieved.) Examiner’s notes: Zhao Ming disclose in [0024] that “In step S102, a binding relationship with an on-vehicle terminal is established by using a NFC technology, the binding relationship indicates that the on-vehicle terminal corresponds to the handheld terminal in a one-to-one relationship”. Examiner interpreting that a binding relationship is already established between on-vehicle terminal device and handheld terminal device then on-vehicle terminal device certificates integrates/carries information of handheld device and predetermined key of the handheld terminal device. Additionally, none of that information described as being part of the certificate is functionally utilized in the claims. Only the predetermined key of the terminal device is used...in the verification step. The rest of the data in the certificate chain is not functionally utilized and considered as non-functional descriptive material. At that point, the data is irrelevant because it is never used so it does not matter what data is included in the certificate. Claim limitations citing that certificate chain is generated based on some data but that data never functionally utilized in the claim(s).
Applicant argues:
“Moreover, Zhao Ming relies on symmetric keys or plaintext/ciphertext verification for control instructions, not on a pre-constructed certificate chain that is verified by the terminal using its own predetermined key. Zhao Ming does not teach the claimed encryption and decryption of the vehicle control instruction based on the target verification information and the certificate chain.”
Examiner respectfully disagree because Zhao Ming disclosed checking legality of the certificates level by level after receiving certificates and then decides of the certificates are decided to be legal. See paragraph [0125], [0127]. Zhao Ming disclose in para [0106] “the handheld terminal decides whether the server certificate and the on-vehicle terminal certificate issued by the server are legal through a built-in ROOT CA and a multi-stage certificate chain.”
Additionally, Zhao Ming disclosed encrypting and decrypting vehicle control instructions based on target information and the certificate chain. Zhao ming disclose in para [0125] that the handheld terminal uses a built-in root certificate for the server, a built-in root certificate for the on-vehicle terminal, and a multi-level certificate chain to check legality of the certificates level by level after receiving the certificates and stores the two certificates locally if the certificates are decided to be legal. Zhao ming first disclose in para [0127]” a multi-level certificate checking process is completed” and then in para [0128] disclose, In step 5, the control instruction is encrypted by using the symmetric key…” which reads on the claim limitations of encryption and decryption of the vehicle control instruction based on the target verification information and the certificate chain”.
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.
Claim(s) 1, 20 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over view of Bunyan (U. S. PGPub. No. 2002/0135466 A1) (hereinafter “Bunyan”) in view of Zhao Ming (EP 3723399 A1) (hereinafter “Zhao Ming”)
Regarding Claim 1, Bunyan teaches:
sending a local identity verification request for controlling an in-vehicle device to a first server (Bunuyan: the portable device 14 then sends an authentication request message to the authentication server 15…), wherein the first server is configured to generate target verification information (Bunuyan: [0036]-[0039]) corresponding to the terminal device (Bunyan: [0027] the identity of the portable device), and the in-vehicle device (Bunyan: [0026] the identity of the vehicle) for the identity verification request (Bunuyan: [0040], portable device determines from the response whether the authentication checks were successful. It then forwards “authentication mandatory” flag to the on-board computer which easily reads into “processing a vehicle control instruction” as it starts the vehicle engine ([0042]).
Bunyan does not explicitly disclose below limitations, however, in an analogous art, Zhao Ming teaches:
receiving the target verification information (Zhao Ming: [0085], When the user wants to use the mobile phone to control a vehicle, a message of a plaintext together with the ciphertext is sent to the on-vehicle terminal, the plaintext is information about the current terminal and the user and includes an equipment fingerprint, a verification code, a MAC address for Bluetooth, a terminal number and the like, and the ciphertext is a portion of the virtual key returned by the cloud server) and a pre-constructed certificate chain that are sent by the first server (Zhao Ming: [0109], meanwhile receives a server certificate and an on-vehicle terminal certificate issued by the server. These certificates are stored locally),
and verifying the pre-constructed certificate chain (Zhao Ming: [0125], In step 4… a multi-level certificate chain to check legality of the certificates level by level after receiving the certificates, and stores the two certificates locally if the certificates are decided to be legal. [0127], In the multi-level certificate checking, the first level certificate uses the root certificate, and from the second certificate, a public key in a certificate of the last level is used to check a digital signature in a certificate of the current level, a public key in the certificate of the current level is obtained if the checking is successful, and the public key in the certificate of the current level is used for checking a digital signature in a certificate of the next level, and so on, a multi-level certificate checking process is completed) and verifying…the target verification information based on a predetermined key of the terminal device to obtain a verification result (Zhao Ming: [0085], After receiving information of the plaintext and the ciphertext, the on-vehicle terminal firstly decrypts the ciphertext, reads the information about the terminal and the user in the ciphertext, then compares the information about the terminal and the user with information contained in the plaintext, determines that the mobile phone is a legal terminal if the information of the terminal and the user is consistent with the information contained in the plaintext, and allows executions of relevant vehicle control instructions..)
wherein the certificate chain is a multi-level certificate chain generated based on server identification information of the first server, a predetermined key of the first server, device information of the terminal device, the predetermined key of the terminal device, device information of the in-vehicle device, and a predetermined key of the in-vehicle device (Zhao Ming: [0125], The handheld terminal (=terminal device=mobile phone) uses a built-in root certificate for the server (=server identification info), a built-in root certificate for the on-vehicle terminal, and a multi-level certificate chain to check legality of the certificates level by level after receiving the certificates, and stores the two certificates locally if the certificates are decided to be legal [0127], The multi-level certificate chain technology is a security protection mechanism adopted to prevent a final certificate inside the handheld terminal from being forged/falsified. An implementation principle is that the checking is carried out level by level from a root certificate provided by a certificate authority, and a vehicle factory certificate, the server certificate (=first server info and predetermined key of the first server) and the on-vehicle terminal certificate (=in-vehicle device info and predetermined key of the in-vehicle device terminal + handheld terminal device information and predetermined key of the handheld terminal device ) are verified in sequence, so that a purpose of checking security and reliability of the on-vehicle terminal certificate is achieved.) Examiner’s notes: Zhao Ming disclose in [0024] that “In step S102, a binding relationship with an on-vehicle terminal is established by using a NFC technology, the binding relationship indicates that the on-vehicle terminal corresponds to the handheld terminal in a one-to-one relationship”. Examiner interpreting that on-vehicle terminal device certificates integrates include information of handheld device and predetermined key of the handheld terminal device.
and when the verification result is that the verification succeeds (Zhao Ming: [0150], In step 6, it is decided whether the instruction is legal by using a stored symmetric key, and a vehicle is informed to execute a relevant action if the instruction is legal. [0155], In step 2, it is fed back whether the handheld terminal is authenticated according to an authentication result. The on-vehicle terminal performs decryption by using a built-in private key according to a received message, decides whether the handheld terminal is an authenticated terminal, and feeds back a success result to the handheld terminal if the handheld terminal is the authenticated terminal. [0156],In step 3, a certain vehicle work function interface is triggered. The user initiates a triggering of a certain vehicle control function, which is generally realized by an APP of the handheld terminal),
encrypting a vehicle control instruction based on the target verification information (Zhao Ming: [0112], The vehicle control instruction processing module is configured to use the symmetric key…to encrypt the control instruction, and then send the encrypted control instruction to the on-vehicle terminal to achieve a purpose of directly controlling the on-vehicle terminal by using the handheld terminal))
and sending the encrypted vehicle control instruction to the in-vehicle device (Dao Ming: [0128], In step 5, the control instruction is encrypted by using the symmetric key and then the encrypted control instruction is sent to the on-vehicle terminal. The handheld terminal sends the control instruction encrypted by the symmetric key to the on-vehicle terminal), wherein the in-vehicle device is enabled to decrypt the encrypted vehicle control instruction based on the target verification information and the certificate chain (Zhao Ming: Dao Ming: [0150], In step 6, it is decided whether the instruction is legal by using a stored symmetric key, and a vehicle is informed to execute a relevant action if the instruction is legal. The on-vehicle terminal decrypts the instruction message by using a symmetric key which is stored securely, if the decryption is successful, the on-vehicle terminal decides that the instruction is a legal control request, and the on-vehicle terminal may send the instruction to other ECUs in the vehicle to execute an operation).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Bunyan’s method of sends an authentication request message to the authentication server which include identity of portable device and identity of the vehicle by applying Zhao Ming’s method of determines that the mobile phone is a legal terminal of handheld terminal is a legal terminal then handheld device able to encrypt the control instructions and send it to on-vehicle terminal in order to decrypting encrypted control instructions. The motivation is to solve a technical problem of low security when an on-vehicle terminal authenticates a handheld terminal (Zhao Ming: [0004])
Regarding Claim 20, this claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 20.
Regarding Claim 23, this claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 23.
Claim(s) 2-3 are rejected under 35 U.S.C. 103 as being unpatentable over Bunyan (U. S. PGPub. No. 2002/0135466 A1) (hereinafter “Bunyan”) in view of Zhao Ming (EP 3723399 A1) (hereinafter “Zhao Ming”), and further in view of Sasaki (U. S. Pat. No. 6,351,536 B1) (hereinafter “Sasaki”) and Yu et al. (U. S. PGPub. No. 2021/0250183 A1) (hereinafter “Yu”)
Regarding Claim 2, Bunyan in view of Zhao Ming teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein before the receiving the target verification information (Zhao Ming: [0085], When the user wants to use the mobile phone to control a vehicle, a message of a plaintext together with the ciphertext is sent to the on-vehicle terminal, the plaintext is information about the current terminal and the user and includes an equipment fingerprint, a verification code, a MAC address for Bluetooth, a terminal number and the like, and the ciphertext is a portion of the virtual key returned by the cloud server) and a pre-constructed certificate chain that are sent by the first server, the method comprises (Zhao Ming: [0109], meanwhile receives a server certificate and an on-vehicle terminal certificate issued by the server. These certificates are stored locally):
The Bunyan in view of Zhao Ming does not explicitly disclose:
receiving the server identification information of the first server and a first public key of the first server, wherein the first public key is a key that corresponds to the first server and that is generated by the first server based on a predetermined key generation algorithm;
generating a second private key and a second public key that correspond to the terminal device based on the predetermined key generation algorithm;
However, in an analogous art, Sasaki teaches:
receiving the server identification information of the first server and a first public key of the first server (Sasaki: [Col 7, lines 50-53], (27) The transmitter 10 which has received the first public key i and the identifier i retrieves a common key i, which corresponds to the received identifier i, of the common keys registered in the external storage device 18 (step 104)), wherein the first public key is a key that corresponds to the first server and that is generated by the first server based on a predetermined key generation algorithm (Sasaki: [Col 6, lines 23-26], (14) iv) a first key generation program for generating a pair of a first public key and a first secret key (hereinafter referred to as a first public key/secret key generation program));
generating a second private key and a second public key that correspond to the terminal device based on the predetermined key generation algorithm (Sasaki: [Col 11, lines 19-22], (59) viii) a second key generation program for generating a pair of a second public key and a second secret key (hereinafter referred to as a second public key/secret key generation program);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming by applying the well-known technique as disclosed by Sasaki of generating a second public key and a second secret key. The motivation is a plurality of encrypted communications are transmitted on the network securely (Sasaki: [Col 2, lines 18-19]).
Bunyan in view of Zhao Ming and Sasaki does not explicitly teaches:
signing the device information of the terminal device based on the second private key to obtain first signature information
generating a root certificate based on the second public key, the device information of the terminal device, and the first signature information
signing the server identification information based on the second private key to obtain second signature information;
generating a second certificate based on the first public key, the server information, and the second signature information.
However, in an analogous art, Yu teaches:
signing the device information of the terminal device based on the second private key to obtain first signature information (Yu: [0124] FIG. 5 shows a first certificate chain in some implementations. In FIG. 5, certificate 51 is a first public key certificate, and includes information about a first task group (for example, denoted as GID1) as a certificate holder, first public key K1 (public key generated for GID1), information about a certificate generator as an issuer, and first signature information signed by the trusted certificate generator) [0125] FIG. 6 shows a first certificate chain in some other implementations. In FIG. 6, certificate 61 is a first public key certificate, and includes information about a first task group (for example, denoted as GID1) as a certificate holder, first public key K1 (public key generated for GID1), information about a certificate generator as an issuer, and first signature information signed by the trusted certificate generator);
generating a root certificate based on the second public key, the device information of the terminal device, and the first signature information (Yu: [0086] A root certificate is a certificate issued (=generating) by a root CA to itself. The root CA is usually the most trustworthy CA center and must be trusted. As shown in the figure, the root certificate 30 includes root CA information (in this case, the root CA is both a holder and an issuer), the root CA's public key, and signature information given by the root CA to the root CA itself. [0087] As such, the root certificate 30 and each public key certificate form a certificate chain or a trust chain, where the root certificate is issued by the root CA to the root CA itself, and subsequent public key certificates are issued by the root CA and each CA authorized by the root CA by level….)
signing the server identification information based on the second private key (Yu: [0124], second signature information self-signed by the trusted certificate generator [0135], Assume that task 4 belongs to a second task group. Therefore, the trusted computing unit 14 can obtain a second root certificate, a second public key certificate, and a second private key that are generated for the second task group) to obtain second signature information (Yu: [0124], second signature information self-signed by the trusted certificate generator);
generating a second certificate based on the first public key, the server identification information, and the second signature information (Yu: [0147] Then, in step S806, the trusted certificate generator returns a certificate report to the user terminal, which is referred to as a second certificate (=second certificate) report, and includes at least the first root certificate in the first certificate chain);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming and Sasaki by applying the well-known technique as disclosed by Yu of generating second certificate by self-signing second signature information. The motivation is to facilitate multiple participants to perform multi-party secure computing to provide corresponding computing services (Yu: [0006]).
Regarding claim 3, Bunyan in view of Zhao Ming, Sasaki and Yu teaches:
The method of claim 2 (see rejection of claim 2 above),
wherein before the receiving the target verification information (Zhao Ming: [0085], When the user wants to use the mobile phone to control a vehicle, a message of a plaintext together with the ciphertext is sent to the on-vehicle terminal, the plaintext is information about the current terminal and the user and includes an equipment fingerprint, a verification code, a MAC address for Bluetooth, a terminal number and the like, and the ciphertext is a portion of the virtual key returned by the cloud server) and a pre-constructed certificate chain that are sent by the first server, the method comprises (Zhao Ming: [0109], meanwhile receives a server certificate and an on-vehicle terminal certificate issued by the server. These certificates are stored locally):
generating a fourth public key corresponding to a user based on the predetermined key generation algorithm (Sasaki: [Col 22, lines 66-67], (212) xiii) a fourth key generation program for generating a pair of a fourth public key and a fourth secret key (hereinafter referred to as a fourth public key/secret key generation program)
and sending the fourth public key and the device identification information of the terminal device to the first server, so that the first server generates the target verification information based on the device information of the terminal device, the fourth public key, the predetermined key of the in- vehicle device, and the device information of the in-vehicle device (Sasaki: [Col 23, lines 45-49], (221) The receiver 20 is connected to the server 30…which has been transmitted from the transmitter 10, so that the fourth public key i and the identifier i are transmitted from the receiver 20 to the server 30 (step 252)).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming by applying the well-known technique as disclosed by Sasaki of transmitting fourth public key from receiver to the server. The motivation is a plurality of encrypted communications are transmitted on the network securely (Sasaki: [Col 2, lines 18-19]).
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Bunyan (U. S. PGPub. No. 2002/0135466 A1) (hereinafter “Bunyan”) in view of Zhao Ming (EP 3723399 A1) (hereinafter “Zhao Ming”), and further in view of Sasaki (U. S. Pat. No. 6,351,536 B1) (hereinafter “Sasaki”) and Yu et al. (U. S. PGPub. No. 2021/0250183 A1) (hereinafter “Yu”); and in further view of Wei et al. (U. S. PGPub. No. 2021/0051023 A1) (hereinafter “Wei”).
Regarding Claim 7, Bunyan in view of Zhao Ming, Sasaki and Yu teaches:
The method of claim 3 (see rejection of claim 3 above),
wherein the generating a fourth public key corresponding to a user based on the predetermined key generation algorithm comprises (Sasaki: [Col 22, lines 66-67], (212) xiii) a fourth key generation program for generating a pair of a fourth public key and a fourth secret key (hereinafter referred to as a fourth public key/secret key generation program):
Bunyan in view of Zhao Ming, Sasaki and Yu does not explicitly teach:
sending an identity verification request for the user to a second server;
receiving a target token generated by the second server based on the identity verification request;
and performing identify verification on the user based on the target token and generating the fourth public key corresponding to the user based on the predetermined key generation algorithm when an identity verification result is that the verification succeeds.
However, in an analogous art, Wei teaches:
sending an identity verification request for the user to a second server (Wei: [0096], obtain a target identity verification request (=identity verification request) and its corresponding target identity verification identifier that are used for identity verification, and send the target identity verification request and the first identity public key to the user terminal. [0060], an authentication server 300 performs step 4: obtaining (=sent by user terminal) a first identity verification request and a first identity verification identifier)
receiving a target token generated by the second server based on the identity verification request (Wei: (Examiner interpreting biometric feature as a target token because biometric features can serve as a type of "token" for identity verification) [0076] the user terminal 100 collects the corresponding target identity verification data (=receiving a token) (=[0076], the target identity verification data includes biometric feature information of the system user) in response to the target identity verification request. In this case, because the target identity verification request includes the second identity verification method, the target identity verification data can be collected by using the second identity verification method);
and performing identify verification on the user based on the target token (Wei: [0098] S108: Perform identity verification by using the target identity verification data, and verify whether the first identity public key and the second identity public key correspond to a same user; and when the identity verification succeeds and it is verified that the two identity public keys correspond to a same user, store obtained target authentication data to an authentication blockchain, where the target authentication data includes the target private key signature data and the target identity verification identifier),
and generating the fourth public key corresponding to the user based on the predetermined key generation algorithm (Sasaki: [Col 22, lines 66-67 0 Col 23, lines 1-2], (212) xiii) a fourth key generation program for generating a pair of a fourth public key and a fourth secret key (hereinafter referred to as a fourth public key/secret key generation program) when an identity verification result is that the verification succeeds (Wei: (2021/0051023 A1) [0050], During the identity verification performed by using the first identity verification data and the matching identity verification data, matching can be performed between the first identity verification data and the matching identity verification data. If the first identity verification data matches the matching identity verification data, it is determined that the identity verification succeeds. If the first identity verification data does not match the matching identity verification data, it is determined that the identity verification fails).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming, Sasaki and Yu by applying the well-known technique as disclosed by Wei of performing identity verification process. The motivation is to perform identity confirmation across blockchain by providing cross-chain authentication method (Wei: [0005]).
Claim(s) 4 is rejected under 35 U.S.C. 103 as being unpatentable over Bunyan (U. S. PGPub. No. 2002/0135466 A1) (hereinafter “Bunyan”) in view of Zhao Ming (EP 3723399 A1) (hereinafter “Zhao Ming”), and further in view of Sasaki (U. S. Pat. No. 6,351,536 B1) (hereinafter “Sasaki”) and Yu et al. (U. S. PGPub. No. 2021/0250183 A1) (hereinafter “Yu”); and further view of Brown et al. (U. S. Pat. No. 9,621,352 B2) (hereinafter “Brown”)
Regarding Claim 4, Bunyan in view of Zhao Ming, Sasaki and Yu teaches:
The method of claim 3 (see rejection of claim 3 above),
The Bunyan in view of Zhao Ming, Sasaki and Yu does not explicitly disclose below limitations, however, in an analogous art, Brown disclose:
wherein the verifying the certificate chain and the target verification information based on a predetermined key of the terminal device to obtain a verification result comprises: (Brown: [Col 12, lines 10-15], (57) For a public key to be trusted, its issuing organization must be trusted. The relationship between a trusted CA and a user's public key can be represented by a series of related certificates, also referred to as a certificate chain. The certificate chain can be followed to determine the validity of a certificate)
verifying the root certificate and the second certificate in the certificate chain (Brown: [Col 12, lines 32-46], (59) However, in the example shown in FIG. 5, certificate 330 is also required to verify the trust status of certificate 310. Certificate 330 is self-signed, and is referred to as a “root certificate”. Accordingly, certificate 320 may be referred to as an “intermediate certificate” in certificate chain 300; any given certificate chain to a root certificate, assuming a chain to the root certificate can be determined for a particular end entity certificate, may contain zero, one, or multiple intermediate certificates. If certificate 330 is a root certificate issued by a trusted source (from a large certificate authority such as Verisign or Entrust, for example), then certificate 310 may be considered to be trusted since it chains to a trusted certificate. The implication is that both the sender and the recipient of the message trust the source of the root certificate 330) based on the first public key of the first server (Brown: [Col 2, lines 8-14], a method of verifying a digital signature on a certificate on a computing device, the method comprising the steps of: performing a first signature verification operation on the digital signature using a first public key associated with an issuer of the certificate; determining if the digital signature is successfully verified in the first signature verification operation; storing the first public key in a memory store) and the second public key of the terminal device to obtain a first verification result (Brown: [Col 2, lines 15-23], receiving a request to perform a second signature verification operation on the digital signature using a second public key associated with an issuer of the certificate; comparing the second public key with the first public key stored in the memory store to determine if the first and second public keys match; and indicating successful verification of the digital signature in response to the request if the digital signature was successfully verified in the first signature verification operation)
verifying the first verifiable information based on the first public key of the first server and the target verification information to obtain a second verification result (Brown: [Col 2, lines 10-12], performing a first signature verification operation on the digital signature using a first public key associated with an issuer of the certificate);
and determining the verification result based on the first verification result and the second verification result (Brown: [Col 18, lines 40-55], the public key and associated result may be stored with the certificate data associated with the certificate, or in a separate memory store (e.g. a lookup table). When a subsequent attempt to verify the digital signature on the same certificate is made using the given public key, rather than performing an expensive signature verification operation requiring at least the decoding of some data using that public key, the public key that would have been used to verify the digital signature again is instead initially compared to the stored public key(s). If the given public key matches a stored public key, then the current verification attempt will be deemed successful or not successful, depending on the stored result associated with that stored public key. If the stored result indicates that the previous verification attempt with that stored public key was successful, then the current verification attempt will be deemed to succeed)
Bunyan in view of Zhao Ming, Sasaki does not explicitly teach:
receiving first verifiable information sent by the first server, wherein the first verifiable information is information that corresponds to the target verification information and that is obtained by the first server by encrypting the target verification information based on a first private key of the first server.
However, in an analogous art, Yu teaches:
receiving first verifiable information sent by the first server, wherein the first verifiable information is information that corresponds to the target verification information and that is obtained by the first server by encrypting the target verification information based on a first private key of the first server (Yu: [0055] S204: The server 106 generates corresponding encrypted information (=target verification information) according to the login request of the first device, wherein the encrypted information (=first verifiable information) includes at least one of the following: a key pair and a digital certificate. [0058] S206: After receiving the encrypted information returned by the server 106, the first device 102 generates encrypted identity information based on the login account and the encrypted information).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming, and Sasaki by applying the well-known technique as disclosed by Yu of generating encrypted information. The motivation is to facilitate multiple participants to perform multi-party secure computing to provide corresponding computing services (Yu: [0006]).
Claim(s) 5 is rejected under 35 U.S.C. 103 as being unpatentable over Bunyan (U. S. PGPub. No. 2002/0135466 A1) (hereinafter “Bunyan”) in view of Zhao Ming (EP 3723399 A1) (hereinafter “Zhao Ming”), and further in view of Sasaki (U. S. Pat. No. 6,351,536 B1) (hereinafter “Sasaki”) and Yu et al. (U. S. PGPub. No. 2021/0250183 A1) (hereinafter “Yu”) and Brown et al. (U. S. Pat. No. 9,621,352 B2) (hereinafter “Brown”); and in further view of Mathias et al. (U. S. PGPub. No. 2020/0052905 A1) (hereinafter “Mathias”);
Regarding Claim 5, Bunyan in view of Zhao Ming, Sasaki and Yu, Brown teaches:
The method of claim 4 (see rejection of claim 4 above),
The Bunyan in view of Zhao Ming, Sasaki and Yu, Brown cited above does not explicitly disclose below limitations, however, in an analogous art, Mathias disclose:
wherein the processing a vehicle control instruction based on the target verification information (Mathias: [0046] Pairing of mobile device 130 and system 110 may involve establishment of a shared secret (which may also be referred to as a shared key) and storing a long-term public key from the SE 134 by the system 110. A detailed description of an exemplary pairing procedure is discussed below, with reference to FIG. 3. Once paired, SE 134 may also facilitate transactions in which the mobile device 130 instructs the system 110 to perform various operations, e.g., as discussed below with reference to FIG. 4.), and sending a processed vehicle control instruction to the in-vehicle device comprises (Mathias: [0047] FIG. 1B is a block diagram illustrating exemplary communications between a system and a mobile device to perform an operation, according to some embodiments. Examples of an operation include opening a door lock, starting an engine, enabling or disabling functionality, changing media being played, connecting or disconnecting the system to a wide-area network, authorizing or removing additional users, access to keychain data, ability to make purchases, etc. In the illustrated embodiment, SE 134 is configured to perform authentication communications 155 for a request 150 initiated by AP 136):
encrypting the vehicle control instruction based on a fourth private key of the user to obtain second verifiable information (Mathias: [0038], In response to receiving the challenge, the secure element of the mobile device generates a response using a private key of the previously generated public key pair….The mobile device then encrypts the response with the other encryption key and sends the response to the system for verification. In response to a successful verification, the system may enable requested functionality. [0045], SE 134 is configured to perform various encryption operations to facilitate secure communications between mobile device 130 and system 110),
and encrypting the vehicle control instruction (Mathias: [0038], The mobile device then encrypts the response with the other encryption key and sends the response to the system for verification. In response to a successful verification, the system may enable requested functionality. [0045], SE 134 is configured to perform various encryption operations (=encrypting the vehicle control instruction) to facilitate secure communications between mobile device 130 and system 110) and the second verifiable information based on the third public key of the in-vehicle device to obtain an encrypted vehicle control instruction (Mathias: [0042], by encrypting results using a private or secret key, a secure circuit may authenticate the source of the encrypted data), and sending the encrypted vehicle control instruction to the in-vehicle device, so that the in- vehicle device processes the vehicle control instruction (Mathias: [0047] FIG. 1B is a block diagram illustrating exemplary communications between a system and a mobile device to perform an operation, according to some embodiments. Examples of an operation include opening a door lock, starting an engine, enabling or disabling functionality, changing media being played, connecting or disconnecting the system to a wide-area network, authorizing or removing additional users, access to keychain data, ability to make purchases, etc. In the illustrated embodiment, SE 134 is configured to perform authentication communications 155 for a request 150 initiated by AP 136) based on the fourth public key and a third private key, wherein the third private key is a private key that corresponds to the third public key and that is generated by the in-vehicle device (Mathias: [0038], The mobile device then encrypts the response with the other encryption key (=private key and public key) and sends the response to the system for verification. In response to a successful verification, the system may enable requested functionality.).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming, Sasaki and Yu, Brown by applying the well-known technique as disclosed by Mathias of after successful verification, processing instruction transmitted from the mobile device in to perform an operations like opening a door lock, starting engine, etc. The motivation is providing electronic security by using cryptographic techniques to prevent malicious entities to gain access [Mathias: [0002-0003])
The above cited combination of Bunyan in view of Zhao Ming, Sasaki and Yu, Brown does not explicitly teach:
wherein the fourth private key is a private key that corresponds to the fourth public key and that is generated by the terminal device based on the predetermined key generation algorithm; receiving a third public key of the in-vehicle device, wherein the third public key is a key that corresponds to the in-vehicle device and that is generated by the in-vehicle device based on the predetermined key generation algorithm;
Furthermore, Sasaki teaches:
wherein the fourth private key is a private key that corresponds to the fourth public key and that is generated by the terminal device based on the predetermined key generation algorithm (Sasaki: [Col 22, lines 66-67 – Col 23, lines 1-2], (212) xiii) a fourth key generation program for generating a pair of a fourth public key and a fourth secret key (=fourth private key) (hereinafter referred to as a fourth public key/secret key generation program);
receiving a third public key of the in-vehicle device, wherein the third public key is a key that corresponds to the in-vehicle device (Sasaki: [Col 14, lines 32-34], (90) In the receiver 20 which has received the first ciphertext i, the identifier i, the first enciphered common key i and the third public key i…) and that is generated by the in-vehicle device based on the predetermined key generation algorithm (Sasaki: [Col 12, lines 56-59], (74) xi) a third key generation program for generating a pair of a third public key and a third secret key (hereinafter referred to as a third public key/secret key generation program);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming, Sasaki and Yu, Brown by applying the well-known technique as disclosed by Sasaki of receiver is receiving the third public key. The motivation is a plurality of encrypted communications are transmitted on the network securely (Sasaki: [Col 2, lines 18-19]).
Claim(s) 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bunyan (U. S. PGPub. No. 2002/0135466 A1) (hereinafter “Bunyan”) in view of Zhao Ming (EP 3723399 A1) (hereinafter “Zhao Ming”), and further in view of Sasaki (U. S. Pat. No. 6,351,536 B1) (hereinafter “Sasaki”) and Yu et al. (U. S. PGPub. No. 2021/0250183 A1) (hereinafter “Yu”); and further view of Brown et al. (U. S. Pat. No. 9,621,352 B2) (hereinafter “Brown”) and Mathias et al. (U. S. PGPub. No. 2020/0052905 A1) (hereinafter “Mathias”); and in further view of DE LOS SANTOS et al. (U. S. PGPub. No. 2015/0005984 A1) (hereinafter “De Los Santos”).
Regarding Claim 6, Bunyan in view of Zhao Ming, Sasaki and Yu, Brown teaches:
The method of claim 4 (see rejection of claim 4 above),
signing the third verifiable information the first timestamp, and the valid time based on a fourth private key of the user to obtain fourth verifiable information (Brown: [Col 16, lines 24-30], (85) Verification of a digital signature on a certificate is a process that requires the public key of the issuing CA. When a CA digitally signs a certificate, certificate information including the name and public key of the certificate holder for example, or a hash of that information obtained through application of a hashing algorithm, is typically encoded using the CA's private key. The algorithm used by the issuing CA to sign a certificate is typically identified in the certificate.)
The Bunyan in view of Zhao Ming, Sasaki and Yu, Brown does not explicitly disclose below limitations, however, in an analogous art, Mathias disclose:
encrypting the vehicle control instruction, based on the third verifiable information to obtain a first encrypted instruction (Mathias: [0038], In response to receiving the challenge, the secure element of the mobile device generates a response using a private key of the previously generated public key pair….The mobile device then encrypts the response with the other encryption key and sends the response to the system for verification. In response to a successful verification, the system may enable requested functionality. [0045], SE 134 is configured to perform various encryption operations to facilitate secure communications between mobile device 130 and system 110);
wherein the processing a vehicle control instruction based on the target verification information (Mathias: [0046] Pairing of mobile device 130 and system 110 may involve establishment of a shared secret (which may also be referred to as a shared key) and storing a long-term public key from the SE 134 by the system 110. A detailed description of an exemplary pairing procedure is discussed below, with reference to FIG. 3. Once paired, SE 134 may also facilitate transactions in which the mobile device 130 instructs the system 110 to perform various operations, e.g., as discussed below with reference to FIG. 4.), and sending a processed vehicle control instruction to the in-vehicle device comprises ((Mathias: [0047] FIG. 1B is a block diagram illustrating exemplary communications between a system and a mobile device to perform an operation, according to some embodiments. Examples of an operation include opening a door lock, starting an engine, enabling or disabling functionality, changing media being played, connecting or disconnecting the system to a wide-area network, authorizing or removing additional users, access to keychain data, ability to make purchases, etc. In the illustrated embodiment, SE 134 is configured to perform authentication communications 155 for a request 150 initiated by AP 136):
generating third verifiable information for the vehicle control instruction (Mathias: [0140], At 908 system 110 then generates a random (or pseudo-random) transaction.ID (=third verifiable information) for the current transaction), wherein the third verifiable information is a random number that is of a predetermined bit quantity, that corresponds to the vehicle control instruction, and that is generated by the terminal device based on a predetermined random number generation algorithm (Mathias: [0140], At 908 system 110 then generates a random (or pseudo-random) transaction.ID for the current transaction);
and sending the first encrypted instruction ((Mathias: [0038], In response to receiving the challenge, the secure element of the mobile device generates a response using a private key of the previously generated public key pair….The mobile device then encrypts the response with the other encryption key and sends the response to the system for verification. In response to a successful verification, the system may enable requested functionality. [0045], SE 134 is configured to perform various encryption operations to facilitate secure communications between mobile device 130 and system 110).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming, Sasaki and Yu, Brown by applying the well-known technique as disclosed by Mathias of after successful verification, processing instruction transmitted from the mobile device in to perform an operations like opening a door lock, starting engine, etc. The motivation is providing electronic security by using cryptographic techniques to prevent malicious entities to gain access [Mathias: [0002-0003]).
receiving a third public key of the in-vehicle device, wherein the third public key is a key that corresponds to the in-vehicle device(Sasaki: [Col 14, lines 32-34], (90) In the receiver 20 which has received the first ciphertext i, the identifier i, the first enciphered common key i and the third public key i…) and that is generated by the in-vehicle device based on the predetermined key generation algorithm ((Sasaki: [Col 12, lines 56-59], (74) xi) a third key generation program for generating a pair of a third public key and a third secret key (hereinafter referred to as a third public key/secret key generation program));
encrypting the third verifiable information, the first timestamp, the valid time, and the fourth verifiable information based on the third public key of the in-vehicle device to obtain target information, and sending the target information to the in-vehicle device ((Yu: [0055] S204: The server 106 generates corresponding encrypted information (=target verification information) according to the login request of the first device, wherein the encrypted information (=third verifiable information) includes at least one of the following: a key pair and a digital certificate. [0058] S206: After receiving the encrypted information returned by the server 106, the first device 102 generates encrypted identity information based on the login account and the encrypted information));
Bunyan in view of Zhao Ming, Sasaki and Yu, Brown and Mathia does not explicitly disclose below limitations, however, in an analogous art, De Los Santos teaches:
generating…a first timestamp corresponding to the third verifiable information (De Los Santos: [0023] The real-time clock (RTC) provides accurate date and time information to the in-vehicle telematics unit 16 hardware and software components that may require and/or request date and time information. In an example, the RTC may provide date and time information periodically, such as, for example, every ten milliseconds),
and valid time of the vehicle control instruction (De Los Santos: [0031] Upon being placed into park mode, a prompt (audio or visual menu) to wait or power down the vehicle 12 may be presented to the driver. If the menu option to "wait" is selected, the audio or visual menu may be presented again to the driver after a predetermined time. If the "power down" menu option is not selected within a predetermined time (=valid time), the "wait" option may be automatically selected by default. In another example, if the "wait" menu option is not selected within a predetermined time, the "power down" menu option may be automatically selected by default)
and a second timestamp (De Los Santos: [0023] In an example, the RTC may provide date and time information periodically (=second timestamp), such as, for example, every ten milliseconds.
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Bunyan in view of Zhao Ming, Sasaki and Yu, Brown by applying the well-known technique as disclosed by De Los Santos of providing accurate date and time to in-vehicle device and validating if instructions received withing predetermined time (=valid time). The motivation is to include and utilize an in-vehicle starting system that is operatively coupled to a smart phone (De Los Santos: [0008]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
YOKOTA (U. S. PGPUB. No. 2023/0401317 A1): In a security method according to one aspect of the present disclosure, when a fraudulent command is detected in an in-vehicle communication network, an electronic control unit (ECU) which can transmit a fraudulent command is specified, the specified ECU is caused to execute update of the software used by the specified ECU, and execution of update of the software by the specified ECU is prohibited after the update of the software is executed.
TAKEMORI et al. (U. S PGPub. No. 2020/0389791 A1): A maintenance system includes a server device, a terminal device, and an in-vehicle device installed in a vehicle. The server device includes a worker authentication information reception unit configured to receive worker authentication information from the terminal device, a server authentication processing unit configured to perform an authentication process on the worker authentication information, and a server key transmission unit configured to transmit a first key to be used with the in-vehicle device to the terminal device whose worker authentication information has been successfully authenticated by the server authentication processing unit. The terminal device includes a worker authentication information transmission unit configured to transmit the worker authentication information to the server device, a terminal key reception unit configured to receive the first key from the server device, and a terminal authentication processing unit configured to perform an authentication process with the in-vehicle device using the first key.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
