DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 112(b):
Applicant’s amendment is considered to have overcome the applied rejection. The limitations drawn to actions of the user computing device (e.g., “the token activation message enabling the user computing device to generate one or more token values based on the token secret,” “thereby enabling the user computing device to generate the one or more token values”) have been interpreted as statements of intended use. The applied rejection has been withdrawn. However, a new 35 USC 112(b) rejection has been made in view of the amended claim language as below.
Regarding claims rejected under 35 USC 103:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Santiago (US 9,038,157 B1).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21, 26-28, 33-35, and 39-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1-2 and 5-6 of U.S. Patent No. 11,652,813 B2 in view of Santiago (US 9,038,157 B1). The patent claims are considered to anticipate the instant claims as per the table below, but do not specify: “in response to receiving an activation request from a user computing device associated with a user, generate a token secret and a user profile associated with the user; link the token secret to the user profile; transmit, to the user computing device, a token activation message including the token secret, the token activation message enabling the user computing device to generate one or more token values based on the token secret; activate, using the token activation message, a token on the user computing device, thereby enabling the user computing device to generate the one or more token values.” However, the patent claims in view of at least FIG. 4-5, Col. 3, Ll. 9-32, Col. 6, Ll. 51-Col. 7, Ll. 2, Col. 1, Ll. 60-Col. 2, Ll. 33, FIG. 11, Col. 3, Ll. 9-13, and Col. 8, Ll. 66-Col. 9, Ll. 13 of Santiago concerning token activation at a user device via token activation and response by a provider server are considered to disclose these limitations. Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to include a token activation procedure for at least the purpose of securely provisioning the user device to generate tokens without manual programming or physical installation.
Instant claims 28, 33-35, and 39-40 are substantially similar to claims 21 and 26-27, and are therefore likewise rejected in view of respective patent claims.
Instant Application
US 11,652,813 B2
21. (currently amended) An identity authority computing device comprising a processor configured to:
communicate with a public network and a secure data processing domain, and prevent access from the public network to confidential user data stored in the secure data processing domain;
in response to receiving an activation request from a user computing device associated with a user, generate a token secret and a user profile associated with the user; link the token secret to the user profile; transmit, to the user computing device, a token activation message including the token secret, the token activation message enabling the user computing device to generate one or more token values based on the token secret; activate, using the token activation message, a token on the user computing device, thereby enabling the user computing device to generate the one or more token values;
transmit, through the secure data processing domain, an encrypted service request to a service provider computing device, the encrypted service request including at least one persistent user identifier, the encrypted service request transmitted in response to a service request (i) including a token value of the one or more token values generated by the user computing device and (ii) received over the public network from an interface domain associated with an interface computing device different from the service provider computing device, wherein the interface computing device enables retrieval of the token value from the user computing device; receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier; filter the service response by removing the at least one persistent user identifier from the service response; and transmit the filtered service response and the token value to the interface computing device without providing access to the confidential user data associated with the user and stored in the secure data processing domain including the at least one persistent user identifier.
1. An identity authority computing device comprising a processor programmed to:
communicate with a public network and with a secure data processing domain, and prevent access from the public network to confidential user data stored in the secure data processing domain;
6. The identity authority computing device of claim 1, wherein the token value is a one-time password generated by a user computing device based on a token secret generated by the identity authority computing device.
receive a service request over the public network from an interface domain that includes an interface computing device in communication with a user computing device … generate an updated service request including the at least one persistent user identifier;generate an encrypted service request by using a public encryption key associated with the service provider identifier to encrypt the updated service request; and
transmit, within the secure data processing domain, the encrypted service request to a service provider computing device associated with the service provider identifier… receive a service request over the public network from an interface domain that includes an interface computing device in communication with a user computing device, the service request including a service provider identifier and a single-use token value associated with a user…
…wherein the interface domain is prevented from accessing confidential user data associated with the user including the persistent user identifier of the user…
2. The identity authority computing device of claim 1, wherein the processor is further programmed to:
receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier;
filter the at least one persistent user identifier from the service response; and
transmit the filtered service response and the token value to the interface computing device.
5. The identity authority computing device of claim 1, wherein the service request is received from the interface computing device in response to receipt by the interface computing device of the token value from a user computing device
26. The identity authority computing device of claim 21, wherein the interface computing device is in communication with a plurality of user computing devices, and wherein the service request further includes a service provider identifier associated with the service provider computing device.
1. …receive a service request over the public network from an interface domain that includes an interface computing device in communication with a user computing device, the service request including a service provider identifier and a single-use token value associated with a user…
27. The identity authority computing device of claim 21, wherein the processor is further configured to, in response to the service request, access an identity database within the secure data processing domain, and wherein the identity database stores and indexes confidential information for a plurality users including a plurality of persistent user identifiers.
1. … in response to the service request, access an identity database within the secure data processing domain, wherein the identity database stores and indexes confidential information for a plurality of users including a plurality of persistent user identifiers…
Claims 22-25, 29-32, and 36-38 are rejected on the ground of nonstatutory double patenting as being unpatentable over U.S. Patent No. 11,652,813 B2 in view of Santiago as applied to claims 21, 26-28, 33-35, and 39-40 above, and further in view of Keresman (US 2019/0172061 A1).
Regarding claim 22, the patent claims do not specify: wherein the processor is further configured to filter the at least one persistent user identifier from the service response by replacing the at least one persistent user identifier with the token value. However, the patent claims in view of Santiago and at least [0050] of Keresman concerning replacing a user credential with a tokenized version are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to include replacement with a tokenized value for at least the reasons specified in [0003] of Keresman concerning the advantages of tokenization (i.e., preventing entities from understanding private user data).
Regarding claim 23, it is rejected for substantially the same reasons as claim 22 above (e.g., the citations and obviousness rationale; also see [0032] of Keresman)
Regarding claim 24, the patent claims do not specify: wherein transmitting the filtered service response to the interface computing device causes the interface computing device to generate an application view based on the service response, and transmit the application view to the user computing device. However, the patent claims in view of Santiago and at least [0052] and [0034] of Keresman concerning a merchant website, interactions with a checkout page, and subsequent response messages are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to include support for a checkout page and subsequent response because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 25, the patent claims in view of Santiago and Keresman disclose: wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data (refer to at least patent claim 3 reciting “wherein the service response includes at least one of credit history data, personal background data, and vehicle insurance data”). Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to implement the checkout page and response of Keresman as part of the service response for substantially the same reasons as claim 24 above.
Regarding claims 29-32 and 36-38, they are substantially similar to claims 22-25 above, and are therefore likewise rejected.
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 21-40 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. Independent claim 21 is drawn to “[a]n identity authority computing device comprising a processor configured to” perform the claim limitations, but further recites “activate, using the token activation message, a token on the user computing device” which renders the claim indefinite because it is not clear whether this limitation relates to actions performed outside of the claim scope. Specifically, it is not clear whether the activation is performed entirely by the identity authority computing device or with input from the user computing device. Where the user computing device is performing an action as part of the activation, this would be outside of the claim scope drawn to the identity authority computing device. Further, the previous step of “transmitting…” achieves the last possible functionality of the claimed identity authority computing device for this concept, so it’s further unclear how these two functions interrelate.
Claim 21 additionally recites two instances of “enabling the user computing device to generate one or more token values:” i.e., “the token activation message enabling the user computing device to generate one or more token values based on the token secret” and “activate, using the token activation message, a token on the user computing, thereby enabling the user computing device to generate the one or more token values.” It is therefore unclear whether just one limitation is sufficient to enable the user computing device to generate the one or more token values, or if both limitations are required to enable the user computing device to generate the one or more token values (i.e., whether just transmitting the token activation message enough, or if it is also necessary to use it to active the token for the “enabling”). Further, simply transmitting a token message with a token secret appears to achieve all the ‘enabling…’ limitations.
As such, a person of ordinary skill in the art could not interpret the metes and bounds of the claim so as to understand how to avoid infringement. Independent claims 28 and 35 recite substantially similar subject matter and are rejected under the same analysis as claim 21. The dependent claims do not rectify the above-identified issues and are therefore likewise rejected with their respective parent 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) 21-24, 26-31, and 33-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman (US 2019/0172061 A1) in view of Santiago (US 9,038,157 B1) and Wang (WO 2019/147251 A1).
Regarding claim 21, Keresman discloses: An identity authority computing device (Trusted Token Service Provider TTSP 140 in FIG. 9 of Keresman) comprising a processor configured to:
communicate with a public network (internet 110 in FIG. 9 of Keresman) and a secure data processing domain (payment network 160 in FIG. 9 of Keresman), and prevent access from the public network to confidential user data (e.g., [0031] of Keresman concerning sensitive user data, including a credential such as a PAN) stored in the secure data processing domain (e.g., [0037] of Keresman concerning a token vault; the payment network likewise needs to know user identifying credentials such as a PAN to actually proceed with payment);
Refer to at least [0032] of Kerseman with respect to, e.g., a merchant server being unable to access the user data.
transmit, through the secure data processing domain, an service request to a service provider computing device, the service request including at least one persistent user identifier,
Refer to at least [0048] of Keresman with respect to the TTSP sending a message with a corresponding PAN to the payment network.
the service request transmitted in response to a service request (i) including a token value of the one or more token values and (ii) received over the public network from an interface domain associated with an interface computing device different from the service provider computing device, (e.g., 130 and 132 in FIG. 9, as well as [0033]-[0035] of Keresman concerning a merchant its merchant website; the merchant is different from the payment network 160 as per FIG. 9; “application views” interpreted as web pages in view of [0043] of the instant specification);
Refer to at least [0041]-[0046] of Keresman with respect to the TTSP being sent a payment request message from the merchant, where the payment request message contains a tokenized version of a user’s PAN.
receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier;
Refer to at least [0049] of Keresman with respect to the payment network sending a response with an included PAN.
filter the service response by removing the at least one persistent user identifier from the service response; and
Refer to at least [0050] of Keresman with respect to the TTSP replacing the PAN with the tokenized version of the PAN.
transmit the filtered service response and the token value to the interface computing device.
Refer to at least [0051]-[0052] of Keresman with respect to the TTSP forwarding the replaced-PAN message to the merchant.
without providing access to the confidential user data associated with the user and stored in the secure data processing domain including the at least one persistent user identifier.
Refer to at least [0032], [0035], and [0051] of Keresman with respect to the merchant having no access to the PAN as known to the payment network.
Keresman does not specify: in response to receiving an activation request from a user computing device associated with a user, generate a token secret and a user profile associated with the user; link the token secret to the user profile; transmit, to the user computing device, a token activation message including the token secret, the token activation message enabling the user computing device to generate one or more token values based on the token secret; activate, using the token activation message, a token on the user computing, thereby enabling the user computing device to generate the one or more token values; the service request to the service provider computer further comprising an encrypted service request; the token value further being generated by the user computing device; wherein the interface computing device enables retrieval of the token value from the user computing device. However, Keresman in view of Santiago discloses: in response to receiving an activation request from a user computing device associated with a user, generate a token secret (e.g., Col. 3, Ll. 21-23 of Santiago) and a user profile (e.g., Col. 2, Ll. 11-14 of Santiago) associated with the user; link the token secret to the user profile; transmit, to the user computing device, a token activation message including the token secret, the token activation message enabling the user computing device to generate one or more token values based on the token secret;
Refer to at least FIG. 5, Col. 3, Ll. 9-32, and Col. 6, Ll. 51-Col. 7, Ll. 2 of Santiago with respect to a user request for token activation to a provider which then returns token activation info to the user device. For instance, FIG. 4 of Santiago with respect to token activation information. The token activation information is used by the user device to activate a OTP seed application using at least some of the token activation information.
activate, using the token activation message, a token on the user computing, thereby enabling the user computing device to generate the one or more token values;
Refer to at least Col. 1, Ll. 60-Col. 2, Ll. 33 and Col. 3, Ll. 28-32 of Santiago with respect to activating the OTP seed application to generate OTPs on the user device.
the token value further being generated by the user computing device;
Refer to at least FIG. 11, Col. 3, Ll. 9-13, and Col. 8, Ll. 66-Col. 9, Ll. 13 of Santiago with respect to the user device utilizing the seed application to generate OTPs.
The teachings of Santiago likewise concern generating and using token values for authentication, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keresman to further implement token generation at the user device and the token activation scheme of Santiago for at least the purpose of allowing a user to control their own authentication to improve convenience and privacy, and because the particular known technique (user device token generation) was recognized as part of the ordinary capabilities of one skilled in the art.
Keresman-Santiago does not specify: the service request to the service provider computer further comprising an encrypted service request; wherein the interface computing device enables retrieval of the token value from the user computing device. However, Keresman-Santiago in view of Wang discloses: the service request to the service provider computer further comprising an encrypted service request;
Refer to at least [0042]-[0043] of Wang with respect to a form of the claimed service request. Further refer to at least [0064] of Wang with respect to securing messages between entities using secure communications protocols (e.g., SSL, HTTPS).
wherein the interface computing device enables retrieval of the token value from the user computing device.
Refer to at least [0102] and [0142]-[0146] of Wang with respect to a resource provider computer (e.g., a merchant) forwarding an authorization request message with the user’s access token.
The teachings of Keresman and Wang both concern generating tokens to secure privacy for sensitive credential information (e.g., [0002] and [0042]-[0043] of Wang), and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keresman to further implement secure communications protocols for at least the purpose of improving security (e.g., preventing eavesdropping of sensitive plaintext data). Additionally, the particular known technique of merchants forwarding user authentication information was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 22, it is rejected for substantially the same reasons as claim 21 above (i.e., the citations concerning replacing the PAN with the tokenized PAN).
Regarding claim 23, it is rejected for substantially the same reasons as claim 21 above (i.e., the citations concerning obfuscating the PAN from the merchant while still allowing the transaction).
Regarding claim 24, Keresman-Santiago-Wang discloses: The identity authority computing device of claim 21, wherein transmitting the filtered service response to the interface computing device causes the interface computing device to generate an application view based on the service response, and transmit the application view to the user computing device.
Refer to at least [0052] and [0034] of Keresman with respect to the transaction taking place on a merchant website accessed by a user and respective user device. Once the transaction is complete, the merchant may send an appropriate message indicating success or failure.
Regarding claim 26, Keresman-Santiago-Wang discloses: The identity authority computing device of claim 21, wherein the interface computing device is in communication with a plurality of user computing devices, and wherein the service request further includes a service provider identifier associated with the service provider computing device.
Refer to at least [0034]-[0035] of Keresman with respect to a user and respective user device used to proceed with checkout at the merchant’s website. The check out procedure includes entering payment data such as a PAN and/or other information identifying the payment processor associated with the user’s payment option. A PAN includes an issuer identification number as part of the standard.
Refer to at least FIG. 1 of Wang with respect to second and third user devices in communication with the first user device.
This claim would have been obvious for substantially the same reasons as claim 21 above.
Regarding claim 27, Keresman-Santiago-Wang discloses: The identity authority computing device of claim 21, wherein the processor is further configured to, in response to the service request, access an identity database within the secure data processing domain, and wherein the identity database stores and indexes confidential information for a plurality users including a plurality of persistent user identifiers.
Refer to at least FIG. 9 and [0037] of Keresman with respect to a token vault storing token-to-credential information.
Regarding independent claim 28, it is substantially similar to independent claim 21 above, and is therefore likewise rejection (i.e., the citations and obviousness rationale).
Regarding claims 29-31 and 33-34, they are substantially similar to claims 22-24 and 26-27 above, and are therefore likewise rejected.
Regarding independent claim 35, it is substantially similar to independent claim 21 above, and is therefore likewise rejection (i.e., the citations and obviousness rationale).
Regarding claims 36-40, they are substantially similar to claims 22-24 and 26-27 above, and are therefore likewise rejected.
Claim(s) 25 and 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman-Santiago-Wang as applied to claims 21-24, 26-31, and 33-40 above, and further in view of Official Notice.
Regarding claim 25, Keresman-Santiago-Wang does not specify: wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data. However, the examiner hereby takes official notice that that it was well known in the art before the filing date of Applicant’s invention for merchant websites to provide credit history data, personal background data, and/or vehicle insurance data responsive to a purchase. For example, purchasing vehicle insurance from an insurance website would take a user to a coverage page. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keresman-Santiago-Wang to include support for wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data because design incentives or market forces provided a reason to make an adaptation (i.e., selling credit history, personal background data, and/or vehicle insurance on a website), and the invention resulted from application of the prior knowledge in a predictable manner (the tokenization and substitution in Keresman-Santiago-Wang is generic to any kind of purchase and merchant website).
Claim 32 is substantially similar to claim 25 above, and is therefore likewise rejected.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/ Examiner, Art Unit 2432
Prosecution Insights