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 .
Election/Restrictions
Restriction to one of the following inventions is required under 35 U.S.C. 121:
I. Claims 1-15, drawn to Asymmetric Key Encryption, classified in H04L 9/0825.
II. Claims 16-20, drawn to Authentication involving digital signatures, classified in H04L 9/3249.
Inventions I and II are related as combination and subcombination. Inventions in this relationship are distinct if it can be shown that (1) the combination as claimed does not require the particulars of the subcombination as claimed for patentability, and (2) that the subcombination has utility by itself or in other combinations (MPEP § 806.05(c)). In the instant case, the combination as claimed does not require the particulars of the subcombination as claimed because while both groups of inventions involve authentication tunneling, group I involves the use of asymmetric keys while group II does not. The subcombination has separate utility such as asymmetric key encryption, classified in H04L 9/0825.
The examiner has required restriction between combination and subcombination inventions. Where applicant elects a subcombination, and claims thereto are subsequently found allowable, any claim(s) depending from or otherwise requiring all the limitations of the allowable subcombination will be examined for patentability in accordance with 37 CFR 1.104. See MPEP § 821.04(a). Applicant is advised that if any claim presented in a divisional application is anticipated by, or includes all the limitations of, a claim that is allowable in the present application, such claim may be subject to provisional statutory and/or nonstatutory double patenting rejections over the claims of the instant application.
During a telephone conversation with Mathew Montgomery on October 28, 2025 a provisional election was made with traverse to prosecute the invention of group I, claims 1-15. Affirmation of this election must be made by applicant in replying to this Office action. Claims 16-20 are withdrawn from further consideration by the examiner, 37 CFR 1.142(b), as being drawn to a non-elected invention.
The examiner has required restriction between product or apparatus claims and process claims. Where applicant elects claims directed to the product/apparatus, and all product/apparatus claims are subsequently found allowable, withdrawn process claims that include all the limitations of the allowable product/apparatus claims should be considered for rejoinder. All claims directed to a nonelected process invention must include all the limitations of an allowable product/apparatus claim for that process invention to be rejoined.
In the event of rejoinder, the requirement for restriction between the product/apparatus claims and the rejoined process claims will be withdrawn, and the rejoined process claims will be fully examined for patentability in accordance with 37 CFR 1.104. Thus, to be allowable, the rejoined claims must meet all criteria for patentability including the requirements of 35 U.S.C. 101, 102, 103 and 112. Until all claims to the elected product/apparatus are found allowable, an otherwise proper restriction requirement between product/apparatus claims and process claims may be maintained. Withdrawn process claims that are not commensurate in scope with an allowable product/apparatus claim will not be rejoined. See MPEP § 821.04. Additionally, in order for rejoinder to occur, applicant is advised that the process claims should be amended during prosecution to require the limitations of the product/apparatus claims. Failure to do so may result in no rejoinder. Further, note that the prohibition against double patenting rejections of 35 U.S.C. 121 does not apply where the restriction requirement is withdrawn by the examiner before the patent issues. See MPEP § 804.01.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Lindemann et al (US PGPub No: 2020/0280550) in view of Hiltgen (US PGPub No: 2003/0177392), hereafter referred to as Lindemann and Hiltgen, respectively.
With regards to claim 1, Lindemann teaches through Hiltgen, a method for authentication tunneling at a remote machine, comprising: transmitting an authentication prompt to a client machine via an encrypted channel between a first authenticator application running on the remote machine and a second authenticator application running on the client machine, the authentication prompt associated with accessing one or more resources via an identity management system (Lindemann teaches a client device with an old authenticator (Aold) establishing a secure connection/channel with a new client device its new authenticator (Anew); see paragraphs 33-34 and Fig. 2 and Fig. 3, Lindemann. The user can enroll to join a cloud service partition (request to access resource) and be asked/prompted to enter a value such as their email address; see paragraphs 185-192, Lindemann);
receiving, from the client machine via the encrypted channel, a first authentication response comprising user verification data associated with a user of the client machine, an identifier of the client machine, and a first digital signature of the second authenticator application running on the client machine (Lindemann teaches using the secure connection to send registration data of Aold to Anew; see paragraph 39, Lindemann. The registration data includes usernames (client machine id), unique codes associated with the user of Aold, the unique code also being referred to as AppID (user verification data associated with the user); see paragraph 39, Lindemann. Lindemann also supports generating and sending from Aold, a signed authorization object of the tuple of the AAID, key, and the AppID; see paragraph 41, Lindemann);
generating, by the first authenticator application running on the remote machine, a second authentication response comprising the user verification data, the identifier of the client machine, an identifier of the remote machine, the first digital signature of the second authenticator application running on the client machine, and a second digital signature of the first authenticator application running on the remote machine (Lindemann further teaches upon receipt, the signature can be verified using a key, to and identifying the user’s account/name, and the AppID; see paragraph 42, Lindemann. This transaction can occur between the Aold and the Anew; see paragraph 43, Lindemann. See Hiltgen below for double signatures);
and transmitting the second authentication response to an authentication endpoint of the identity management system (see Hiltgen below).
While Lindemann teaches authenticating a resource access request, Lindemann does not explicitly support double signatures and transmitting a response with the double signature to an authentication endpoint of the identity management system.
In the same field of endeavor, Hiltgen also teaches a client connecting to a server infrastructure to retrieve an entrance web page hosted by an application server (resource request); see paragraph 90, Hiltgen. The client loads an applet from the entrance web page, via an SSL encrypted channel, to access a smart card and open tokens, keys, and certificates; see paragraphs 91-92, Hiltgen. Hiltgen further details an encrypted channel being set and then used to transmit information required for authenticating the client side; see paragraphs 20, 34, and 96, Hiltgen. The client and the server can possess the same secret; see paragraph 96, Hiltgen. In particular, Hiltgen explains support for double signatures, when a first signature can be signed with a second signature and transmitted over the secure communication channel back to the application server (transmit a response with a double signature to an authentication endpoint of the identity management system); see paragraph 23, Hiltgen. Note signatures use keys, so a second signature uses second key; see paragraph 13, Hiltgen.
By using a secure channel and two authentication steps (double signatures) with two keys, authentication security is increased; see paragraph 13, Hiltgen. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Hiltgen with those of Lindemann, to increase authentication security; see paragraph 13, Hiltgen.
With regards to claim 2, Lindemann teaches through Hiltgen, the method further comprising: establishing the encrypted channel between the remote machine and the client machine using a secret key accessible by the client machine, wherein the authentication prompt and the first authentication response are encrypted with the secret key
Hiltgen details an encrypted channel being set and then used to transmit information required for authenticating the client side; see paragraphs 20, 34, and 96, Hiltgen. The encrypted channel can use a secret key; see paragraph 19, Hiltgen. Hiltgen further explains support for double signatures, when a first signature can be signed with a second signature and transmitted over the secure communication channel back to the application server; see paragraph 23, Hiltgen.
By using a secure channel and two authentication steps (double signatures) with two keys, authentication security is increased; see paragraph 13, Hiltgen. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Hiltgen with those of Lindemann, to increase authentication security; see paragraph 13, Hiltgen.
With regard to claims 3 and 14, Lindemann teaches through Hiltgen, the method further comprising: establishing a connection between a remote client module of the client machine and a remote connection module of the remote machine; and exchanging the secret key in accordance with the connection, wherein establishing the encrypted channel using the secret key is based at least in part on the secret key being exchanged
Hiltgen details an encrypted channel being set and then used to transmit information required for authenticating the client side; see paragraphs 20, 34, and 96, Hiltgen. The encrypted channel can use a secret key; see paragraph 19, Hiltgen. The client and the server can possess the same secret; see paragraph 96, Hiltgen. Hiltgen further explains support for double signatures, when a first signature can be signed with a second signature and transmitted over the secure communication channel back to the application server; see paragraph 23, Hiltgen.
By using a secure channel and two authentication steps (double signatures) with two keys, authentication security is increased; see paragraph 13, Hiltgen. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Hiltgen with those of Lindemann, to increase authentication security; see paragraph 13, Hiltgen.
With regard to claims 4 and 15, Lindemann teaches through Hiltgen, the method further comprising: establishing the encrypted channel via an authentication management service having a respective connection to the client machine and the remote machine (Lindemann teaches a client device with an old authenticator (Aold) establishing a secure connection/channel with a new client device its new authenticator (Anew); see paragraphs 33-34 and Fig. 2 and Fig. 3, Lindemann. A relying party with a secure transaction service can provide secure transactions between Aold and Anew as well; see Figure 3 and paragraph 35, Lindemann).
With regard to claim 5, Lindemann teaches through Hiltgen, the method further comprising: obtaining a set of credentials associated with the user of the client machine; and establishing the encrypted channel using the set of credentials (Lindemann teaches setting a secure protocol on the a set channel between Aold and Anew by having Aold and Anew share registration data and key pairs; see paragraph 34, Lindemann).
With regard to claim 6, Lindemann teaches through Hiltgen, the method wherein the set of credentials are obtained from an authentication management service based at least in part on a verification of the set of credentials with the authentication management service, the authentication management service having a respective connection to the client machine and the remote machine (Lindemann teaches setting a secure protocol on the a set channel between Aold and Anew by having Aold and Anew share registration data and key pairs; see paragraphs 33-34 and Fig. 2 and Fig. 3, Lindemann. A relying party with a secure transaction service can provide secure transactions between Aold and Anew as well; see Figure 3 and paragraph 35, Lindemann).
With regard to claim 7, Lindemann teaches through Hiltgen, the method wherein the encrypted channel between the first authenticator application and the second authenticator application comprises a secure shell (SSH) channel or a virtual channel that is established using a remote connection module of the remote machine (Lindemann supports SSL/TLS, a secure virtual connection; see paragraph 33, Lindemann).
With regard to claim 8, Lindemann teaches through Hiltgen, the method further comprising: transmitting, to the authentication endpoint of the identity management system, a request to access the one or more resources via the identity management system; and receiving, from the authentication endpoint of the identity management system, the authentication prompt associated with accessing the one or more resources via the identity management system (The user can enroll to join a cloud service partition (request to access resource) or access an App (also a request to access a resource; see paragraph 233) and be asked/prompted to enter a value such as their email address; see paragraphs 185-192, Lindemann).
With regard to claim 9, Lindemann teaches through Hiltgen, the method further comprising: receiving, from the authentication endpoint of the identity management system, an indication that the remote machine is authorized to access the one or more resources via the identity management system (Lindemann teaches Anew being authorized access that Aold has; see paragraph 51 and Figure 5, Lindemann).
With regard to claim 10, Lindemann teaches through Hiltgen, the method further comprising: transmitting, to a remote connection endpoint of the identity management system, a request to register a remote connection between the remote machine and a client machine, wherein authorization of the remote machine is based at least in part on verification of the second authentication response and the remote connection
Lindemann teaches Anew being authorized access that Aold has; see paragraph 51 and Figure 5, Lindemann. Lindemann however doesn’t support second authentication response (e.g. double signature).
Hiltgen explains support for double signatures, when a first signature can be signed with a second signature and transmitted over the secure communication channel back to the application server (transmit a response with a double signature to an authentication endpoint of the identity management system); see paragraph 23, Hiltgen. Note signatures use keys, so a second signature uses second key; see paragraph 13, Hiltgen.
By using a secure channel and two authentication steps (double signatures) with two keys, authentication security is increased; see paragraph 13, Hiltgen. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Hiltgen with those of Lindemann, to increase authentication security; see paragraph 13, Hiltgen.
With regard to claim 11, Lindemann teaches through Hiltgen, the method for authentication tunneling at a client machine, comprising: establishing an encrypted channel between a first authenticator application running on a remote machine and a second authenticator application running on the client machine, wherein the encrypted channel is established using a secret key accessible by the client machine; receiving an authentication prompt from the remote machine via the encrypted channel, the authentication prompt associated with accessing one or more resources via an identity management system, wherein the authentication prompt is encrypted with the secret key associated with the client machine (Lindemann teaches a client device with an old authenticator (Aold) establishing a secure connection/channel with a new client device its new authenticator (Anew); see paragraphs 33-34 and Fig. 2 and Fig. 3, Lindemann. The user can enroll to join a cloud service partition (request to access resource) and be asked/prompted to enter a value such as their email address; see paragraphs 185-192, Lindemann. Private/secret key is supported for the signing; see paragraphs 41-41, Lindemann);
obtaining user verification data from a user of the client machine in accordance with the authentication prompt, wherein the user verification data is obtained using the second authenticator application running on the client machine (Lindemann teaches using the secure connection to send registration data of Aold to Anew; see paragraph 39, Lindemann. The registration data includes usernames (client machine id), unique codes associated with the user of Aold, the unique code also being referred to as AppID (user verification data associated with the user); see paragraph 39, Lindemann. Lindemann also supports generating and sending from Aold, a signed authorization object of the tuple of the AAID, key, and the AppID; see paragraph 41, Lindemann);
and transmitting, to the remote machine via the encrypted channel, a first authentication response comprising the user verification data associated with the user of the client machine, an identifier of the client machine, and a first digital signature of the second authenticator application running on the client machine, wherein the first authentication response is encrypted with the secret key associated with the client machine (see Hiltgen below).
While Lindemann teaches authenticating a resource access request, Lindemann does not explicitly support double signatures and transmitting a response encrypted with a secret key (i.e. double signature).
In the same field of endeavor, Hiltgen also teaches a client connecting to a server infrastructure to retrieve an entrance web page hosted by an application server (resource request); see paragraph 90, Hiltgen. The client loads an applet from the entrance web page, via an SSL encrypted channel, to access a smart card and open tokens, keys, and certificates; see paragraphs 91-92, Hiltgen. Hiltgen further details an encrypted channel being set and then used to transmit information required for authenticating the client side; see paragraphs 20, 34, and 96, Hiltgen. The client and the server can possess the same secret; see paragraph 96, Hiltgen. In particular, Hiltgen explains support for double signatures (encrypting signed data with a secret key), when a first signature can be signed with a second signature and transmitted over the secure communication channel back to the application server; see paragraphs 19, 23, and 64, Hiltgen. Note signatures use keys, so a second signature uses second key; see paragraph 13, Hiltgen.
By using a secure channel and two authentication steps (double signatures) with two keys, authentication security is increased; see paragraph 13, Hiltgen. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Hiltgen with those of Lindemann, to increase authentication security; see paragraph 13, Hiltgen.
With regard to claim 12, Lindemann teaches through Hiltgen, the method wherein obtaining the user verification data comprises: obtaining the user verification data via one or more sensors or components integrated with the second authenticator application running on the client machine, wherein the user verification data includes biometric information associated with the user of the client machine (Lindemann supports using sensors for capturing biometric verification data; see paragraph 56, Lindemann).
With regard to claim 13, Lindemann teaches through Hiltgen, the method further comprising: transmitting, to an authentication endpoint of the identity management system via the remote machine, a second authentication response comprising the user verification data, the identifier of the client machine, an identifier of the remote machine, the first digital signature generated by the second authenticator application running on the client machine, and a second digital signature generated by the first authenticator application running on the remote machine
Hiltgen explains support for double signatures (encrypting signed data with a secret key), when a first signature can be signed with a second signature and transmitted over the secure communication channel back to the application server; see paragraphs 19, 23, and 64, Hiltgen. Note signatures use keys, so a second signature uses second key; see paragraph 13, Hiltgen.
By using a secure channel and two authentication steps (double signatures) with two keys, authentication security is increased; see paragraph 13, Hiltgen. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Hiltgen with those of Lindemann, to increase authentication security; see paragraph 13, Hiltgen.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AZIZUL Q CHOUDHURY whose telephone number is (571)272-3909. The examiner can normally be reached M-F.
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, EMMANUEL MOISE can be reached at (571) 272-3865. 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.
/AZIZUL CHOUDHURY/Primary Examiner, Art Unit 2455