DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. The RCE amendment, filed on 6/11/2026, is acknowledged and considered.
Claims 1-11, 14, and 16-21 are pending.
Claims 1, 10, and 17 are independent claims.
Claims 12-13 and 15 are cancelled by Applicant. Claim 21 is new.
Continued Examination Under 37 CFR 1.114
3. 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 6/11/2026 has been entered.
Priority
4. The current application has relationship to the following:
PCT/US2021/037235, filing date 06/14/2021
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
5. Claims 1-11, 14, and 16-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1, 10, and 17, currently amended to further limit “an entirety” of the secret. The original disclosure fails to explicitly comply that the secret has to be an entirety, as claimed the “entirety of a/the secret”. The disclosure does not require or suggest an entirety of the secret. Thus, the claimed shared secret may broadly be in an its entirety, or in parts, or shares.
Response to Arguments
6. Applicant’s arguments with respect to claim(s) 1-11, 14, and 16-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
The factual inquiries 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.
7. Claim(s) 1-11, 14, and 16-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Verzun, et al. [US 20180359811] in view of Hoy, et al. [US 20170099140].
As per claim 1: Verzun, teaches a non-transitory computer readable medium storing instructions that, when executed, cause a processor of a further authenticator to:
receive, at the further authenticator, an entirety of a secret from an initial authenticator, an entirety of the secret being accessible by both the further authenticator and the initial authenticator; [Verzun: para 0168; The selector is a part of a body of information referred to as “shared secrets”. Para 0565; the algorithm of seed generation, hidden number generator, and the list of scrambling algorithms represent “shared secrets,” information stored in a DMZ server and not known to either the sender or the recipient of a data packet. The terms “initial authenticator” and “further authenticator” are not explicitly defined, thus, any of the initial or further authenticators can broadly be in the form of a software or hardware such as an application, entity, device or user, or any component used to process or perform authentication per se. As such, an initial authenticator and further authenticator may broadly be in the form of server, node or recipient. The server, node, or recipient may all receive and communicate shared secrets and/or seed to one another, thus, any of the server, node, or recipient may be the initial authenticator and/or further authenticator]
**receive, at a key generator of the further authenticator, seed data to generate authentication data [**rejected under a secondary reference, discussion below], the seed data including the entirety of the secret [Verzun: para 0505-0508], the entirety of the secret being accessible to the initial authenticator and the further authenticator; and [Verzun: para 0174; The shared secrets held by the DMZ servers include selectors or tables of encryption and splitting algorithms and key generators. Para 0176; the seeds and keys may be transmitted through the signaling servers instead of from the sending media node directly to the receiving media node. Para 0566; The algorithm used by the seed generator to produce a seed is part of the shared secrets, and hence knowledge of the seed does not allow one to determine the state on which the seed is based. The seed is passed from one communication node to the next by embedding it within the data packet itself, by sending it through another channel or path]
generate a signature, using the authentication data, for use with a relying party. [Verzun: para 0403, 1051; signature for use with a depending node, application, server, etc. (or relying party)]
Verzun discloses the selector is a part of a body of information referred to as “shared secrets” [Verzun: para 0168]. The shared secrets held by the DMZ servers include selectors or tables of encryption and splitting algorithms and key generators. The seeds and keys may be transmitted through the signaling servers instead of from the sending media node directly to the receiving media node [Verzun: para 0174-0176]. The algorithm of seed generation, hidden number generator, and the list of scrambling algorithms represent “shared secrets,” information stored in a DMZ server and not known to either the sender or the recipient of a data packet. The algorithm used by the seed generator to produce a seed is part of the shared secrets, and hence knowledge of the seed does not allow one to determine the state on which the seed is based. The seed is passed from one communication node to the next by embedding it within the data packet itself, by sending it through another channel or path [Verzun: para 05650-0566]. Verzun suggest a seed data used for authentication data with a key generator. However, Verzun did not clearly teach to “receive, at a key generator of the further authenticator, seed data to generate authentication data”.
Hoy discloses using physical objects to generate physical (e.g., public key-based) authenticators and, in particular, to use “everyday” physical objects to create a generator seed for a key generator that will use that seed to generate a key pair comprising a public key, and its associated private key. The physical object is used to create a digital representation that together with some uniqueness associated to the user, gives rise to a key generator seed value. Without knowledge of the physical object itself, how the physical object characteristic is converted, and the uniqueness value, an attacker cannot reproduce the key generator seed (or the key(s) generated from that seed) [Hoy: para 0051]. FIG. 4 depicts a user selects a physical object to serve as an authenticator. The physical object may be of any type, e.g., a coin, a pen, a pair of glasses, a computer mouse, etc. [Hoy: para 0052]. This suggest there may be multiple possible authenticators which likely will be to produce data (i.e. seed, keys, unique value) for authentication. The digital representation is fed into a key generator as a “seed” value to produce a key pair. Typically, the key generator is a public key generator algorithm such that the key generated is a public key of a key pair comprising the public key and an associated private (secret) key [Hoy: para 0054]. As such one would be motivated to receive seed data “at a key generator of an initial authenticator, seed data to generate authentication data”, is to use the seed to generate a key pair and with the uniqueness value so that an attacker cannot reproduce the key generator seed.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hoy with Verzun to teach to provide seed data “receive, at a key generator of the further authenticator, seed data to generate authentication data” for the reason to use the seed to generate a key pair and with the uniqueness value so that an attacker cannot reproduce the key generator seed [Hoy: para 0051].
Claim 2: Verzun: para 0170-0171, 0193 [the relying party may be any of the nodes or clients that receives the packet with seed or key with data to unscramble or decrypt]; discussing the non-transitory computer readable medium of claim 1, wherein the seed data includes relying party data of the relying party.
Claim 3: Verzun: para 0404; discussing the non-transitory computer readable medium of claim 2, wherein the authentication data includes a private-public key pair associated with the initial authenticator.
Claim 4: Verzun: para 0138, 0660; discussing the non-transitory computer readable medium of claim 3, wherein the authentication data includes the initial authenticator.
Claim 5: Verzun: para 0403-0404 [RSA or public and private key to the dependent node or sender/receiver]; discussing the non-transitory computer readable medium of claim 2, wherein the authentication data includes a relying party specific private-public key pair associated with the initial authenticator, the relying party data and an earlier established private-public key pair associated with the initial authenticator.
Claim 6: Verzun: para 0174, 0193 [a transmitting client device may send a seed and/or key directly to the receiving client device]; discussing the non-transitory computer readable medium of claim 1, wherein the authentication data includes the relying party data and an earlier established public key associated with the further authenticator; and wherein the seed data includes relying party data and an earlier established public key associated with the further authenticator, and wherein the instructions cause the processor further to output unique/replying party specific public key associated with the further authenticator for sending to the relying party. [Verzun: para 0403-0404; distribute the public key to the dependent node or relevant party]
Claim 7: Verzun: para 0403 [distribute the public key to the dependent node or relevant party]; discussing the non-transitory computer readable medium of claim 1, wherein the instructions cause the processor further to output a structured data set, comprising the public key associated with the further authenticator; the structured data set being associated with a ring signature for sending to the relying party.
Claim 8: Verzun: para 0403 [distribute the public key to the dependent node or relevant party]; discussing the non-transitory computer readable medium of claim 7, wherein the instructions cause the processor further to output a structured data set comprising the public key associated with the further authenticator and a public key associated with the initial authenticator.
Claim 9: Verzun: para 0403, 1051 in view of Hoy: para 0046 [suggesting “generate the signature using at least a private key”, under the same pretext and motivation as in claim 1]; discussing the non-transitory computer readable medium of claim 1, wherein the instructions cause the processor further to: generate the signature using at least a private key associated with the further authenticator, and output the signature for sending to the relying party.
As per claim 10: Verzun, et al. teaches a multiphase authentication system comprising a plurality of phases; the system to:
establish an initial phase to establish an entirety of a shared secret [Verzun: para 0505-0508; seed and shared secret. Para 0184, 0563, 0649; seed and associated authentication data (i.e. key, random number, code)] associated with an initial authenticator and a further authenticator, the entirety of the shared secret being accessible by the initial authenticator and the further authenticator; [Verzun: para 0169; When the prior node scrambled the packet its associated DMZ server generated the seed based on the state. A seed generator operating within the DMZ server generates the seed using an algorithm based on the state at the time the process is executed. Para 0565; the algorithm of seed generation, hidden number generator, and the list of scrambling algorithms represent “shared secrets,” information stored in a DMZ server and not known to either the sender or the recipient of a data packet. The terms “initial authenticator” and “further authenticator” are not explicitly defined, thus, any of the initial or further authenticators can broadly be in the form of a software or hardware such as an application, entity, device or user, or any component used to process or perform authentication per se. As such, an initial authenticator and further authenticator may broadly be in the form of server, node or recipient. The server, node, or recipient may all receive and communicate shared secrets and/or seed to one another, thus, any of the server, node, or recipient may be the initial authenticator and/or further authenticator]
**provide, to a first key generator of an initial authenticator, seed data to generate first authentication data [**rejected under a secondary reference, discussion below], the first seed data including the entirety of the shared secret; [Verzun: para 0174; The shared secrets held by the DMZ servers include selectors or tables of encryption and splitting algorithms and key generators. Para 0176; the seeds and keys may be transmitted through the signaling servers instead of from the sending media node directly to the receiving media node. Para 0566; The algorithm used by the seed generator to produce a seed is part of the shared secrets, and hence knowledge of the seed does not allow one to determine the state on which the seed is based. The seed is passed from one communication node to the next by embedding it within the data packet itself, by sending it through another channel or path]
register, using the first authentication data, the initial authenticator with a relying party; and [0159, 1051, 1064; examples of register an authenticator using authentication data, such as signature, encryption data, seed, secret]
before registering the further authenticator with the relying party: [0184-0185; As an added security benefit, separate security “zones,” having different selectors, seed and key generators and other shared secrets, may be established within a single SDNP cloud. Adjacent zones are connected by bridge media nodes, which hold the shared secrets of both zones. Each interface bridge server has access to the relevant shared secrets and other security items for each cloud. The security zones with seed and key generators and other secrets where the server has access to the relevant secrets and security items for each cloud suggest the seed that generates any (i.e. first or second) of the authentication data is obtained prior to the registering of the further authenticator]
**provide, to a second key generator of the further authenticator, second seed data to generate second authentication data [**rejected under a secondary reference, discussion below], the second seed data including the entirety of the shared secret; [Verzun: para 0176; the seeds and keys may be transmitted through the signaling servers. Para 0184, 0563, 0649; seeds and shared secrets suggest second seed data associated to second authentication data (i.e. key, random number, code)]
receive, at the further authenticator, a challenge from the relying party; and [Verzun: para 0178; a media node may request instructions on what to do with a packet it has received by providing its associated DMZ server with a seed or key (based for example on the time or state that the packet was created). Para 0666-0668, 0709; examples of challenge from a relying party]
send, at the further authenticator, a challenge response, the challenge response being derived from the second authentication data to gain access to a resource. [Verzun: para 0178; The DMZ server responds to requests by using the seed or key to determine what method the media node should use in unscrambling, decrypting or mixing a packet. For example, the DMZ server may examine a list of scrambling algorithms to find the particular algorithm that corresponds to the seed. The media node transmits inquiries embodied in seeds or keys to the DMZ server, and the DMZ server responds to those inquiries with instructions]
Verzun discloses the selector is a part of a body of information referred to as “shared secrets” [Verzun: para 0168]. The shared secrets held by the DMZ servers include selectors or tables of encryption and splitting algorithms and key generators. The seeds and keys may be transmitted through the signaling servers instead of from the sending media node directly to the receiving media node [Verzun: para 0174-0176]. The algorithm of seed generation, hidden number generator, and the list of scrambling algorithms represent “shared secrets,” information stored in a DMZ server and not known to either the sender or the recipient of a data packet. The algorithm used by the seed generator to produce a seed is part of the shared secrets, and hence knowledge of the seed does not allow one to determine the state on which the seed is based. The seed is passed from one communication node to the next by embedding it within the data packet itself, by sending it through another channel or path [Verzun: para 05650-0566]. Verzun suggest a seed data used for authentication data with key generators. However, Verzun does not particularly include providing seed data to the respective key generators for generating authentication, specifically “provide, to a first key generator of an initial authenticator, seed data to generate first authentication data” and “provide, to a second key generator of the further authenticator, second seed data to generate second authentication data”.
Hoy discloses using physical objects to generate physical (e.g., public key-based) authenticators and, in particular, to use “everyday” physical objects to create a generator seed for a key generator that will use that seed to generate a key pair comprising a public key, and its associated private key. The physical object is used to create a digital representation that together with some uniqueness associated to the user, gives rise to a key generator seed value. Without knowledge of the physical object itself, how the physical object characteristic is converted, and the uniqueness value, an attacker cannot reproduce the key generator seed (or the key(s) generated from that seed) [Hoy: para 0051]. FIG. 4 depicts a user selects a physical object to serve as an authenticator. The physical object may be of any type, e.g., a coin, a pen, a pair of glasses, a computer mouse, etc. [Hoy: para 0052]. This suggest there may be multiple possible authenticators which likely will be to produce the data (i.e. seed, keys, unique value) for authentication. The digital representation is fed into a key generator as a “seed” value to produce a key pair. Typically, the key generator is a public key generator algorithm such that the key generated is a public key of a key pair comprising the public key and an associated private (secret) key [Hoy: para 0054]. As such, Hoy obviously suggest “provide, to a first key generator of an initial authenticator, seed data to generate first authentication data” and “provide, to a second key generator of the further authenticator, second seed data to generate second authentication data”, where one would be motivated to use the seed to generate a key pair and the uniqueness value so that an attacker cannot reproduce the key generator seed.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hoy with Verzun to teach “provide, to a first key generator of an initial authenticator, seed data to generate first authentication data” and “provide, to a second key generator of the further authenticator, second seed data to generate second authentication data” for the reason to use the seed to generate a key pair and with the uniqueness value so that an attacker cannot reproduce the key generator seed [Hoy: para 0051].
Claim 11: Verzun: para 0170-0171, 0193 [the relying party may be any of the nodes or clients that receives the packet with seed or key with data to unscramble or decrypt]; discussing the system of claim 10, wherein the first authentication data includes a private-public authentication data; and wherein the first seed data includes relying party data associated with the relying party; and wherein the second authentication data.
Claim 12: Cancelled
Claim 13: Cancelled
Claim 14: Verzun: para 0170-0171, 0193 [the relying party may be any of the nodes or clients that receives the packet with seed or key with data to unscramble or decrypt]; discussing the system of claim 10, wherein the second seed data includes the relying party data associated with the relying party.
Claim 15: Cancelled
Claim 16: Verzun: para 0403-0404 [RSA or public and private key to the dependent node or sender/receiver]; discussing the non-transitory computer readable medium of claim 1, wherein the seed data includes: a first private-public key pair associated with the initial authenticator; a second private-public key pair associated with the further authenticator; and relying party data, the relying party data uniquely being associated with a respective relying party.
As per claim 17: Verzun, et al. teaches a method comprising:
generating, using an initial authenticator, first authentication data using a secret [Verzun: para 0505-0508, 0649; secret associated authentication data (i.e. key, random number, code)], an entirety of the secret being accessible to the initial authenticator and a further authenticator; [Verzun: para 0565; the algorithm of seed generation, hidden number generator, and the list of scrambling algorithms represent “shared secrets,” information stored in a DMZ server and not known to either the sender or the recipient of a data packet. Para; 0; The terms “initial authenticator” and “further authenticator” are not explicitly defined, thus, any of the initial or further authenticators can broadly be in the form of a software or hardware such as an application, entity, device or user, or any component used to process or perform authentication per se. As such, an initial authenticator and further authenticator may broadly be in the form of server, node or recipient. The server, node, or recipient may all receive and communicate shared secrets and/or seed to one another, thus, any of the server, node, or recipient may be the initial authenticator and/or further authenticator]
sending, using the initial authenticator, the first authentication data to a relying party to register the initial authenticator with the relying party; [Verzun: para 0575; secure communication over a packet-switched network relies on several elements to prevent hacking and ensure security, one of which involves SDNP encryption. The secret knowledge generally involves sharing one or more “keys” used for encrypting and decrypting the data. Para 0159, 1051, 1064; examples of register an authenticator using authentication data, such as signature, encryption data, seed, secret]]
after the initial authenticator registers with the relying party, but before the further authenticator registers with the relying party: [0184-0185; As an added security benefit, separate security “zones,” having different selectors, seed and key generators and other shared secrets, may be established within a single SDNP cloud. Adjacent zones are connected by bridge media nodes, which hold the shared secrets of both zones. Each interface bridge server has access to the relevant shared secrets and other security items for each cloud. The security zones with seed and key generators and other secrets where the server has access to the relevant secrets and security items for each cloud suggest the seed that generates any (i.e. first or second) of the authentication data is obtained prior to the registering of the further authenticator]
generating, using the further authentication, second authentication data using the secret; and [Verzun: para 0176; the seeds and keys may be transmitted through the signaling servers. Para 0184, 0563, 0649; seeds and shared secrets suggest second seed data associated to second authentication data (i.e. key, random number, code)]
**sending, using the further authenticator, the second authentication data [**rejected under a secondary reference, discussion below] to the relying party to gain access to a resource. [Verzun: para 0178; The DMZ server responds to requests by using the seed or key to determine what method the media node should use in unscrambling, decrypting or mixing a packet. For example, if the packet has been scrambled and the media node wants to know how to unscramble it, the DMZ server may examine a list of scrambling algorithms to find the particular algorithm that corresponds to the seed. The media node transmits inquiries embodied in seeds or keys to the DMZ server, and the DMZ server responds to those inquiries with instructions]
Verzun discloses the selector is a part of a body of information referred to as “shared secrets” [Verzun: para 0168]. The shared secrets held by the DMZ servers include selectors or tables of encryption and splitting algorithms and key generators. The seeds and keys may be transmitted through the signaling servers instead of from the sending media node directly to the receiving media node [Verzun: para 0174-0176]. The algorithm of seed generation, hidden number generator, and the list of scrambling algorithms represent “shared secrets,” information stored in a DMZ server and not known to either the sender or the recipient of a data packet. The algorithm used by the seed generator to produce a seed is part of the shared secrets, and hence knowledge of the seed does not allow one to determine the state on which the seed is based. The seed is passed from one communication node to the next by embedding it within the data packet itself, by sending it through another channel or path [Verzun: para 05650-0566]. Verzun suggest a seed data used for authentication data with a key generator. However, Verzun did not clearly teach to provide seed data “sending, using the further authenticator, the second authentication data”.
Hoy discloses using physical objects to generate physical (e.g., public key-based) authenticators and, in particular, to use “everyday” physical objects to create a generator seed for a key generator that will use that seed to generate a key pair comprising a public key, and its associated private key. The physical object is used to create a digital representation that together with some uniqueness associated to the user, gives rise to a key generator seed value. Without knowledge of the physical object itself, how the physical object characteristic is converted, and the uniqueness value, an attacker cannot reproduce the key generator seed (or the key(s) generated from that seed) [Hoy: para 0051]. FIG. 4 depicts a user selects a physical object to serve as an authenticator. The physical object may be of any type, e.g., a coin, a pen, a pair of glasses, a computer mouse, etc. [Hoy: para 0052]. This suggest there may be multiple possible authenticators which likely will be to produce the data (i.e. seed, keys, unique value) for authentication. As such one would be motivated to “sending, using the further authenticator, the second authentication data”, so as to be able to use unique data that an attacker cannot reproduce.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hoy with Verzun to teach “sending, using the further authenticator, the second authentication data” for the reason to provide unique data so that an attacker cannot reproduce from different authenticators [Hoy: para 0051].
Claim 18: Verzun: para 0170-0171, 0193 [the relying party may be any of the nodes or clients that receives the packet with seed or key with data to unscramble or decrypt]; discussing the method of claim 17, wherein the first authentication data is generated using first seed data that includes the secret, the seed data including specific relying party data that uniquely identifies the relying party.
Claim 19: Verzun: para 0159, 1064 [register an authenticator using authentication data, such as signature, encryption data, seed, secret]; discussing the method of claim 17, further comprising sending, using the initial authenticator, a proof of possession to the relying party to register the initial authenticator with the relying party.
Claim 20: Verzun: para 0178, 0666-0668 [a media node request instructions on what to do with a packet it has received by providing its associated DMZ server with a seed or key. The media node transmits inquiries embodied in seeds or keys to the DMZ server, and the DMZ server responds to those inquiries with instructions]; discussing the method of claim 19, wherein the proof of possession includes at least one of a ring signature or a signature in response to a challenge sent by the relying party to the initial authenticator.
Claim 21: Verzun: para 0730, 0880; discussing the non-transitory computer readable medium of claim 1, wherein the initial authenticator comprises a first processor and a first communication interface; and wherein the further authenticator comprises a second processor and a second communication interface.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Leynna Truvan whose telephone number is (571)272-3851. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM, EST.
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, Amir Mehrmanesh can be reached at 571-270-3351. 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.
Leynna Truvan
Examiner
Art Unit 2435
/L.TT/Examiner, Art Unit 2435
/EDWARD ZEE/Primary Examiner, Art Unit 2435
Prosecution Insights