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 .
DETAILED ACTION
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 06/23/2026 has been entered.
Response to Amendments
In response to communication filed on 06/23/2026, applicant amends claims 1, 7, 12, 13, new Claims 19-31 have been added and cancels Claims 2-3, 5-6, 8-9, 11, 14-15, 17-18. The following claims, 1, 4, 7, 10, 12, 13, 16, 19-31 are presented for examination.
Response to Arguments
Applicant’s arguments, see Pages 8-10, filed June 23, 2026, with respect to the rejection(s) of claim(s) 1-18 under 35 USC 103 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 newly found prior art reference, Mahajan et al. (US2020/0336484 A1, publish date 10/22/2020). Examiner withdraws Shravan et al. (US2021/0281576 A1, file date 03/04/2020), Levin et al. (US2022/0029988 A1, file date 07/27/2020 ), and Konda et al. (US2022/0321362 A1, file date 03/31/2021).
Applicant argues Howry does not remedy these deficiencies. The Office Action relies on Howry for allegedly teaching security posture contained in a certificate. Those teachings are not relevant to the currently pending limitations. Howry is not cited as teaching an access node that accesses a device identification embedded in a device certificate and uses the embedded device identification to request a corresponding device record.
In response to Applicant’s argument, Examiner holds Howry is relevant to the currently pending limitations. See rejection set forth below.
Upon further consideration and based on amendments, a new ground of rejection of claims 1, 4, 7, 10, 12, 13, 16, 19-31 is set forth below.
Minor Informalities
Claim 7 is objected to because of the following informalities: Claim 7 recites “An access node”. Examiner suggests to make lower case. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis 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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4, 7, 10, 12, 13, 16, 19-31 are rejected under 35 U.S.C. 103 as being unpatentable over Howry et al. (US2017/0324733 A1, publish date 11/09/2017) in view of Mahajan et al. (US2020/0336484 A1, publish date 10/22/2020).
Claim 1:
With respect to claim 1, Howry et al. discloses a method for trust security processing for an endpoint device in a network (UE: Figures 3 and 4) (a security posture may also be referred to as a security posture value (SPV) or a security posture level, a security posture may be represented quantitatively or qualitatively. The security posture may provide a verifiable point-in-time trust metric on the overall level of trust in a node, 0020), the method comprising:
receiving, by an access node, a network access request from the endpoint device, the network access request including a device certificate associated with the endpoint device (the first CN 304 sends its SPV.sub.1 to the NMM 308, the SPV.sub.1 may be sent in the form of a certificate, 0050);
accessing, by the access node, a device identification embedded in the device certificate (the SPV of an entity may be represented in the form of a digital certificate, an example certificate 200 is shown that is issued to a device that is identified by its Device name (8686.NorristownFD.org), type, 0034, Figure 2);
requesting, by the access node and using the device identification accessed from the
device certificate, a device record for the endpoint device (the UE 402 may periodically provide its UE ID, its current location, and various context information (e.g., type of service or application being used, etc.) to the NMM 408, the NMM 408 may query, based on the identity (ID) of the UE 403 for example, a User Profile DB 412 to obtain profile information associated with the UE 402, the NMM 408 stores the UE's profile information with the ESPL of the UE 402, 0054, Figure 4, 412) (The certificates may be stored locally within a secure hardware module and invoked, for example, by a Trusted Execution Environment that is virtualized or via a Trusted Platform Module/Trusted Execution Environment. SPV certificates may additionally, or alternatively, be stored securely in a network element or server and fetched when needed using secure mechanisms. 0035), wherein the device record includes a security posture of the endpoint device (a security posture may also be referred to as a security posture value (SPV) or a security posture level, a security posture may be represented quantitatively or qualitatively. The security posture may provide a verifiable point-in-time trust metric on the overall level of trust in a node, 0020) (security postures are extended to indicate an evaluation of systems. Such evaluations may include, for example, a vulnerability assessment, penetration testing, or a TRA of live, production or development systems, 0022) (The security posture of a device may indicate, for instance include, parameters associated with security applications (e.g., a list of virus detection applications, the scan status associated with each virus detection application, a time of the last vulnerability assessment by way of security scan results) that are on the device, 0024) and an indication of ownership of the endpoint device (an example certificate 200 is shown that is issued to a device that is identified by its Device name (8686.NorristownFD.org). As shown, the device belongs to the Norristown Fire Department., 0035) (Figure 2) (the PVB may optionally authenticate the first CN 304 in order to verify the real identity of the certificate owner, 0051);
receiving, by the access node, the device record (based on a profile of the UE 302, a Security Posture requirement of the UE 302, or other attributes (e.g., location, QoS, etc.), the Network Mobility Manager (NMM) 308 identifies potential Candidate Networks for the UE 302 to connect or offload, 0050) (a User Profile DB 412 to obtain profile information associated with the UE 402, the NMM 408 stores the UE's profile information with the ESPL of the UE 402, 0054, Figure 4, 412);
determining, by the access node, a scope of network access for the endpoint device based on a combination of the device record (based on a profile of the UE 302, a Security Posture requirement of the UE 302, or other attributes (e.g., location, QoS, etc.), the Network Mobility Manager (NMM) 308 identifies potential Candidate Networks for the UE 302 to connect or offload, 0050) (the security postures (SPV.sub.1 and SPV.sub.2) are compared with each other to determine which security posture is best suited for the UE 302, 0051), user authentication associated with the network access request (the PVB may optionally authenticate the first CN 304 in order to verify the real identity of the certificate owner, 0051), and one or more network security policies (A consumer of a service may be provisioned with an appropriate set of policies so that the consumer may use the certificates to assess the trustworthiness of a service provider before a respective service is consumed. Policies may dictate whether the SPV of an entire platform is required. Policies may further stipulate whether the SPV of each component is required or whether a cumulative SPV is permitted or required. 0039); and
selectively granting, by the access node, network access to the endpoint device based on the determination (the security posture that indicates that its associated network is most secure as compared to the other candidate networks is selected. In the illustrated example, the SPV associated with the first CN 304 is adequate as compared to the ESPL of the UE 302, and the SPV associated with the first CN 304 is determined to be better than the SPV associated with the second CN 306. Thus, the PVB 310 selects the first CN 304 as the network (which can be an AP or Base station for example) to offload or attach. At 332, the result of the posture verification and comparison is communicated to the NMM 308. 0051)
Howry et al. does not disclose zero trust security processing as claimed.
However, Mahajan et al. teaches FIG. 6 is a network diagram of a Zero Trust Network Access (ZTNA) application utilizing the cloud-based system 100. For ZTNA, the cloud-based system 100 can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 404, connected to enterprise file shares and applications. (0066),
The user device 300 and the unified agent application 350 can perform a registration/identity 620 process through the agent manager cloud 606 where the user identity, the user's certificates, and a device fingerprint can uniquely identify the user device 300. Once registered, the unified agent application 350 has an identity 622, which can include the user, certificates, device posture, etc. and which is shared with the cloud-based system 100. (0080).
Howry et al. and Mahajan et al. are analogous art because they are from the same field of endeavor of network security/trust security.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Mahajan et al. in Howry et al. for enforcing security policies on mobile devices in a hybrid architecture, to leverage the benefits of both approaches while reducing or eliminating the shortcomings. (see Mahajan et al. 0008)
Claims 4, 10, 16:
With respect to claims 4, 10, 16, Howry et al. discloses wherein the security posture includes at least one of: an indication of an out-of-date operating system executing on the endpoint device, an insecure application executing on the endpoint device, a vulnerable hardware element included as part of the endpoint device, or an up-to-date virus detection and mitigation application executing on the endpoint device (The security posture of a device may indicate, for instance include, parameters associated with security applications (e.g., a list of virus detection applications, the scan status associated with each virus detection application, a time of the last vulnerability assessment by way of security scan results) that are on the device, 0024).
Claim 7:
With respect to claim 7, Howry et al. discloses a system for zero trust security processing for an endpoint device in a network (UE: Figures 3 and 4) (a security posture may also be referred to as a security posture value (SPV) or a security posture level, a security posture may be represented quantitatively or qualitatively. The security posture may provide a verifiable point-in-time trust metric on the overall level of trust in a node, 0020), the system comprising:
An access node including a processing resource and a non-transitory computer readable storage medium storing instructions that, when executed by the processing resource (a UE, AP, or WTRU 52. As shown in FIG. 11B, the WTRU 52 may include a processor 68, non-removable memory 80, removable memory, 0103) cause the access node to:
receive a network access request providing a device certificate associated with the endpoint device (the first CN 304 sends its SPV.sub.1 to the NMM 308, the SPV.sub.1 may be sent in the form of a certificate, 0050);
access a device identification embedded in the device certificate (the SPV of an entity may be represented in the form of a digital certificate, an example certificate 200 is shown that is issued to a device that is identified by its Device name (8686.NorristownFD.org), type, 0034, Figure 2);
request, using the device identification accessed from the device certificate, a device record for endpoint device (the UE 402 may periodically provide its UE ID, its current location, and various context information (e.g., type of service or application being used, etc.) to the NMM 408, the NMM 408 may query, based on the identity (ID) of the UE 403 for example, a User Profile DB 412 to obtain profile information associated with the UE 402, the NMM 408 stores the UE's profile information with the ESPL of the UE 402, 0054, Figure 4, 412) (The certificates may be stored locally within a secure hardware module and invoked, for example, by a Trusted Execution Environment that is virtualized or via a Trusted Platform Module/Trusted Execution Environment. SPV certificates may additionally, or alternatively, be stored securely in a network element or server and fetched when needed using secure mechanisms. 0035),
wherein the device record includes a security posture of the endpoint device (a security posture may also be referred to as a security posture value (SPV) or a security posture level, a security posture may be represented quantitatively or qualitatively. The security posture may provide a verifiable point-in-time trust metric on the overall level of trust in a node, 0020) (security postures are extended to indicate an evaluation of systems. Such evaluations may include, for example, a vulnerability assessment, penetration testing, or a TRA of live, production or development systems, 0022) (The security posture of a device may indicate, for instance include, parameters associated with security applications (e.g., a list of virus detection applications, the scan status associated with each virus detection application, a time of the last vulnerability assessment by way of security scan results) that are on the device, 0024) and an indication of ownership of the endpoint device (an example certificate 200 is shown that is issued to a device that is identified by its Device name (8686.NorristownFD.org). As shown, the device belongs to the Norristown Fire Department., 0035) (Figure 2) (the PVB may optionally authenticate the first CN 304 in order to verify the real identity of the certificate owner, 0051);
receive the device record (based on a profile of the UE 302, a Security Posture requirement of the UE 302, or other attributes (e.g., location, QoS, etc.), the Network Mobility Manager (NMM) 308 identifies potential Candidate Networks for the UE 302 to connect or offload, 0050) (a User Profile DB 412 to obtain profile information associated with the UE 402, the NMM 408 stores the UE's profile information with the ESPL of the UE 402, 0054, Figure 4, 412);
determine a scope of network access for the endpoint device based on a combination of the device record (based on a profile of the UE 302, a Security Posture requirement of the UE 302, or other attributes (e.g., location, QoS, etc.), the Network Mobility Manager (NMM) 308 identifies potential Candidate Networks for the UE 302 to connect or offload, 0050) (the security postures (SPV.sub.1 and SPV.sub.2) are compared with each other to determine which security posture is best suited for the UE 302, 0051), user authentication associated with the network access request (the PVB may optionally authenticate the first CN 304 in order to verify the real identity of the certificate owner, 0051), and one or more network security policies (A consumer of a service may be provisioned with an appropriate set of policies so that the consumer may use the certificates to assess the trustworthiness of a service provider before a respective service is consumed. Policies may dictate whether the SPV of an entire platform is required. Policies may further stipulate whether the SPV of each component is required or whether a cumulative SPV is permitted or required. 0039); and
selectively grant network access to the endpoint device based on the determination (the security posture that indicates that its associated network is most secure as compared to the other candidate networks is selected. In the illustrated example, the SPV associated with the first CN 304 is adequate as compared to the ESPL of the UE 302, and the SPV associated with the first CN 304 is determined to be better than the SPV associated with the second CN 306. Thus, the PVB 310 selects the first CN 304 as the network (which can be an AP or Base station for example) to offload or attach. At 332, the result of the posture verification and comparison is communicated to the NMM 308. 0051).
Howry et al. does not disclose zero trust security processing as claimed.
However, Mahajan et al. teaches FIG. 6 is a network diagram of a Zero Trust Network Access (ZTNA) application utilizing the cloud-based system 100. For ZTNA, the cloud-based system 100 can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 404, connected to enterprise file shares and applications. (0066),
The user device 300 and the unified agent application 350 can perform a registration/identity 620 process through the agent manager cloud 606 where the user identity, the user's certificates, and a device fingerprint can uniquely identify the user device 300. Once registered, the unified agent application 350 has an identity 622, which can include the user, certificates, device posture, etc. and which is shared with the cloud-based system 100. (0080).
Howry et al. and Mahajan et al. are analogous art because they are from the same field of endeavor of network security/trust security.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Mahajan et al. in Howry et al. for enforcing security policies on mobile devices in a hybrid architecture, to leverage the benefits of both approaches while reducing or eliminating the shortcomings. (see Mahajan et al. 0008)
Claim 12:
With respect to claim 12, Howry et al. discloses wherein the access node is communicably coupled to an endpoint management system from which the device record is requested (Figures 3, 4, 11C).
Claim 13:
With respect to claim 13, Howry et al. discloses a non-transitory computer-readable storage medium embodying a set of instructions, which when executed by one or more processing resources of an access node (a UE, AP, or WTRU 52. As shown in FIG. 11B, the WTRU 52 may include a processor 68, non-removable memory 80, removable memory, 0103), causes the one or more processing resources to:
receive a network access request from an endpoint device, the network access request providing a device certificate associated with the endpoint device (the first CN 304 sends its SPV.sub.1 to the NMM 308, the SPV.sub.1 may be sent in the form of a certificate, 0050);
access a device identification embedded in the device certificate (the SPV of an entity may be represented in the form of a digital certificate, an example certificate 200 is shown that is issued to a device that is identified by its Device name (8686.NorristownFD.org), type, 0034, Figure 2);
request, using the device identification accessed from the device certificate, a device record for endpoint device (the UE 402 may periodically provide its UE ID, its current location, and various context information (e.g., type of service or application being used, etc.) to the NMM 408, the NMM 408 may query, based on the identity (ID) of the UE 403 for example, a User Profile DB 412 to obtain profile information associated with the UE 402, the NMM 408 stores the UE's profile information with the ESPL of the UE 402, 0054, Figure 4, 412) (The certificates may be stored locally within a secure hardware module and invoked, for example, by a Trusted Execution Environment that is virtualized or via a Trusted Platform Module/Trusted Execution Environment. SPV certificates may additionally, or alternatively, be stored securely in a network element or server and fetched when needed using secure mechanisms. 0035), wherein the device record includes a security posture of the endpoint device (a security posture may also be referred to as a security posture value (SPV) or a security posture level, a security posture may be represented quantitatively or qualitatively. The security posture may provide a verifiable point-in-time trust metric on the overall level of trust in a node, 0020) (security postures are extended to indicate an evaluation of systems. Such evaluations may include, for example, a vulnerability assessment, penetration testing, or a TRA of live, production or development systems, 0022) (The security posture of a device may indicate, for instance include, parameters associated with security applications (e.g., a list of virus detection applications, the scan status associated with each virus detection application, a time of the last vulnerability assessment by way of security scan results) that are on the device, 0024) and an indication of ownership of the endpoint device (an example certificate 200 is shown that is issued to a device that is identified by its Device name (8686.NorristownFD.org). As shown, the device belongs to the Norristown Fire Department., 0035) (Figure 2) (the PVB may optionally authenticate the first CN 304 in order to verify the real identity of the certificate owner, 0051);
receive the device record (based on a profile of the UE 302, a Security Posture requirement of the UE 302, or other attributes (e.g., location, QoS, etc.), the Network Mobility Manager (NMM) 308 identifies potential Candidate Networks for the UE 302 to connect or offload, 0050) (a User Profile DB 412 to obtain profile information associated with the UE 402, the NMM 408 stores the UE's profile information with the ESPL of the UE 402, 0054, Figure 4, 412);
determine a scope of network access for the endpoint device based on a combination of the device record (based on a profile of the UE 302, a Security Posture requirement of the UE 302, or other attributes (e.g., location, QoS, etc.), the Network Mobility Manager (NMM) 308 identifies potential Candidate Networks for the UE 302 to connect or offload, 0050) (the security postures (SPV.sub.1 and SPV.sub.2) are compared with each other to determine which security posture is best suited for the UE 302, 0051), user authentication associated with the network access request (the PVB may optionally authenticate the first CN 304 in order to verify the real identity of the certificate owner, 0051), and one or more network security policies (A consumer of a service may be provisioned with an appropriate set of policies so that the consumer may use the certificates to assess the trustworthiness of a service provider before a respective service is consumed. Policies may dictate whether the SPV of an entire platform is required. Policies may further stipulate whether the SPV of each component is required or whether a cumulative SPV is permitted or required. 0039); and
selectively grant network access to the endpoint device based on the determination (the security posture that indicates that its associated network is most secure as compared to the other candidate networks is selected. In the illustrated example, the SPV associated with the first CN 304 is adequate as compared to the ESPL of the UE 302, and the SPV associated with the first CN 304 is determined to be better than the SPV associated with the second CN 306. Thus, the PVB 310 selects the first CN 304 as the network (which can be an AP or Base station for example) to offload or attach. At 332, the result of the posture verification and comparison is communicated to the NMM 308. 0051).
Howry et al. does not disclose zero trust security processing as claimed.
However, Mahajan et al. teaches FIG. 6 is a network diagram of a Zero Trust Network Access (ZTNA) application utilizing the cloud-based system 100. For ZTNA, the cloud-based system 100 can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 404, connected to enterprise file shares and applications. (0066),
The user device 300 and the unified agent application 350 can perform a registration/identity 620 process through the agent manager cloud 606 where the user identity, the user's certificates, and a device fingerprint can uniquely identify the user device 300. Once registered, the unified agent application 350 has an identity 622, which can include the user, certificates, device posture, etc. and which is shared with the cloud-based system 100. (0080).
Howry et al. and Mahajan et al. are analogous art because they are from the same field of endeavor of network security/trust security.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Mahajan et al. in Howry et al. for enforcing security policies on mobile devices in a hybrid architecture, to leverage the benefits of both approaches while reducing or eliminating the shortcomings. (see Mahajan et al. 0008)
Claims 19, 23, 26:
With respect to claims 19, 23, 26, Howry et al. discloses wherein the device identification is a unique device identification embedded in the device certificate (the SPV of an entity may be represented in the form of a digital certificate, an example certificate 200 is shown that is issued to a device that is identified by its Device name (8686.NorristownFD.org), type, 0034, Figure 2).
Claims 20, 24, 27:
With respect to claims 20, 24, 27, Howry et al. discloses wherein requesting the device record comprises transmitting the device identification to an endpoint management system (the UE 402 may periodically provide its UE ID, its current location, and various context information (e.g., type of service or application being used, etc.) to the NMM 408, the NMM 408 may query, based on the identity (ID) of the UE 403 for example, a User Profile DB 412 to obtain profile information associated with the UE 402, the NMM 408 stores the UE's profile information with the ESPL of the UE 402, 0054, Figure 4, 412).
Claims 21, 25, 28:
With respect to claims 21, 25, 28, Howry et al. discloses wherein the device record further includes the device identification (the UE 402 may periodically provide its UE ID, its current location, and various context information (e.g., type of service or application being used, etc.) to the NMM 408, the NMM 408 may query, based on the identity (ID) of the UE 403 for example, a User Profile DB 412 to obtain profile information associated with the UE 402, the NMM 408 stores the UE's profile information with the ESPL of the UE 402, 0054, Figure 4, 412).
Claims 22, 29:
With respect to claims 22, 29, Howry et al. discloses wherein the access node receives the device record from an endpoint management system maintaining the device record (At 418, the NMM 408 may query, based on the identity (ID) of the UE 403 for example, a User Profile DB 412 to obtain profile information associated with the UE 402. , 0054, 418, Figure 4).
Claims 30, 31:
With respect to claims 30, 31, Howry et al. discloses wherein determining the scope of network access comprises determining the scope of network access based on the security posture of the endpoint device (based on a profile of the UE 302, a Security Posture requirement of the UE 302, or other attributes (e.g., location, QoS, etc.), the Network Mobility Manager (NMM) 308 identifies potential Candidate Networks for the UE 302 to connect or offload, 0050) (the security postures (SPV.sub.1 and SPV.sub.2) are compared with each other to determine which security posture is best suited for the UE 302, 0051), the indication of ownership of the endpoint device
(an example certificate 200 is shown that is issued to a device that is identified by its Device name (8686.NorristownFD.org). As shown, the device belongs to the Norristown Fire Department., 0035) (Figure 2) (the PVB may optionally authenticate the first CN 304 in order to verify the real identity of the certificate owner, 0051), the user authentication (the PVB may optionally authenticate the first CN 304 in order to verify the real identity of the certificate owner, 0051), and the one or more network security policies (A consumer of a service may be provisioned with an appropriate set of policies so that the consumer may use the certificates to assess the trustworthiness of a service provider before a respective service is consumed. Policies may dictate whether the SPV of an entire platform is required. Policies may further stipulate whether the SPV of each component is required or whether a cumulative SPV is permitted or required. 0039).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: see PTO Form 892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Helai Salehi whose telephone number is 571-270-7468. The examiner can normally be reached on Monday - Friday from 9 am to 5 pm., every other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Jeff Pwu, can be reached on 571-272-6798. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/HELAI SALEHI/ Examiner, Art Unit 2433
/JEFFREY C PWU/ Supervisory Patent Examiner, Art Unit 2433
