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
This is the initial office action that has been issued in response to patent application, 18/613,099, filed on 03/21/2024. Claims 1-20 are currently pending and have been considered below. Claims 1, 9 and 15 are independent claims.
Priority
The application claims priority of provisional application PRO 63/491,532 filled on 03/21/2024.
Drawings
The drawings filed on 03/21/2024 are accepted by the examiner.
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.
Claims 1, 9 and 15 recites the limitation “the data”, “the signed data”, “the data token”. It is unclear what structure or element these phrases refer to. There is insufficient antecedent basis for this limitation in the claim.
Claims 1 and 15 recite the limitation “verifying images” The term “images” is vague and lacks sufficient clarity because the specification describes verifying “digital content,” not specifically “images.”. There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites the limitation “attestation information.”This limitation is vague and lacks sufficient clarity because the specification does not clearly define the structure or content of the “attestation information.” There is insufficient antecedent basis for this limitation in the claim.
Claim 4 recites the limitation “computer instructions of the mobile device.” This limitation is indefinite because it is unclear whether it refers to the verifying application, the operating system, or other general executable code. There is insufficient antecedent basis for this limitation in the claim.
Claim 5 recites the limitation “at least one of user content and a hash of user content.” This limitation is indefinite because the phrase “at least one of … and …” renders the scope ambiguous as to whether one, both, or any combination of the listed items is required. There is insufficient antecedent basis for this limitation in the claim.
Claim 6 recites the limitation “verified data.” This limitation lacks sufficient clarity because the specification does not define what constitutes “verified data,”
There is insufficient antecedent basis for this limitation in the claim.
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. therefore, they are rejected based on the same rational as applied to their parent claims above.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Mathias(US 20200052905 A1).
Regarding Claim 1:
Mathias discloses:
A system for verifying images, comprising: a server having a server processor and a server memory, the server processor coupled to the server memory(Mathias, [0044-0047], System 110, in the illustrated embodiment, includes control unit 137 and receives a pairing request 140 from a use… Mobile device 130, in the illustrated embodiment, includes an application processor (AP) 136 and wireless interface 132 …a system and a mobile device to perform an operation, according to some embodiments…[0049], mobile device 130 further includes a secure enclave processor (SEP) 210, cellular interface 220, CPU 230, memory 240, peripherals 250 coupled via a communication fabric 260. As shown, SEP 210 may include one or more processors P 212, a secure memory 214);
and a mobile device having a device processor and a device memory, the device processor coupled to the device memory(Mathias, [0040], The mobile device and system may include any suitable hardware to implement functionality described herein. Accordingly, this hardware may include a processor subsystem coupled to a system memory… [0049], Mobile device 130 may include wireless interface 132, SE 134, and biosensor 138. In the illustrated embodiments, mobile device 130 further includes a secure enclave processor (SEP) 210, cellular interface 220, CPU 230, memory 240, peripherals 250 coupled via a communication fabric 260. As shown, SEP 210 may include one or more processors P 212, a secure memory 214,);
wherein the server includes computer program instructions that, when executed by the server processor, cause the server processor to: receive a request from the mobile device to sign a device public key of the mobile device(Mathias, [0039], .an owner of the system may wish to enable a mobile device of another user to access the system. In some embodiments, a secure element of the other user's mobile device may generate a public key pair and a corresponding certificate signing request for the public key. The other user's device may then send the certificate signing request to the secure element of the owner's mobile device, which generates a certificate for public key);
and in response to the request from the mobile device, sign the device public key with a server private key of the server and return the signed device public key to the mobile device(Mathias, [0123], In some embodiments, in response to a second request to permit another mobile device to access the system, the mobile device signs, using a private key of the public key pair, a certificate for another public key pair generated by a secure circuit of the other mobile device. In some embodiments, the mobile device requests, via a wide area network, a server signature of the certificate signed by the secure circuit and the server signature is usable by the system to determine whether to grant an operation requested by the other mobile device.);
and wherein the mobile device includes computer program instructions that, when executed by the device processor, cause the device processor to: generate data for verification(Mathias, [0174], Mobile device 130 then generates phoneAuthenticatedData as the previously-computed phone data and phoneSig if the verification is successful and sends AUTH1 response 940 with the phoneAuthenticatedData);
sign the data with a device private key of the mobile device(Marthais, [0123], the mobile device signs, using a private key);
and store the signed data(Mathias, [0259], the signed certificates are stored), the device public key of the mobile device, and the signed device public key of the mobile device as a data token within the device memory.
Regarding Claim 2:
Mathias discloses:
The system of claim 1 wherein the device memory includes computer program instructions that, when executed by the device processor, cause the device processor to: create the device private key and the device public key(Mathias, [0303], the system generates a first shared secret using a key exchange function that uses the first private key and the second public key as inputs.);
send a request to the server with the device public key(Mathias, [0310], At 3012, mobile device OS 2120 sends a command to SE applet 3030 to create a digital key according to the configuration information. SE applet 3030 creates the digital key (which may include various information discussed herein such as a long-term public key pair for the pairing session) and sends an attestation and the public key to mobile device OS);
and receive the signed device public key from the server(Mathisa, Claim 1, verify a signed certificate received from the system using the public key of the system,).
Regarding Claim 3:
Mathias discloses:
The system of claim 2 wherein the device memory includes computer program instructions that, when executed by the device processor, cause the device processor to: provide attestation information to the server to verify computer program instructions of the mobile device(Mathisa, [0310], the mobile device 130 is configured to request from the SE a revocation attestation on a revoked key, as shown in 1706, which may be signed by phone. SK. In the illustrated embodiment, the mobile device returns a revocation attestation 1708 and the server 146 verifies the authenticity of the revocation attestation using phone.PK at 1710. In some embodiments, the mobile device 130 is configured to instruct the SE to delete the keys in revoked state, as shown in elements 1712-1716).
Regarding Claim 4:
Mathias discloses:
The system of claim 3 wherein the server memory includes computer program instructions that, when executed by the server processor, cause the server processor to: receive attestation information from the mobile device(Mathias, [0252], the mobile device 130 is configured to request from the SE a revocation attestation on a revoked key, as shown in 1706, which may be signed by phone. SK. In the illustrated embodiment, the mobile device returns a revocation attestation 1708 and the server 146 verifies the authenticity of the revocation attestation using phone.PK at 1710);
determine if computer instructions of the mobile device are valid based on the attestation information(Mathias, [0311], System 110 then verifies, at 3018 the attestation data and accepts or rejects the public key based on the verification.);
sign the device public key and return the signed device public key to the mobile device if the server determines the computer instructions of the mobile device are valid based on the attestation information(Mathias, [0206], An operating system of the mobile device may instruct one or more applets on a secure element to create the digital key according to the configuration. The SE may also generate the long-term public key pair phone.PK and phone. SK. In some embodiments, the SE generates a certificate with the configuration information (as an attestation that the digital key has been created according to the configuration) and signs it using the phone.SK. In these embodiments, the system 110 may verify that the digital key was properly created by verifying the certificate and confirming that the configuration information is correct.);
and not sign the device public key if the server determines the computer instructions of the mobile device are invalid based on the attestation information(Mathias, [0253], In various embodiments, the disclosed techniques may allow for system, owner-device, and/or internet-based revocations with attestation that the revoked keys were actually removed or frozen on a sharee device.).
Regarding Claim 5:
Mathias discloses:
The system of claim 1 wherein the data includes at least one of user content and a hash of user content(Mathias, [0050], SEP 210 is configured to maintain previously-captured biometric template data 218 of one or more authorized users).
Regarding Claim 6:
Mathias discloses:
The system of claim 1 wherein the mobile device is configured to share verified data with another mobile device without communicating with the server(Mathias, [0075], a text confirmation is then performed (this step may be omitted in other embodiments) and both the mobile device 130 and the system 110 generate text information based on the shared secret and display the text information to the user at 338. [0094], application processor 136, and SE 134 for granting authorization to another mobile device 160. [0096], owner AP 136 sends a notification at 504 that key sharing is desired and information specifying the entitlements to other AP 536 (where other AP 536 and other SE 534 are included in another mobile device 160, ).
Regarding Claim 7:
Mathias discloses:
The system of claim 6 wherein the device memory includes computer program instructions that, when executed by the device processor, cause the device processor to share data and the data token with another mobile device without communicating with the server(Mathias, [0075], a text confirmation is then performed (this step may be omitted in other embodiments) and both the mobile device 130 and the system 110 generate text information based on the shared secret and display the text information to the user at 338. [0094], application processor 136, and SE 134 for granting authorization to another mobile device 160. [0096], owner AP 136 sends a notification at 504 that key sharing is desired and information specifying the entitlements to other AP 536 (where other AP 536 and other SE 534 are included in another mobile device 160 ) .
Regarding Claim 8:
Mathias discloses:
The system of claim 1 wherein: the server memory includes secure memory and standard memory(Mathias, [0049], mobile device 130 further includes a secure enclave processor (SEP) 210, cellular interface 220, CPU 230, memory 240, peripherals 250 coupled via a communication fabric 260. As shown, SEP 210 may include one or more processors P 212, a secure memory 214, and one or more security peripherals 216.);
the server processor includes a secure processor and a standard processor(Mathias, [0036], …In some embodiments, other types of secure circuits or secure processors may perform functionality described as being performed by a secure element, including, for example, a secure enclave processor discussed below);
the device memory includes secure memory and standard memory(Mathias, [0049], mobile device 130 further includes a secure enclave processor (SEP) 210, cellular interface 220, CPU 230, memory 240, peripherals 250 coupled via a communication fabric 260. As shown, SEP 210 may include one or more processors P 212, a secure memory 214, and one or more security peripherals 216. SE 134 may include one or more processors P 222 and a memory 224. CPU 320 may include one or more processors P 232. Memory 240);
and the device processor includes a secure processor and a standard processor( Mathias, [0049], Mobile device 130 may include wireless interface 132, SE 134, and biosensor 138. In the illustrated embodiments, mobile device 130 further includes a secure enclave processor (SEP) 210, cellular interface 220, CPU 230, memory 240, peripherals 250, coupled via a communication fabric 260. As shown, SEP 210 may include one or more processors P 212,);
wherein the server private key is stored in the secure memory of the server (Mathias,[0053], a secure memory 214 may include software executable by SEP processor 212. The software may be stored in the memory 240 in encrypted form to avoid observation. Despite the steps taken to ensure security of the secure software, the secure software may still be prevented from directly accessing/obtaining stored private keys );
and wherein the device private key is stored in the secure memory of the mobile device(Mathias, [0053], The software may be stored in the memory 240 in encrypted form to avoid observation. Despite the steps taken to ensure security of the secure software, the secure software may still be prevented from directly accessing/obtaining stored private keys. Only hardware may have access to private keys, in an embodiment).
Regarding Claim 9:
Mathias discloses:
A method of verifying images, comprising: receiving, at a server, a request from a mobile device to sign a device public key of the mobile device(Mathias, [0039], .an owner of the system may wish to enable a mobile device of another user to access the system. In some embodiments, a secure element of the other user's mobile device may generate a public key pair and a corresponding certificate signing request for the public key. The other user's device may then send the certificate signing request to the secure element of the owner's mobile device, which generates a certificate for public key);
in response to the request from the mobile device, signing, at the server, the device public key with a server private key so as to generate a signed device public key and returning the signed device public key to the mobile device(Mathias, [0123], In some embodiments, in response to a second request to permit another mobile device to access the system, the mobile device signs, using a private key of the public key pair, a certificate for another public key pair generated by a secure circuit of the other mobile device. In some embodiments, the mobile device requests, via a wide area network, a server signature of the certificate signed by the secure circuit and the server signature is usable by the system to determine whether to grant an operation requested by the other mobile device.);
generating, at the mobile device, data for verification(Mathias, [0174], Mobile device 130 then generates phoneAuthenticatedData as the previously-computed phone data and phoneSig if the verification is successful and sends AUTH1 response 940 with the phoneAuthenticatedData);
signing, at the mobile device, the data with a device private key of the mobile device(Marthais, [0123], the mobile device signs, using a private key);
and storing, at the mobile device, the signed data(Marthais, [0123], the mobile device signs, using a private key) ,
the device public key of the mobile device, and the signed device public key of the mobile device as a data token(Mathias, [0039], a secure element of the other user's mobile device may generate a public key pair and a corresponding certificate signing request for the public key. The other user's device may then send the certificate signing request to the secure element of the owner's mobile device, which generates a certificate for public key.).
Regarding Claim 10:
Mathias discloses:
The method of claim 9 further comprising: creating, at the mobile device, the device private key and the device public key(Mathias, [0303], the system generates a first shared secret using a key exchange function that uses the first private key and the second public key as inputs.);
sending, from the mobile device, a request to the server with the device public key(Mathias, [0310], At 3012, mobile device OS 2120 sends a command to SE applet 3030 to create a digital key according to the configuration information. SE applet 3030 creates the digital key (which may include various information discussed herein such as a long-term public key pair for the pairing session) and sends an attestation and the public key to mobile device OS);
and receiving, from the server, the signed device public key(Mathisa, Claim 1, verify a signed certificate received from the system using the public key of the system,).
Regarding Claim 11:
Mathias discloses:
The method of claim 10 further comprising providing, from the mobile device to the server, attestation information to verify computer program instructions of the mobile device(Mathias, [0252], the mobile device 130 is configured to request from the SE a revocation attestation on a revoked key, as shown in 1706, which may be signed by phone. SK. In the illustrated embodiment, the mobile device returns a revocation attestation 1708 and the server 146 verifies the authenticity of the revocation attestation using phone.PK at 1710).
Regarding Claim 12:
Mathias discloses:
The method of claim 10 further comprising: receiving, at the server, attestation information from the mobile device(Mathias, [0252], the mobile device 130 is configured to request from the SE a revocation attestation on a revoked key, as shown in 1706, which may be signed by phone. SK. In the illustrated embodiment, the mobile device returns a revocation attestation 1708 and the server 146 verifies the authenticity of the revocation attestation using phone.PK at 1710);
determining, at the server, if computer instructions of the mobile device are valid based on the attestation information(Mathias, [0311], System 110 then verifies, at 3018 the attestation data and accepts or rejects the public key based on the verification.);
signing, at the server, the device public key and returning the signed device public key to the mobile device if the server determines the computer instructions of the mobile device are valid based on the attestation information(Mathias, [0206], An operating system of the mobile device may instruct one or more applets on a secure element to create the digital key according to the configuration. The SE may also generate the long-term public key pair phone.PK and phone. SK. In some embodiments, the SE generates a certificate with the configuration information (as an attestation that the digital key has been created according to the configuration) and signs it using the phone.SK. In these embodiments, the system 110 may verify that the digital key was properly created by verifying the certificate and confirming that the configuration information is correct.);
and not signing, at the server, the device public key if the server determines the computer instructions of the mobile device are invalid based on the attestation information(Mathias, [0253], In various embodiments, the disclosed techniques may allow for system, owner-device, and/or internet-based revocations with attestation that the revoked keys were actually removed or frozen on a sharee device.).
Regarding Claim 13:
Mathias discloses:
The method of claim 9 further comprising employing the mobile device to share verified data with another mobile device without communicating with the server (Mathias, [0075], a text confirmation is then performed (this step may be omitted in other embodiments) and both the mobile device 130 and the system 110 generate text information based on the shared secret and display the text information to the user at 338. [0094], application processor 136, and SE 134 for granting authorization to another mobile device 160. [0096], owner AP 136 sends a notification at 504 that key sharing is desired and information specifying the entitlements to other AP 536 (where other AP 536 and other SE 534 are included in another mobile device 160 ) .
Regarding Claim 14:
Mathias discloses:
The method of claim 13 further comprising employing the mobile device to share the data and the data token with another mobile device without communicating with the server(Mathias, [0075], a text confirmation is then performed (this step may be omitted in other embodiments) and both the mobile device 130 and the system 110 generate text information based on the shared secret and display the text information to the user at 338. [0094], application processor 136, and SE 134 for granting authorization to another mobile device 160. [0096], owner AP 136 sends a notification at 504 that key sharing is desired and information specifying the entitlements to other AP 536 (where other AP 536 and other SE 534 are included in another mobile device 160 ) .
Regarding Claim 15:
Mathias discloses:
A system for verifying images, comprising: a server having a server processor and a server memory, the server processor coupled to the server memory(Mathias, [0044-0047], System 110, in the illustrated embodiment, includes control unit 137 and receives a pairing request 140 from a use… Mobile device 130, in the illustrated embodiment, includes an application processor (AP) 136 and wireless interface 132 …a system and a mobile device to perform an operation, according to some embodiments…[0049], mobile device 130 further includes a secure enclave processor (SEP) 210, cellular interface 220, CPU 230, memory 240, peripherals 250 coupled via a communication fabric 260. As shown, SEP 210 may include one or more processors P 212, a secure memory 214);
and an application executable on a mobile device having a device processor and a device memory(Mathias, [0040], The mobile device and system may include any suitable hardware to implement functionality described herein. Accordingly, this hardware may include a processor subsystem coupled to a system memory… [0049], Mobile device 130 may include wireless interface 132, SE 134, and biosensor 138. In the illustrated embodiments, mobile device 130 further includes a secure enclave processor (SEP) 210, cellular interface 220, CPU 230, memory 240, peripherals 250 coupled via a communication fabric 260. As shown, SEP 210 may include one or more processors P 212, a secure memory 214,);
wherein the server includes computer program instructions that, when executed by the server processor, cause the server processor to: receive a request from the mobile device to sign a device public key of the mobile device(Mathias, [0039], .an owner of the system may wish to enable a mobile device of another user to access the system. In some embodiments, a secure element of the other user's mobile device may generate a public key pair and a corresponding certificate signing request for the public key. The other user's device may then send the certificate signing request to the secure element of the owner's mobile device, which generates a certificate for public key);
and in response to the request from the mobile device, sign the device public key with a server private key of the server and return the signed device public key to the mobile device(Mathias, [0123], In some embodiments, in response to a second request to permit another mobile device to access the system, the mobile device signs, using a private key of the public key pair, a certificate for another public key pair generated by a secure circuit of the other mobile device. In some embodiments, the mobile device requests, via a wide area network, a server signature of the certificate signed by the secure circuit and the server signature is usable by the system to determine whether to grant an operation requested by the other mobile device.);
and wherein the application executable on the mobile device includes computer program instructions that, when executed by the device processor, cause the device processor to: generate data for verification(Mathias, [0174], Mobile device 130 then generates phoneAuthenticatedData as the previously-computed phone data and phoneSig if the verification is successful and sends AUTH1 response 940 with the phoneAuthenticatedData);
sign the data with a device private key of the mobile device(Marthais, [0123], the mobile device signs, using a private key);
and store the signed data, the device public key of the mobile device, and the signed device public key of the mobile device as a data token within the device memory(Marthais, [0123], the mobile device signs, using a private key).
Regarding Claim 16:
Mathias discloses:
The system of claim 15 wherein the device memory includes computer program instructions that, when executed by the device processor, cause the device processor to: create the device private key and the device public key(Mathias, [0303], the system generates a first shared secret using a key exchange function that uses the first private key and the second public key as inputs.);
send a request to the server with the device public key(Mathias, [0310], At 3012, mobile device OS 2120 sends a command to SE applet 3030 to create a digital key according to the configuration information. SE applet 3030 creates the digital key (which may include various information discussed herein such as a long-term public key pair for the pairing session) and sends an attestation and the public key to mobile device OS);
and receive the signed device public key from the server(Mathisa, Claim 1, verify a signed certificate received from the system using the public key of the system,).
Regarding Claim 17:
Mathias discloses:
The system of claim 16 wherein the device memory includes computer program instructions that, when executed by the device processor, cause the device processor to: provide attestation information to the server to verify computer program instructions of the mobile device(Mathisa, [0310], the mobile device 130 is configured to request from the SE a revocation attestation on a revoked key, as shown in 1706, which may be signed by phone. SK. In the illustrated embodiment, the mobile device returns a revocation attestation 1708 and the server 146 verifies the authenticity of the revocation attestation using phone.PK at 1710. In some embodiments, the mobile device 130 is configured to instruct the SE to delete the keys in revoked state, as shown in elements 1712-1716).
Regarding Claim 18:
Mathias discloses:
The system of claim 17 wherein the server memory includes computer program instructions that, when executed by the server processor, cause the server processor to: receive attestation information from the mobile device(Mathias, [0252], the mobile device 130 is configured to request from the SE a revocation attestation on a revoked key, as shown in 1706, which may be signed by phone. SK. In the illustrated embodiment, the mobile device returns a revocation attestation 1708 and the server 146 verifies the authenticity of the revocation attestation using phone.PK at 1710);
determine if computer instructions of the mobile device are valid based on the attestation information(Mathias, [0311], System 110 then verifies, at 3018 the attestation data and accepts or rejects the public key based on the verification.);
sign the device public key and return the signed device public key to the mobile device if the server determines the computer instructions of the mobile device are valid based on the attestation information(Mathias, [0206], An operating system of the mobile device may instruct one or more applets on a secure element to create the digital key according to the configuration. The SE may also generate the long-term public key pair phone.PK and phone. SK. In some embodiments, the SE generates a certificate with the configuration information (as an attestation that the digital key has been created according to the configuration) and signs it using the phone.SK. In these embodiments, the system 110 may verify that the digital key was properly created by verifying the certificate and confirming that the configuration information is correct.);
and not sign the device public key if the server determines the computer instructions of the mobile device are invalid based on the attestation information(Mathias, [0253], In various embodiments, the disclosed techniques may allow for system, owner-device, and/or internet-based revocations with attestation that the revoked keys were actually removed or frozen on a sharee device.).
Regarding Claim 19:
Mathias discloses:
The system of claim 15 wherein the data includes at least one of user content and a hash of user content(Mathias, [0050], SEP 210 is configured to maintain previously-captured biometric template data 218 of one or more authorized users).
Regarding Claim 20:
Mathias discloses:
The system of claim 15 wherein the mobile device is configured to share verified data with another mobile device without communicating with the server(Mathias, [0075], a text confirmation is then performed (this step may be omitted in other embodiments) and both the mobile device 130 and the system 110 generate text information based on the shared secret and display the text information to the user at 338. [0094], application processor 136, and SE 134 for granting authorization to another mobile device 160. [0096], owner AP 136 sends a notification at 504 that key sharing is desired and information specifying the entitlements to other AP 536 (where other AP 536 and other SE 534 are included in another mobile device 160 ) .
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAYASA SHAAWAT whose telephone number is (571)272-3939. The examiner can normally be reached on M-F, 8 AM TO 5 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, JEFFREY PWU can be reached on (571)272-6789. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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 https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAYASA A. SHAAWAT/Examiner, Art Unit 2433