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 .
Status of the Claims
Instant application is CON of US Patent No. 12,354,077 B2 (Application No. 17/847,961). Claims 2-21 are presented for examination. Applicant filed an original claim 1 on 06/10/2025 and an amendment canceling claim 1 and adding new claims 2-21 on 08/25/2025. Examiner has established objections for claims 11, 15, 17-18, and 21; and double patenting and § 101 rejections for claims 2-21 in the instant Office action.
Claim Objections
Claim 11 is objected to because of the following informality:
11. The method of claim 2, wherein authenticating the login credential comprises sending, by the application, the login credentials to the server and receiving, by the application, verification of the login credentials from the server.
The word “credential” should be recited in plural “credentials” because it appears in plural form elsewhere in the claims. Applicant could amend claim 11 to recite:
11. The method of claim 2, wherein authenticating the login credentials comprises sending, by the application, the login credentials to the server and receiving, by the application, verification of the login credentials from the server.
Claim 15 is objected to because of the following informalities:
15. The non-transitory computer-readable storage medium of claim 12, wherein the payment information includes a virtual card number (VCN), wherein use of the VCN is restricted to the merchant associated with the merchant web page, wherein the server transmits the VCN to a merchant server associated with the merchant, wherein the application loads an authentication page of the application based on the action ID parameter.
Both “merchant” and “action ID parameter” should have indefinite article in front of them because they both appear in the claim set for the first time. Applicant could amend claim 15 to recite:
15. The non-transitory computer-readable storage medium of claim 12, wherein the payment information includes a virtual card number (VCN), wherein use of the VCN is restricted to [[the]] a merchant associated with the merchant web page, wherein the server transmits the VCN to a merchant server associated with the merchant, wherein the application loads an authentication page of the application based on [[the]] an action ID parameter.
Claim 17 is objected to because of the following informality:
17. The non-transitory computer-readable storage medium of claim 15, . . . receiving, by the mobile device, a notification from one or more of: (i) a merchant server associated with the merchant web page, or (ii) the server, wherein the notification is received based on the transaction not being processed within a threshold amount of time relative to the generation of the VCN.
There should be no article in front of “generation.” Applicant could amend claim 17 to recite:
17. The non-transitory computer-readable storage medium of claim 15, . . . receiving, by the mobile device, a notification from one or more of: (i) a merchant server associated with the merchant web page, or (ii) the server, wherein the notification is received based on the transaction not being processed within a threshold amount of time relative to [[the]] generation of the VCN.
Claim 18 is objected to because of the following informality:
18. The non-transitory computer-readable storage medium of claim 12, wherein the URI further comprises a user ID parameter, wherein the method further comprises associating, by the application, the session ID parameter and the user ID parameter with the account.
There should be indefinite article in front of “method.” Applicant could amend claim 18 to recite:
18. The non-transitory computer-readable storage medium of claim 12, wherein the URI further comprises a user ID parameter, wherein [[the]] a method further comprises associating, by the application, the session ID parameter and the user ID parameter with the account.
Claim 21 is objected to because of the following informality:
21. The non-transitory computer-readable storage medium of claim 12, wherein the application causes the mobile OS to bring the web browser to the foreground after receiving the payment information.
There should be indefinite article in front of “foreground.” Applicant could amend claim 21 to recite:
21. The non-transitory computer-readable storage medium of claim 12, wherein the application causes the mobile OS to bring the web browser to [[the]] a foreground after receiving the payment information.
Double Patenting
The non-statutory 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 non-statutory 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 non-statutory 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 §§ 706.02(l)(1) – 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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: www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 2-21 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,354,077 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the instant application are obvious over the reference claims.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 2-21 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claims 2-11 is a series of steps, which is method (i.e., a process) and, thus, one of the statutory categories of invention. Further, the claimed invention of claims 12-21 is a non-transitory computer-readable storage medium, which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 2-21 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 2-21, however, recite an abstract idea of mobile web browser checkout using a contactless card. The creation of mobile web browser checkout using a contactless card, as recited in the independent claims 2 and 12 belongs to certain methods of organizing human activity (i.e., commercial interactions) that are found by the courts to be abstract ideas. The limitations in independent claims 2 and 12, which set forth or describe the recited abstract idea, are found in the following steps:
“launching an application based on the selection of the first financial institution and via a uniform resource identifier (URI), wherein the URI comprises a session identifier (ID) parameter associated with a transaction executed on the merchant web page” (claims 2 and 12);
“authenticating login credentials for an account associated with the first financial institution” (claims 2 and 12);
“refreshing the merchant web page, wherein the refreshed merchant web page includes the payment information automatically populated in a form field” (claims 2 and 12); and
“processing the transaction based at least in part on the payment information in the form field” (claims 2 and 12).
Prong 2: In addition to abstract steps recited above in Prong 1, independent claims 2 and 12 recite additional elements:
“a merchant web page in a web browser executing on a processor of a mobile device” (claims 2 and 12);
“an application” (claims 2 and 12);
“a server” (claims 2 and 12); and
“a non-transitory computer-readable storage medium, the computer-readable storage medium including instructions executed by a processor of a mobile device” (claim 12).
These additional elements are recited at a high level of generality (e.g., as a generic processor performing a generic computer functions) such that they amount to no more than mere instructions to apply the exception using a generic computer components. Further, the following limitations recite insignificant extra solution activity (for example, data gathering):
“receiving selection of a first financial institution” (claims 2 and 12);
“receiving encrypted data from a contactless card associated with the account, the encrypted data generated by an applet executing on the contactless card when the contactless card is tapped to the mobile device, and transmitting the encrypted data for verification” (claims 2 and 12); and
“receiving payment information based on verification of the encrypted data” (claims 2 and 12).
These additional limitations do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional elements/limitations of independent claims 2 and 12 here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); MPEP § 2106.05(c) (particular transformations); or MPEP § 2106.05(e) (other meaningful limitations).
Conclusion of Step 2A Analysis: The limitations in independent claims 2 and 12, which set forth or describe the recited abstract idea are not patent eligible either alone or in combination. The additional elements/limitations in independent claims 2 and 12 are not patent eligible either alone or in combination. Further, the combination of these additional elements/limitations and the limitations which set forth or describe the recited abstract idea is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements/limitations and the limitations which set forth or describe the recited abstract idea do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, independent claims 2 and 12 are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements of independent claims 2 and 12 (see above under Step 2A – Prong 2) are described by Applicant’s Specification in following terms:
[0034] The computing architecture 100 comprises one or more computing devices 102, one or more authentication servers 106, one or more contactless cards 104, and one or more merchant servers 108. The contactless card 104 is representative of any type of card, such as a credit card, debit card, ATM card, gift card, payment card, smart card, and the like. The contactless card 104 may comprise one or more communications interfaces 124, such as a radio frequency identification (RFID) chip, configured to communicate with a communications interface 124 (also referred to herein as a “card reader”, a “wireless card reader”, and/or a “wireless communications interface”) of the computing devices 102 via NFC, the EMV standard, or other short-range protocols in wireless communication. Although NFC is used as an example communications protocol herein, the disclosure is equally applicable to other types of wireless communications, such as the EMV standard, Bluetooth, and/or Wi-Fi.
[0035] The computing device 102 is representative of any number and type of computing device, such as smartphones, tablet computers, wearable devices, laptops, portable gaming devices, virtualized computing system, merchant terminals, point-of-sale systems, servers, desktop computers, and the like. A mobile device may be used as an example of the computing device 102, but should not be considered limiting of the disclosure. The authentication server 106 and merchant server 108 are representative of any type of computing device, such as a server, workstation, compute cluster, cloud computing platform, virtualized computing system, and the like. Although not depicted for the sake of clarity, the computing device 102, contactless card 104, authentication server 106, and merchant server 108 each include one or more processor circuits, e.g., to execute programs, code, and/or instructions.
[0036] As shown, a memory 110 of the contactless card 104 includes an applet 112, a counter 114, a master key 116, a diversified key 118, and a unique customer identifier (ID) 120. The applet 112 is executable code configured to perform the operations described herein. The counter 114, master key 116, diversified key 118, and customer ID 120 are used to provide security in the system 100 as described in greater detail below.
[0037] As shown, a memory 126 of the authentication server 106 includes an authentication application 128 and an account database 130. The account database 130 generally includes information related to an account holder (e.g., one or more users), one or more accounts of the account holder, and one or more contactless cards 104 of the account. For each contactless card associated with a financial institution associated with the authentication server 106, the authentication server 106 may store corresponding instances of the master key 116 and counter 114.
[0038] As shown, a memory 134 of the computing device 102 includes an instance of an operating system 136. Example operating systems include the Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, the operating system 136 includes an account application 138 and a web browser 140. The account application 138 allows users to perform various account-related operations, such as activating payment cards, viewing account balances, purchasing items, processing payments, and the like. In some embodiments, a user may authenticate using authentication credentials to access certain features of the account application 138. For example, the authentication credentials may include a username (or login) and password, biometric credentials (e.g., fingerprints, Face ID, etc.), and the like. The web browser 140 is an application that allows the computing device 102 to access information via the network 154 (e.g., via the Internet). For example, using the web browser 140, the user may access one or more resources of the merchant server 108, such as the web page 142 stored in the memory 152 of the merchant server 108, which may be one of a plurality of web pages hosted by the merchant server 108 (or another hosting entity). Although a web browser is used as a reference example herein, the techniques of the disclosure are equally applicable to other types of applications (e.g., dedicated shopping applications provided by the merchant, other types of applications, etc.).
This is a description of general-purpose computer. Thus, individually, the additional elements of independent claims 2 and 12 are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. Further, the additional limitations of “receiving” information amount to no more than mere instructions to apply the exception using generic computer components. For the same reason these additional limitations are not sufficient to provide an inventive concept. The additional limitations of “receiving” information were considered as insignificant extra-solution activity in Step 2A – Prong 2. Re-evaluating here in Step 2B, they are also determined to be well-understood, routine, and conventional activity in the field. Similarly to OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), the additional limitations of independent claims 2 and 12 “receive” information. The courts have recognized “receiving” information functions as well-understood, routine and conventional when claimed in a merely generic manner. Therefore, the additional limitations of independent claims 2 and 12 are well-understood, routine, and conventional. Further, taken as combination, the additional elements/ limitations add nothing more than what is present when the additional elements/limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 2 and 12 are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: Dependent claims 3-11 depend on independent claim 2; and dependent claims 13-21 depend on independent claim 12. The elements in dependent claims 3-11 and 13-21, which set forth or describe the abstract idea, are:
“the URI further comprises a user ID parameter, wherein the method further comprises associating, by the application, the session ID parameter and the user ID parameter with the account” (claim 3: further narrowing the recited abstract idea);
“associating the user ID parameter and the session ID parameter with the account comprises: associating, by the application, the user ID parameter and the session ID parameter with the account in: (i) an account database stored on the mobile device, or (ii) an account database stored by the server, wherein associating the user ID parameter and the session ID parameter with the account associates the account with a browsing session for the transaction in the web browser” (claim 4: further narrowing the recited abstract idea);
“the URI further comprises a merchant ID parameter of a merchant associated with the merchant web page and an action ID parameter, wherein the payment information is generated by the server based on the authentication of the login credentials and the verification of the encrypted data” (claim 5: further narrowing the recited abstract idea);
“the payment information comprises a virtual card number (VCN), wherein use of the VCN is restricted to the merchant associated with the merchant web page, wherein the server transmits the VCN to a merchant server associated with the merchant, wherein the application loads an authentication page of the application based on the action ID parameter” (claim 6: further narrowing the recited abstract idea);
“transmitting, by the application, the user ID parameter, the session ID parameter, the merchant ID parameter, and the action ID parameter to the server, wherein the server further generates the VCN based on the user ID parameter, the session ID parameter, the merchant ID parameter, and the action ID parameter” (claim 7: insignificant extra solution activity);
“use of the VCN is restricted to a transaction amount and/or a location” (claim 8: further narrowing the recited abstract idea);
“prior to processing the transaction: receiving, by the mobile device, a notification from one or more of: (i) a merchant server associated with the merchant web page, or (ii) the server, wherein the notification is received based on the transaction not being processed within a threshold amount of time relative to transmission of the payment information by the server” (claim 9: insignificant extra solution activity);
“before receiving selection of the first financial institution, displaying, on a user interface associated with the mobile device, the first financial institution among a plurality of financial institutions” (claim 10: further narrowing recited abstract idea);
“authenticating the login credential comprises sending, by the application, the login credentials to the server and receiving, by the application, verification of the login credentials from the server” (claim 11: insignificant extra solution activity);
“determine, by a mobile operating system (OS) executing on the mobile device, that the application is not installed on the mobile device; download, by the mobile OS, the application; and install, by the mobile OS, the application on the mobile device” (claim 13: further narrowing the recited abstract idea);
“the web browser determines the application is installed on the mobile device based on a function provided by a mobile operating system (OS) executing on the mobile device” (claim 14: further narrowing the recited abstract idea);
“the payment information includes a virtual card number (VCN), wherein use of the VCN is restricted to the merchant associated with the merchant web page, wherein the server transmits the VCN to a merchant server associated with the merchant, wherein the application loads an authentication page of the application based on the action ID parameter” (claim 15: further narrowing the recited abstract idea);
“the refreshed merchant web page further includes: (i) a name associated with the account in a second form field of the plurality of form fields, (ii) an expiration date associated with the VCN in a third form field of the plurality of form fields, (iii) a card verification value (CVV) associated with the VCN in a fourth form field of the plurality of form fields, (iv) a phone number associated with the account in a fifth form field of the plurality of form fields, and (v) an email address associated with the account in a sixth form field of the plurality of form fields” (claim 16: further narrowing the recited abstract idea);
“prior to processing the transaction: receiving, by the mobile device, a notification from one or more of: (i) a merchant server associated with the merchant web page, or (ii) the server, wherein the notification is received based on the transaction not being processed within a threshold amount of time relative to the generation of the VCN” (claim 17: insignificant extra solution activity);
“the URI further comprises a user ID parameter, wherein the method further comprises associating, by the application, the session ID parameter and the user ID parameter with the account” (claim 18: further narrowing the recited abstract idea);
“the URI further comprises a merchant ID parameter of a merchant associated with the merchant web page and an action ID parameter, wherein the payment information is generated by the server based on the authentication of the login credentials and the verification of the encrypted data” (claim 19: further narrowing the recited abstract idea);
“the encrypted data includes an encryption of a user ID parameter, wherein the data is encrypted using a key and an encryption algorithm on the contactless card” (claim 20: further narrowing the recited abstract idea); and
“the application causes the mobile OS to bring the web browser to the foreground after receiving the payment information” (claim 21: further narrowing the recited abstract idea).
Conclusion of Dependent Claims Analysis: Dependent claims 3-11 and 13-21 do not correct the deficiencies of independent claims 2 and 12 and they are, thus, rejected on the same basis.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 2-21 are rejected as directed to an abstract idea without “significantly more” under 35 USC § 101.
Examiner’s Remarks Regarding Prior Art under § 102 and § 103
The closest prior art reference located by Examiner – Corella (US 2020/0043003 A1) – teaches generally mobile web browser authentication and checkout using a contactless card. Corella, however, does not teach – alone or in combination with other references – following limitations found in independent claims 2 and 12 as an ordered combination of steps with the other claim steps:
launching, by a mobile device, an application based on the selection of the first financial institution and via a uniform resource identifier (URI), wherein the URI comprises a session identifier (ID) parameter associated with a transaction executed on the merchant web page;
receiving, by the application, encrypted data from a contactless card associated with the account, the encrypted data generated by an applet executing on the contactless card when the contactless card is tapped to the mobile device, and transmitting the encrypted data to a server for verification;
receiving, by the merchant web page from the server, payment information based on verification of the encrypted data;
refreshing, by the web browser, the merchant web page, wherein the refreshed merchant web page includes the payment information automatically populated in a form field; and
processing, by the merchant web page, the transaction based at least in part on the payment information in the form field.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chayanam (US 8,136,148 B1) discloses: “The client computer may communicate with the authentication server, rather than the web server, to transmit and receive user authentication data for authenticating a user. After the user has been authenticated, the client computer may the signal the web server to provide updated user specific data for the authenticated user. For example, the parent web page may be prompted to refresh the page and provided a user identifier, so that the web server may retrieve and integrate the user data into the web page, for example, by automatically populating form user input fields with retrieved user data, or by initiating an encrypted connection and logging in the authenticated user to a secure website, such as, for example, an online banking web site or merchant web site.”
Isaacson (US 2018/0232817 A1) discloses: “The method involves receiving a first data associated with a first account from a first browser and through a first browser application programming interface, the first data is associated with processing a purchase. A dynamically modified second buy button is presented which is associated with a second account. A second payment request having second information associated with the purchase is transmitted from a site for a user (104) to a second browser and through a second browser application programming interface that defines a protocol for communicating information about purchases between the site and the second browser. A second data is received associated with the second account from the second browser and through the second browser application programming interface, the second data is associated with processing the purchase.”
Hauser (US 2022/0414204 A1) discloses: “[0045] . . . In some embodiments, this process may be automated using entity security extension 352, wherein the entity security extension 352 is a browser plug-in or add-on which automates the process of querying the unique device identifier of the user device, transmitting this information to the bilateral security system 200 directly, receiving the bilateral security display data, and automatically populating or refreshing the web page to include the bilateral security display data.”
P. Garner, R. Edwards and P. Coulton, "Card-based Macropayment for Mobile Phones," 2006 International Conference on Mobile Business, Copenhagen, Denmark, 2006, pp. 4-4 – disclosing: “Most new entrants into the mobile commerce marketplace are faced with a paradox; how can we attract users without merchants, and how can we attract merchants without customers? Without a huge investment in marketing to build consumer recognition, starting a new m-commerce service is risky. In this paper we analyse how successful companies on the Web have managed to create successful payment services by utilising the brand recognition and ubiquity of the popular card networks. Attempts to marry credit cards and mobile phones are not new - encrypted phone wallet systems have been bundled with devices for a number of years. However, use of these wallet systems remains limited as the public failed to embrace shopping via WAP, frustrated by slow speeds and poor user interfaces. With mobile terminals more suited for browsing, and higher speeds from mobile data becoming the norm, we present a system to enable remote macropurchases using existing credit card technology.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday - Friday, 10 am - 6 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691
Prosecution Insights