DETAILED ACTION
The following claims are pending in this office action: 1-15
Claims 1,13 and 15 are independent claims.
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 .
Drawings
The drawings filed on 04/07/2025 are accepted.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/07/2025 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, an initialed and dated copy of Applicant’s IDS form 1449 filed 04/07/2025 is attached to the instant Office action.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4-7, 9-10 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Sivaraman et al. (US Pub. 2022/0006804) (hereinafter “Sivaraman”) in view of Yellepeddy (US Pub. 2004/0111607) (hereinafter “Yellepeddy”).
As per claim 1, Sivaraman teaches a method for establishing a secure communication between an aircraft and a ground entity, the method comprising: ([Sivaraman, para. 0010] “a secure communication established between the server [ground entity] and the client device [aircraft] over the wireless link”; [para. 0034] “client ... includes a vehicle”; [para. 0078] “the technology may be applied to different vehicle types, including ... aircraft”)
sending a communication initialization message from the aircraft to the ground entity, ([Sivaraman, para. 0059-0060] “a handshake process 500 between a vehicle head unit 290 [from the aircraft– see para. 0011: “the client device includes a head unit of the vehicle] and a server 125 [to the ground entity] ... A first step ... of the handshake process ... involves the head unit 290 sending a “client hello” message”)
wherein the communication initialization message comprises either 1) a public key certificate of the aircraft or 2) unique identification information regarding the public key certificate of the aircraft; and ([Sivaraman, para. 0060] “a “client hello” message ... include ... a digital certificate [a public key certificate of the aircraft – see para. 0010-0011: “the credential ... transmitted by the client device using a communication protocol and received by the server ... a public key encryption certificate”] ... the certificate serial number [unique identification information regarding the public key certificate of the aircraft]”)
sending the public key certificate of the ground entity and forwarding the validation response from the ground entity to the aircraft as part of a response message to the communication initialization message. ([Sivaraman, para. 0061] “Once the certificate information has been validated by the head unit gateway 410 [forwarding the validation response] ... a next step 560 in the handshake process occurs [as a part of a response message to the communication initialization message] when the server 125 sends back to the head unit 290 [from the ground entity to the aircraft] a series of messages, which may include for example a “server hello” message, [response message] a chosen cipher suite for encrypting HTTP traffic, a shared encryption key, a digital certificate, [sending the public key certificate of the ground entity] and a signature”)
Sivaraman does not clearly teach wherein the communication initialization message comprises an indication of at least one trusted responder; and at the ground entity, sending a validation request regarding a public key certificate of the ground entity to a selected one of the at least one trusted responder and receiving a validation response from the selected trusted responder of the at least one trusted responder.
However, Yellependdy teaches wherein the communication initialization message comprises an indication of at least one trusted responder; and ([Yellependdy, para. 0050] “the fields of a standard ... digital certificate [communication initiation message] are shown”; [Fig. 4A] shows the “issuer” name of the certificate: an indication of at least one trusted responder as the CA/certificate authority indicates the trusted responder; [para, 0040] “Certificates are issued by certificate authorities ... that is trusted ... for verifying the identity and key ownership of an entity when issuing the certificate”; [para. 0055] “OCSP client 402 issues a status request to OCSP responder [at least one trusted responder] ... a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA that indicates that the responder may issue OCSP responses for that CA”)
at the ground entity, ([Yellependdy, para. 0045-0047] “application 306 on host system 308 ... to authorize ... for accessing services and resources [server that serves the services/resources/ground entity]”; [ para. 0053] “in lieu of ... checking for a CRL ... an application may use OCSP to obtain the status of a certificate ... The application may incorporate a dedicated client module [server/ground entity] that handles the OCSP transaction”) sending a validation request regarding a public key certificate of the ground entity ([para. 0058] “At some point in time, OCSP client 502 [a server/ground entity] needs to check the status of a certificate [a validation] that is being used within a transaction, [public key certificate of the ground entity as it is being sent by the server/ground entity] and OCSP client 502 sends an OCSP request message [validation request message] to any of OCSP responders 504-512”) to a selected one of the at least one trusted responder and ([para. 0070] “reverse proxy 532 can be employed to disperse incoming OCSP requests among a set of OCSP responders [selecting one of the at least one trusted responder] in a load-balancing fashion”) receiving a validation response from the selected trusted responder of the at least one trusted responder. ([Para. 0078] “The process begins with the OCSP responder receiving an OCSP request message from an OCSP client (step 632) ... The OCSP responder [from the selected trusted responder of the at least one trusted responder] ... returns the OCSP response message [receiving a validation response] to the OCSP client (step 644), thereby concluding the process”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman with the teachings of Yellependdy to include wherein the communication initialization message comprises an indication of at least one trusted responder; and at the ground entity, sending a validation request regarding a public key certificate of the ground entity to a selected one of the at least one trusted responder and receiving a validation response from the selected trusted responder of the at least one trusted responder. One of ordinary skill in the art would have been motivated to make this modification because a computing environment that is supporting more than one OCSP responder can provide additional OCSP responders, and the availability of this group of responders is greater than the availability of any one member of the group. (Yellependdy, para. 0093)
As per claim 2, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman also teaches wherein the communication initialization message comprises an uncompressed version of the public key certificate of the aircraft. ([Sivaraman, para. 0069] “The listener filter 530a examines the unencrypted message traffic 710 to determine if its headers contain metadata (e.g., digital certificate information and/or vehicle ID information) that can be used to establish a TLS session 360”)
As per claim 4, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman also teaches wherein the communication initialization message comprises unique identification information regarding a public key certificate of the aircraft; and ([Sivaraman, para. 0010] “a credential uniquely associated with the vehicle, where the credential is configured to be transmitted by the client device”; [para. 0011] “the credential includes a public key encryption certificate”)
the unique identification information comprises a serial number of the public key certificate of the aircraft. ([Sivaraman, para. 0069] “a “client hello” message which may include for example a digital certificate ... the certificate serial number”)
Sivaraman does not clearly teach the unique identification information comprises certificate issuer information.
However, Yellependdy teaches the unique identification information comprises certificate issuer information. ([Yellependdy, para. 0050] “the fields of a standard ... digital certificate [unique identification information] are shown”; [Fig. 4A] shows the “issuer” name of the certificate: certificate issuer information)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman with the teachings of Yellependdy to include the unique identification information comprises certificate issuer information. One of ordinary skill in the art would have been motivated to make this modification because this allows the certificate authority to serve as a neutral and trusted introduction service. (Yellependdy, para. 0041)
As per claim 5, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman also teaches wherein the secure communication between the aircraft and the ground entity is a Transport Layer Security (TLS)/Datagram TLS (DTLS)-based secure communication. ([Sivaraman, para. 0053] “In a client-server architecture, this “handshake” process may occur ... to establish a TLS session 360 between the client 340 and the server 125”)
As per claim 6, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman also teaches wherein the communication initialization message is a client hello message. ([Sivaraman, para. 0053] “A first step 550 of the handshake process 500 ... involves ... sending a “client hello” message”)
As per claim 7, Sivaraman in view of Yellependdy teaches claim 6.
Sivaraman also teaches the indication of the at least one trusted responder is provided in a responder extension of the client hello message; and/or (Examiner interprets this limitation in accordance with its broadest reasonable interpretation, that either the first or the second part are required to be disclosed for the limitation to be met; here, the second part is disclosed, but the responder extension or an extension record is also disclosed by Sharifi Mehr (US Patent No. 10,951,652) as disclosed in the mapping for claim 8 below) wherein the public key certificate of the aircraft or the unique identification information regarding the public key certificate of the aircraft is provided in a certificate extension of the client hello message. ([Sivaraman, para. 0010] “a credential uniquely associated with the vehicle, where the credential is configured to be transmitted by the client device”; [para. 0011] “the credential includes a public key encryption certificate”; [para. 0060] “sending a “client hello” message which may include for example a digital certificate. ... the certificate serial number”)
As per claim 9, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman does not clearly teach wherein: the at least one trusted responder includes at least one Online Certificate Status Protocol (OCSP) trusted responder, and wherein the validation request and the validation response are an OCSP validation request and an OCSP validation response, respectively.
However, Yellependdy teaches wherein: the at least one trusted responder includes at least one Online Certificate Status Protocol (OCSP) trusted responder, ([Yellependdy, para. 0055] “a trusted responder whose public key is trusted by the requester... the OCSP responder”) and wherein the validation request and the validation response are an OCSP validation request and an OCSP validation response, respectively. ([Para. 0055] “OCSP client 502 needs to check the status [validation] of a certificate that is being used within a transaction, and OCSP client 502 sends an OCSP request message [OCSP validation request] to any of OCSP responders 504-512”; [para. 0078] “The OCSP responder ... returns the OCSP response message [OCSP validation response] to the OCSP client (step 644), thereby concluding the process”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman with the teachings of Yellependdy to include wherein: the at least one trusted responder includes at least one Online Certificate Status Protocol (OCSP) trusted responder, and wherein the validation request and the validation response are an OCSP validation request and an OCSP validation response, respectively. One of ordinary skill in the art would have been motivated to make this modification because such a method shifts the burden of determining the status of a certificate from the server/ground entity to an OCSP server. (Yellependdy, para. 0053)
As per claim 10, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman also teaches wherein the response message to the communication initialization message is a server hello message. ([Sivaraman, para. 0061] “Once the certificate information has been validated ... the server 125 sends back [the response to the communication initialization message] ... a “server hello” message”)
As per claim 13, Sivaraman teaches a method for facilitating a secure communication between an aircraft and a ground entity at the aircraft, the method comprising: ([Sivaraman, para. 0010] “a secure communication established between the server [ground entity] and the client device [aircraft] over the wireless link”; [para. 0034] “client ... includes a vehicle”; [para. 0078] “the technology may be applied to different vehicle types, including ... aircraft”)
sending a communication initialization message from the aircraft to the ground entity, ([Sivaraman, para. 0059-0060] “a handshake process 500 between a vehicle head unit 290 [from the aircraft– see para. 0011: “the client device includes a head unit of the vehicle] and a server 125 [to the ground entity] ... A first step ... of the handshake process ... involves the head unit 290 sending a “client hello” message”)
wherein the communication initialization message comprises a public key certificate of the aircraft or unique identification information regarding the public key certificate of the aircraft; and ([Sivaraman, para. 0060] “a “client hello” message ... include ... a digital certificate [a public key certificate of the aircraft – see para. 0010-0011: “the credential ... transmitted by the client device using a communication protocol and received by the server ... a public key encryption certificate”] ... the certificate serial number [unique identification information regarding the public key certificate of the aircraft]”)
receiving a response message to the communication initialization message from the ground entity, wherein the response message comprises a public key certificate of the ground entity and a validation response regarding the public key certificate of the ground entity. ([Sivaraman, para. 0061] “Once the certificate information has been validated by the head unit gateway 410 [forwarding the validation response] ... a next step 560 in the handshake process occurs [as a part of a response message to the communication initialization message] when the server 125 sends back to the head unit 290 [from the ground entity to the aircraft] a series of messages, which may include for example a “server hello” message, [response message] a chosen cipher suite for encrypting HTTP traffic, a shared encryption key, a digital certificate, [receiving the public key certificate of the ground entity] and a signature”)
Sivaraman does not clearly teach wherein the communication initialization message comprises an indication of at least one trusted responder; and the response message issued by a selected trusted responder of the at least one trusted responder.
However, Yellependdy teaches wherein the communication initialization message comprises an indication of at least one trusted responder; and ([Yellependdy, para. 0050] “the fields of a standard ... digital certificate [communication initiation message] are shown”; [Fig. 4A] shows the “issuer” name of the certificate: an indication of at least one trusted responder as the CA/certificate authority indicates the trusted responder; [para, 0040] “Certificates are issued by certificate authorities ... that is trusted ... for verifying the identity and key ownership of an entity when issuing the certificate”; [para. 0055] “OCSP client 402 issues a status request to OCSP responder [at least one trusted responder] ... a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA that indicates that the responder may issue OCSP responses for that CA”)
the response message issued by a selected trusted responder of the at least one trusted responder. ([Yellependdy, para. 0070] “reverse proxy 532 can be employed to disperse incoming OCSP requests among a set of OCSP responders [selecting one of the at least one trusted responder] in a load-balancing fashion”; [para. 0078] “The OCSP responder [from the selected trusted responder of the at least one trusted responder] ... returns the OCSP response message [issued by a selected trusted responder] to the OCSP client”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman with the teachings of Yellependdy to include wherein the communication initialization message comprises an indication of at least one trusted responder; and the response message issued by a selected trusted responder of the at least one trusted responder. One of ordinary skill in the art would have been motivated to make this modification because a computing environment that is supporting more than one OCSP responder can provide additional OCSP responders, and the availability of this group of responders is greater than the availability of any one member of the group. (Yellependdy, para. 0093)
As per claim 14, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman also teaches determining whether to start the secure communication with the ground entity. ([Sivaraman, para. 0061] “Once the certificate information has been validated [a determination] ... the head unit 290 and server 125 begin exchanging message traffic [start the secure communication with the ground entity]”)
Sivaraman in view of Yellependdy does not clearly teach further comprising checking whether the response message was issued by any of the at least one trusted responder; and evaluating a trustworthiness of the ground entity based on the response message; and determining whether to start the secure communication with the ground entity.
However, Yellependdy teaches further comprising checking whether the response message was issued by any of the at least one trusted responder; and ([Yellependdy, para. 0078] “The OCSP responder ... attaches the group public key certificate to the OCSP response message (step 642) and returns the OCSP response message to the OCSP client”; [para. 0057] “The OCSP client is able to ascertain that the message was digitally signed by a member of this group [issued by any of the at least one trusted responder] based on a chain of trust represented by a chain of certificates [the group public key certificate - see para. 0079]”)
evaluating a trustworthiness of the ground entity based on the response message; and ([Yellependdy, para. 0057] “An OCSP client uses the group public key to verify the signature [evaluating a trustworthiness] on an OCSP response [based on the response message] from any of the OCSP responders”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to combine the teachings of Sivaraman and Yellependdy for the same reasons as disclosed above.
As per claim 15, Sivaraman teaches a method for facilitating a secure communication between an aircraft and a ground entity at the ground entity, the method comprising: ([Sivaraman, para. 0010] “a secure communication established between the server [ground entity] and the client device [aircraft] over the wireless link”; [para. 0034] “client ... includes a vehicle”; [para. 0078] “the technology may be applied to different vehicle types, including ... aircraft”)
receiving a communication initialization message from the aircraft, ([Sivaraman, para. 0059-0060] “a handshake process 500 between a vehicle head unit 290 [from the aircraft– see para. 0011: “the client device includes a head unit of the vehicle] and a server 125 [receiving by the ground entity] ... A first step ... of the handshake process ... involves the head unit 290 sending a “client hello” message”)
wherein the communication initialization message comprises a public key certificate of the aircraft or unique identification information regarding the public key certificate of the aircraft; and ([Sivaraman, para. 0060] “a “client hello” message ... include ... a digital certificate [a public key certificate of the aircraft – see para. 0010-0011: “the credential ... transmitted by the client device using a communication protocol and received by the server ... a public key encryption certificate”] ... the certificate serial number [unique identification information regarding the public key certificate of the aircraft]”)
sending the public key certificate of the ground entity and forwarding the validation response to the aircraft as part of a response message to the communication initialization message. ([Sivaraman, para. 0061] “Once the certificate information has been validated by the head unit gateway 410 [forwarding the validation response] ... a next step 560 in the handshake process occurs [as a part of a response message to the communication initialization message] when the server 125 sends back to the head unit 290 [from the ground entity to the aircraft] a series of messages, which may include for example a “server hello” message, [response message] a chosen cipher suite for encrypting HTTP traffic, a shared encryption key, a digital certificate, [sending the public key certificate of the ground entity] and a signature”)
Sivaraman does not clearly teach wherein the communication initialization message comprises an indication of at least one trusted responder; sending a validation request regarding a public key certificate of the ground entity to a selected trusted responder of the at least one trusted responder; and receiving a validation response from the selected trusted responder.
However, Yellependdy teaches wherein the communication initialization message comprises an indication of at least one trusted responder; ([Yellependdy, para. 0050] “the fields of a standard ... digital certificate [communication initiation message] are shown”; [Fig. 4A] shows the “issuer” name of the certificate: an indication of at least one trusted responder as the CA/certificate authority indicates the trusted responder; [para, 0040] “Certificates are issued by certificate authorities ... that is trusted ... for verifying the identity and key ownership of an entity when issuing the certificate”; [para. 0055] “OCSP client 402 issues a status request to OCSP responder [at least one trusted responder] ... a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA that indicates that the responder may issue OCSP responses for that CA”)
sending a validation request regarding a public key certificate of the ground entity ([Yellependdy, para. 0058] “At some point in time, OCSP client 502 [a server/ground entity] needs to check the status of a certificate [a validation] that is being used within a transaction, [public key certificate of the ground entity as it is being sent by the server/ground entity] and OCSP client 502 sends an OCSP request message [validation request message] to any of OCSP responders 504-512”) to a selected trusted responder of the at least one trusted responder; and ([para. 0070] “reverse proxy 532 can be employed to disperse incoming OCSP requests among a set of OCSP responders [selecting one of the at least one trusted responder] in a load-balancing fashion”)
receiving a validation response from the selected trusted responder. ([Para. 0078] “The process begins with the OCSP responder receiving an OCSP request message from an OCSP client (step 632) ... The OCSP responder [from the selected trusted responder of the at least one trusted responder] ... returns the OCSP response message [receiving a validation response] to the OCSP client (step 644), thereby concluding the process”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman with the teachings of Yellependdy to include wherein the communication initialization message comprises an indication of at least one trusted responder; sending a validation request regarding a public key certificate of the ground entity to a selected trusted responder of the at least one trusted responder; and receiving a validation response from the selected trusted responder. One of ordinary skill in the art would have been motivated to make this modification because a computing environment that is supporting more than one OCSP responder can provide additional OCSP responders, and the availability of this group of responders is greater than the availability of any one member of the group. (Yellependdy, para. 0093)
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Sivaraman in view of Yellependdy as applied to claim 1 above, and further in view of Vanstone et al. (US Pub. 2009/0022311) (hereinafter “Vanstone”).
As per claim 3, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman also teaches wherein the communication initialization message comprises the public key certificate of the aircraft. ([Sivaraman, para. 0060] “a “client hello” message ... include ... a digital certificate [a public key certificate of the aircraft – see para. 0010-0011: “the credential ... transmitted by the client device using a communication protocol and received by the server ... a public key encryption certificate”]”)
Sivaraman in view of Yellependdy does not clearly teach wherein the communication initialization message comprises a compressed version of the public key certificate of the aircraft.
However, Vanstone teaches wherein the communication initialization comprises a compressed version of the public key certificate. ([Vanstone, para. 0021] “public key certificates are compressed according to this method of generating a cryptographic value”; [para. 0055-0056] “The CA initializes the process ... provides the subject entity ... the compressed public key certificate”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman in view of Yellependdy with the teachings of Vanstone to include wherein the communication initialization comprises a compressed version of the public key certificate. One of ordinary skill in the art would have been motivated to make this modification because certificates often need to be stored or transmitted and compressing certificates help reduce the associated storage and transmission costs. (Vanstone, para. 0052)
Claims 8 is rejected under 35 U.S.C. 103 as being unpatentable over Sivaraman in view of Yellependdy as applied to claim 1 above, and further in view of Sharifi Mehr (US Patent No. 10,951,652) (hereinafter “Sharifi Mehr”).
As per claim 8, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman in view of Yellependdy does not clearly teach wherein the indication of the at least one trusted responder comprises a list of a plurality of trusted responders.
However, Sharifi Mehr teaches wherein the indication of the at least one trusted responder comprises a list of a plurality of trusted responders. ([Sharifi Mehr, col. 4, ln. 21-26] “the client computer system 102 [aircraft] sends a “client hello” message to the first server 106 [ground entity] containing an extension record [a list] ... The extension record indicates, to the first server 106, that the client computer system 102 supports session resumption [trusted as they previously established TLS connections – see col. 4, ln. 1-4] with multiple servers [a list of a plurality of trusted responders as they are trusted and respond to the client – see col. 12, ln. 46-50]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman in view of Yellependdy with the teachings of Sharifi Mehr to include wherein the indication of the at least one trusted responder comprises a list of a plurality of trusted responders. One of ordinary skill in the art would have been motivated to make this modification because such a technique allows the client/aircraft to use previously negotiated cryptographic material and allows communication sessions to be established more quickly. (Sharifi Mehr, col. 2, ln. 49-54)
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Sivaraman in view of Yellependdy as applied to claim 1 above, and further in view of Grajek et al. (US Pub. 2009/0307486) (hereinafter “Grajek”).
As per claim 11, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman does not clearly teach wherein: the validation request relates to the public key certificate of the ground entity and the public key certificate of the aircraft, and wherein the validation response contains an indication of a trustworthiness of a public key infrastructure (PKI) path between the public key certificate of the aircraft and the public key certificate of the ground entity.
However, Yellependdy teaches wherein the validation response contains an indication of a trustworthiness of a public key infrastructure (PKI) path between the public key certificate of the aircraft and the public key certificate of the ground entity. ([Yellependdy, para. 0005] “digital certificates ... cryptographically binds the certificate holder ... with its public cryptographic key ... based on the involvement of a trusted entity within the Internet Public Key Infrastructure [an indication of a trustworthiness of a PKI path] ... whenever the certificate is presented to a system for use of a service, its signature is verified [the validation response]”; [para. 0044] “User 202, operating on some type of client computer [between the public certificate of the aircraft] ... present digital certificate 216... to engage in trusted transactions or trusted communications [PKI path between the certificate of the aircraft]”; [para. 0046] “The entity that receives certificate 304 [the public certificate of the ground entity] ... perform some type of service for user... uses certificate 304 verifies the authenticity of the certificate [trustworthiness of communications/PKI path between the certificate of the aircraft and the public key certificate of the ground entity]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman with the teachings of Yellependdy to include wherein the validation response contains an indication of a trustworthiness of a public key infrastructure (PKI) path between the public key certificate of the aircraft and the public key certificate of the ground entity. One of ordinary skill in the art would have been motivated to make this modification because as a result, a strong and trusted association between the certificate holder and its public key can become public information yet remain tamper-proof and reliable. (Yellependdy, para. 0005)
Sivaraman does not clearly teach wherein: the validation request relates to the public key certificate of the ground entity and the public key certificate of the aircraft.
However, Grajek teaches wherein: the validation request relates to the public key certificate of the ground entity and the public key certificate of the aircraft ([Grajek, para. 0040] “the method for mutually authenticating the client ... and the server ... continues with ... transmitting a response packet ... the response packet ... is comprised of ... the server certificate 46, [public key certificate of the ground entity] and a client certificate 78 [public key certificate of the aircraft]”; [para. 0041] “the method further includes validating the contents of the response packet”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman in view of Yellependdy with the teachings of Grajek to include wherein: the validation request relates to the public key certificate of the ground entity and the public key certificate of the aircraft. One of ordinary skill in the art would have been motivated to make this modification because this prevents man-in the middle attacks as a malicious server/ground entity will have a different public key certificate from the one stored. (Grajek, para. 0043)
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Sivaraman in view of Yellependdy as applied to claim 1 above, and further in view of Pahl et al. (US Pub. 2015/0288514) (hereinafter “Pahl”).
As per claim 12, Sivaraman in view of Yellependdy teaches claim 1.
Sivaraman also teaches exchanging one or more messages between the aircraft and the ground entity, ([Sivaraman, para. 0065] “the head unit 290 and server 125 begin exchanging message traffic”)
wherein the one or more messages from the aircraft to the ground entity are encrypted, and wherein the one or more messages from the ground entity to the aircraft are encrypted. ([para. 0055] “The head unit 290 and the server 130 then exchange a mutual encryption key 367 to establish a TLS session 360 that permits secure, encrypted communication between the head unit 290 and the server 125”)
Sivaraman in view of Yellependdy does not clearly teach wherein the one or more messages from the aircraft to the ground entity are encrypted with a ground entity public key associated with the public key certificate of the ground entity, and wherein the one or more messages from the ground entity to the aircraft are encrypted with an aircraft public key associated with the public key certificate of the aircraft.
However, Pahl teaches wherein the one or more messages from the aircraft to the ground entity are encrypted with a ground entity public key ([Pahl, para. 0291] “future messages sent between the client device and the secure session server over the secure session will be encrypted and decrypted using the set of session keys ... the client write key [ground entity public key as it is known by and used by the ground entity to decrypt the message] is used by the client device to encrypt data and used by the secure session server to decrypt data received from the client device [from the aircraft to the ground entity]”) associated with the public key certificate of the ground entity, and ([Para. 0200] “As part of establishing the secure session [associated with the server write key as establishing the session allows the key to be used] ... the secure session server ... transmit ... its certificate [certificate of the ground entity as per Sivaraman above]”)
wherein the one or more messages from the ground entity to the aircraft are encrypted with an aircraft public key ([Pahl, para. 0291] “future messages sent between the client device and the secure session server over the secure session will be encrypted and decrypted using the set of session keys ... the server write key [aircraft public key] is used by the secure session server to encrypt data ... received from the secure session server [from the ground entity to the aircraft”) associated with the public key certificate of the aircraft. ([Para. 0200] “As part of establishing the secure session [associated with the client write key as establishing the session allows the key to be used] ... request a client certificate [certificate of the ground entity as per Sivaraman above]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Sivaraman in view of Yellependdy with the teachings of Pahl to include wherein the one or more messages from are encrypted with a ground entity public key associated with the public key certificate of the ground entity, and wherein the one or more messages from the ground entity to the aircraft are encrypted with an aircraft public key associated with the public key certificate of the aircraft. One of ordinary skill in the art would have been motivated to make this modification because this allows the private key to not be locally accessible to the ground entity/secure session server which provides increased security during the secure session handshake. (Pahl, para. 0376)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kass (US Pub. 2018/0145837) discloses a method for establishing a verifiable secure communication where a trusted secure gateway verifies both a certificate of the server and a certificate of the client.
Barr et al. (US Pub. 2016/0044023) discloses a certificate validator that keeps a list of trusted certificate authorities to check if the certificate authority is trusted.
Sato et al. (US Pub. 2014/0149740) discloses a OCSP responder that receives a validation request from aa terminal device and sending the validation result data to the terminal device after it is validated.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHE LIU whose telephone number is (571) 272-3634. The examiner can normally be reached on Monday - Friday: 8:30 AM to 5:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Carl Colin can be reached on (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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (IN USA OR CANADA) or (571) 272-1000.
/ZHE LIU/Examiner, Art Unit 2493
Prosecution Insights