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 .
Status of Claims
The following is a Final Office Action in response to applicant’s response on June 29, 2026. Claims 1, 10-12, 16, 20 and 21 were amended. Claims 3-4 were cancelled. Claims 1, 2, and 5-21 are pending, of which claims 1, 10, 16, and 20 are in independent form.
Response to Amendment
The amendment filed June 29, 2026, has been entered. Amendments to the claims do not overcome the previous 35 USC § 112(b) issue. Claims 1, 2, and 5-21 are rejected under 35 USC § 112(b) as being indefinite.
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected, under 35 USC 103(a), have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter.
35 U.S.C. 112(b) Rejection
Regarding claims 1 and 10, amendments to the claim do not overcome the previous 35 USC § 112(b) issue. Thus, the rejection under 35 USC § 112(b) is maintained.
The claim is still drafted to cover alternatives, so the zero-certificate received that does not necessarily require additional certificates. As drafted, in the alternative does not cure the ambiguity; instead, it still leaves unclear whether the additional-certificate sequence is a required branch or merely an optional implementation.
If the claim says “zero additional certificates”, that is an empty set. By plain meaning logic, you do not “find” additional certificates in an empty set if none are received. Limitation “determine whether there are one or more additional certificates in the zero additional certificates received”
The claim recites receiving “zero or more additional root certificates,” but then conditions subsequent limitations on “a determination that there are one or more additional certificates in the zero or more additional root certificates received from the server.” This language creates ambiguity as to how the determination is made when zero certificates are received and whether the additional-certificate is triggered only when a non-empty set is received. The claim therefore fails to particularly point out and distinctly claim the invention, hence indefinite. This should be correct by way of amendment to remove such ambiguity.
In addition, BRI implications, the claim is drafted to cover alternatives, “processing electronics configured to …: receiving zero OR more additional certificates…”, so the zero-certificate embodiment as claimed, does not necessarily require additional certificates.
Under the broadest reasonable interpretation, the claim reads on at least two alternatives:
electronics configured to: zero additional certificates are received, which then the device authenticates using the prior root certificate and the server certificate;
As drafted in the alternatives, OR one or more additional certificates are received, which
then the device authenticates the chain of additional certificates and then the server certificate. So as a matter of claim scope, the phrase “zero or more additional root certificates” does not impose a requirement that additional certificates must be received.
Regarding claim 10, amendments do not overcome the 112(b) issue. Claim 10 is rejected under 112(b) as being indefinite because the role and relationship of the “first Root certificate” are unclear. The claim initially defines the first Root certificate as the first certificate among the Root certificates and requires it to be signed using the private key of the particular Root certificate associated with an immediately previous Root certificate in the chain. It is unclear whether the particular Root certificate is part of the temporal chain, whether it is immediately previous Root certificate relative to the first root certificate or the first Root certificate is excluded from the requirement applicable to “each Root certificate” in the temporal chain. Therefore, claim 10 and dependent claims 11-15 are rejected under 35 U.S.C. 112(b).
Further, regarding claims 9, 12, and 14-15, the amendments did not overcome the 112(b) rejection, therefore, claims 9, 12, and 14-15 will remain rejected under 112(b).
35 U.S.C. 103 Rejection
On pages 10-13 of remarks, Applicant’s argues that “Amended claims 1, 10, 16 and 20 provide that the additional root certificates and the prior root certificate form a temporal certificate chain providing an orthogonal verification path from one root certificate to another in time… Himawan completely fails to teach or suggest a root certificate signing a subsequent root certificate over time, as recited in the pending claims.
Further, Stradling, Chen, and Ignatchenko similarly lack any concept of an orthogonal temporal verification path between root certificates" as amended in claims 1, 10, 16 and 20.
Applicant’s arguments, with respect to the rejection(s) of claims 1, 10, 16 and 20 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 LLOYD et al. (US 2016/0315777 A1).
As to the dependent claims 2, 5-9, 11-15, 17-19 and 21, these claims remain rejected by virtue of dependency to their independent claims.
Therefore, the examiner maintains the rejection under 35 USC § 103.
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, 2, and 5-21 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.
Claim 1 recites “wherein each root certificate in the temporal certificate chain, including the prior root certificate and each of the one or more additional root certificates, is at the bottom of the public key infrastructure hierarchy usable to authenticate the server certificate via the certificate verification path from the server certificate, through zero or more intermediate certificates, to that root certificate”. The specification fails to describe requiring each root certificate in the temporal certificate chain, including the prior root certificate and every additional root certificate, to be independently usable to authenticate the same server certificate through a certificate-verification path terminating that respective root certificate. Although paragraph [0052] describes (the server certificate can be signed using this most recent one of the additional Root certificates), However, the specification does not provide adequate written description support for every root in the temporal chain independently anchoring a verification path for the same server certificate.
Claim 1 recites “…receiving, from the server via the communication interface, zero or more additional root certificates and the server certificate; wherein upon determination that there are zero additional root certificates in the zero or more additional root certificates received from the server,”. Although the paragraph [0032] of the specification repeats the same language “A typical certificate verification path is from the server certificate, to zero or more intermediate certificates, to a Root certificate. Temporal chains may provide an orthogonal verification path from one root to another in time.”. However, the specification does not describe what structural, cryptographic, or operational characteristic makes a verification path “orthogonal”, nor does it explain how orthogonally is determined or measured “in time”. Accordingly, the original disclosure fails to provide adequate written-description support for this limitation.
Claims 10, 16 and 20 are similarly rejected and the dependent claims 2, 5-9, 11-15, 17-19 and 21, are rejected by virtue of dependency on their independent claims.
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, 2, and 5-21 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.
Claim 1 recites “…receiving, from the server via the communication interface, zero or more additional root certificates and the server certificate; wherein upon determination that there are zero additional root certificates in the zero or more additional root certificates received from the server,”. The claim recites receiving “zero or more additional root certificates,” but then conditions subsequent limitations on “a determination that there are one or more additional certificates in the zero or more additional root certificates received from the server.” The claim therefore fails to particularly point out and distinctly claim the invention, hence indefinite. This should be correct by way of amendment to remove such ambiguity.
In addition, BRI implications, the claim is drafted to cover alternatives, “processing electronics configured to …: receiving zero OR more additional certificates…”, so the zero-certificate embodiment as claimed, does not necessarily require additional certificates.
Under the broadest reasonable interpretation, the claim reads on at least two alternatives:
electronics configured to: zero additional certificates are received, which then the device authenticates using the prior root certificate and the server certificate;
As drafted in the alternatives, OR one or more additional certificates are received, which
then the device authenticates the chain of additional certificates and then the server certificate. So as a matter of claim scope, the phrase “zero or more additional root certificates” does not impose a requirement that additional certificates must be received. Therefore, the metes and bounds of claim 1 are unclear.
Claim 1 recites “the prior root certificate form a temporal certificate chain providing an orthogonal verification path from one root certificate to another in time,”. The claim is indefinite because it is unclear what structural, or operational property makes the recited verification path “orthogonal”, or how a verification path can be orthogonal in time. The specification does not define “orthogonal” or provide an orthogonal verification path from one root to another in time and does not provide an objective standard for determining whether a particular verification path is orthogonal. Therefore, the metes and bounds of claim 1 are unclear.
Claim 9 recites “wherein zero additional root certificates are received based on the prior root certificate being same as a most recent root certificate.”. The claim is indefinite because it is unclear how the condition “the prior root certificate being same as the most recent root certificate” is evaluated when zero additional root certificates are received, as no additional root certificates exist from which a “most recent root certificate” can be determined.
Claim 10 recites “causing the electronic server device to send, to the client device, zero or more Root certificates of the temporal chain, wherein when one or more root certificates are sent, a first Root certificate of the Root certificates is signed using a private cryptographic key of the particular Root certificate, and wherein each Root certificate other than the first root certificate is signed using a private cryptographic key of an immediately previous Root certificate in the temporal chain;”. The claim is indefinite because the scope of the root certificates is unclear, Specifically, “each Root certificate other than the first Root certificate” does not specify whether it refers only to the root certificates sent to the client or every Root certificate in the temporal chain. Moreover, the claim requires “each root certificate” in the temporal chain, even though the first root certificate has no immediately previous Root certificate within the chain. Therefore, it is unclear whether the first Root certificate is excluded from the requirement applicable to “each Root certificate” in the temporal chain. Accordingly, the metes and bounds of claim 10 are unclear.
Claim 12 recites “the zero or more Root certificates immediately follow the particular Root certificate according to the ordering and are a contiguous subset of the temporal chain according to the ordering”. The claim is indefinite because it is unclear how “zero or more Root certificates” can “immediately follow” a particular root certificate and a form a “contiguous subset” of the chain of root certificates when zero root certificates are present.
Claim 14 recites “wherein the zero or more Root certificates are sent to the client device, in one or more messages, in response to a same single message from the client device”. The claim is indefinite because when zero root certificates are sent, there is no certificate that can be “sent to the client device”, rendering the recited transmission operation unclear.
Claim 15 recites “wherein the server implicitly or explicitly indicates, to the client device, the ordering among the zero or more Root certificates in the temporal chain”. The claim is indefinite because it is unclear how an “ordering” can be indicated among zero root certificates. Additionally, the claim does not specify what constitutes “implicitly” indicating the ordering, nor specifies distinguishing implicit indication from explicit indication.
As to the dependent claims remain rejected by virtue of dependency on their independent claims. Appropriate correction is required.
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, 2, 5, 6, and 8-21 are rejected under 35 U.S.C. 103 as being unpatentable over Stradling (US 2008/0155254 A1), in view of LLOYD et al. (US 2016/0315777 A1), hereinafter LLOYD.
Regarding Claim 1, Stradling discloses an electronic device comprising: a communication interface configured to communicate directly or indirectly with a server (Stradling, Figure 1 shows a computer (i.e., electronic device) communicating via SSL/TLS handshake with a server computer);
a memory configured to store a prior root certificate (Stradling, Figure 1 shows a root storage facility (i.e., memory) for storing root certificates on the computing device); wherein the prior root certificate is at a bottom of a public key infrastructure hierarchy usable to authenticate a server certificate via a certificate verification path from the server certificate (Stradling, Fig. 1 and Para. 0004, the SSL protocol maintains security by using a public key infrastructure during network transactions. During a transaction, the server computer utilizes the SSL connection to transfer certificate information to a client computer for verification), through zero or more intermediate certificates, to the prior root certificate (Stradling, Para. 0005, the client computer will try to establish trust by using data associated with the sent certificate to establish a certificate chain by tracing referenced certificates (cross-certificates) in an attempt to locate a trusted certificate. The end point of a certificate chain or the trusted certificate upon which other certificates rely for their verification is called a root certificate) and (Stradling, Para. 0017, zero or more legacy root certificates plus zero or more cross-certificates, to allow the client to build the certificate chain(s) up to one or more legacy root certificates);
and processing electronics configured to perform a process including:
sending, to the server via the communication interface, an indication of the prior root certificate” (Stradling, Para. 0005, the client computer examines the server computer's certificate information to determine the validity of the server computer. The certificate is considered trusted if the sent certificate is found in the local trusted root storage facility (the one or more places on the client computer where digital certificates are stored). If the certificate is not found, the client computer will try to establish trust by using data associated with the sent certificate to establish a certificate chain by tracing referenced certificates (cross-certificates) in an attempt to locate a trusted certificate) and (Stradling, Para. 0023; discloses a method of updating a root certificate on a computer with a root update mechanism 2 by causing a new root certificate (which includes root certificates that are updated and will replace root certificates already installed) 10 to be sent to the client computer during an SSL/TLS handshake in addition to the legacy certificate chain 8) it is noted that the initiation of root certificate updating during an SSL/TLS handshake implies the existence of a prior trusted root certificate;
receiving, from the server via the communication interface, zero or more additional root certificates and the server certificate (Stradling, Figure 1 shows the server sending at least zero additional root certificates to the client computer and [0024] describes how a first certificate is requested (and received) via a SSL/TLS handshake);
Stradling does not explicitly disclose wherein upon determination that there are zero additional root certificates in the zero or more additional root certificates received from the server, the processing electronics are further configured to authenticate the server using the prior root certificate and the server certificate; and wherein upon determination that there are one or more additional certificates in the zero or more additional root certificates received from the server, the processing electronics are further configured to: authenticate a first one of the one or more additional root certificates using the prior root certificate; after authenticating the first one of the one or more additional root certificates, sequentially authenticate each subsequent one of the one or more additional root certificates using another one of the one or more additional root certificates already authenticated; after authenticating each of the one or more additional root certificates, authenticate the server using a most recent one of the one or more additional root certificates and the server certificate; and replace the prior root certificate with the most recent additional root certificate; wherein, when there are one or more additional root certificates, the one or more additional root certificates and the prior root certificate form a temporal certificate chain providing an orthogonal verification path from one root certificate to another in time, in which each additional root certificate is a forward-signed updated certificate for a same entity as the prior root certificate, each root certificate in the one or more additional root certificates being signed with a private cryptographic key associated with an immediately previous root certificate in the temporal certificate chain; and wherein each root certificate in the temporal certificate chain, including the prior root certificate and each of the one or more additional root certificates, is at the bottom of the public key infrastructure hierarchy usable to authenticate the server certificate via the certificate verification path from the server certificate, through zero or more intermediate certificates, to that root certificate.
However, LLOYD teaches wherein upon determination that there are zero additional root certificates in the zero or more additional root certificates received from the server (LLOYD, Para. 0058, a determination is made whether a PKIX algorithm will work with an acquired chain (e.g., a certificate chain, server chain, etc. as described above). If the PKIX algorithm works with the chain as sent, the method ends at step 760…a chain is built using the certificates acquired from the URL, and the PKIX algorithm is executed again to build a chain. After the chain is built, the method 700 ends at step 760), the processing electronics are further configured to authenticate the server using the prior root certificate and the server certificate (LLOYD, Para. 0042, if there is a new root certificate, then a device (e.g., intermediate certificate authority 220, end entity 230, etc.) can verify whether the new root certificate can be trusted based on a root certificate update algorithm)and (LLOYD, para. 0036, a new root certificate signed by an old root certificate (also known as a new-with-old certificate)); and wherein upon determination that there are one or more additional certificates in the zero or more additional root certificates received from the server (LLOYD, Para. 0042, if there is a new root certificate, then a device (e.g., intermediate certificate authority 220, end entity 230, etc.) can verify whether the new root certificate can be trusted based on a root certificate update algorithm), the processing electronics are further configured to: authenticate a first one of the one or more additional root certificates using the prior root certificate (LLOYD, Para. 0036, a new root certificate signed by an old root certificate (also known as a new-with-old certificate)) and (LLOYD, Para. 0037, a certificate path can be referred to herein as a chain, certificate chain, chain of certificates, or server chain) and (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key); after authenticating the first one of the one or more additional root certificates (LLOYD, Para. 0051), sequentially authenticate each subsequent one of the one or more additional root certificates using another one of the one or more additional root certificates already authenticated (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520. An end entity 570 can use either old trust anchor 510 (via intermediate certificate authority with an old certificate 550) or new trust anchor 520 (via intermediate certificate authority with a new certificate 560) if the chain contains a requisite amount of certificates) and (LLOYD, Para. 0055, this process can be repeated when a root certificate update occurs); after authenticating each of the one or more additional root certificates (LLOYD, Para. 0051), authenticate the server using a most recent one of the one or more additional root certificates and the server certificate (LLOYD, Para. 0042, if there is a new root certificate, then a device (e.g., intermediate certificate authority 220, end entity 230, etc.) can verify whether the new root certificate can be trusted based on a root certificate update algorithm) and (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520. An end entity 570 can use either old trust anchor 510 (via intermediate certificate authority with an old certificate 550) or new trust anchor 520 (via intermediate certificate authority with a new certificate 560) if the chain contains a requisite amount of certificates) and (LLOYD, Para. 0058, a chain is built using the certificates acquired from the URL, and the PKIX algorithm is executed again to build a chain); and replace the prior root certificate with the most recent additional root certificate (LLOYD, Paras. 0050-0052, Environment 500 illustrates an example approach for replacing a trust anchor 510. Environment 500 includes an old trust anchor 510, a new trust anchor 520, a new-with-old certificate 530, an old-with-new certificate 540); wherein, when there are one or more additional root certificates, the one or more additional root certificates and the prior root certificate form a temporal certificate chain providing an orthogonal verification path from one root certificate to another in time (LLOYD, Para. 0036, a new root certificate signed by an old root certificate (also known as a new-with-old certificate) and (LLOYD, Paras. 0050-0052) and (LLOYD, Para. 0044) It is noted that LLOYD teaches an orthogonal path because the old root verifies the new root across successive times, separately from the conventional path used to verify the server certificate, in which each additional root certificate is a forward-signed updated certificate for a same entity as the prior root certificate (LLOYD, Para. 0051) and (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530) and (LLOYD, Para. 0044, For security, an X.509 Subject Name is the same in all certificates and matches the trust anchor that is replaced), each root certificate in the one or more additional root certificates being signed with a private cryptographic key associated with an immediately previous root certificate in the temporal certificate chain (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530) and (LLOYD, Para. 0041) ; and wherein each root certificate in the temporal certificate chain (LLOYD, Para. 0041, for instance, a PKCS #10 file can include requests for certificates with one or more particular extensions (e.g., a Subject Key Identifier Extension, which is an identifier that aids a certificate chaining system in matching public keys to signatures). In some embodiments, end entity 230 can retrieve one new certificate issued by third party certificate authority 240. This new certificate is the latest version of a certificate that identifies end entity 230. The new certificate can have the same public key as the previous certificate, along with a later ValidFrom date (e.g., a time and/or date indicating when a certificate's validity period starts)), including the prior root certificate and each of the one or more additional root certificates, is at the bottom of the public key infrastructure hierarchy usable to authenticate the server certificate via the certificate verification path from the server certificate ((LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520. An end entity 570 can use either old trust anchor 510 (via intermediate certificate authority with an old certificate 550) or new trust anchor 520 (via intermediate certificate authority with a new certificate 560) if the chain contains a requisite amount of certificates) and (LLOYD, Paras. 0051- 0052, a root certificate can be used to authenticate an intermediate certificate authority, and the intermediate certificate authority can be used to authenticate an end entity), through zero or more intermediate certificates, to that root certificate (LLOYD, Paras. 0051- 0052).
Stradling and LLOYD are considered to be analogous to the claim invention because they are in the same field of public key infrastructure (PKI) certificate management, particularly updating, distributing, and validating root certificates or trust anchors used to authenticate server certificates. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include wherein upon determination that there are zero additional root certificates in the zero or more additional root certificates received from the server (LLOYD, Para. 0058), the processing electronics are further configured to authenticate the server using the prior root certificate and the server certificate (LLOYD, Para. 0042)and (LLOYD, para. 0036); and wherein upon determination that there are one or more additional certificates in the zero or more additional root certificates received from the server (LLOYD, Para. 0042), the processing electronics are further configured to: authenticate a first one of the one or more additional root certificates using the prior root certificate (LLOYD, Para. 0036) and (LLOYD, Para. 0037) and (LLOYD, Para. 0052); after authenticating the first one of the one or more additional root certificates (LLOYD, Para. 0051), sequentially authenticate each subsequent one of the one or more additional root certificates using another one of the one or more additional root certificates already authenticated (LLOYD, Para. 0051) and (LLOYD, Para. 0055); after authenticating each of the one or more additional root certificates (LLOYD, Para. 0051), authenticate the server using a most recent one of the one or more additional root certificates and the server certificate (LLOYD, Para. 0042) and (LLOYD, Para. 0051) and (LLOYD, Para. 0058); and replace the prior root certificate with the most recent additional root certificate (LLOYD, Paras. 0050-0052); wherein, when there are one or more additional root certificates, the one or more additional root certificates and the prior root certificate form a temporal certificate chain providing an orthogonal verification path from one root certificate to another in time (LLOYD, Para. 0036) and (LLOYD, Paras. 0050-0052) and (LLOYD, Para. 0044), in which each additional root certificate is a forward-signed updated certificate for a same entity as the prior root certificate (LLOYD, Para. 0051) and (LLOYD, Para. 0052) and (LLOYD, Para. 0044), each root certificate in the one or more additional root certificates being signed with a private cryptographic key associated with an immediately previous root certificate in the temporal certificate chain (LLOYD, Para. 0052) and (LLOYD, Para. 0041) ; and wherein each root certificate in the temporal certificate chain (LLOYD, Para. 0041), including the prior root certificate and each of the one or more additional root certificates, is at the bottom of the public key infrastructure hierarchy usable to authenticate the server certificate via the certificate verification path from the server certificate ((LLOYD, Para. 0051) and (LLOYD, Paras. 0051- 0052), through zero or more intermediate certificates, to that root certificate (LLOYD, Paras. 0051- 0052). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Paras. 0015).
Regarding Claim 2, the combination of Stradling in view of LLOYD teaches “The electronic device of claim 1, wherein the one or more additional root certificates are generated after the prior root certificate” (Stradling, Para. 0016, and Figure 1 shows a process of root certificates being sent to the computing device in succession).
Regarding Claim 5, the combination of Stradling in view of LLOYD teaches “The electronic device of claim 1, wherein authenticating of any one of the additional root certificates comprises determining that said one of the additional root certificates is signed with a private cryptographic key associated with another root certificate” (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include wherein authenticating of any one of the additional root certificates comprises determining that said one of the additional root certificates is signed with a private cryptographic key associated with another root certificate” (LLOYD, Para. 0052). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Paras. 0015).
Regarding Claim 6, the combination of Stradling in view of LLOYD teaches “The electronic device of claim 1, wherein the processing electronics are further configured to authenticate a server certificate indicative of an identity of the server using a most recent additional root certificate of the one or more additional root certificates” (Stradling, Figure 1 shows a process of root certificate issuance to a client computing device, where a chain is started based on the latest root certificate (reference character 12)).
Regarding Claim 8, the combination of Stradling in view of LLOYD teaches “The electronic device of claim 1, wherein the one or more additional root certificates are received based on the prior root certificate being different from a most recent additional root certificates” (Stradling, Figure 1 shows the issuance of a new or updated root certificate; a new root certificate implies that it is different from prior root certificates).
Regarding Claim 9, the combination of Stradling in view of LLOYD teaches “The electronic device of claim 1, wherein zero additional root certificates are received based on the prior root certificate being same as a most recent root certificate” (Stradling, Figure 1 shows the issuance of a number of certificates, where the number may be zero).
Regarding Claim 10, Stradling discloses an electronic server device, comprising: one or more communication interfaces configured to communicate directly or indirectly with a client device and with a certificate authority (Stradling, Para. 0024, and Figure 1 shows a computer (i.e., electronic device) communicating via SSL/TLS handshake with a server computer);
a memory (Stradling, Figure 1 shows a root storage facility (i.e., memory) for storing root certificates on the computing device); and
processing electronics configured to: store, in the memory (Stradling, Para. 0026, if the new root certificate included in the bundle file is a PEM-encoded certificate then this configuration will enable EV certificates on computers with an update mechanism), a temporal chain of Root certificates received from the certificate authority over time as part of a root certificate rotation (Stradling, Paras. 0023-0024, a new root certificate (which includes root certificates that are updated and will replace root certificates already installed) 10 to be sent to the client computer during an SSL/TLS handshake in addition to the legacy certificate chain 8. This causes the new root certificate to automatically be downloaded and installed from the root updating facility) and (Stradling, Para. 0025),
Stradling does not explicitly disclose each Root certificate of the temporal chain being a forward-signed updated certificate for a same entity, wherein each Root certificate is signed using a private cryptographic key associated with an immediately previous Root certificate in the temporal chain according to an ordering of the temporal chain, the temporal chain providing an orthogonal verification path from one Root certificate to another in time; wherein each Root certificate in the temporal chain is at a bottom of a public key infrastructure hierarchy usable to authenticate a server certificate via a certificate verification path from the server certificate, through zero or more intermediate certificates, to that Root certificate; and
in response to the electronic server device receiving, from the client device, at least one message including a message indicating a particular Root certificate: causing the electronic server device to send, to the client device, zero or more Root certificates of the temporal chain, wherein when one or more Root certificates are sent, a first Root certificate of the one or more Root certificates is signed using a private cryptographic key of the particular Root certificate, and wherein each Root certificate other than the first Root certificate is signed using a private cryptographic key of an immediately previous Root certificate in the temporal chain; wherein the ordering of Root certificates in the temporal chain is cryptographically enforced by having each Root certificate signed with the private cryptographic key associated with the immediately previous Root certificate in the temporal chain.
However, LLOYD teaches each Root certificate of the temporal chain being a forward-signed updated certificate for a same entity (LLOYD, Para. 0044, an X.509 Subject Name is the same in all certificates and matches the trust anchor that is replaced. For example, an X.509 Subject Name can comprise a domain component, such as DC=citrix.com) and (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key), wherein each Root certificate is signed using a private cryptographic key associated with an immediately previous Root certificate in the temporal chain according to an ordering of the temporal chain (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530) and (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520), the temporal chain providing an orthogonal verification path from one Root certificate to another in time (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520) and (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key) It is noted that LLOYD teaches an orthogonal path because the old root verifies the new root across successive times, separately from the conventional path used to verify the server certificate; wherein each Root certificate in the temporal chain is at a bottom of a public key infrastructure hierarchy usable to authenticate a server certificate via a certificate verification path from the server certificate (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520. An end entity 570 can use either old trust anchor 510 (via intermediate certificate authority with an old certificate 550) or new trust anchor 520 (via intermediate certificate authority with a new certificate 560) if the chain contains a requisite amount of certificates) and (LLOYD, Paras. 0051- 0052, a root certificate can be used to authenticate an intermediate certificate authority, and the intermediate certificate authority can be used to authenticate an end entity), through zero or more intermediate certificates, to that Root certificate (LLOYD, Paras. 0051- 0052); and
in response to the electronic server device receiving, from the client device (LLOYD, Para. 0044, root certificate authority 210 can send a PKCS #10 file to request three certificates from third party certificate authority 240), at least one message including a message indicating a particular Root certificate (LLOYD, Para. 0040, the certificates returned in a PKCS #7 file can be based at least in part on the identity of a device that authenticates itself to a certificate authority) and (LLOYD, Para. 0044): causing the electronic server device to send, to the client device, zero or more Root certificates of the temporal chain, wherein when one or more Root certificates are sent (LLOYD, Para. 0044, third party certificate authority 240 can issue a PKCS #7 file with three certificates), a first Root certificate of the one or more Root certificates is signed using a private cryptographic key of the particular Root certificate (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530), and wherein each Root certificate other than the first Root certificate is signed using a private cryptographic key of an immediately previous Root certificate in the temporal chain (LLOYD, Para. 0030, certificate authorities such as third party certificate authority 240 can return all, or some of the certificates stored in certificate repository 245 to various certificate authorities and end entities, such as root certificate authority 21) and (LLOYD, Para. 0052, this is referred to as the old-with-new certificate 540. After this step, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530); wherein the ordering of Root certificates in the temporal chain is cryptographically enforced by having each Root certificate signed with the private cryptographic key associated with the immediately previous Root certificate in the temporal chain (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520) and (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key).
Stradling and LLOYD are considered to be analogous to the claim invention because they are in the same field of public key infrastructure (PKI) certificate management, particularly updating, distributing, and validating root certificates or trust anchors used to authenticate server certificates. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include each Root certificate of the temporal chain being a forward-signed updated certificate for a same entity (LLOYD, Para. 0044) and (LLOYD, Para. 0052), wherein each Root certificate is signed using a private cryptographic key associated with an immediately previous Root certificate in the temporal chain according to an ordering of the temporal chain (LLOYD, Para. 0052) and (LLOYD, Para. 0051), the temporal chain providing an orthogonal verification path from one Root certificate to another in time (LLOYD, Para. 0051) and (LLOYD, Para. 0052); wherein each Root certificate in the temporal chain is at a bottom of a public key infrastructure hierarchy usable to authenticate a server certificate via a certificate verification path from the server certificate (LLOYD, Para. 0051) and (LLOYD, Paras. 0051- 0052), through zero or more intermediate certificates, to that Root certificate (LLOYD, Paras. 0051- 0052); and in response to the electronic server device receiving, from the client device (LLOYD, Para. 0044), at least one message including a message indicating a particular Root certificate (LLOYD, Para. 0040) and (LLOYD, Para. 0044): causing the electronic server device to send, to the client device, zero or more Root certificates of the temporal chain, wherein when one or more Root certificates are sent (LLOYD, Para. 0044), a first Root certificate of the one or more Root certificates is signed using a private cryptographic key of the particular Root certificate (LLOYD, Para. 0052), and wherein each Root certificate other than the first Root certificate is signed using a private cryptographic key of an immediately previous Root certificate in the temporal chain (LLOYD, Para. 0030) and (LLOYD, Para. 0052); wherein the ordering of Root certificates in the temporal chain is cryptographically enforced by having each Root certificate signed with the private cryptographic key associated with the immediately previous Root certificate in the temporal chain (LLOYD, Para. 0051) and (LLOYD, Para. 0052). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Paras. 0015).
Regarding Claim 11, the combination of Stradling in view of LLOYD teaches “the electronic server device of claim 10, wherein said previous root certificate of the temporal chain is an immediately previous root certificate of the temporal chain according to the ordering” (LLOYD, Para. 0051, an end entity 570 can use either old trust anchor 510 (via intermediate certificate authority with an old certificate 550) or new trust anchor 520 (via intermediate certificate authority with a new certificate 560) if the chain contains a requisite amount of certificates). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include the electronic server device of claim 10, wherein said previous root certificate of the temporal chain is an immediately previous root certificate of the temporal chain according to the ordering” (LLOYD, Para. 0051). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Paras. 0015).
Regarding Claim 12, the combination of Stradling in view of LLOYD teaches “The electronic server device of claim 11, wherein: the particular Root certificate is one root certificate of the temporal chain or immediately precedes the temporal chain according to the ordering (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520. An end entity 570 can use either old trust anchor 510 (via intermediate certificate authority with an old certificate 550) or new trust anchor 520 (via intermediate certificate authority with a new certificate 560) if the chain contains a requisite amount of certificates); and
the zero or more Root certificates immediately follow the particular Root certificate according to the ordering and are a contiguous subset of the plurality of temporal chain according to the ordering” (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530) and (LLOYD, Para. 0030) and (LLOYD, Para. 0040). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include wherein: the particular Root certificate is one root certificate of the temporal chain or immediately precedes the temporal chain according to the ordering (LLOYD, Para. 0051); and
the zero or more Root certificates immediately follow the particular Root certificate according to the ordering and are a contiguous subset of the plurality of temporal chain according to the ordering” (LLOYD, Para. 0052) and (LLOYD, Para. 0030) and (LLOYD, Para. 0040). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Paras. 0015).
Regarding Claim 13, the combination of Stradling in view of LLOYD teaches “The electronic server device of claim 10, wherein the particular Root certificate is a most recent Root certificate held by the client device” (LLOYD, Para. 0060, a device can poll (e.g., call back) to its certificate authority at a particular frequency, such as once a day, to see if there is a new certificate chain available). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include wherein the particular Root certificate is a most recent Root certificate held by the client device” (LLOYD, Para. 0060). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Paras. 0015).
Regarding Claim 14, the combination of Stradling in view of LLOYD teaches “The electronic server device of claim 10, wherein the zero or more Root certificates are sent to the client device, in one or more messages, in response to a same single message from the client device” (Stradling: The Abstract describes how a message identifying one or more root certificates is received and stored in non-volatile storage (i.e., on the client device)).
Regarding Claim 15, the combination of Stradling in view of LLOYD teaches “The electronic server device of claim 10, wherein the server implicitly or explicitly indicates, to the client device, the ordering among the zero or more Root certificates in the chain of root certificates” (LLOYD, Para. 0043, if an intermediate certificate authority (or other device) has a choice regarding which certificate to use to authenticate itself with (e.g., when more than one certificate is within its validity period), the certificate with the most recent ValidFrom data is typically used) and (LLOYD, Para. 0044, root certificate authority 210 can send a PKCS #10 file to request three certificates from third party certificate authority 240. Third party certificate authority 240 can issue a PKCS #7 file with three certificates (e.g., using a standard extension): (1) a new certificate (which can be self-signed and has a more recent ValidFrom date and a new public key); (2) a new-with-old certificate; and (3) an old-with-new certificate). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include The electronic server device of claim 10, wherein the server implicitly or explicitly indicates, to the client device, the ordering among the zero or more Root certificates in the chain of root certificates” (LLOYD, Para. 0043) and (LLOYD, Para. 0044). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Paras. 0015).
Regarding claim 16, the claim is interpreted and rejected for the same rational set forth
in claim 1.
Regarding Claim 17¸ the combination of Stradling in view of LLOYD teaches “The method of claim 16, further comprising receiving or determining an indication of ordering of the one or more additional Root certificates” (LLOYD, Para. 0044, a new certificate (which can be self-signed and has a more recent ValidFrom date and a new public key)) and (LLOYD, Para. 0043, intermediate certificate authorities 220 can be identified and/or authenticated based at least in part on their ValidFrom dates, since they can have the same ValidFrom date as another certificate in a chain (e.g., acquired using an extension). If an intermediate certificate authority (or other device) has a choice regarding which certificate to use to authenticate itself with (e.g., when more than one certificate is within its validity period), the certificate with the most recent ValidFrom data is typically used);
“and wherein said sequentially authenticating is performed according to said ordering” (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include the method of claim 16, further comprising receiving or determining an indication of ordering of the one or more additional Root certificates” (LLOYD, Para. 0044) and (LLOYD, Para. 0043); and wherein said sequentially authenticating is performed according to said ordering” (LLOYD, Para. 0052). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Para. 0015).
Regarding Claim 18, the combination of Stradling in view of LLOYD teaches “The method of claim 16, further comprising authenticating a server certificate indicative of an identity of the server using the most recent one of the additional Root certificates” (Stradling: Figure 1 shows a process of root certificate issuance to a client computing device, where a chain is started based on the latest root certificate (reference character 12)).
Regarding Claim 19, the combination of Stradling in view of LLOYD teaches “The method of claim 16, further comprising, prior to receiving the two or more additional Root certificates, sending an indication of the prior Root certificate to the server” (Stradling: Para. 0017 describes how the client computer requests an updated certificate from the server via SSL/TLS handshake. This implies that the computer was already in possession of a root certificate).
Regarding Claim 20, Stradling discloses a method comprising, by an electronic server device (Stradling, Para. 0024, and Figure 1 shows a computer (i.e., electronic device) communicating via SSL/TLS handshake with a server computer): storing, in memory (Stradling, Para. 0026, if the new root certificate included in the bundle file is a PEM-encoded certificate then this configuration will enable EV certificates on computers with an update mechanism), a temporal chain of Root certificates received from a certificate authority over time as part of a root certificate rotation (Stradling, Paras. 0023-0024, a new root certificate (which includes root certificates that are updated and will replace root certificates already installed) 10 to be sent to the client computer during an SSL/TLS handshake in addition to the legacy certificate chain 8. This causes the new root certificate to automatically be downloaded and installed from the root updating facility) and (Stradling, Para. 0025),
Stradling does not explicitly disclose each Root certificate of the temporal chain being a forward-signed updated certificate for a same entity, each Root certificate being signed using a private cryptographic key associated with an immediately previous Root certificate in the temporal chain according to an ordering of the temporal chain, the temporal chain providing an orthogonal verification path from one Root certificate to another in time, wherein each Root certificate in the temporal chain is at a bottom of a public key infrastructure hierarchy usable to authenticate a server certificate via a certificate verification path from the server certificate, through zero or more intermediate certificates, to that Root certificate; and in response to the electronic server device receiving, from a client device, at least one message including a message indicating a particular Root certificate: sending, to the client device, one or more Root certificates of the chain of Root certificates, wherein when the one or more Root certificates are sent, a first Root certificate of the one or more Root certificates is signed using a private cryptographic key of the particular Root certificate, and wherein each subsequent Root certificate other than the first Root certificate is signed using a private cryptographic key of a previous Root certificate in the temporal chain.
However, LLOYD teaches each Root certificate of the temporal chain being a forward-signed updated certificate for a same entity (LLOYD, Para. 0044, an X.509 Subject Name is the same in all certificates and matches the trust anchor that is replaced. For example, an X.509 Subject Name can comprise a domain component, such as DC=citrix.com) and (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key), each Root certificate being signed using a private cryptographic key associated with an immediately previous Root certificate in the temporal chain according to an ordering of the temporal chain (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530) and (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520), the temporal chain providing an orthogonal verification path from one Root certificate to another in time (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520) and (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key) It is noted that LLOYD teaches an orthogonal path because the old root verifies the new root across successive times, separately from the conventional path used to verify the server certificate, wherein each Root certificate in the temporal chain is at a bottom of a public key infrastructure hierarchy usable to authenticate a server certificate via a certificate verification path from the server certificate (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520. An end entity 570 can use either old trust anchor 510 (via intermediate certificate authority with an old certificate 550) or new trust anchor 520 (via intermediate certificate authority with a new certificate 560) if the chain contains a requisite amount of certificates) and (LLOYD, Paras. 0051- 0052, a root certificate can be used to authenticate an intermediate certificate authority, and the intermediate certificate authority can be used to authenticate an end entity), through zero or more intermediate certificates, to that Root certificate (LLOYD, Paras. 0051- 0052); and in response to the electronic server device receiving, from a client device (LLOYD, Para. 0044, root certificate authority 210 can send a PKCS #10 file to request three certificates from third party certificate authority 240), at least one message including a message indicating a particular Root certificate (LLOYD, Para. 0040, the certificates returned in a PKCS #7 file can be based at least in part on the identity of a device that authenticates itself to a certificate authority) and (LLOYD, Para. 0044): sending, to the client device, one or more Root certificates of the chain of Root certificates (LLOYD, Para. 0044, third party certificate authority 240 can issue a PKCS #7 file with three certificates), wherein when the one or more Root certificates are sent (LLOYD, Para. 0044, a first Root certificate of the one or more Root certificates is signed using a private cryptographic key of the particular Root certificate (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key. This is referred to as the new-with-old certificate 530), and wherein each subsequent Root certificate other than the first Root certificate is signed using a private cryptographic key of a previous Root certificate in the temporal chain (LLOYD, Para. 0051, the trust anchor changes from old trust anchor 510 to new trust anchor 520) and (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key).
Stradling and LLOYD are considered to be analogous to the claim invention because they are in the same field of public key infrastructure (PKI) certificate management, particularly updating, distributing, and validating root certificates or trust anchors used to authenticate server certificates. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include each Root certificate of the temporal chain being a forward-signed updated certificate for a same entity (LLOYD, Para. 0044) and (LLOYD, Para. 0052), each Root certificate being signed using a private cryptographic key associated with an immediately previous Root certificate in the temporal chain according to an ordering of the temporal chain (LLOYD, Para. 0052) and (LLOYD, Para. 0051), the temporal chain providing an orthogonal verification path from one Root certificate to another in time (LLOYD, Para. 0051) and (LLOYD, Para. 0052) It is noted that LLOYD teaches an orthogonal path because the old root verifies the new root across successive times, separately from the conventional path used to verify the server certificate, wherein each Root certificate in the temporal chain is at a bottom of a public key infrastructure hierarchy usable to authenticate a server certificate via a certificate verification path from the server certificate (LLOYD, Para. 0051) and (LLOYD, Paras. 0051- 0052), through zero or more intermediate certificates, to that Root certificate (LLOYD, Paras. 0051- 0052); and in response to the electronic server device receiving, from a client device (LLOYD, Para. 0044), at least one message including a message indicating a particular Root certificate (LLOYD, Para. 0040) and (LLOYD, Para. 0044): sending, to the client device, one or more Root certificates of the chain of Root certificates (LLOYD, Para. 0044), wherein when the one or more Root certificates are sent (LLOYD, Para. 0044), a first Root certificate of the one or more Root certificates is signed using a private cryptographic key of the particular Root certificate (LLOYD, Para. 0052), and wherein each subsequent Root certificate other than the first Root certificate is signed using a private cryptographic key of a previous Root certificate in the temporal chain (LLOYD, Para. 0051) and (LLOYD, Para. 0052). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Paras. 0015).
Regarding Claim 21, the combination of Stradling in view of LLOYD teaches “The method of claim 20, wherein: said previous root certificate of the chain of Root certificates is an immediately previous one of the chain of Root certificates according to the ordering” (LLOYD, Para. 0051, an end entity 570 can use either old trust anchor 510 (via intermediate certificate authority with an old certificate 550) or new trust anchor 520 (via intermediate certificate authority with a new certificate 560) if the chain contains a requisite amount of certificates) and (LLOYD, Para. 0052);
“the particular Root certificate is a most recent Root certificate held by the client device” (LLOYD, Para. 0051) and (LLOYD, Para. 0044); and “the electronic server device implicitly or explicitly indicates, to the client device, the ordering among the one or more Root certificates in the temporal chain” (LLOYD, Para. 0052, a certificate containing a new public key for the root certificate authority is signed with the old private key) and (LLOYD, Para. 0044, a new certificate (which can be self-signed and has a more recent ValidFrom date and a new public key); (2) a new-with-old certificate; and (3) an old-with-new certificate. New-with-old and old-with-new are certificates that can be used to update a trust anchor). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling to incorporate the teachings of LLOYD to include the method of claim 20, wherein: said previous root certificate of the chain of Root certificates is an immediately previous one of the chain of Root certificates according to the ordering” (LLOYD, Para. 0051) and (LLOYD, Para. 0052); the particular Root certificate is a most recent Root certificate held by the client device” (LLOYD, Para. 0051) and (LLOYD, Para. 0044); and “the electronic server device implicitly or explicitly indicates, to the client device, the ordering among the one or more Root certificates in the temporal chain” (LLOYD) and (LLOYD, Para. 0044). Doing so would aid in updating certificates that have previously been issued server/client device and trust anchor certificates to autonomously handle pushed certificates, cross-signing with new chains, and a transition between old and new certificate chains and trust anchors (also referred to herein as root certificate authorities) (LLOYD, Para. 0015).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Stradling (US 2008/0155254 A1), hereinafter Stradling, in view of LLOYD et al. (US 2016/0315777 A1), hereinafter LLOYD, and further in view of Ignatchenko et al (US 2013/0346747 A1), hereinafter Ignatchenko.
Regarding Claim 7, the combination of Stradling in view of LLOYD does not explicitly teach the electronic device of claim 1, wherein the electronic device receives at least one invalid root certificate that occurs after a most recent additional root certificate, and wherein the processing electronics are further configured to: determine that the at least one invalid root certificate cannot be authenticated using the most recent additional root certificate; and restart the process from a most recently successfully authenticated additional root certificate.
However, Ignatchenko teaches “The electronic device of claim 3, wherein the electronic device receives at least one invalid root certificate that occurs after a most recent one of the additional root certificate, and wherein the processing electronics are further configured to: determine that the at least one invalid root certificate cannot be authenticated using the most recent additional root certificates” (Ignatchenko: Para. 0055 describes a process where verification may fail (i.e., receiving an invalid root certificate);
“and restart the process from the most recent one of the additional root certificates” (Ignatchenko: Para. 0055 describes the failure of the process for verifying root certificates. It is implied that this process is restarted in order to complete the verification of the root certificates). Stradling, LLOYD and Ignatchenko are considered to be analogous to the claim invention because they are in the same field of public key infrastructure (PKI) certificate management, particularly updating, distributing, and validating root certificates or trust anchors used to authenticate server certificates. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Stradling and LLOYD to incorporate the teachings of Ignatchenko to include the electronic device of claim 3, wherein the electronic device receives at least one invalid root certificate that occurs after a most recent one of the additional root certificate, and wherein the processing electronics are further configured to: determine that the at least one invalid root certificate cannot be authenticated using the most recent additional root certificates” (Ignatchenko: Para. 0055); and restart the process from the most recent one of the additional root certificates (Ignatchenko: Para. 0055). Doing so would aid to securely create new root certificates following the compromise of a current root certificate (Ignatchenko, para. 0009).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTOL-892.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6:00 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, Jorge L. Ortiz-Criado can be reached at (571)272-7624. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights