DETAILED ACTION
This action is in response to the application filed on October 16, 2024. Claims 1-12 are pending. Claims 1-8 represent a method and claims 9-12 represents a system directed to key exchange through a plurality of non-trusted third parties.
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 .
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-12 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.
Claim 1, Line 21, the limitation “out of order” is indefinite. The limitations do not provide a baseline to determine how the order would become “out of order”.
Claim 1, Line 30, “each assigned key server recording the sender and receiver’s identifying information;” is indefinite. The package received by the key server contains an encrypted key-challenge pairs and ordering information, however receiver information is not included. Unclear where the receiver information is obtained from.
Claim 1, Line 32, 34, and 41 discloses “the key”, There is insufficient antecedent basis for this limitation in the claim. Unclear if “the key” corresponds to the ordered key previously mentioned.
Claim 1, Line 40 discloses “the challenge password”, There is insufficient antecedent basis for this limitation in the claim.
Claim 1, Line 39 and 49 discloses “the encryption keys”, There is insufficient antecedent basis for this limitation in the claim.
Independent claims 5 and 9 are rejected due to the issues outlined in (A-E). Dependent claims 2-4, 6-8, and 10-12 are rejected due to their dependency on the independent claims.
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.
Claim(s) 1, 3-5, 7-9 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Von Willich et al. (US 20240267203), hereinafter referred to as Von Willich, in view of Simon et al. (US 20080301435), hereinafter referred to as Simon, in further view of Wilkins et al. (US 20120204032), hereinafter referred to as Wilkins.
Regarding Claim 1, Von Willich discloses:
A networked method for exchanging encrypted data without a public key, the method comprising (In ¶ 5, Von Willich discloses “the method, the indexed random data is used to generate a symmetric cryptographic key for the encrypted communication between the client and the other client.”): providing a sender, comprising a computing device (In ¶ 34, Von Willich discloses “Client—A computing device capable of receiving and storing pre-shared random data (PSRD) and initiating requests for key generation or shared secrets with other Clients via some number of Security Servers;”); providing a receiver, comprising a computing device (In ¶ 34, Von Willich discloses “Client—A computing device capable of receiving and storing pre-shared random data (PSRD) and initiating requests for key generation or shared secrets with other Clients via some number of Security Servers;”); providing three or more independent key servers (In ¶ 21, Von Willich discloses “In yet another case of the computing device, the secure network comprises a plurality of security servers” wherein the examiner interprets the security servers as the claimed key servers), each comprising membership authentication software, an encryption protocol, and a non-transitory storage medium (In ¶ 80, Von Willich discloses “Any DSKE Client can use a protocol to query the identities of other clients from each Security Server, where the Security Server authenticates and the DSKE Client validates the identity claim by the Security Server using an information-theoretically secure message tag” and further discloses in ¶ 88 “One-Time Pad encryption for the transfer of secret data from one Security Server to a Client, or vice versa, is an example of encryption with complete secrecy.”); registering the sender with a separate member account on two or more of the key servers; registering the receiver with a separate member account on two or more of the key servers (In ¶ 78, Von Willich discloses “The Client 40 shares random data (the PSRD) with the Security Servers 20 in one or more Security Hubs 30, and key generation can use such data.” And further in ¶ 80 “the Security Server authenticates and the DSKE Client validates the identity claim by the Security Server using an information-theoretically secure message tag”); the sender requesting a list of key servers with which the receiver has registered accounts (In ¶ 80, Von Willich discloses “Any DSKE Client can use a protocol to query the identities of other clients from each Security Server,”); the sender retrieving a list of key servers with which the receiver has registered accounts (In ¶ 80, Von Willich discloses “Any DSKE Client can use a protocol to query the identities of other clients from each Security Server,”); the sender generating an ordered key corresponding to the number of key servers on which the sender and receiver have registered accounts in common (In ¶ 81, Von Willich discloses “Alice uses a pre-agreed family of (N, k) secret sharing schemes to generate N shares S.sub.1, S.sub.2, . . . , S.sub.N of the final key S. Share S.sub.1 is associated with Security Server 1, share S.sub.2 is associated with Security Server 2, and so on. k is the minimum number of these shares from which it is possible to reconstruct the key S, which is to be shared between Alice and Bob”); the sender generating a challenge paired with each key generated (In ¶ 81, Von Willich discloses “Alice arrives at N strings of bits like the following: R.sup.A.sub.i=[H.sup.A.sub.i,j, H.sup.A.sub.i,j+1, H.sup.A.sub.i,j+2, . . . , H.sup.A.sub.i,j+m+I−1], where j is the index into the table H.sup.A.sub.i, optionally of the first bit that has never been used before in the DSKE protocol.”); the sender randomly assigning a key and paired challenge out of order to each key server in common (In ¶ 82, Von Willich discloses “She arbitrarily selects k Security Servers for which she sets Y.sub.i=R.sup.A.sub.i and uses this as a share for Security Server i.”); the sender encrypting the key-challenge pairs and ordering information into packages corresponding to the assigned key servers, using the encryption protocol employed by the key servers (In ¶ 83, Von Willich discloses “During the third part, referred to as “Share Distribution”, for each i∈{1, 2, . . . , N}, Alice encodes N, k, the ordered indices of the sequence of bits R.sup.A.sub.i from H.sup.A.sub.i (which, for example, may simply be a start index and a length), along with Bob's identity, a unique key identifier (which, for example, may include an index into a running key), and the key tag if generated.”); sending the packages to the assigned key servers and storing them in association with the sender’s account (In ¶ 83, Von Willich discloses “The Security Server i marks all the bits of H.sup.A.sub.i that were consumed in the process as ‘used’.”); each assigned key server authenticating the sender’s account (In ¶ 80, Von Willich discloses “where the Security Server authenticates and the DSKE Client validates the identity claim by the Security Server using an information-theoretically secure message tag.”); each assigned key server decrypting the stored package (In ¶ 83, Von Willich discloses “Security Server i interprets the message that it receives from Alice, checking indices for overlap, validates the message tag, and decrypts each share”); each assigned key server recording the sender and receiver’s identifying information (In ¶ 83, Von Willich discloses “Security Server i interprets the message that it receives from Alice, checking indices for overlap, validates the message tag,”); each assigned key server recording the key and its ordering information from the decrypted package (In ¶ 83, Von Willich discloses “checking indices for overlap, validates the message tag, and decrypts each share, marking as ‘used’ the indices into H.sup.A.sub.i. The Security Server i marks all the bits of H.sup.A.sub.i that were consumed in the process as ‘used’.”); the assigned key servers transmitting the stored key and ordering information to the receiver (In ¶ 84, Von Willich discloses “Security Server i then builds a key instruction message for Bob as Alice did for Security Server i, including an encoding of the sequence of indices of the sequence of bits used from H.sup.B.sub.i, Alice's identifier, the key identifier, the encrypted share Z.sup.B.sub.i, the key tag that Alice may have included and a message tag. Security Server i then sends this message to Bob.”); the assigned key servers deleting their records of the stored keys, ordering information, and challenges (In ¶ 4, Von Willich discloses “the method further comprising deleting the portion of the indexed random data shared with the client after the portion is used for the encrypted communication.”); the receiver compiling the received keys in ordered form (In ¶ 86, Von Willich discloses “he reconstructs a candidate secret from each subset of k shares with consistent protocol parameters (including the key tag, if present) using the associated (N, k) secret sharing scheme.”); the receiver confirming the encryption key compilation with the sender (In ¶ 87, Von Willich discloses “Bob matches all reconstructed candidate secrets against the key tag applicable to the subset of k shares that it was derived from”); and the sender and receiver exchanging one or more messages encrypted using the compiled keys (In ¶ 88, Von Willich discloses “the Clients 40 are in a position to use approaches for secure communication, such as those described herein, over classical communication channels”).
However, Von Willich does not disclose the key servers generating and providing a hash to the sender.
Simon discloses:
each assigned key server creating a hash for the key using the challenge from the decrypted package (In ¶ 20, Simon discloses “Server 104 generates a challenge (e.g., a random value) and encrypts it using the user's salted hash.”); each assigned key server encrypting and delivering a message comprising the hash of the challenge and status information to the sender (In ¶ 24, Simon discloses “Server 104 adds one to the value and returns the new value encrypted with the session key.”); the sender verifying the hash (In ¶ 24 Simon discloses “At 314, client 102 decrypts the server's incremented nonce and verifies it.”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Von Willich’s approach by utilizing Simon’s approach to perform a verification between the server and the client as the motivation would be to ensure mutual verification between both devices (Simon, ¶ 24).
However, Von Willich does not disclose the sender delivering a list of assigned key servers to a receiver.
Wilkins discloses:
the sender delivering a list of assigned key servers through which the encryption keys may be obtained and the challenge password (In ¶ 98, Wilkins discloses “User A conveys the SN 22 to User B. In one embodiment, the SN 22 is conveyed, along with an associated trademark that identifies the source of the SN 22 and the associated KES 10.”); the receiver requesting the keys from the assigned key servers (In ¶ 99, Wilkins discloses “The communication application is adapted to transmit an entered serial number 22 to the KES 10 and requests corresponding encryption key information associated with User A.”); the assigned key servers each authenticating the receiver’s accounts and challenge password (In ¶ 100, Wilkins discloses “The encryption key request is transmitted from the network device 32 to the KES 10 and may include a ‘User ID’ for authentication of the requester”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Von Willich’s approach by utilizing Wilkins approach to provide information for where to obtain the password as well as an identifier to the password as the motivation would be to facilitate a secure exchange of keys between two users using a remote entity (Wilkins, ¶ 257).
Regarding Claim 3, the combination of Von Willich, Simon, and Wilkins discloses:
The method of Claim 1, wherein the ordered keys generated are each 16-byte random numbers. (In ¶ 81, Von Willich discloses “To generate the key shares that will be used to distribute the key to Bob, Alice first decides the length of the key to be generated, i.e. the number of bits m in the key that she wants to share with Bob.” wherein m can represent 128 bits (i.e. 16 bytes).”)
Regarding Claim 4, the combination of Von Willich, Simon, and Wilkins discloses:
The method of Claim 3, wherein the challenges paired with the ordered keys are random numbers (In ¶ 81, Von Willich discloses “Alice arrives at N strings of bits like the following: R.sup.A.sub.i=[H.sup.A.sub.i,j, H.sup.A.sub.i,j+1, H.sup.A.sub.i,j+2, . . . , H.sup.A.sub.i,j+m+I−1], where j is the index into the table H.sup.A.sub.i, optionally of the first bit that has never been used before in the DSKE protocol.”);
Regarding Claim 5, Von Willich discloses:
A networked method for exchanging encrypted data without a public key, the method comprising (In ¶ 5, Von Willich discloses “the method, the indexed random data is used to generate a symmetric cryptographic key for the encrypted communication between the client and the other client.”): providing a sender, comprising a computing device (In ¶ 34, Von Willich discloses “Client—A computing device capable of receiving and storing pre-shared random data (PSRD) and initiating requests for key generation or shared secrets with other Clients via some number of Security Servers;”); providing a receiver, comprising a computing device (In ¶ 34, Von Willich discloses “Client—A computing device capable of receiving and storing pre-shared random data (PSRD) and initiating requests for key generation or shared secrets with other Clients via some number of Security Servers;”); providing three or more independent key servers (In ¶ 21, Von Willich discloses “In yet another case of the computing device, the secure network comprises a plurality of security servers” wherein the examiner interprets the security servers as the claimed key servers), each comprising membership authentication software, an encryption protocol, and a non-transitory storage medium (In ¶ 80, Von Willich discloses “Any DSKE Client can use a protocol to query the identities of other clients from each Security Server, where the Security Server authenticates and the DSKE Client validates the identity claim by the Security Server using an information-theoretically secure message tag” and further discloses in ¶ 88 “One-Time Pad encryption for the transfer of secret data from one Security Server to a Client, or vice versa, is an example of encryption with complete secrecy.”); registering the sender with a separate member account on two or more of the key servers ; registering the receiver with a separate member account on two or more of the key servers (In ¶ 78, Von Willich discloses “The Client 40 shares random data (the PSRD) with the Security Servers 20 in one or more Security Hubs 30, and key generation can use such data.” And further in ¶ 80 “the Security Server authenticates and the DSKE Client validates the identity claim by the Security Server using an information-theoretically secure message tag”); the sender requesting a list of key servers with which the receiver has registered accounts (In ¶ 80, Von Willich discloses “Any DSKE Client can use a protocol to query the identities of other clients from each Security Server,”); the sender retrieving a list of key servers with which the receiver has registered accounts (In ¶ 80, Von Willich discloses “Any DSKE Client can use a protocol to query the identities of other clients from each Security Server,”); the sender generating an ordered key corresponding to the number of key servers on which the sender and receiver have registered accounts in common (In ¶ 81, Von Willich discloses “Alice uses a pre-agreed family of (N, k) secret sharing schemes to generate N shares S.sub.1, S.sub.2, . . . , S.sub.N of the final key S. Share S.sub.1 is associated with Security Server 1, share S.sub.2 is associated with Security Server 2, and so on. k is the minimum number of these shares from which it is possible to reconstruct the key S, which is to be shared between Alice and Bob”); the sender encrypting a message for the receiver utilizing the ordered keys (In ¶ 90, Von Willich discloses “One-Time-Pad encryption and information-theoretically secure authentication, and sends the encrypted and authenticated message to Bob.”); the sender generating a challenge paired with each key generated (In ¶ 81, Von Willich discloses “Alice arrives at N strings of bits like the following: R.sup.A.sub.i=[H.sup.A.sub.i,j, H.sup.A.sub.i,j+1, H.sup.A.sub.i,j+2, . . . , H.sup.A.sub.i,j+m+I−1], where j is the index into the table H.sup.A.sub.i, optionally of the first bit that has never been used before in the DSKE protocol.”); the sender randomly assigning a key and paired challenge out of order to each key server in common(In ¶ 82, Von Willich discloses “She arbitrarily selects k Security Servers for which she sets Y.sub.i=R.sup.A.sub.i and uses this as a share for Security Server i.”); the sender encrypting the key-challenge pairs and ordering information into packages corresponding to the assigned key servers, using the encryption protocol employed by the key servers (In ¶ 83, Von Willich discloses “During the third part, referred to as “Share Distribution”, for each i∈{1, 2, . . . , N}, Alice encodes N, k, the ordered indices of the sequence of bits R.sup.A.sub.i from H.sup.A.sub.i (which, for example, may simply be a start index and a length), along with Bob's identity, a unique key identifier (which, for example, may include an index into a running key), and the key tag if generated.”); sending the packages to the assigned key servers and storing them in association with the sender's account (In ¶ 83, Von Willich discloses “The Security Server i marks all the bits of H.sup.A.sub.i that were consumed in the process as ‘used’.”); each assigned key server authenticating the sender's account (In ¶ 80, Von Willich discloses “where the Security Server authenticates and the DSKE Client validates the identity claim by the Security Server using an information-theoretically secure message tag.”); each assigned key server decrypting the stored package (In ¶ 83, Von Willich discloses “Security Server i interprets the message that it receives from Alice, checking indices for overlap, validates the message tag, and decrypts each share”); each assigned key server recording the sender and receiver's identifying information (In ¶ 83, Von Willich discloses “Security Server i interprets the message that it receives from Alice, checking indices for overlap, validates the message tag,”); the assigned key servers transmitting the stored key and ordering information to the receiver (In ¶ 84, Von Willich discloses “Security Server i then builds a key instruction message for Bob as Alice did for Security Server i, including an encoding of the sequence of indices of the sequence of bits used from H.sup.B.sub.i, Alice's identifier, the key identifier, the encrypted share Z.sup.B.sub.i, the key tag that Alice may have included and a message tag. Security Server i then sends this message to Bob.”); the assigned key servers deleting their records of the stored keys, ordering information, and challenges (In ¶ 4, Von Willich discloses “the method further comprising deleting the portion of the indexed random data shared with the client after the portion is used for the encrypted communication.”); the receiver compiling the received keys in ordered form (In ¶ 86, Von Willich discloses “he reconstructs a candidate secret from each subset of k shares with consistent protocol parameters (including the key tag, if present) using the associated (N, k) secret sharing scheme.”); and the receiver decrypting the encrypted message using the compiled keys (In ¶ 88, Von Willich discloses “the Clients 40 are in a position to use approaches for secure communication, such as those described herein, over classical communication channels”).
However, Von Willich does not disclose the key servers generating and providing a hash to the sender.
Simon discloses:
each assigned key server creating a hash for the key using the challenge from the decrypted package (In ¶ 20, Simon discloses “Server 104 generates a challenge (e.g., a random value) and encrypts it using the user's salted hash.”); each assigned key server encrypting and delivering a message comprising the hash of the challenge and status information to the sender (In ¶ 24, Simon discloses “Server 104 adds one to the value and returns the new value encrypted with the session key.”); the sender verifying the hash (In ¶ 24 Simon discloses “At 314, client 102 decrypts the server's incremented nonce and verifies it.”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Von Willich’s approach by utilizing Simon’s approach to perform a verification between the server and the client as the motivation would be to ensure mutual verification between both devices (Simon, ¶ 24).
However, Von Willich does not disclose the sender delivering a list of assigned key servers to a receiver.
Wilkins discloses:
the sender delivering a list of assigned key servers through which the encryption keys may be obtained and the challenge password (In ¶ 98, Wilkins discloses “User A conveys the SN 22 to User B. In one embodiment, the SN 22 is conveyed, along with an associated trademark that identifies the source of the SN 22 and the associated KES 10.”); the receiver requesting the keys from the assigned key servers (In ¶ 99, Wilkins discloses “The communication application is adapted to transmit an entered serial number 22 to the KES 10 and requests corresponding encryption key information associated with User A.”); the assigned key servers each authenticating the receiver’s accounts and challenge password (In ¶ 100, Wilkins discloses “The encryption key request is transmitted from the network device 32 to the KES 10 and may include a ‘User ID’ for authentication of the requester”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Von Willich’s approach by utilizing Wilkins approach to provide information for where to obtain the password as well as an identifier to the password as the motivation would be to facilitate a secure exchange of keys between two users using a remote entity (Wilkins, ¶ 257).
Regarding Claim 7, the combination of Von Willich, Simon, and Wilkins discloses:
The method of Claim 5, wherein the ordered keys generated are each 16-byte random numbers. (In ¶ 81, Von Willich discloses “To generate the key shares that will be used to distribute the key to Bob, Alice first decides the length of the key to be generated, i.e. the number of bits m in the key that she wants to share with Bob.” wherein m can represent 128 bits (i.e. 16 bytes).”)
Regarding Claim 8, the combination of Von Willich, Simon, and Wilkins discloses:
The method of Claim 7, wherein the challenges paired with the ordered keys are random numbers (In ¶ 81, Von Willich discloses “Alice arrives at N strings of bits like the following: R.sup.A.sub.i=[H.sup.A.sub.i,j, H.sup.A.sub.i,j+1, H.sup.A.sub.i,j+2, . . . , H.sup.A.sub.i,j+m+I−1], where j is the index into the table H.sup.A.sub.i, optionally of the first bit that has never been used before in the DSKE protocol.”);
Claims 9 and 11-12 are directed to a system having functionality corresponding to the method of Claims 5 and 7-8 respectively, and are rejected by a similar rationale, mutatis mutandis.
Claim(s) 2, 6, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Von Willich et al. (US 20240267203), hereinafter referred to as Von Willich, in view of Simon et al. (US 20080301435), hereinafter referred to as Simon, in further view of Wilkins et al. (US 20120204032), hereinafter referred to as Wilkins, in further view of Heath et al. (US 20220391831), hereinafter referred to as Heath.
Regarding Claim 2, the combination of Von Willich, Simon, and Wilkins discloses the limitations of Claim 1.
However, Von Willich does not explicitly disclose a membership software associated with a digital currency.
Heath discloses:
The method of Claim 1, wherein the membership authentication software is associated with a digital currency (In ¶ 48, Heath discloses “Authorization may be provided to a user based on a characteristic that is identified from a record in a blockchain. Authorization pertains to what a user is allowed to do rather than who the user is (which is authentication). The blockchain may be the same blockchain used to provide the authentication for the user. For example, authorization may be based on the amount of funds in a cryptocurrency wallet (either in cryptocurrency or in fiat currency equivalents). In an embodiment, an authorization may identify that a cryptocurrency wallet associated with a private key has more than a threshold value of currency in the wallet.”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Von Willich’s approach by utilizing Heath’s approach to utilize blockchain and digital currency as the motivation would be to ensure a secure method of managing transactions and information within the blockchain as the blockchain ensures full transparency (Heath, ¶ 107).
Regarding Claim 6, the combination of Von Willich, Simon, and Wilkins discloses the limitations of Claim 5.
However, Von Willich does not explicitly disclose a membership software associated with a digital currency.
Heath discloses:
The method of Claim 1, wherein the membership authentication software is associated with a digital currency (In ¶ 48, Heath discloses “Authorization may be provided to a user based on a characteristic that is identified from a record in a blockchain. Authorization pertains to what a user is allowed to do rather than who the user is (which is authentication). The blockchain may be the same blockchain used to provide the authentication for the user. For example, authorization may be based on the amount of funds in a cryptocurrency wallet (either in cryptocurrency or in fiat currency equivalents). In an embodiment, an authorization may identify that a cryptocurrency wallet associated with a private key has more than a threshold value of currency in the wallet.”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Von Willich’s approach by utilizing Heath’s approach to utilize blockchain and digital currency as the motivation would be to ensure a secure method of managing transactions and information within the blockchain as the blockchain ensures full transparency (Heath, ¶ 107).
Claim 10 is directed to a system having functionality corresponding to the method of Claim 9, and is rejected by a similar rationale, mutatis mutandis.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Holyfield et al. (US 20150271146) discloses a method for secure transfer of files or data between persons using a third party host.
McCarty et al. (US 20210111898 ) discloses an apparatus for authenticating and authorizing users using quantum key distribution through segmented quantum computing environments.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHADI H KOBROSLI whose telephone number is (571)272-1952. The examiner can normally be reached M-F 9am-5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rupal Dharia can be reached at 571-272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHADI H KOBROSLI/Examiner, Art Unit 2492 /RUPAL DHARIA/ Supervisory Patent Examiner, Art Unit 2492