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 .
DETAILED ACTION
The IDS filed 3/27/2023, 10/7/2024, 2/5/2026 were received and considered.
Claims 1-18 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 6, 14 and 16-18 are 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 2, 6 and 14, the limitation “the first RootCA Certificate included in the list as a trust anchor” lacks sufficient antecedent basis. Further, it is unclear if the recited “first RootCA Certificate” is the same as that recited in the independent claims.
Regarding claim 16, the limitation “wherein the program instructions are further configured to cause the processor to authenticate the EV comprises instructions” renders the claim indefinite, as a skilled artisan would expect the claimed instructions to cause method steps (the recited language appears to be a typographical error).
Claims 17-18 inherit the deficiency from claim 16.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 11 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. The limitation “… without generating the symmetric key and transmitting and receiving messages …” broadens the scope of the claim when compared to claim 9. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-5 and 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over “Road vehicles — Vehicle-to-Grid Communication Interface — Part 2: Network and application protocol requirements” (ISO 15118-:2014) (ISO) (IDS filed 10/7/2024), in view of “Plug-and-patch: Secure value added services for electric vehicle charging” by Buschlinger et al. (Buschlinger).
Regarding claim 1, ISO discloses an authentication method for enabling plug-and-charge (PnC) charging (plug and charge scenario, p. 12, §7.3.1 and p. 13, Fig. 4) of an electric vehicle (EV) (EVCC, p. 13, Fig. 4, and p. 14) through communication with a charging station (CS) device (SECC, p. 13, Fig. 4), the method comprising: receiving, from the CS device (SECC, p. 13, Fig. 4), a supply equipment communication controller (SECC) certificate chain including a SECC Certificate and at least one charging device series SubCA Certificate used to issue the SECC Certificate (SECC … shall send its own certificate and a chain up to a root (excluding the root certificate itself) which shall be one of those roots previously indicated by the EVCC as being present in the EVCC, p. 30, Note 5); authenticating an SECC by verifying the SECC Certificate using the at least one charging device series SubCA Certificate and a first RootCA Certificate stored in a storage of the EV (EVCC shall check the validity of the Sub-CA Certificates (in the SECCs certificate chain) via an OCSP response according to IETF RFC 6960, when TLS is used, p. 29, ¶7.7.3.3; SECC … shall send its own certificate and a chain up to a root (excluding the root certificate itself) which shall be one of those roots previously indicated by the EVCC as being present in the EVCC, p. 30, Note 5; EVCC shall verify the SECC Certificate, the complete certificate chain and all OCSP responses, p. 31, V2G2-875; certificate chain from the V2G Root Certificate to the SECC Certificate, p. 31, ¶7.7.3.4); sending a verification result for the SECC Certificate to the CS device (EVCC has requested OCSP responses, for each certificate that the TLS server responds with, an OCSP response shall be sent to EVCC, p. 30, Note 5)and generating a symmetric key through a handshake with the CS device (communicated message between EVCC and SECC is encrypted using a symmetric key (one-way “key agreement”) negotiated during the TLS key negotiation phase, p. 31, ¶7.7.3.4); and transmitting and receiving messages encrypted by the symmetric key to and from the CS device (¶7.7.3.4). Note that, in ISO, a contract certificate is issued to EVCC either by V2G Root CA or by Sub-CA, p. 3, §3.4; V2G Root Certificates and possibly Sub-CA Certificates which certify SECC Certificates and Contract Certificates, p. 16, §7.3.2). Further note that, in ISO, the EVCC sends the Contract Certificate and certificate chain in a message, where the SECC can validate the certificate, including its chain, up to a Root certificate (p. 73, V2G2-898-899) and that all certificate validations are carried out in conformance with RFC 5280 (p. 17, V2G2-885). ISO lacks, in addition to receiving the verification result, providing the CS device with an EV certificate chain including an EV Certificate of the EV and at least one EV series SubCA Certificate used to issue the EV Certificate; receiving a verification result for the EV Certificate from the CS device. However, Buschlinger teaches that it was known to perform mutual authentication between an EVCC (client) and SECC (server) so that malicious EVs can be detected (§4.2, ¶1), where the charging point should validate the EVs certificate (“one has to make sure that the CP can validate the EV’s certificate, i.e. the respective root certificates are present. In case of PnC, the EV’s Contract Certificate, which currently serves for charging authorization at CPs (see Sec. 8.4.3.7 in [21]), could be used as a proof of the EV’s identity already during TLS session establishment”, §4.2, ¶1). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify ISO to perform mutual authentication as part of the TLS process and as such to include providing the CS device with an EV certificate chain including an EV Certificate of the EV and at least one EV series SubCA Certificate used to issue the EV Certificate and to include receiving a verification result for the EV Certificate from the CS device (as per certificate validation in ISO and as part of a mutual authentication process). One of ordinary skill in the art would have been motivated to perform such a modification to verify the EV, which gains the benefit of identifying malicious EVs, as taught by Buschlinger.
Regarding claim 5, ISO discloses an authentication method for allowing plug-and-charge (PnC) charging (plug and charge scenario, p. 12, §7.3.1 and p. 13, Fig. 4) of an electric vehicle (EV) (EVCC, p. 13, Fig. 4, and p. 14) through communication with a charging station (CS) device (SECC, p. 13, Fig. 4), the method comprising: providing the EV with a supply equipment communication controller (SECC) certificate chain (EVCC authenticates the SECC by verifying the SECC Certificate (chain) provided from the SECC to the EVCC, p. 29, §7.7.3.2) including a SECC Certificate and at least one charging device series SubCA Certificate (EVCC shall check the validity of the Sub-CA Certificates (in the SECCs certificate chain) via an OCSP response according to IETF RFC 6960, when TLS is used, p. 29, ¶7.7.3.3; SECC … shall send its own certificate and a chain up to a root (excluding the root certificate itself) which shall be one of those roots previously indicated by the EVCC as being present in the EVCC, p. 30, Note 5) used to issue the SECC Certificate (EVCC shall verify the SECC Certificate, the complete certificate chain and all OCSP responses, p. 31, V2G2-875; certificate chain from the V2G Root Certificate to the SECC Certificate, p. 31, ¶7.7.3.4); receiving, from the EV, a verification result for the SECC Certificate (EVCC has requested OCSP responses, for each certificate that the TLS server responds with, an OCSP response shall be sent to EVCC, p. 30, Note 5); generating a symmetric key through a handshake with the EV (communicated message between EVCC and SECC is encrypted using a symmetric key (one-way “key agreement”) negotiated during the TLS key negotiation phase, p. 31, ¶7.7.3.4); and transmitting and receiving messages encrypted by the symmetric key to and from the EV (¶7.7.3.4). Note that, in ISO, a contract certificate is issued to EVCC either by V2G Root CA or by Sub-CA, p. 3, §3.4; V2G Root Certificates and possibly Sub-CA Certificates which certify SECC Certificates and Contract Certificates, p. 16, §7.3.2). Further note that, in ISO, the EVCC sends the Contract Certificate and certificate chain in a message, where the SECC can validate the certificate, including its chain, up to a Root certificate (p. 73, V2G2-898-899) and that all certificate validations are carried out in conformance with RFC 5280 (p. 17, V2G2-885). ISO lacks, in addition to receiving the verification result, receiving, from the EV, an EV certificate chain including an EV Certificate of the EV and at least one EV series SubCA Certificate used to issue the EV Certificate, and authenticating the EV by verifying the EV Certificate using the at least one EV series SubCA Certificate and a first RootCA Certificate stored in a storage of the CS device. However, Buschlinger teaches that it was known to perform mutual authentication between an EVCC (client) and SECC (server) so that malicious EVs can be detected (§4.2, ¶1), where the charging point should validate the EVs certificate (“one has to make sure that the CP can validate the EV’s certificate, i.e. the respective root certificates are present. In case of PnC, the EV’s Contract Certificate, which currently serves for charging authorization at CPs (see Sec. 8.4.3.7 in [21]), could be used as a proof of the EV’s identity already during TLS session establishment”, §4.2, ¶1). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify ISO to perform mutual authentication as part of the TLS process and as such to include receiving, from the EV, an EV certificate chain including an EV Certificate of the EV and at least one EV series SubCA Certificate used to issue the EV Certificate (receive EV certificate and certificate chain for authentication of the EV as part of a mutual TLS authentication), and authenticating the EV by verifying the EV Certificate using the at least one EV series SubCA Certificate and a first RootCA Certificate stored in a storage of the CS device (as per certificate validation in ISO and as part of a mutual authentication process). One of ordinary skill in the art would have been motivated to perform such a modification to verify the EV, which gains the benefit of identifying malicious EVs, as taught by Buschlinger.
Regarding claims 3 and 7, ISO, as modified, lacks wherein the at least one EV series SubCA Certificate is a certificate issued based on an Original Equipment Manufacturer (OEM) RootCA Certificate issued by an OEM RootCA. However, ISO teaches that it was known to utilize certificates issued by an OEM RootCA (OEM Root certificate) to verify device validity asserted by the OEM (p. 87, V2G2-894) and further teaches that the Contract Certificate (p. 303, Fig. E.1) can be a reused V2G Root as an OEM root (p. 303, ¶1). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to further modify ISO such that the at least one EV series SubCA Certificate is a certificate issued based on an Original Equipment Manufacturer (OEM) RootCA Certificate issued by an OEM RootCA (utilize V2G Root as an OEM root). One of ordinary skill in the art would have been motivated to perform such a modification to maintain consistency with ISO.
Regarding claim 4, ISO, as modified, teaches wherein the verification result for the EV Certificate is determined in the CS device by verifying the EV certificate using the at least one EV series SubCA Certificate (Contract certificate, per Buschlinger, §4.2) along with a V2G RootCA Certificate or the OEM RootCA Certificate stored in a storage of the CS device (ISO teaches verification of the contract certificate using V2G Root, p. 303, Fig. E.1 and ¶1).
Regarding claim 8, ISO discloses wherein the verification result for the SECC Certificate is determined in the EV by verifying the SECC certificate using the at least one charging device series SubCA Certificate and a V2G RootCA Certificate stored in a storage of the EV (p. 303, Fig. E.1 list the EVSE certificate chain as including a CPO SubCA and V2G Root; EVCC shall check the validity of the Sub-CA Certificates (in the SECCs certificate chain) via an OCSP response according to IETF RFC 6960, when TLS is used, p. 29, ¶7.7.3.3).
Claims 2 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over ISO and Buschlinger, as applied to claims 1 and 5, in view of US 2003/0014629 A1 to Zuccherato.
Regarding claims 2 and 6, ISO, as modified, lacks wherein receiving, from the CS device, the SECC certificate chain comprises: providing the CS device with a list of at least some RootCA Certificates maintained in the EV, wherein the SECC Certificate is authenticated by using the first RootCA Certificate included in the list as a trust anchor. However, Zuccherato teaches that it was known to specify trusted root certificates (¶3, ¶19) and that allowing a subscriber device to specify which roots it trusts, a Web server, or other suitable server, which also has the root certificates stored thereon, can choose the correct certificate (one trusted by the subscriber device) to send to the subscriber or to abandon the protocol if the server does not trust any of the root certificates specified by the subscriber (¶5). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify ISO such that receiving, from the CS device, the SECC certificate chain comprises: providing the CS device with a list of at least some RootCA Certificates maintained in the EV (providing SECC with a list of trusted root certificates), wherein the SECC Certificate is authenticated by using the first RootCA Certificate included in the list as a trust anchor (selecting compatible certificate authenticable with a common root certificate). One of ordinary skill in the art would have been motivated to perform such a modification to efficiently select a common certificate, as taught by Zuccherato.
Claims 12, 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over ISO, in view of Buschlinger and US 2018/0001776 A1 to Kim et al. (Kim).
Regarding claim 12, the claim is similar in scope to claim 1 and is rejected using a similar rationale. ISO, as modified in the rejection of claim 1, lacks the charging station (CS) device (SECC) comprising: a memory having program instructions stored therein; and a processor coupled to the memory and configured to execute the program instructions stored in the memory, wherein the program instructions, when executed by the processor, are configured to cause the processor to perform the method. However, Kim, in an analogous art (EV charging using an SECC, Abstract) teaches that it was known to utilize an SECC including at least one processor, a memory storing instructions executed by the at least one processor, and a communication module (¶25), wherein the instructions are configured to cause the communication module to establish a communication connection with an ICCB mounted on an EV charging cable (¶25). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify SIO such that the charging station (CS) device (SECC) comprises: a memory having program instructions stored therein; and a processor coupled to the memory and configured to execute the program instructions stored in the memory, wherein the program instructions, when executed by the processor, are configured to cause the processor to perform the method. One of ordinary skill in the art would have been motivated to perform such a modification to a known hardware-software architecture to implement the method programmatically, as taught by Kim.
Regarding claim 14, ISO, as modified, lacks wherein the at least one EV series SubCA Certificate is a certificate issued based on an Original Equipment Manufacturer (OEM) RootCA Certificate issued by an OEM RootCA. However, ISO teaches that it was known to utilize certificates issued by an OEM RootCA (OEM Root certificate) to verify device validity asserted by the OEM (p. 87, V2G2-894) and further teaches that the Contract Certificate (p. 303, Fig. E.1) can be a reused V2G Root as an OEM root (p. 303, ¶1). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to further modify ISO such that the at least one EV series SubCA Certificate is a certificate issued based on an Original Equipment Manufacturer (OEM) RootCA Certificate issued by an OEM RootCA (utilize V2G Root as an OEM root). One of ordinary skill in the art would have been motivated to perform such a modification to maintain consistency with ISO.
Regarding claim 15, ISO discloses wherein the verification result for the SECC Certificate is determined in the EV by verifying the SECC certificate using the at least one charging device series SubCA Certificate and a V2G RootCA Certificate stored in a storage of the EV (p. 303, Fig. E.1 list the EVSE certificate chain as including a CPO SubCA and V2G Root; EVCC shall check the validity of the Sub-CA Certificates (in the SECCs certificate chain) via an OCSP response according to IETF RFC 6960, when TLS is used, p. 29, ¶7.7.3.3).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over ISO, Buschlinger and Kim, as applied to claim 12, in view of US 2003/0014629 A1 to Zuccherato.
Regarding claim 13, ISO, as modified, lacks wherein receiving, from the CS device, the SECC certificate chain comprises: providing the CS device with a list of at least some RootCA Certificates maintained in the EV, wherein the SECC Certificate is authenticated by using the first RootCA Certificate included in the list as a trust anchor. However, Zuccherato teaches that it was known to specify trusted root certificates (¶3, ¶19) and that allowing a subscriber device to specify which roots it trusts, a Web server, or other suitable server, which also has the root certificates stored thereon, can choose the correct certificate (one trusted by the subscriber device) to send to the subscriber or to abandon the protocol if the server does not trust any of the root certificates specified by the subscriber (¶5). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify ISO such that receiving, from the CS device, the SECC certificate chain comprises: providing the CS device with a list of at least some RootCA Certificates maintained in the EV (providing SECC with a list of trusted root certificates), wherein the SECC Certificate is authenticated by using the first RootCA Certificate included in the list as a trust anchor (selecting compatible certificate authenticable with a common root certificate). One of ordinary skill in the art would have been motivated to perform such a modification to efficiently select a common certificate, as taught by Zuccherato.
Allowable Subject Matter
Claims 9-10 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Regarding claim 9, “Authenticating Users and IoT Devices with Mutual TLS", September 2020” (SSL . com) teaches that it was known to perform mutual authentication with TLS, where once the server is authenticated during the handshake, it will send a CertificateRequest message to the client (p. 2, Mutual Authentication). However, the prior art – individually, or in a reasonable combination – lacks wherein, during the operation of authenticating the EV, verifying the EV Certificate and the mutual authentication between the EV and the CS device are performed only when the EV certificate chain is received from the EV, wherein, when the EV certificate chain is not received from the EV, a verification of the EV Certificate is not performed while a verification of the SECC Certificate is performed by the EV so as to carry out a one-way TLS.
Claim 10 inherits the allowable subject matter.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
KR 20200106826 A (SHIN MIN HO.) teaches an EVCC authenticating an SECC at the TLS layer (p. 60).
US 20200282859 A1 (Shin; Min Ho) teaches mutual authentication between an EVCC and SECC (Fig. 2B, ¶¶95-98).
KR 20200000960 A (LIM YOU SEOK et al.) teaches EV authentication at the application layer.
WO 2020222516 A1 (SHIN, MIN HO.) teaches cross-certificate in ISO 15118 (¶13, ¶19, ¶¶29-34; see also ¶¶139-144).
“Exploring the public key infrastructure for ISO 15118 in the EV charging ecosystem” (Klapwijk, Paul, and Lonneke Driessen-Mutters) teaches PKI in ISO 15118 (see pp. 13-14, 29-34, 40-41).
“Multimodal and multi-pass authentication mechanisms for electric vehicle charging networks” (Vaidya, Binod, and Hussein T. Mouftah) teaches V2G-based certificate architecture in ISO 15118 (§II-B).
“Using ISO 15118 Plug & Charge with OCPP 1.6” (Open Charge Alliance) teaches Plug and Charge authorization (pp. 9-10).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J SIMITOSKI whose telephone number is (571)272-3841. The examiner can normally be reached Monday - Friday, 7:00-3:00.
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, Carl Colin can be reached at 571-272-3862. 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.
/Michael Simitoski/ Primary Examiner, Art Unit 2493
February 23, 2026