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 .
This action is in response to the claims filed 6/05/2026. Claims 1-22 are pending. Claims 1 (a method) and 16 (a machine) are independent.
Response to Arguments
Applicant’s arguments, see page 9, filed 6/05/2026, with respect to the rejection(s) of claim(s) 1-5, 10, and 11 under Stapleton 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 Stapleton, US 12,231,584 (filed 2022), in view of Campbell et al., RFC 8705 – Oauth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-22 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.
Claims 1 and 16 now require:
“intercepting the client request at a perimeter guard system transparently, without performing decryption”
However, Applicant’s specification and the claims detail that the perimeter guard system performs encrypted communication, and thereby performs decryption: “the second session comprising forming a mutually authenticated transport layer security (TLS) session”. See also ¶ 20 of Applicant’s specification.
It is unclear what “transparently, without performing decryption” requires when the claim separately requires performing decryption and the request is not required to be encrypted.
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.
Claim(s) 1-5, 10, 11, 15-18, and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stapleton, US 12,231,584 (filed 2022), in view of Campbell et al., RFC 8705 – Oauth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
As to claims 1 and 16, Stapleton discloses a method/machine comprising:
communicating, by a client device, a client request for accessing the protected web resource; (“The application circuit 122 can be used to execute one or more applications or software on the subscriber computing system 106 for which communication with the relying party computing system 108 is needed. For example, the application circuit 122 can execute one or more applications that generate data, information, messages, and so on to be sent to the relying party computing system 108.” Stapleton col. 4, ln. 38. “in response to a request received from the subscriber computing system 106.” Stapleton col. 6 ll. 63.)
intercepting the client request at a perimeter guard systemtransparaently, without performing decryption; (“At 205, the relying party computing system 108 sends to the subscriber computing system 106 via the network 110, an OID of the relying party 104. In some examples, the relying party computing system 108 sends the OID of the relying party 104 to the subscriber computing system 106 in response to a request received from the subscriber computing system 106.” Stapleton col. 6, ll. 59+. Relying party system 106)
initiating a first session between the client device and an authentication server; (“at 220, the subscriber computing system 106 sends, via the network 110, a request for a certificate (e.g., a digital certificate) to the CA computing system 105, where the request includes the OID of the relying party 104 received at 210.” Stapleton col. 7, ll. 53+)
authenticating the client device at the authentication server during the first session; (“To generate a digital certificate, the CA computing system 105 first verifies the identity of the subscriber 102 that is to be associated with the public key of the subscriber 102 on the digital certificate. To verify the identity of a subscriber 102, the identity verification circuit 160 receives information from the subscriber computing system 106 regarding the identity of the subscriber 102.” Stapleton col. 6, ll. 8+)
the authentication token storing the certificate hash (a signature is a hash. “At 235, the CA computing system 105 generates the certificate by signing the TBS certificate with the private signature key of the CA 103 or the CA computing system 105.” Stapleton Col. 8, ln. 17)
in response to authenticating, associating an authentication token with a first cryptographic signature; (“the CA computing system 105 binds or wraps the OID of the replying party 102 to the certificate of the subscriber 102 by digitally signing the certificate so that the OID of the relying party 102, along with other information included in the certificate, cannot be changed unless a new certificate is used by the CA computing system 105.” Stapleton col. 8, ll. 24+. A signature. “the relying party computing system 108 signs each of at least one OID of the relying party 104 with a private key of the relying party 104, and then the signed at least one OID of the relying party 104 is sent to the subscriber computing system 106 at 205.” Stapleton col. 7, ll. 24+. Another signature.)
communicating the authentication token to the client device; (“At 240, the CA computing system 105 sends, via the network 110 to the subscriber computing system 106, the certificate, which the subscriber computing system 106 receives at 245.” Stapleton col. 8, ll. 64+)
initiating a second session between the client device and the perimeter guard system using the authentication token; and (“At 310, the subscriber computing system 106 sends the certificate with the public key and the OID (e.g., at least one OID) to the relying party 104. At 320, the relying party computing system 108 receives the certificate with the public key and the OID (e.g., at least one OID) of the relying party 104. An example of the certificate is shown and described relative to FIG. 4. The subscriber computing system 106 may send a certificate in a communication request e.g., Transport Layer Security (TLS) to the relying party computing system 108.” Stapleton col. 9, ll. 15+)
the second session comprising forming a mutually authenticated transport layer security (TLS) session, (“The subscriber computing system 106 may send a certificate in a communication request e.g., Transport Layer Security (TLS) to the relying party computing system 108.” Stapleton col. 9, ln. 20) obtaining a TLS peer certificate, fingerprinting the TLS peer certificate using the one-way hash function, and generating a second certificate hash (“At 330, the relying party computing system 108 authenticates the certificate of the subscriber 102 using a public key of the CA 103. For example, the relying party computing system 108 can obtain a CA certificate of the CA 103, where the CA certificate contains a public key of the CA 103. The relying party computing system 108 can verify a signature of the CA 103 in the certificate using the public key of the CA 103,” Stapleton col. 9, ln. 25)
based on the authentication token, (“At 330, the relying party computing system 108 authenticates the certificate of the subscriber 102 using a public key of the CA 103…. ” Stapelton col. 9, ll. 25+) allowing the client device to access the protected web resource. (“The communications at 350 and 360 can be performed for at least one of 1) one or more applications on the relying party computing system 108” Stapleton col. 10, ll. 34+)
only when the second certificate hash matches the certificate hash stored in the authentication token.
(“At 330, the relying party computing system 108 authenticates the certificate of the subscriber 102 using a public key of the CA 103. For example, the relying party computing system 108 can obtain a CA certificate of the CA 103, where the CA certificate contains a public key of the CA 103. The relying party computing system 108 can verify a signature of the CA 103 in the certificate using the public key of the CA 103,” Stapleton col. 9, ln. 25. After verifying the signature: “At 350 and 360, in response to authenticating the OID in the certificate at 340, the relying party computing system 108 and the subscriber computing system 106 communicate with each other using the public key of the subscriber 102 included in the certificate.” Stapleton col. 10, ln. 5)
Stapleton does not disclose:
obtaining, by the authentication server, a TLS peer certificate from the first session, fingerprinting the TLS peer certificate using a one-way hash function, and generating a certificate hash;
Campbell discloses:
initiating a first session between the client device and an authentication server; (“The client makes an HTTPS POST request to the authorization server” Campbell § 1)
authenticating the client device at the authentication server during the first session; (“In order to utilize TLS for OAuth client authentication, the TLS connection between the client and the authorization server have been established or re-established with mutual-TLS X.509 certificate authentication (i.e., the client Certificate and CertificateVerify messages are sent during the TLS handshake).” Campbell § 2)
obtaining, by the authentication server, a TLS peer certificate from the first session, fingerprinting the TLS peer certificate using a one-way hash function, and generating a certificate hash; (“Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource, such as embedding the certificate hash in the issued access token directly,” Campbell § 3)
in response to authenticating, associating an authentication token with a first
communicating the authentication token to the client device; (“In the response, the authorization server issues an access token to the client.” Campbell § 1)
initiating a second session between the client device and the perimeter guard system using the authentication token, the second session comprising forming a mutually authenticated transport layer security (TLS) session, obtaining a TLS peer certificate, fingerprinting the TLS peer certificate using the one-way hash function, and generating a second certificate hash; and (“The protected resource obtain, from its TLS implementation layer, the client certificate used for mutual TLS and verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt be rejected with an error” Campbell § 3)
based on the authentication token, allowing the client device to access the protected web resource only when the second certificate hash matches the certificate hash stored in the authentication token. (“The protected resource obtain, from its TLS implementation layer, the client certificate used for mutual TLS and verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt be rejected with an error” Campbell § 3).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have modify Stapelton with Campbell by utilizing the standard of Campbell to issue a token from an authentication authority for communication with a relying party. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Stapleton with Campbell in order to provide certificate-bound access tokens which prevents use or reply of stolen access tokens, Campbell § 1, while utilizing a standards based authentication mechanism allowing interfacing with a wider variety of systems and allowing off the shelf implementations to be utilized for ease of implementation.
As to claim 2, Stapleton discloses the method/machine of claims 1 and further discloses:
wherein prior to initiating the first session, redirecting the client device to the authentication server disposed separately from the perimeter guard system when an authentication token is not present in the client request. (note that this does not require the HTTP redirect discussed in Applicant’s specification ¶ 52)
(no token results in contacting the CA “At 205, the relying party computing system 108 sends to the subscriber computing system 106 via the network 110, an OID of the relying party 104. In some examples, the relying party computing system 108 sends the OID of the relying party 104 to the subscriber computing system 106 in response to a request received from the subscriber computing system 106.” Stapleton col. 6, ll. 59+.
with token “At 310, the subscriber computing system 106 sends the certificate with the public key and the OID (e.g., at least one OID) to the relying party 104. At 320, the relying party computing system 108 receives the certificate with the public key and the OID (e.g., at least one OID) of the relying party 104…. The communications at 350 and 360 can be performed for at least one of 1) one or more applications on the relying party computing system 108” Stapleton cols. 9-10).
As to claim 3, Stapleton discloses the method/machine of claims 1 and further discloses:
wherein intercepting is performed at a request proxy of the perimeter guard system. (Stapleton col. 6, ll. 59+. Relying party system 106 as cited in claim 1. The proxy is a software element of the perimeter guard system and is not structurally distinct. Since no further functionality is claimed, claim 3 is similar in scope to claim 1.)
As to claims 4 and 18, Stapleton discloses the method/machine of claims 1 and 16 and further discloses:
wherein initiating a second session comprises initiating a second session having a second cryptographic signature and (“the relying party computing system 108 signs each of at least one OID of the relying party 104 with a private key of the relying party 104, and then the signed at least one OID of the relying party 104 is sent to the subscriber computing system 106 at 205.” Stapleton col. 7, ll. 24+. “At 310, the subscriber computing system 106 sends the certificate with the public key and the OID (e.g., at least one OID) to the relying party 104. At 320, the relying party computing system 108 receives the certificate with the public key and the OID (e.g., at least one OID) of the relying party 104. An example of the certificate is shown and described relative to FIG. 4. The subscriber computing system 106 may send a certificate in a communication request e.g., Transport Layer Security (TLS) to the relying party computing system 108.” Stapleton col. 9, ll. 15+)
wherein allowing the client device to access the protected web resource comprises allowing the client device to access based on comparing the first cryptographic signature and the second cryptographic signature. (“At 340, the relying party computing system 108 authenticates the OID included in the certificate to determine whether the OID included in the certificate is an OID of the relying party 104.” Stapleton col. 9, ll. 39+)
As to claim 5, Stapleton discloses the method/machine of claims 1 and further discloses:
wherein initiating a second session comprises initiating a second session comprising a second cryptographic signature and comparing the first cryptographic signature and the second cryptographic signature, (Stapleton col. 7, ll. 24+, Stapleton col. 9, ll. 15+)
wherein the first cryptographic signature and the second cryptographic signature matches. (Stapleton col. 9, ll. 39+)
As to claim 10, Stapleton discloses the method/machine of claims 1 and further discloses:
wherein during authenticating, generating the authentication token comprises determining a policy and associating the policy with the authentication token. (“The extension 480 includes the at least one OID (e.g., at least one RPOID 482) of the relying party 104. For example, the at least one POID 482 can be one OID identifying one or more of the relying party 104, the relying party computing system 108, or an application on the relying party computing system 108. In some examples, the at least one RPOID 482 can be multiple RPOIDs each identifying a separate application on the relying party computing system 108.” (Stapleton col. 13, ll. 25+).
As to claim 11, Stapleton discloses the method/machine of claims 1 and further discloses:
wherein generating the authentication token comprises generating a token accessor. (“The extension 480, which can include one or more X.509 v3 extensions, includes at least one certificate policy 481 for using the certificate 400 (which can be a link such as an Uniform Resource Locator (URL) or an object identifier),” Stapleton col. 13, ll. 8+)
As to claim 15, Stapleton in view of Campbell discloses the method/machine of claims 16 and further discloses:
wherein initiating a first session comprises forming a first mutually authenticated transport layer security (TLS) session (“In order to utilize TLS for OAuth client authentication, the TLS connection between the client and the authorization server have been established or re-established with mutual-TLS X.509 certificate authentication (i.e., the client Certificate and CertificateVerify messages are sent during the TLS handshake).” Campbell § 2) and wherein initiating a second session comprises forming a second mutually authenticated transport layer security (TLS) session. and (“The protected resource obtain, from its TLS implementation layer, the client certificate used for mutual TLS and verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt be rejected with an error” Campbell § 3)
As to claim 17, Stapleton discloses the method/machine of claims 16 and further discloses:
wherein the authentication server is disposed separately from the perimeter guard system, (Stapleton Fig. 1) the client device being redirected to the authentication server.
(note that this does not require the HTTP redirect discussed in Applicant’s specification ¶ 52)
(no token results in contacting the CA “At 205, the relying party computing system 108 sends to the subscriber computing system 106 via the network 110, an OID of the relying party 104. In some examples, the relying party computing system 108 sends the OID of the relying party 104 to the subscriber computing system 106 in response to a request received from the subscriber computing system 106.” Stapleton col. 6, ll. 59+.
with token “At 310, the subscriber computing system 106 sends the certificate with the public key and the OID (e.g., at least one OID) to the relying party 104. At 320, the relying party computing system 108 receives the certificate with the public key and the OID (e.g., at least one OID) of the relying party 104…. The communications at 350 and 360 can be performed for at least one of 1) one or more applications on the relying party computing system 108” Stapleton cols. 9-10).
As to claim 22, Stapleton discloses the method/machine of claims 16 and further discloses:
wherein during authenticating, generating the authentication token comprises determining a policy and associating the policy with the authentication token. (“The extension 480 includes the at least one OID (e.g., at least one RPOID 482) of the relying party 104. For example, the at least one POID 482 can be one OID identifying one or more of the relying party 104, the relying party computing system 108, or an application on the relying party computing system 108. In some examples, the at least one RPOID 482 can be multiple RPOIDs each identifying a separate application on the relying party computing system 108.” (Stapleton col. 13, ll. 25+).
Claim(s) 6-9, and 19-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stapleton, US 12,231,584 (filed 2022), in view of Campbell et al., RFC 8705 – Oauth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, and Shah et al., US 2016/0087957 (filed 2014).
As to claims 6 and 19, Stapleton in view of Campbell discloses the method/machine of claims 1 and 16 but does not disclose:
wherein during the first session, generating the authentication token comprises generating a score and allowing the client device to access the protected web resource based on the score.
Shah discloses:
wherein during the first session, generating the authentication token comprises generating a score (“At 718 and 720, in accordance with the illustrated embodiment, the SP 104 communicates its assurance level requirement to the MFAS/master IdP 106 via the browser 704, using an HTTP redirect mechansim at 720.” Shah ¶ 153. “At 736, in accordance with the illustrated embodiment, the MFAS 106 sends a trigger to the second authentication server 706b to create a second authentication context.” Shah ¶ 157) and allowing the client device to access the protected web resource based on the score. (“MFAS 106 may send the result of each authentication. At 746, the browser 704 receives the consolidated assertion from the MFAS 106. At 748, the browser 704 re-directs and sends the assertion to the SP 104. The signed assertion, which may contain the aggregate assurance level, is communicated by the MFAS 106 to the SP 104 via the UE browser at 746, for example by using an HTTP redirect message. Alternatively, the signed assertion containing the aggregrate assurance level may be communicated directly by the MFAS 106 to the SP 104 using other channels. The signed assertion that is sent may include the freshness level for each authentication factor and the assurance level that was achieved by the multi-factor authentication that was performed.” Shah ¶ 158. “the MFAS 106 verifies the signed assertion and verifies if the required AL has been achieved. At 1276, following the OID protocol, for example, a redirect message containing the Signed Assertion is sent to second RP 1204 (www.merrillynch.com). At 1280, the Assertion is verified by the RP 1204. At 1282, the RP sends a HTTP 200 Ok message to the user, and the user 107 can access the requested service provided by the second RP 1204.” Shah ¶ 173)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stapleton in view of Campbell with Shah by including the assurance level multi-authentication scheme of Shah to authenticate the user prior to issuing the certificate (by the CA of Stapleton). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stapleton in view of Campbell with Shah in order to dynamically authenticate users/terminals based on their capabilities in order to attain a desired assurance level of authentication, Shah ¶ 5.
As to claims 7 and 20, Stapleton in view of Campbell and Shah discloses the method/machine of claims 6 and further discloses:
wherein generating the score comprises generating a score based on a plurality of authenticators. (“At 736, in accordance with the illustrated embodiment, the MFAS 106 sends a trigger to the second authentication server 706b to create a second authentication context.” Shah ¶ 157. The second authenticator of a plurality of authenticators shown in Figures 7A-C)
As to claim 8, Stapleton in view of Campbell and Shah discloses the method/machine of claims 6 and further discloses:
wherein generating the score comprises generating a score based on a plurality of authenticators independent from the authentication server. (“the MFAS 106 consolidates the first, second, and third assertions to create a consolidated assertion for multiple authentication factors. In one example, an aggregate assurance level is computed by summing the assurance level associated with each authentication factor together.” Shah ¶ 157, the assertions from the various authentication servers of Figure 7A-C)
As to claims 9 and 21, Stapleton in view of Campbell and Shah discloses the method/machine of claims 6 and further discloses:
wherein allowing the client device to access the protected web resource comparing the score to a level of security.
(“the MFAS 106 verifies the signed assertion and verifies if the required AL has been achieved. At 1276, following the OID protocol, for example, a redirect message containing the Signed Assertion is sent to second RP 1204 (www.merrillynch.com).” Shah ¶ 173)
Claim(s) 12-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stapleton, US 12,231,584 (filed 2022), in view of Campbell et al., RFC 8705 – Oauth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, and Ahmed et al., US 2013/0227291 (filed 2012).
As to claim 12, Stapleton in view of Campbell discloses the method/machine of claims 11 and 16 but does not disclose:
wherein the token accessor comprises a header or a cookie.
Ahmed discloses:
wherein the token accessor comprises a header or a cookie.
(“subsequent HTTP/HTTPS requests from the mobile web browser, an encrypted session token may be generated by the gateway server 18 and passed back to the EVC 2 as a URL parameter, HTTP session cookie, or other parameter.” Ahmed ¶ 107)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stapleton in view of Campbell with Ahmed by incorporating the cookie/token structure of Ahmed into a gateway that brokers connections to protected app servers, Ahmed ¶ 50, and intermediate the authentications, Ahmed ¶ 118. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stapleton in view of Campbell with Ahmed in order to implement a constrained delegation scheme whereby a gateway intermediates sessions to secured app servers thereby easing integration of disparate devices that may not have support for the required authentications, Ahmed ¶ 80.
As to claim 13, Stapletonin view of Campbell discloses the method/machine of claims 11 and 16 but does not disclose:
wherein generating authentication token comprises aliasing the authentication token using the accessor.
Ahmed discloses:
wherein generating authentication token comprises aliasing the authentication token using the accessor.
(“The session token may then be resent to the gateway server 18 as a URL parameter, HTTP session cookie, or other parameter in subsequent HTTP/HTTPS requests…. The gateway server may maintain authenticated session states for each application or internal domain via an HTTP session cookie with the session token.” Ahmed ¶ 107. “the embodiment shown in FIG. 8 caches the Kerberos TGTs on the gateway server 18 and associates them with, and protects them by, the gateway server session tokens.” Ahmed ¶ 116)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stapleton in view of Campbell with Ahmed by incorporating the cookie/token structure of Ahmed into a gateway that brokers connections to protected app servers, Ahmed ¶ 50, and intermediate the authentications, Ahmed ¶ 118. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stapleton in view of Campbell with Ahmed in order to implement a constrained delegation scheme whereby a gateway intermediates sessions to secured app servers thereby easing integration of disparate devices that may not have support for the required authentications, Ahmed ¶ 80.
As to claim 14, Stapleton in view of Campbell discloses the method/machine of claims 11 and 16 but does not disclose:
wherein aliasing comprises aliasing the authentication token by pointing to a credential backends without revealing token contents.
Ahmed discloses:
wherein aliasing comprises aliasing the authentication token by pointing to a credential backends without revealing token contents. (“The session token may then be resent to the gateway server 18 as a URL parameter, HTTP session cookie, or other parameter in subsequent HTTP/HTTPS requests…. The gateway server may maintain authenticated session states for each application or internal domain via an HTTP session cookie with the session token.” Ahmed ¶ 107. “the embodiment shown in FIG. 8 caches the Kerberos TGTs on the gateway server 18 and associates them with, and protects them by, the gateway server session tokens.” Ahmed ¶ 116.
“an encrypted session token may be generated by the gateway server 18 and passed back to the EVC 2 as a URL parameter, HTTP session cookie, or other parameter.” Ahmed ¶ 107)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stapleton in view of Campbell with Ahmed by incorporating the cookie/token structure of Ahmed into a gateway that brokers connections to protected app servers, Ahmed ¶ 50, and intermediate the authentications, Ahmed ¶ 118. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stapleton in view of Campbell with Ahmed in order to implement a constrained delegation scheme whereby a gateway intermediates sessions to secured app servers thereby easing integration of disparate devices that may not have support for the required authentications, Ahmed ¶ 80.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Simmons et al., US 2013/0268755, discloses providing cross certification using a JSON web token.
Madden, US 11,595,215, discloses using certificate bound access tokens.
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 MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
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, Rupal Dharia can be reached at (571) 272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492
Prosecution Insights