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 Claims
Claims 1-20 are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/27/25 and 3/2/26 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-20 are directed to a system, method, or product, which are/is one of the statutory categories of invention. (Step 1: YES).
The Examiner has identified independent method claim 1 as the claim that represents the claimed invention for analysis and is similar to independent system claim 8 and product claim 15. Claim 1 recites the limitations of linking/adding payment accounts to an electronic wallet.
These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. Determining if user wallet can be linked to a user’s payment service account; displaying link option on wallet user interface; receiving request to link wallet to the user’s payment account; and sending payment card information to a payment service server to be added to the payment service account, – specifically, the claim recites:
“determining… whether a wallet of a user can be linked to a payment service account of the user;
causing a link option to be displayed to the user… receiving… a request to link the wallet to the payment service account; and sending… card information for one or more payment cards in the wallet… be added to the payment service account”, recites a fundamental economic practice, directed to mitigating risk.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice or commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The “a system”, “one or more processors”, “a wallet user interface”, “a payment service server”, and “one or more non-transitory computer-readable media”, in claim 8; and the additional technical element of “a wallet server” in claim 1, are just applying generic computer components to the recited abstract limitations. The recitation of generic computer components in a claim does not necessarily preclude that claim from reciting an abstract idea. Claims 1 and 15 are also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims recite an abstract idea)
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of: a computer such as a system, a payment service server, a wallet server, and one or more processors; a communication device such as a wallet user interface; and a storage unit such as one or more non-transitory computer-readable media. The computer hardware/software is/are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, claims 1, 8, and 15 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer hardware amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Accordingly, these additional elements, do not change the outcome of the analysis, when considered separately and as an ordered combination. Thus, claims 1, 8, and 15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims further define the abstract idea that is present in their respective independent claims 1, 8, and 15 and thus correspond to Certain Methods of Organizing Human Activity, and hence are abstract for the reasons presented above.
Dependent claim 2 discloses the limitation of determining whether the wallet can be linked to the payment service account of the user comprises determining whether the payment service account of the user exists based on contact information for the user stored in the wallet of the user, which further narrows the abstract idea.
Dependent claim 3 discloses the limitation of before sending the card information for the one or more payment cards to the payment service server: causing the user to be authenticated with the payment service server for the payment service account of the user, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 4 discloses the limitation of before sending the card information for the one or more payment cards to the payment service server: initiating an asynchronous process to obtain one or more tokens for the one or more payment cards in the wallet for subsequent use in one or more checkout transactions at one or more merchant websites, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 5 discloses the limitation of sending the one or more tokens to the payment service server, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 6 discloses the limitation of the tokens are obtained from a token service provider, which further narrows the abstract idea.
Dependent claim 7 discloses the limitation of creating a secure payload for a transaction of the one or more checkout transactions; and sending the secure payload to the payment service server to enable the payment service server to process the transaction using a selected payment card of the one or more payment cards, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 9 discloses the limitation of whether the wallet can be linked to the payment service account of the user comprises determining whether the payment service account of the user exists based on contact information for the user stored in the wallet of the user, which further narrows the abstract idea.
Dependent claim 10 discloses the limitation of before sending the card information for the one or more payment cards to the payment service server: causing the user to be authenticated with the payment service server for the payment service account of the user, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 11 discloses the limitation of before sending the card information for the one or more payment cards to the payment service server: initiating an asynchronous process to obtain one or more tokens for the one or more payment cards in the wallet for subsequent use in one or more checkout transactions at one or more merchant websites, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 12 discloses the limitation of sending the one or more tokens to the payment service server, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 13 discloses the limitation of the tokens are obtained from a token service provider, which further narrows the abstract idea.
Dependent claim 14 discloses the limitation of creating a secure payload for a transaction of the one or more checkout transactions; and sending the secure payload to the payment service server to enable the payment service server to process the transaction using a selected payment card of the one or more payment cards, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 16 discloses the limitation of determining whether the wallet can be linked to the payment service account of the user comprises determining whether the payment service account of the user exists based on contact information for the user stored in the wallet of the user, which further narrows the abstract idea.
Dependent claim 17 discloses the limitation of the operations further comprise, before sending the card information for the one or more payment cards to the payment service server: causing the user to be authenticated with the payment service server for the payment service account of the user, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 18 discloses the limitation of the operations further comprise, before sending the card information for the one or more payment cards to the payment service server: initiating an asynchronous process to obtain one or more tokens for the one or more payment cards in the wallet for subsequent use in one or more checkout transactions at one or more merchant websites, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 19 discloses the limitation of sending the one or more tokens to the payment service server, which further narrows the abstract idea.
Dependent claim 20 discloses the limitation of creating a secure payload for a transaction of the one or more checkout transactions; and sending the secure payload to the payment service server to enable the payment service server to process the transaction using a selected payment card of the one or more payment cards, which further narrows the abstract idea. Note that the technical element “the payment service server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Thus, the dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Therefore, the dependent claims are directed to an abstract idea. Thus, the claims 1-20 are not patent-eligible.
Claim Rejections - 35 USC § 102(a)(1)
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention
OR
(a) (2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Apple (iPhone User Guide, https://web.archive.org/web/20210418221003/https://support.apple.com/guide/iphone/set-up-apple-pay-iph9b7f53382/ios, April 18, 2021).
Regarding claim 1, Apple teaches.
a computer-implemented method comprising: determining, by a wallet server, whether a wallet of a user can be linked to a payment service account of the user
(“Page 1, bottom half: Do one of the following: Add a new card: Position iPhone so that your card appears in the frame, or enter the card details manually. Add your previous cards: Select the card associated with your Apple ID, cards you use with Apple Pay on your other devices, or cards that you removed. Tap Continue, then enter the CVV number of each card. Alternatively, you may be able to add your card from the app of the bank or card issuer”).
causing a link option to be displayed to the user on a wallet user interface
(“Page 1, paragraph 2: To set up Apple Pay, add your debit, credit, and prepaid cards to Wallet”).
PNG
media_image1.png
588
489
media_image1.png
Greyscale
receiving, at the wallet server from the wallet user interface, a request to link the wallet to the payment service account
(“Page 1, paragraph 2: To set up Apple Pay, add your debit, credit, and prepaid cards to Wallet”).
PNG
media_image1.png
588
489
media_image1.png
Greyscale
sending, by the wallet server, card information for one or more payment cards in the wallet to a payment service server be added to the payment service account
(“Page 1, last paragraph: The card issuer determines whether your card is eligible for Apple Pay, and may ask you for additional information to complete the verification process”).
Regarding claim 2, Apple discloses
determining whether the wallet can be linked to the payment service account of the user comprises determining whether the payment service account of the user exists based on contact information for the user stored in the wallet of the user
(“Page 1, bottom half, 2nd bullet: Add your previous cards: Select the card associated with your Apple ID, cards you use with Apple Pay on your other devices, or cards that you removed. Tap Continue, then enter the CVV number of each card”).
Regarding claim 3, Apple discloses
before sending the card information for the one or more payment cards to the payment service server: causing the user to be authenticated with the payment service server for the payment service account of the user
(“Page 1, last paragraph: The card issuer determines whether your card is eligible for Apple Pay, and may ask you for additional information to complete the verification process”).
Claim 8 is rejected using the same rationale that was used for the rejection of claim 1.
Claim 9 is rejected using the same rationale that was used for the rejection of claim 2.
Claim 10 is rejected using the same rationale that was used for the rejection of claim 3.
Claim 15 is rejected using the same rationale that was used for the rejection of claim 1.
Claim 16 is rejected using the same rationale that was used for the rejection of claim 2.
Claim 17 is rejected using the same rationale that was used for the rejection of claim 3.
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 4-7, 11-14, and 18-20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Apple in view of Hurley (20180315051).
Regarding claim 4, Apple discloses
Apple does not disclose, however, Hurley teaches
before sending the card information for the one or more payment cards to the payment service server: initiating an asynchronous process
(“[0249] In particular embodiments, client system 1106 may include a web browser… As an example, and not by way of limitation, webpages may render from HTML files, Extensible Hyper Text Markup Language (XHTML) files, or Extensible Markup Language (XML) files, according to particular needs. Such pages may also execute scripts such as, for example and without limitation, those written in JAVASCRIPT, JAVA, MICROSOFT SILVERLIGHT, combinations of markup language and scripts such as AJAX (Asynchronous JAVASCRIPT and XML), and the like. Herein, reference to a webpage encompasses one or more corresponding webpage files (which a browser may use to render the webpage) and vice versa, where appropriate”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Apple to include before sending the card information for the one or more payment cards to the payment service server: initiating an asynchronous process as taught by Hurley to include multiple scripts/process (including Asynchronous) to facilitate payment transactions between users of a networking system by providing an application program interface that allows a plurality of different providers to integrate with a networking system – see “[0008] One or more embodiments described herein provide benefits and/or solve one or more of the foregoing or other problems in the art with systems and methods to facilitate payment transactions between users of a networking system. In particular, the systems and methods provide an application program interface that allows a plurality of different providers to integrate with a networking system. By allowing different providers to integrate with the networking system using the application program interface, one or more embodiments leverage the networking system to allow users of various providers to engage in payment transactions with each other. Thus, the systems and methods provide a centralized system that facilitates payment transactions between users even if the users use different providers.” And (“[0249] In particular embodiments, client system 1106 may include a web browser… As an example, and not by way of limitation, webpages may render from HTML files, Extensible Hyper Text Markup Language (XHTML) files, or Extensible Markup Language (XML) files, according to particular needs. Such pages may also execute scripts such as, for example and without limitation, those written in JAVASCRIPT, JAVA, MICROSOFT SILVERLIGHT, combinations of markup language and scripts such as AJAX (Asynchronous JAVASCRIPT and XML), and the like. Herein, reference to a webpage encompasses one or more corresponding webpage files (which a browser may use to render the webpage) and vice versa, where appropriate”).
Apple also does not disclose, however, Hurley teaches
to obtain one or more tokens for the one or more payment cards in the wallet for subsequent use in one or more checkout transactions at one or more merchant websites
(“[0093] As the request for the payment transaction comes from the networking system 114, the payment provider can require that networking system 114 authenticate or otherwise verify that the transaction was requested by the user/owner of the account associated with the account identifier in the transaction instructions 420. As such, the payment provider 404 can require that the transaction instructions 420 include an access token associated with the account associated with the account identifier. The access token can allow the networking system 114 to make requests on behalf of the user/owner of the account associated with the account identifier”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Apple to include to obtain one or more tokens for the one or more payment cards in the wallet for subsequent use in one or more checkout transactions at one or more merchant websites as taught by Hurley to include secure features (including access token) to facilitate payment transactions between users of a networking system by providing an application program interface that allows a plurality of different providers to integrate with a networking system – see “[0008] One or more embodiments described herein provide benefits and/or solve one or more of the foregoing or other problems in the art with systems and methods to facilitate payment transactions between users of a networking system. In particular, the systems and methods provide an application program interface that allows a plurality of different providers to integrate with a networking system. By allowing different providers to integrate with the networking system using the application program interface, one or more embodiments leverage the networking system to allow users of various providers to engage in payment transactions with each other. Thus, the systems and methods provide a centralized system that facilitates payment transactions between users even if the users use different providers.” And (“[0093] As the request for the payment transaction comes from the networking system 114, the payment provider can require that networking system 114 authenticate or otherwise verify that the transaction was requested by the user/owner of the account associated with the account identifier in the transaction instructions 420. As such, the payment provider 404 can require that the transaction instructions 420 include an access token associated with the account associated with the account identifier. The access token can allow the networking system 114 to make requests on behalf of the user/owner of the account associated with the account identifier”).
Regarding claim 5, the combination of Apple and Hurley, as shown in the rejection above, discloses the limitations of claim 4.
Apple does not disclose, however, Hurley further discloses
sending the one or more tokens to the payment service server
(“[0200] As mentioned, the user profile database 838 stores user profile information for users. In one or more embodiments, user profile information includes payment credentials (i.e., a payment token representing a payment authorization number, as described previously) for a credit card, a debit card, a deposit account or other bank accounts, gift card accounts, store credit accounts, etc. The user profile database 838 can also store additional information associated with the payment credentials, such as expiration dates, security codes, address information, and/or other information. User profile information can also include one or more default payment method for payment transactions for one or more merchants or co-users”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Apple to include sending the one or more tokens to the payment service server as taught by Hurley to include secure features (including access token) to facilitate payment transactions between users of a networking system by providing an application program interface that allows a plurality of different providers to integrate with a networking system – see “[0008] One or more embodiments described herein provide benefits and/or solve one or more of the foregoing or other problems in the art with systems and methods to facilitate payment transactions between users of a networking system. In particular, the systems and methods provide an application program interface that allows a plurality of different providers to integrate with a networking system. By allowing different providers to integrate with the networking system using the application program interface, one or more embodiments leverage the networking system to allow users of various providers to engage in payment transactions with each other. Thus, the systems and methods provide a centralized system that facilitates payment transactions between users even if the users use different providers.” And (“[0093] As the request for the payment transaction comes from the networking system 114, the payment provider can require that networking system 114 authenticate or otherwise verify that the transaction was requested by the user/owner of the account associated with the account identifier in the transaction instructions 420. As such, the payment provider 404 can require that the transaction instructions 420 include an access token associated with the account associated with the account identifier. The access token can allow the networking system 114 to make requests on behalf of the user/owner of the account associated with the account identifier”).
Regarding claim 6, the combination of Apple and Hurley, as shown in the rejection above, discloses the limitations of claim 4.
Apple does not disclose, however, Hurley further discloses
the tokens are obtained from a token service provider
(“[0200] As mentioned, the user profile database 838 stores user profile information for users. In one or more embodiments, user profile information includes payment credentials (i.e., a payment token representing a payment authorization number, as described previously) for a credit card, a debit card, a deposit account or other bank accounts, gift card accounts, store credit accounts, etc. The user profile database 838 can also store additional information associated with the payment credentials, such as expiration dates, security codes, address information, and/or other information. User profile information can also include one or more default payment method for payment transactions for one or more merchants or co-users”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Apple to include the tokens are obtained from a token service provider as taught by Hurley to include secure features (including access token) to facilitate payment transactions between users of a networking system by providing an application program interface that allows a plurality of different providers to integrate with a networking system – see “[0008] One or more embodiments described herein provide benefits and/or solve one or more of the foregoing or other problems in the art with systems and methods to facilitate payment transactions between users of a networking system. In particular, the systems and methods provide an application program interface that allows a plurality of different providers to integrate with a networking system. By allowing different providers to integrate with the networking system using the application program interface, one or more embodiments leverage the networking system to allow users of various providers to engage in payment transactions with each other. Thus, the systems and methods provide a centralized system that facilitates payment transactions between users even if the users use different providers.” And (“[0093] As the request for the payment transaction comes from the networking system 114, the payment provider can require that networking system 114 authenticate or otherwise verify that the transaction was requested by the user/owner of the account associated with the account identifier in the transaction instructions 420. As such, the payment provider 404 can require that the transaction instructions 420 include an access token associated with the account associated with the account identifier. The access token can allow the networking system 114 to make requests on behalf of the user/owner of the account associated with the account identifier”).
Regarding claim 7, the combination of Apple and Hurley, as shown in the rejection above, discloses the limitations of claim 4.
Apple does not disclose, however, Hurley further discloses
creating a secure payload for a transaction of the one or more checkout transactions; and sending the secure payload to the payment service server to enable the payment service server to process the transaction using a selected payment card of the one or more payment cards
(“[0092] For example, in one or more embodiments, the transaction instructions comprise a request identifier, a client identifier, a network system specific transfer identifier, a currency, an amount, a fee if any, sender payment data (e.g., a payment type (wallet), a provider account identifier, a provider type, a credential identifier, and an access token), receiver payout data (e.g., a payment type (wallet), a provider account identifier, a provider type, and a credential identifier), and optionally routing instructions for sending the payment to the recipient payment provider)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Apple to include creating a secure payload for a transaction of the one or more checkout transactions; and sending the secure payload to the payment service server to enable the payment service server to process the transaction using a selected payment card of the one or more payment cards as taught by Hurley to include secure features (including access token) to facilitate payment transactions between users of a networking system by providing an application program interface that allows a plurality of different providers to integrate with a networking system – see “[0008] One or more embodiments described herein provide benefits and/or solve one or more of the foregoing or other problems in the art with systems and methods to facilitate payment transactions between users of a networking system. In particular, the systems and methods provide an application program interface that allows a plurality of different providers to integrate with a networking system. By allowing different providers to integrate with the networking system using the application program interface, one or more embodiments leverage the networking system to allow users of various providers to engage in payment transactions with each other. Thus, the systems and methods provide a centralized system that facilitates payment transactions between users even if the users use different providers.” And (“[0093] As the request for the payment transaction comes from the networking system 114, the payment provider can require that networking system 114 authenticate or otherwise verify that the transaction was requested by the user/owner of the account associated with the account identifier in the transaction instructions 420. As such, the payment provider 404 can require that the transaction instructions 420 include an access token associated with the account associated with the account identifier. The access token can allow the networking system 114 to make requests on behalf of the user/owner of the account associated with the account identifier”).
Claim 11 is rejected using the same rationale that was used for the rejection of claim 4.
Claim 12 is rejected using the same rationale that was used for the rejection of claim 5.
Claim 13 is rejected using the same rationale that was used for the rejection of claim 6.
Claim 14 is rejected using the same rationale that was used for the rejection of claim 7.
Claim 18 is rejected using the same rationale that was used for the rejection of claim 4.
Claim 19 is rejected using the same rationale that was used for the rejection of claim 5.
Claim 20 is rejected using the same rationale that was used for the rejection of claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Badal-Badalian (20180150832) teaches system, process and device for e-commerce transactions.
Liu (20180150816) teaches mobile payment system.
Spector (9195984) teaches systems and methods for processing transactions using a wallet.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK H GAW whose telephone number is (571)270-0268. The examiner can normally be reached Mon-Fri: 9am -5pm.
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, Mike Anderson can be reached on 571 270-0508. 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.
/MARK H GAW/Examiner, Art Unit 3693
Prosecution Insights