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.
Response to Arguments
Applicant’s arguments, see page 8, filed 09/02/2025, with respect to claim 7 have been fully considered and are persuasive. The rejection under 35 U.S.C. 112(b) of 09/02/2025 has been withdrawn.
Applicant’s arguments, see page 8-12, filed 09/02/2025, with respect to the rejection(s) of claim(s) 1, 20 and 23 under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of newly found prior art.
Claims 1-7, 20 and 23 are pending.
Claims 8-19 are cancelled.
Claims 21-22 are canceled.
Claim Objections
Claims 1-7, 20, and 23 are objected to because of the following informalities:
Claims 1-7, 20, and 23: The claims use the broad term “device information of the terminal device” and “device information of the in-vehicle device,” whereas the specification more clearly describes these data as identification-type information (e.g., “identification information of the terminal device, such as a device ID, a product serial number SN, and a MAC address of the terminal device”). For improved clarity and consistency with “server information” (expressly defined as including identification information and attribute information of the first server), applicant is invited to amend “device information of the terminal device” and “device information of the in-vehicle device” to more precise terminology such as “identification information of the terminal device” and “identification information of the in-vehicle device,” or other language consistent with the examples in the specification (e.g., device ID, serial number, MAC address), to better reflect the intended scope.
In claim 4, the limitation “first verifiable information” is unclear because, in substance, it corresponds to an encrypted form of the target verification information (i.e., information obtained by encrypting the target verification information using the first server’s private key), yet the claim uses only the generic label “verifiable information,” which does not clearly reflect this structure. For clarity, applicant is requested to amend “first verifiable information” to more accurately reflect its nature, for example, “encrypted target verification information” (or equivalent language consistent with the description), and to make similar clarifying changes to “second verifiable information,” “third verifiable information,” and “fourth verifiable information” so that each is named in a manner that reflects the underlying encrypted or signed target data it represents.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-7, 20 and 23 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 20 and 23 recite the broad genus “process[ing] a vehicle control instruction based on the target verification information, and send[ing] a processed vehicle control instruction…,” without specifying the type of processing. The specification, however, primarily describes processing as encrypting the vehicle control instruction (optionally combined with signing) based on the target verification information or related keys, and then sending the resulting encrypted instruction. Other “processing methods” are referenced only in generic terms, without concrete examples.
Thus, while the specification provides support for at least one species—encrypting (and optionally signing) the vehicle control instruction—it does not reasonably convey possession of the full breadth of the claimed “processing” genus, which on its face encompasses other, unspecified kinds of processing of the vehicle control instruction. Accordingly, the written description requirement of 35 U.S.C. 112(a) is not satisfied for the full scope of “processing a vehicle control instruction … to obtain a processed vehicle control instruction.” Applicant may overcome this issue by amending the claims to more closely track the disclosed species (e.g., “encrypting the vehicle control instruction … to obtain an encrypted vehicle control instruction”) or by pointing out where in the specification additional, materially distinct processing techniques are described.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7, 20, and 23 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 20, and 23:
Issue # 1
Claims 1, 20, and 23 recite the limitations "receiving…a pre-constructed certificate chain" and “verifying….the certificate chain”. It is unclear from the claim whether “the certificate chain” being verified is the same “pre-constructed certificate chain” that was previously received, or a different certificate chain.
If applicant intends these to be the same certificate chain, claim 1 should be amended to recite “verifying … the pre-constructed certificate chain” to provide proper antecedent basis and make clear that no new certificate chain is being introduced. If applicant instead intends to refer to a different certificate chain, claim 1 should be amended to recite “verifying … a certificate chain” to indicate that this is a newly introduced element.
Issue # 2
Additionally, in claim 1, the phrase “information of the first server” in the limitation “wherein the certificate chain is a multi-level certificate chain generated based on information of the first server, a predetermined key of the first server, device information of the terminal device, …” lacks clear antecedent basis and does not clearly define what specific “information” is required. It is therefore unclear to a person of ordinary skill in the art what set of data must be present for the certificate chain to fall within the scope of the claim, rendering the metes and bounds of this limitation uncertain.
Applicant may consider, for example, amending claim 1 to provide clear antecedent basis and definition for this term, such as by first introducing “identification information of the first server” (requires updates to claim 2 and claim that uses this term) and then referring back to that term (e.g., “based on the identification information of the first server …”) or otherwise specifying the type of information used.
Regarding claim 5:
In addition, claim 5 recites encrypting the vehicle control instruction to obtain second verifiable information, and then encrypting “the vehicle control instruction and the second verifiable information … to obtain an encrypted vehicle control instruction,” but the specification shows that the resulting ciphertext is an encryption of a composite message including both the instruction and its verification data rather than the instruction alone. Accordingly, it is unclear whether “encrypted vehicle control instruction” in claim 5 requires encryption of only the vehicle control instruction or of a composite of the vehicle control instruction and the second verifiable information, leaving the scope of this limitation and the resulting claim uncertain to a person of ordinary skill in the art.
In addition to any separately identified deficiencies above, claims 2-7 depend on claim 1 and fail to cure the deficiency of claim 1. Therefore, claims 2-7 are rejected under same rationale as that provided in the grounds of rejection applied to claim 1.
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 certificate chain and 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 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, 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 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)
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),
processing a vehicle control instruction based on the target verification information (Zhao Ming: [0158], In step 5, the on-vehicle terminal compares information in the plaintext with the ciphertext after decrypting the ciphertext, and allows execution of a relevant vehicle control instruction if the information in the plaintext is consistent with the ciphertext. The on-vehicle terminal compares terminal information and user information extracted from the ciphertext with the relevant information in the plaintext after decrypting the ciphertext, and if the terminal information and the user information are matched with the related information in the plaintext, the on-vehicle considers that the handheld terminal is a legal terminal and allows the execution of the relevant vehicle control instruction.)
and sending a processed vehicle control instruction to the in-vehicle device , so that the in-vehicle device processes the vehicle control instruction based on the target verification information and the certificate chain (Zhao Ming: [0149], 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. [0150], 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. [0085], 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.).
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 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 and allow to execute vehicle control instructions, in order to provide identity authentication method. 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 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 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 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 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 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 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.
Bhattacharya et al. (U. S. Pat. No. 11,070,542 B2): In certificate chain validation, a parent certificate is used to validate a child certificate. The child certificate can indicate which parent certificate can be used to validate it. In some situations, a child certificate may not contain a certificate authority identifier that can be used to identify the parent certificate. Instead, the child certificate can contain a hash value of a modulus of the parent public key that can be used to identify the parent certificate. The hash value of the modulus of the parent public key can be associated with the parent public key. As such, the parent public key used in certificate chain validation of the child certificate can be identified using the hash value of the modulus of the parent public key.
AHMED et al. (U. S. PGPub. No. 2015/0120402 A1): In an example of a method for enabling after-hours vehicle pick up, a server recognizes that a service payment request is outstanding for a serviced vehicle. In response to the recognizing, the server transmits an ignition block command to the serviced vehicle. The ignition block command triggers a powertrain control module of the serviced vehicle to enter a disengaged state that electrically prohibits the powertrain control module from providing tractive power to a vehicle drive wheel. At the server, a notification of a payment acceptance is received from an infotainment unit of the serviced vehicle or a mobile communications device associated with the serviced vehicle. In response to receiving the notification, the server transmits an ignition enabling command triggering the powertrain control module to enter an engaged state that electrically enables the powertrain control module to provide tractive power to the vehicle drive wheel.
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
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.
Bhattacharya et al. (U. S. Pat. No. 11,070,542 B2): In certificate chain validation, a parent certificate is used to validate a child certificate. The child certificate can indicate which parent certificate can be used to validate it. In some situations, a child certificate may not contain a certificate authority identifier that can be used to identify the parent certificate. Instead, the child certificate can contain a hash value of a modulus of the parent public key that can be used to identify the parent certificate. The hash value of the modulus of the parent public key can be associated with the parent public key. As such, the parent public key used in certificate chain validation of the child certificate can be identified using the hash value of the modulus of the parent public key.
AHMED et al. (U. S. PGPub. No. 2015/0120402 A1): In an example of a method for enabling after-hours vehicle pick up, a server recognizes that a service payment request is outstanding for a serviced vehicle. In response to the recognizing, the server transmits an ignition block command to the serviced vehicle. The ignition block command triggers a powertrain control module of the serviced vehicle to enter a disengaged state that electrically prohibits the powertrain control module from providing tractive power to a vehicle drive wheel. At the server, a notification of a payment acceptance is received from an infotainment unit of the serviced vehicle or a mobile communications device associated with the serviced vehicle. In response to receiving the notification, the server transmits an ignition enabling command triggering the powertrain control module to enter an engaged state that electrically enables the powertrain control module to provide tractive power to the vehicle drive wheel.
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
/ALEXANDER LAGOR/ Supervisory Patent Examiner, Art Unit 2437