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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on January 23, 2026 has been being considered by the examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 18, 2026 has been entered.
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.
Claim 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Le Saint et al. (US 20180375663 A1 –hereinafter—"Le Saint”) in view of FAY (US 20200344052).
As per claim 1. Le Saint discloses a method comprising:
establishing, between a first device and a second device (Figure 2: Client computer 240 and server computer 280 and Similarly from Figure 3-6: Client computer as first device and server computer as second device),
a static key pair using a group generator ([0040] The Diffie-Hellman key exchange may not be based on any information previous stored at the first or second computer before the key exchange. For example, a Diffie-Hellman based algorithm, such as Elliptic-Curve Diffie-Hellman (ECDH) may be used to generate a shared secret from a private key of a first computer and a public key of a second computer. The examiner further notes the Diffie-Hellman (DH) key exchange is a protocol that allows two parties to securely establish a shared secret key over an insecure channel, using the principles of modular exponentiation and the discrete logarithm problem. "DH groups" are pre-defined, standardized sets of a prime number (𝑝) and a generator (𝑔) that ensure interoperability and security strength, with higher group numbers typically indicating stronger security due to larger keys. These groups are commonly used in protocols like TLS and IPsec to generate a shared secret for subsequent symmetric encryption) the static key pair comprising
a static public key and a static private key ([0028] A “static key pair” may include a public key (i.e., a “static public key”) and a private key (i.e., a “static private key”) maintained over a period of time. Typically, though not necessarily, a static private key may be stored securely, such as in a hardware security module (HSM) or secure element (SE). Typically, though not necessarily, a static public key may be bound to an identity through the use of a digital certificate. The static key pair may be of any suitable format, such as ECC or RSA);
the establishing of the static key pair comprising:
storing the static private key on the second device ([0028] A “static key pair” may include a public key (i.e., a “static public key”) and a private key (i.e., a “static private key”) maintained over a period of time. Typically, though not necessarily, a static private key may be stored securely, such as in a hardware security module (HSM) or secure element (SE). [0052] The server computer 280 can store a server static key pair 286 including a server static private key 282 and a server static public key 284. The server computer 280 can also store the server certificate 288. The server certificate 288 may include the server static public key 284 and a signature of a certificate authority for authentication of the server computer 288. The server static private key 282 and a server static public key 284 may be “static” in that they do not change over time, enabling the server computer 288 to be authenticated using the server certificate 288); and
generating, by the first device, the static public key ([0035] the static public key of a first computer is sent to a second computer in the clear (e.g., not encrypted) during a Diffie-Hellman key exchange. The first computer's public key may be static because it corresponds to a certificate stored thereon that is signed by a certificate authority. As such, the first computer may be identified and tracked by intercepting its communications based on an unencrypted public key sent during the Diffie-Hellman key exchange. [0095] In this message flow, the client computer 440 can initiate the establishment of secure communications. Prior to the message flow, the client computer 440 may store a client static key pair 446 including a client static private key 442 and a client static public key 444. The client computer may also store a client certificate 448 that is signed by a certificate authority and that includes the client static public key 444. The client computer 440 can also store the server certificate 488. In addition, the client computer 440 can store client payload data 452, which may be sensitive data);
computing, by the first and second devices, ephemeral key pairs based on the static key pair ([0027] An “ephemeral key pair” may include a public key (i.e., an “ephemeral public key”) and a private key (i.e., an “ephemeral private key) generated for use with a single transaction or other communication session. The ephemeral key pair may be of any suitable format, such as ECC or RSA. Typically, an ephemeral key pair may is deleted once the transaction or communication session has concluded);
establishing a shared session key based on the ephemeral key pairs ([0028] A “static key pair” may include a public key (i.e., a “static public key”) and a private key (i.e., a “static private key”) maintained over a period of time. Typically, though not necessarily, a static private key may be stored securely, such as in a hardware security module (HSM) or secure element (SE). Typically, though not necessarily, a static public key may be bound to an identity through the use of a digital certificate. The static key pair may be of any suitable format, such as ECC or RSA. [0034] A “session key” may include any key used to encrypt or decrypt data to be securely communicated. In some cases, a session key may be generated from a shared secret known both to a sending entity and a receiving entity. For example, the session key may be derived using a key derivation function and the shared secret);
transmitting, by the first device to the second device, a message comprising a certificate of the first device using the shared session key that has been established based on the ephemeral key pairs ([0151-0152] a request message transmitted by the client computer 640 at 607 that cannot be repudiated by the client computer 640 and a response message transmitted by the server computer 680 at 618 that cannot be repudiated by the server computer 680. The request message at 607 and the response message at 618 are non-traceable since they include one-time-use blinded public keys instead of static public keys. Furthermore, request and response message maintain perfect forward secrecy. The generation and format of the request and response messages are described in further detail below. The client computer 640 can initiate the establishment of secure communications. Prior to the message flow, the client computer 640 may store a client static key pair 646 including a client static private key 642 and a client static public key 644. The client computer may also store a client certificate 648 that is signed by a certificate authority and that includes the client static public key 644. The client computer 640 can also store the server certificate 688. In addition, the client computer 640 can store client payload data 652, which may be sensitive data).
Le Saint does not explicitly disclose the generated static privacy public key by multiplying the group generator by a modular multiplicative inverse of the static privacy private key modulo a group order and the computing of the ephemeral key pairs comprising generating, by the first device, a first public ephemeral key by multiplying the static privacy public key by a first private ephemeral key of the first device. Fey, in analogous art however, discloses the generated static privacy public key by multiplying the group generator by a modular multiplicative inverse of the static privacy private key modulo a group order ([0035] To establish such a secure communication channel there are different possibilities, depending on the infrastructure that is available to Alice and Bob. In most cases this will be a public key infrastructure (PKI) or they already have set up a password. In the first case (PKI) one or both parties have a private/public key pair and in many cases also some certificate (Cert) of their public key, signed by a trusted third party (TTP), such that everybody who also trusts the TTP is assured that a certified public key belongs to the corresponding party, which is also included in the certificate. For Alice, the private key is x, and the public key is X. For Bob, the private key is y, and the public key is Y. For public key algorithms, the fundamental building blocks are usually based on one or more mathematical groups, such as.sub.p the ring of integers modulo a prime p (or a ultiplicative subgroup of it) or a prime order subgroup of an elliptic curve E(.sub.z) over some field.sub.q with q either prime or a power of two. There are also other groups possible, but these are the most common ones used. Such groups usually have a generator G, such that all group elements can be uniquely represented as i.Math.G with some integer i smaller than the group order n=||=|G| (size of the group). [0040] The second point is then chosen in the same way with the following output of the pseudorandom function. For subgroups of .sub.p the numbers would be a longer output of the pseudorandom function, reduced modulo p and multiplied by the co-factor (if given, this would normally be written as exponentiation). See also Table 1 for static key values and 3 for ephemeral computed key vales); the computing of the ephemeral key pairs comprising generating, by the first device, a first public ephemeral key by multiplying the static privacy public key by a first private ephemeral key of the first device ([0033] The embodiments of key exchange protocols described herein has a similar communication footprint as a normal Diffie-Hellman key exchange (DH-KF) in its secret sharing phase but performs additional computations on each side. It combines an ephemeral key exchange with two semi-static key exchanges. Afterwards, these key exchange embodiments check to determine if the key exchange was correctly executed by using an explicit authentication and implied key confirmation. On top of this or instead, a password authentication can also be used in using two different methods. Every variant of the protocol only uses three steps or messages that get sent around, which could also include some so-called early messages, which have a security level between plain messages before the handshake and secured messages after the handshake. Several multiplications are needed to carry out the key exchange protocol that may be optimized by using pre-computation for the same bases. The usage of the private key(s) and the passwords are already protected against side-channel attacks by design. The embodiments described herein provide a technological advancement in security by improving various security properties as described above). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of generated static privacy public key disclosed by Le Saint to include generate static privacy public key by multiplying the group generator by a modular multiplicative inverse of the static privacy private key modulo a group order the computing of the ephemeral key pairs comprising generating, by the first device, a first public ephemeral key by multiplying the static privacy public key by a first private ephemeral key of the first device. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to advance a modular handshake for key agreement and optional authentication as suggested by FAY ([0006]).
As per claim 2. Le Saint in view of FAY discloses the method of claim 1, wherein the first device comprises an access control reader; and wherein the second device comprises a user device (Le Saint [0029] A “shared secret” may include any data value or other information known only to authorized parties in a secure communication. A shared secret can be generated in any suitable manner, from any suitable data. For example, a Diffie-Hellman based algorithm, such as Elliptic-Curve Diffie-Hellman (ECDH) may be used to generate a shared secret from a private key and a public key. For example, a first computer may generate a first key pair include a first public key and a first private key. A second computer may generate a second key pair including a second public key and a second private key. The first computer may generate a shared secret using the second public key of the second computer and the first private key of the first computer. The second computer may generate the same shared secret using the first public key of the first computer and the second private key of the second computer. The first computer and the second computer may both use the shared secret to generate a session key. [0034] A “session key” may include any key used to encrypt or decrypt data to be securely communicated. In some cases, a session key may be generated from a shared secret known both to a sending entity and a receiving entity. For example, the session key may be derived using a key derivation function and the shared secret).
As per claim 3: Le Saint in view of FAY discloses the method of claim 1, wherein establishing the static privacy key pair comprises performing Diffie-Hellman key exchange to exchange public ephemeral keys of the ephemeral key pairs (Le Saint [0029;0040] a Diffie-Hellman based algorithm, such as Elliptic-Curve Diffie-Hellman (ECDH))
As per claim 4: Le Saint in view of FAY discloses the method of claim 1, further comprising: prior to the first device identifying itself to the second device, generating, by the first device, the first ephemeral key pair of the ephemeral key pairs, the first ephemeral key pair comprising the first public ephemeral key and a first private ephemeral key (Le Saint [0054] At 202, the client computer 240 can determine a client ephemeral public key using the client ephemeral private key. The client ephemeral private key and the client ephemeral public key can form a key pair for use in public key cryptography); and generating, by the second device, a second ephemeral key pair of the ephemeral key pairs, the second ephemeral key pair comprising a third public ephemeral key and a fourth private ephemeral key (Le Saint [0066] At 214, after determining the second shared secret and the second session key, the client computer 240 can zeroize the client ephemeral private key. That is, the client computer 240 can delete the client ephemeral private key such that it cannot be recovered later. Furthermore, even if the client ephemeral private key were compromised and obtained by a third party in the short period of time prior to it being zeroized, the third party would not be able to decrypt any other communications using the client ephemeral private key since this client ephemeral private key was only used to decrypt this particular response message).
As per claim 5: Le Saint in view of FAY discloses the method of claim 4, wherein generating the first ephemeral key pair comprises:
retrieving the static privacy public key of the static privacy key pair (Le Saint [0065] At 213 the client computer 240 can determine the second shared secret using the client ephemeral private key and the server blinded public key. The second shared secret determined by the client computer 240 at 213 may be the same as the second shared secret determined by the server computer 280 at 209 using the client ephemeral public key, the server blinding factor, and the server static private key 284. The client computer 240 may also determine the same second session key (as also determined by the server computer 280) using a key derivation function and the second shared secret)); and
computing the first public ephemeral key as a function of the static privacy public key and the first private ephemeral key (Le Saint [0066] At 214, after determining the second shared secret and the second session key, the client computer 240 can zeroize the client ephemeral private key. That is, the client computer 240 can delete the client ephemeral private key such that it cannot be recovered later. Furthermore, even if the client ephemeral private key were compromised and obtained by a third party in the short period of time prior to it being zeroized, the third party would not be able to decrypt any other communications using the client ephemeral private key since this client ephemeral private key was only used to decrypt this particular response message).
As per claim 6: Le Saint in view of FAY discloses the method of claim 5, wherein the function comprises an Elliptic-curve Diffie-Hellman (ECDH) function (Le Saint [0029;0040] a Diffie-Hellman based algorithm, such as Elliptic-Curve Diffie-Hellman (ECDH))
As per claim 7: Le Saint in view of FAY discloses the method of claim 4, further comprising: computing, by the first device, the shared session key as a function of the third public ephemeral key and the first private ephemeral key (FAY [0027] Various embodiments are described, wherein: computing the shared secret Z based upon the ephemeral shared secret Z′, the ephemeral public key R, the ephemeral public key S, the semi-static shared secret R′ and the second party's public key Y is done by hashing the ephemeral shared secret Z′, the semi-static shared secret R′, the ephemeral public key R, the ephemeral public key S and the second party's public key Y; computing a key K based upon the shared secret Z is done by hashing a first constant value followed by the shared secret Z; computing a new value for the shared secret Z based upon the shared secret Z is done by hashing a first constant value followed by the shared secret Z; and compute a check value cB based upon the key K, the ephemeral public key R and the ephemeral public key S is done by computing a MAC over a third constant value, the ephemeral public key R, the ephemeral public key S using the key K).
As per claim 8: Le Saint in view of FAY discloses the method of claim 4, further comprising:
computing, by the second device, the shared session key as a function of the first public ephemeral key and a value derived from the fourth private ephemeral key and the static privacy private key (FAY [0032] These security properties may include: perfect forward secrecy; forward deniability; key compromise impersonation resistance; security against unknown key share attack; explicit authentication; key confirmation; (session-)key independence key separation (different keys for encryption and MACing); extendibility e.g., against DOS attacks . . . (e.g., using cookies, . . . ); support of early messages; small communication footprint; support of public-key and/or password authentication, different security/performance trade-offs for authentication by password; and implicit side-channel protection.)..
As per claim 9: Le Saint in view of FAY discloses the method of claim 8, further comprising computing the value by multiplying the fourth private ephemeral key by the static privacy private key modulo a group order (Le Saint [0203] At 904, the client computer can determine a first intermediate shared secret (“Z_1”). The first intermediate shared secret can be based on an x-coordinate of an elliptic curve Diffie-Hellman shared resulting point based on the client blinding factor and the server authentication public (Z_1=[d_bc]. Q_s_{n}).
As per claim 10: Le Saint in view of FAY discloses the method of claim 1, further comprising: generating, by the second device, the static privacy key pair, the static privacy public key being computed based on a group order (Le Saint [0245] At 1004, the client computer can determine a first intermediate shared secret (“Z_1”). The first intermediate shared secret can be based on an x-coordinate of an elliptic curve Diffie-Hellman shared resulting point based on the client blinding factor and the server authentication public (Z_1=[d_bc]. Q_s_{n}).
As per claim 11. Le Saint in view of FAY discloses the method of claim 1, further comprising: computing, by the first device, the shared session key by multiplying a public ephemeral key of the second device by a private ephemeral key of the first device (Le Saint [0228] At 929, the client computer can validate that the blinded server public key (“Q_bs”) belongs to the elliptic curve domain. [0229] At 930, the client computer can determine the second intermediate shared secret (“Z”) using the client blinding factor (“d_bc”) and the blinded server public key (“Q_bs”) (Z=[d_bc]. Q_bs). [0230] At 931, the client computer can determine the server identifier for this communication session (“sID_s”) using the blinded server public key (“Q_bs”). The server identifier (“sID_s”) may be based on the elliptic curve x-coordinate of the blinded server public key (“Q_bs”) (sID_s=x-coord (Q_bs)).
As per claim 12: Le Saint in view of FAY discloses the method of claim 1, further comprising: computing, by the second device, the shared session key by computing a product h of an ephemeral private key of the second device by the static privacy private key and multiplying an ephemeral public key of the first device by h (Le Saint [0231] At 932, the client computer can determine the second session key (“sk_s|sk_c”) using a key derivation function based on the second intermediate shared secret (“Z”), the server identifier (“sID_s”) for this communication session, and the client identifier (“sID_c”) for this session (sk_s|sk_c=KDF (Z, sID_s, sID_c)). [0232] At 933, the client computer can zeroize the second intermediate shared secret (“Z”) and the client blinding factor (“d_bc”).
As per claim 13: Le Saint in view of FAY discloses the method of claim 1, further comprising: generating an authentication message by the second device using the shared session key (FAY [0032] These security properties may include: perfect forward secrecy; forward deniability; key compromise impersonation resistance; security against unknown key share attack; explicit authentication; key confirmation; (session-)key independence key separation (different keys for encryption and MACing); extendibility e.g., against DOS attacks . . . (e.g., using cookies, . . . ); support of early messages; small communication footprint; support of public-key and/or password authentication, different security/performance trade-offs for authentication by password; and implicit side-channel protection).
As per claim 14: Le Saint in view of FAY discloses the method of claim 1, wherein the shared session key, computed by the first and second devices, is of a same value (FAY [0032] These security properties may include: perfect forward secrecy; forward deniability; key compromise impersonation resistance; security against unknown key share attack; explicit authentication; key confirmation; (session-)key independence key separation (different keys for encryption and MACing); extendibility e.g., against DOS attacks . . . (e.g., using cookies, . . . ); support of early messages; small communication footprint; support of public-key and/or password authentication, different security/performance trade-offs for authentication by password; and implicit side-channel protection).
As per claims 15-19: claims 15-19 are directed to a system comprising: one or more processors coupled to a memory comprising non-transitory computer instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, having substantially similar corresponding limitation features of claims 1-5 respectively and therefore claims 15-19 are rejected with the same rationale given above to reject claims 1-5.
As per claim 20: claim 20 is directed to a non-transitory computer readable medium comprising non-transitory computer-readable instructions that, when executed by one or more processors, configure the one or more processors to perform operations having substantially similar corresponding limitation features of claim 1 and therefore claim 20 is rejected with the same rationale given above to reject claim 1.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408