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 .
This Office Action is in response to Response filed on 04/13/2026.
In the instant Amendment, claims 6, 13, and 20 have been cancelled; claims 1, 8 and 15 have been amended; and claims 1, 8, and 15 are independent claims. Claims 1-20 have been examined and are pending.
Response to Arguments
The 112 (d) rejection is withdrawn as claims 6, 13, and 20 have been cancelled.
Applicants’ arguments with respect to claims 1, 8 and 15 have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment.
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-20 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.
Regarding claims 1, 9, and 15:
Issue # 1 — Unclear whether the received credential is the credential unique to the first authentication
The claims are indefinite because it is unclear whether “the credential associated with the user of the device” is the same credential previously recited as “a credential that is unique to the first authentication.” The claim first recites “generating a credential that is unique to the first authentication,” but later recites “receiving, by an identity agent installed on a device, the credential associated with the user of the device.”. The claim does not clearly indicate whether the received credential is the credential unique to the first authentication, or a different credential associated with the user and/or device.
Although the specification may describe an example credential 132, the claim language itself must clearly and precisely define the metes and bounds of the claimed invention. The Examiner has considered the specification, but the specification does not resolve the ambiguity in the claim language regarding the claimed “credential”. The Examiner cannot import limitations from disclosed embodiment, such as credential 132 being received from browser 140a or being stored by identity agent 160 on device 120 into the claim to cure the unclear scope of the amended credential limitation. Se MPEP § 2111.01, § 2173.02, § 2173.05(a) and (e).
Therefore, even when claims 1, 9 and 15 are read in light of the specification, one of ordinary skill in the art would not be reasonably apprised of the scope of the claimed ”credential”, including whether the same credential is generated, received, stored, associated with the posture, and used for the second authentication. For purposes of examination, the limitation will be interpreted as it is the same credential.
Issue # 2 — Unclear whether “a device” is the same device previously recited”
The claim recites “A device comprising…: ….using a login authentication factor received from a user of a device; …an identity installed on a device”.
The claims are indefinite because it is unclear whether the “device” on which the identity agent is installed is the same device recited in the preamble and the same device to which the user is first authenticated. Claim 1 recites “a device comprising one or more processors,” and further recites “performing, using a login authentication factor received from a user of a device, a first authentication of the user to the device.” However, the claim later recites “receiving, by an identity agent installed on a device, the credential associated with the user of the device.” Because the claim uses “a device” rather than “the device,” it is unclear whether the identity agent is installed on the claimed device, the user’s device, the device to which the user is first authenticated, or a different device. Accordingly, the metes and bounds of the claimed device are unclear. For purposes of examination, the limitation will be interpreted as it is the same device.
Issue # 3 — Unclear whether “a user” is the same user previously authenticated”
The claim recites “performing, using authentication factor received from a user of a device; ….receiving, by the identity agent installed on a device, the credential associated with a user of the device …”.
The claims are indefinite because it is unclear whether the user associated with the credential is the same user previously recited as performing the first authentication. Claim 1 first recites a first authentication of the user to the device, but later recites that the identity agent receives the credential associated with the user of the device.” To the extent the amended claim uses “a user” or otherwise introduces a user without clear antecedent relationship to “the user,” it is unclear whether the credential is associated with the same authenticated user or a different user of the device. Accordingly, the scope of the claimed user and credential relationship is unclear. For purposes of examination, the limitation will be interpreted as it is the same user.
Issue # 4 — Unclear whether the second authentication uses the association or only the security posture and credential separately
The claims are indefinite because the role of the claimed “association of the security posture and the credential” in the second authentication is unclear. The claim recites “generating, by the identity agent, an association of the security posture and the credential,” “receiving, by the identity agent, a request for the association of the security posture and the credential from a first browser,” and “communicating, by the identity agent, the association of the security posture and the credential to the first browser.” However, the claim later recites “performing a second authentication of the user to the device using the security posture and the credential unique to the first authentication,” rather than using the generated association. Thus, it is unclear whether the second authentication is performed using the generated association, the security posture and credential as separate items, or the communication of the association to the first browser. Accordingly, the scope and function of the claimed association are unclear.
Issue # 5 — Unclear and internally inconsistent timing of capturing the security information
The claims are indefinite because the timing of capturing the security information used to generate the security posture is unclear and internally inconsistent. T
he claim first recites:
1st - “capturing, by the identity agent, security information associated with the device,”
2nd - “generating, by the identity agent, a security posture using the security information associated with the device,” and
3rd - “generating, by the identity agent, an association of the security posture and the credential”
before reciting “receiving, by the identity agent, a request for the association of the security posture and the credential from a first browser.”
However, the final wherein clause recites that “the identity agent captures the security information associated with the security posture of the device after receiving the request for the association of the security posture and the credential from the first browser.” Therefore, it is unclear whether the security information is captured before or after the browser request, and it is unclear how the security posture and association can be generated before the browser request if the security information used for the security posture is captured after the browser request.
Issue # 6 — Unclear what “granting the user access to the device” means
The claims are indefinite because it is unclear what access is being granted by the limitation “granting the user access to the device.” The claim previously recites performing “a first authentication of the user to the device” and later recites performing “a second authentication of the user to the device.” Therefore, it is unclear whether the claimed “access” refers to access to the device itself, continued access to the device, access to the first browser, access to an application, access to a protected resource, or some other access. Accordingly, the scope of the claimed access grant is unclear.
Because of the above ambiguities, claims 1, 9 and 15 do not reasonably apprise one of ordinary skill in the art of the scope of the claimed invention. As a result, the Examiner is unable to determine the limit and bound of the claims to properly search them.
Claims 2-5, 7-12, and 14-19 are rejected under 35 U.S.C. § 112(b) for failing to particularly point out and distinctly claim the subject matter claims 1, 9 and 15 and incorporate the same limitations for which claims 1, 9 and 15 has been rejected. The same reasoning and factual bases set forth for the rejection of claims 1, 9 and 15 are equally applicable to claims 2-5, 7-12, and 14-19.
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-3, 5, 7-10, 12, 14-17, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Dani et al. (U.S 20210021629 A1; Hereinafter “Dani”) in view of Otranen et el. (U.S 20110202989 A1; Hereinafter “Otranen”), Cockerill et al. (US 20210258304 A1; Hereinafter “Cockerill”), and Sim et al. (US 20180234464 A1; Hereinafter “Sim”).
As per claims 1, 8, 15, Dani teaches a device (device 125) comprising one or more processors and one or more computer-readable non-transitory storage media coupled to the one or more processors and including instructions that, when executed by the one or more processors, cause the device to perform operations comprising (Dani: fig. 1 & 2, and para[33-34], “The processing unit 202 may control one or more of the memory unit 204, the I/O unit 206, and the communication unit 208 of the computing environment 200,”):
capturing, by the identity agent (security infrastructure 140), security information (system vulnerability) associated with the device (device 125) (Dani: fig. 1, para[22-26], [51], [70-72], “The security infrastructure 140 may either be on the server 105 and/or on the endpoint device 125…Security infrastructure 140 may include at least a security profile generation unit 234, attack path generation unit 236, threat detection unit (not shown), and a scan history unit (not shown).”, “system vulnerability may be an aggregate of applications used by the computing device for which system exploitability is computed…For example, the system vulnerability may be obtained using: system vulnerability=0.5?(OS is EOL)+0.2?(is OS vulnerable)+0.2?(are some 1st level apps vulnerable e. g. browser, pdf reader, java)+0.1?(are some 2nd level apps vulnerable e. g. WinSCP, WinZip, etc.)”);
generating, by the identity agent, and independent of the credential, a security posture (system exploitability information) using the security information associated with the device (Dani: para[51-54], [85-86], “the security profile generation unit 234 may determine system exploitability information of the computing device. System exploitability information, in some embodiments, indicates one or more of: the vulnerability associated with the computing device, an exposure window associated with the computing device, and a protection window associated with the computing device…the vulnerability is based on factors/data/information relating to vulnerability and patching (e.g., applying security patches or other system patches) associated with the computing device….a hardware specification of the computing device, whether the operating system of the computing device is up to date, a list of shared directories on the computing device, whether the computing device has the latest patches, whether the computing device has the latest services enabled, one or more connectivity types associated with the computing device, and types of security solutions associated with the computing device..”),
wherein the security posture represents a level of susceptibility of the device to cyber-attacks (Dani: para [56], [85-86], “System exploitability information, in some embodiments, indicates one or more of: the vulnerability associated with the computing device, an exposure window associated with the computing device, and a protection window associated with the computing device….The system exploitability value included in RP 2 may be 70, for example while the system criticality associated with RP 4 may be 80, for example. Applying the steps for attack path prediction outlined above results in the attack path indicated by the dotted arrow between endpoint device 425a and file server 405c. A similar rationale may be applied to determining the attack path between endpoint device 425e and certificates store 425k”);
generating, by the identity agent, an association of the security posture (system exploitability information) and the credential (user information) (Dani: para[55-56], [84], [87], “the security profile generation unit 234 may determine a risk profile for the computing device based on the user information, the system exploitability information, and the system criticality information…the risk profile is determined based on combining the user information, the system exploitability information, and the system criticality information.” Para[84], “the security profile generation unit 234 may determine user information indicating one or more user attributes associated with a vulnerability of a computing device…the one or more user attributes associated with the vulnerability of the computing device comprises:…application and system credentials of the user, sensitive user credentials such as internet information services (IIS) application pool, user credentials stored in plain-text on the computing device.., and automatic logon configurations associated with the user.”,).
Dani does not explicitly teach performing, using a login authentication factor received from a user of a device, a first authentication of the user to the device; generating a credential that is unique to the first authentication; receiving, by an identity agent installed on the device, a credential associated with a user of the device; storing, by the identity agent, the credential on the device; receiving, by the identity agent, a request for the association of the security posture and the credential from a first browser; and communicating, by the identity agent, the association of the security posture and the credential to the first browse; performing a second authentication of the user to the device using the security posture and the credential that is unique to the first authentication; granting the user access to the device; and wherein the identity agent captures the security information associated with the security posture of the device after receiving the request for the association of the security posture and the credential from the first browser.
However, in the related art, Otranen teaches receiving, by an identity agent (DE 109 fig. 2, para [0044]) installed on the device, a credential associated with a user of the device (UE 101) (Otranen: fig. 1-2, para[25], “In an on-boarding process 202, a subject 204 may submit claims 206 to establish an identity 208 with the service provider, e.g., service provider system 110. A process 210 of identity proofing may be performed to verify claims 206. Process 210 of identity proofing may provide a set of attributes 212 associated with identity 208 of subject 204”);
storing, by the identity agent, the credential on the device (Otranen: para[0056], “Attributes 212 may be stored, for example, in user information database 140. Attributes 212 may be provided to process 214 for matching specific attributes and providing further input, for example, to a process 260 for identity assurance and authentication confidence or, for example, to a process 280 for role-based attribute based access control (RABAC) 280, as seen in FIG.”);
receiving, by the identity agent, a request for the association of the security posture and the credential from a first browser (Otranen: para[0028-0029], “the interface DE 109 can be implemented as an SSO authentication enabler to advantageously share authentication session information between different client applications (e.g., client applications 111 and/or browser 113) of the UE 101…. when the interface DE 109 receives an authentication request from one of client applications 111, such as client application 111b, the DE 109 determines whether an authentication process has already been performed for the client applications 111”); and
communicating, by the identity agent, the association of the security posture and the credential to the first browser ( Otranen: para[0028-0029], “If the DE 109 determines that the authentication context exists (and for example, is not outdated), the authentication context is retrieved from, for example, the cache and/or authentication database 117 and is returned to the client application 111b. Therefore, the interface DE 109 implements single sign-in functionality by caching and/or storing the authentication context and retrieving it for requesting client applications”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Dani with the process discussed in Otranen, it will enable sharing of authentication information between different client applications and reduces the use of computing, network and power resources of the device (Otranen: para[30]).
Dani in view of Otranen does not explicitly teach performing, using a login authentication factor received from a user of a device, a first authentication of the user to the device; generating a credential that is unique to the first authentication; performing a second authentication of the user to the device using the security posture and the credential that is unique to the first authentication; granting the user access to the device; and wherein the identity agent captures the security information associated with the security posture of the device after receiving the request for the association of the security posture and the credential from the first browser.
However, in the related art, Cockerill teaches performing a second authentication of the user to the device using the security posture (device factors) and the credential (user factors) (Cockerill: fig. 1, para[69], para[84-87], “the access request is generated by application 1013, which is executing on mobile device 149.”, [88-93], “access to a service provided by service provider 170 is conditioned on a successful evaluation of various risk-based factors. Mechanisms that may be used to authenticate a device, user, and/or application by evaluation server 150 include one or more of the following: requiring that an SSL client certificate be supplied for each access request by mobile device 149, evaluating authentication factors provided from network connection establishment (e.g., Wi-Fi, VPN, cellular, etc.) by mobile device 149…. factors used in a security evaluation by evaluation server 150 to allow or deny access to a service are now described below… 1. Various device factors associated with mobile device 149 include determining whether the device is compromised, such as whether an operating system is compromised, whether the device is up-to-date, such as whether a vulnerable operating system version is in use. Further factors include determining a presence of malware, or determining whether the device has a secure configuration…. 2. Various user factors may be used in the security evaluation. These factors may include biometric factors such as a fingerprint,..”, )
granting the user access to the device (Cockerill: para [128-129], “if the device is determined to be configured correctly, or passes a threshold of configuration correctness (even though not fully correctly configured), the client application on the device informs the service provider that the device is correctly configured…The service provider permits the device to access the service”).
wherein the identity agent captures the security information associated with the security posture of the device after receiving the request, for the association of the security posture and the credential from the first browser (Cockerill: para[72-75], “The access request is transmitted to evaluation server 150, which performs a security evaluation of a configuration of mobile device 149 based on various factors,….Evaluation server 150 performs a security evaluation of risk factors associated with mobile device 149. If the evaluation determines that the configuration is not secure, server 150 blocks access by mobile device 149 to the service….the security evaluation is based on data received from the mobile device 149…this data is received from component 104, or from another software component such as component 106 that is on mobile device 149. The data sent to evaluation server 150 is obtained from the mobile device using this software component.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have modified the modified Dani to determine whether to authenticate a user and grant access using the device security posture and user credentials as taught by Cockerill, it will improve security by preventing access from vulnerable devices, and ensure that authentication decisions are based on a current and accurate device security state (Cockerill: para[10]).
Dani in view of Otranen and Cockerill does not explicitly teach performing, using a login authentication factor received from a user of a device, a first authentication of the user to the device; generating a credential that is unique to the first authentication.
However, in the related art, Sim teaches performing, using a login authentication factor received from a user of a device, a first authentication of the user to the device (Sim: para [27-37], claim 9 , “performing a first authentication procedure to authenticate the user, the first authentication procedure comprising validating an authentication factor provided by the client application via the network with a stored authentication factor associated with the user identity, wherein the first authentication procedure authenticates the user identity”);
generating a credential that is unique to the first authentication (Sim: para [27-37], claim 9, “based on the authentication of the user identity, generating a token associated with the user identity, storing the token”, “The access token 110 may include a unique string that serves as a validatable credential; a signed nonce, a random number, or any other authentication identifier that can later be validated by the authentication server”)
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have modified the modified Dani to generate the credential as a unique validatable authentication token issued in response to the user’s first authentication, as taught by Sim, it would securely identify the prior authentication event , reduce the need for repeated manual login, and allow the credential to be validated and reuse during access control operation (Sim: para[02]).
As per claims 2, 9, and 16, Dani in view of Otranen, Cockerill and Sim teaches the independent claims 1, 8 and 15. Otranen teaches wherein: the credential indicates that the user is successfully logged into an operating system of the device (Otranen: para[0023], “if the authentication is successful (e.g., the user credentials are valid), the authentication server 107 generates and returns a valid authentication context to the DE 109. In one example, the success of the authentication is determined by the authentication server 107 by comparing the received user credentials with user credentials stored in a database (not shown) associated with the authentication server 107. However, it is contemplated that other authentication schemes and protocols can be used to authenticate the client applications 111 and/or user(s) of the client applications.”); and
the credential is one of the following: a single sign-on token; a passwordless credential; or a single sign-on credential (Otranen: para[0020-0022], “the term "authentication context" can include: 1) information regarding initial identification mechanisms of a user, client, customer, etc.; (2) information regarding authentication mechanism or method (e.g., passwords, one time password, a cookie, a limited use key, a secret key, a consumer key, an access token, etc.); (3) information regarding storage and protection of credential (e.g., password rules, smart carts, etc.); and the like”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Dani with the process discussed in Otranen, it will enable sharing of authentication information between different client applications and reduces the use of computing, network and power resources of the device (Otranen: para[30]).
As per claims 3, 10, and 17, Dani in view of Otranen, Cockerill and Sim teaches the independent claims 1, 8 and 15. Dani teaches wherein the security posture information is associated with one or more of the following: a patch level of one or more operating systems associated with the device; a patch level of one or more applications installed on the device; a presence of one or more security applications associated with the device; and a presence of one or more security controls associated with the device (Dani: para[69], [85] “the vulnerability is based on factors/data/information relating to vulnerability and patching (e.g., applying security patches or other system patches) associated with the computing device. The factors/data/information relating to vulnerability and patching include on one or more of: a hardware specification of the computing device, whether the operating system of the computing device is up to date, a list of shared directories on the computing device, whether the computing device has the latest patches, whether the computing device has the latest services enabled, one or more connectivity types associated with the computing device, and types of security solutions associated with the computing device.”.
As per claims 5, 12 and 19, Dani in view of Otranen, Cockerill and Sim teaches the independent claims 1, 8 and 15. Cockerill teaches wherein the security posture is a conceptual diagram that illustrates potential risk items identified by the identity agent, the potential risk items comprising one or more from the following list of potential risk items: unpatched software; a password issue; phishing; ransomware; a denial-of-service attack; a misconfiguration; and an encryption issue. (Cockerill: para[78-81], “the security evaluation determines that a risk configuration of mobile device 149 passes a security threshold. If the threshold is passed, server 150 sends a communication to service provider 170 and/or identity provider 172 regarding the passed security threshold. This communication may include data obtained from mobile device 149 and used in the security evaluation above.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have modified the modified Dani to determine whether to authenticate a user and grant access using the device security posture and user credentials as taught by Cockerill, it will improve security by preventing access from vulnerable devices, and ensure that authentication decisions are based on a current and accurate device security state (Cockerill: para[10]).
As per claims 7 and 14, Dani in view of Otranen, Cockerill and Sim teaches the independent claims 1, 8 and 15. Otranen teaches wherein: the credential is generated by the user or an authentication service (Otranen: para[23] “if the authentication is successful (e.g., the user credentials are valid), the authentication server 107 generates and returns a valid authentication context to the DE 109”); and
the request is associated with an application that is federated behind the authentication service (Otranen: fig. 4, para[54] “the authentication request can include information associated to the client application 111a, a user of the client application, an application server that the client application 111a desires to access, etc.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Dani with the process discussed in Otranen, it will enable sharing of authentication information between different client applications and reduces the use of computing, network and power resources of the device (Otranen: para[30]).
Claims 4, 11, and 18, are rejected under 35 U.S.C. 103 as being unpatentable over Dani et al. (U.S 20210021629 A1; Hereinafter “Dani”) in view of Otranen et el. (U.S 20110202989 A1; Hereinafter “Otranen”), Cockerill et al. (U.S 20210258304 A1; Hereinafter “Cockerill”), Sim et al. (US 20180234464 A1; Hereinafter “Sim”) and Tulshibagwale et al. (U.S 20220191200 A1; Hereinafter “Tulshibagwale”).
As per claims 4, 11, and 18, Dani in view of Otranen, Cockerill and Sim teaches the independent claims 1, 8 and 15.
Dani in view of Otranen and Cockerill does not teach wherein the identity agent receives the credential from a login client installed on the device or from a second browser installed on the device.
However, in the related art, Tulshibagwale teaches wherein the identity agent receives the credential from a login client installed on the device or from a second browser installed on the device (Tulshibagwale: fig. 4, para[0028],[0030-0031] “That is, the application service 130 requests the authenticator 170 to authenticate the user 12 so that the user 12 may access a resource associated with the application service 130. The application service 130 may send the authentication request 132 to the remote system 140 in response to a selection or indication from the user 12… As discussed in more detail below, the authenticator 170 may receive the authentication credentials 20 in response to prompting the user 12 via, for example, a display of the user device 10, to provide the authentication credentials 20”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Dani with Tulshibagwale, it enable secure authentication information and prevent privacy and security concerns (Tulshibagwale [21].
Conclusion
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 LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Alexander Lagor can be reached on (571)-270-5143. 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.
/L.L.N./Examiner, Art Unit 2437
/ALEXANDER LAGOR/ Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights