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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 30, 2026 has been entered.
Response to Amendment
The amendment filed March 30, 2026 has been entered. Claims 1 and 4-22 remain pending in the application. Applicant’s amendments to the Claims have overcome each and every 101 rejections previously set forth in the Non-Final Office Action mailed December 29, 2025.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4-5, 8-9, 11-13, 15, and 17-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dill (US 20150032627 A1) in view of Cho (US 20180276657 A1).
Regarding Claims 1 and 19-20, Dill teaches A computer-implemented method comprising (Dill: Abstract): A system comprising one or more processors and one or more non-transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising (Dill: Paragraph(s) 0013-0014): One or more non-transitory computer-readable media storing computing instructions that, when executed on one or more processors, cause the one or more processors to perform operations comprising (Dill: Paragraph(s) 0013-0014, 0140):
Setting up, by a wallet system, a shared wallet associated with a user in a wallet directory of the wallet system based on identifying information for a plurality of cards issued to the user from multiple different issuers (Dill: Paragraph(s) 0089-0090, 0098, 0175 teach(es) the consumer device may include a wallet or a payment application that may be associated with one or more payment accounts of the consumer; the consumer device may be a payment card such as a credit card, debit card, prepaid card, loyalty card, gift card, etc.); receiving, by the wallet system from a first merchant, a unique identifier associated with the user, wherein the unique identifier is entered by the user on a page of the first merchant (Dill: Paragraph(s) 0123, 0149, 0070, 0081, 0123 teach(es) e-commerce merchants may provide a token requestor identifier, a PAN (card-on-file), a CVV2, an expiration date and optionally a consumer user identifier used for an e-commerce web application using the merchant token interface; the merchant token interface may allow the e-commerce merchants to initiate token generation requests for cards-on-file during checkout processes using those cards on file. For example, the token generation module may receive a token requestor identifier, a card-on-file PAN, a CVV2, an expiration date, and optionally a consumer identifier for the e-commerce web application); determining, by the wallet system using the wallet directory, the shared wallet associated with the user based on the unique identifier, wherein the wallet system is operated by an entity that is different from the first merchant, a wallet network system, and the multiple different issuers (Dill: Paragraph(s) 0175, 0144, 0217-0218, 0149, 0070, 0081, 0123, 0091 teach(es) the token requestor identifier may be associated with a wallet application that may be used by the consumer to initiate a transaction using the consumer device; the network token system may allow the registered entities to register their payment cards or accounts with the network token system using their respective interfaces. For example, the registered entities may provide a token requestor identifier; the merchant token interface may allow the e-commerce merchants to initiate token generation requests for cards-on-file during checkout processes using those cards on file), the wallet directory comprises a plurality of unique identifiers and a plurality of shared wallets corresponding with the plurality of unique identifiers, the shared wallet associated with the user is determined from the plurality of shared wallets based on the unique identifier associated with the user, and the shared wallet associated with the user comprises the identifying information for the plurality of cards issued from the multiple different issuers (Dill: Paragraph(s) 0034, 0040, 0148-0149, 0050 teach(es) a network token system that provides a platform that can be leveraged by external entities (e.g., third party wallets, e-commerce merchants, payment enablers/payment service providers, etc.) or internal payment processing network systems that have the need to use the tokens to facilitate payment transactions. A token registry (also referred to as a token vault or token database) can provide interfaces for various token requestors (e.g., mobile device, issuers, merchants, mobile wallet providers, etc.), merchants, acquirers, issuers, and payment processing network systems; a token may be random with respect to the real PAN and the association of the token to the PAN may be provide by a lookup table; The token generation module may provide a token and dCVV which may be validated by the payment processing network computer during the authorization process); …; obtaining, by the wallet system from the first merchant, information about a first selected card of the plurality of cards based on a selection received from the user (Dill: Paragraph(s) 0042, 0144, 0149-0150 teach(es) token request messages may allow a token requestor to request a token to thereby tokenize a PAN. After the token is received by the token requester, the token may be provided to a merchant to conduct a payment transaction); requesting, by the wallet system from an issuer of the first selected card, a first payment authorization token for the first selected card (Dill: Paragraph(s) 0033, 0180 teach(es) The payment processing network (or a server computer therein) can authenticating tokens during and after transactions, thus ensuring that consumers are authorized to complete purchases using the tokens. The payment processing network can also link the payment tokens to the original payment credentials and accountholders associated with the payment tokens; The authorization module may also restore the token in the authorization response message received from the issuer before forwarding it to the acquirer computer), wherein the first payment authorization token is a dynamic cryptogram and valid for a single transaction (Dill: Paragraph(s) 0005-0006, 0068, 0047 teach(es) Payment tokens can be sub categorized into static and dynamic tokens, both of which can be used to submit payment transactions once they are activated; the token presentment mode could be provided through a type of cryptogram or other dynamic data generated for a transaction); and sending, by the wallet system to the first merchant, the first payment authorization token comprising a token cryptogram to enable the first merchant to process the first transaction using the first selected card (Dill: Paragraph(s) 0034, 0068, 0211 teach(es) A token registry (also referred to as a token vault or token database) can provide interfaces for various token requestors (e.g., mobile device, issuers, merchants, mobile wallet providers, etc.), merchants, acquirers, issuers, and payment processing network systems. The interfaces can be used to request, use, manage and request information about tokens; the token presentment mode could be provided through a type of cryptogram or other dynamic data generated for a transaction. For example, each type of transaction presentment mode may have a different cryptogram algorithm associated with that type of presentment mode (e.g., NFC vs. QR Code), and the type of cryptogram used by be determined during validation of the cryptogram).
However, Dill does not explicitly teach sending, by the wallet system to the first merchant, the identifying information for the plurality of cards issued from the multiple different issuers to a user device to enable the user to select one of the cards for a first transaction at the first merchant.
Cho from same or similar field of endeavor teaches sending, by the wallet system to the first merchant, the identifying information for the plurality of cards issued from the multiple different issuers to a user device to enable the user to select one of the cards for a first transaction at the first merchant (Cho: Abstract; Paragraph(s) 0030 teach(es) displaying a list of payment card accounts associated with the selected wallet application for association with the companion application, receiving a selection of at least one payment card account, transmitting payment account credentials of the selected payment account to a wallet server computer, receiving a companion token representing a digitization of the selected payment card account from the wallet server computer, and associating the companion token with the companion application; the user selects one or more payment accounts from a list of payment accounts that are in the user's wallet (which payment accounts may correspond to, for example, payment card accounts such as credit card accounts, debit card accounts, merchant-affiliated payment card accounts, and the like); The consumer next authenticates to the companion application (for example, by entering a personal identification number (“PIN”) or other user credential(s)), and upon successful user authentication the user selects one or more payment accounts from a list of payment accounts that are in the user's wallet (which payment accounts may correspond to, for example, payment card accounts such as credit card accounts, debit card accounts, merchant-affiliated payment card accounts, and the like); In implementations where the companion application is a third-party server-based wallet or is a merchant application, the selected payment account may be digitized as a cloud token (e.g., MDES for commerce platforms token or MDES for merchants token) to a remote platform (such as to a third party server based wallet platform, or to merchant platform)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Dill to incorporate the teachings of Cho for sending, by the wallet system to the first merchant, the identifying information for the plurality of cards issued from the multiple different issuers to a user device to enable the user to select one of the cards for a first transaction at the first merchant.
There is motivation to combine Cho into Dill because Cho’s teachings of selecting one or more payment accounts from a list of payment accounts that are in the user's wallet would facilitate to secure payment credentials from the wallet application for tokenization (Cho: Paragraph(s) 0017, 0030).
Regarding Claim 4, the combination of Dill and Cho teaches all the limitations of claim 1 above; and Dill further teaches wherein the plurality of cards are preloaded into the shared wallet stored in the wallet directory of the wallet system before the first transaction based on the plurality of cards being provisioned in the shared wallet based at least in part on information provided from the multiple different issuers (Dill: Paragraph(s) 0144, 0034, 0040 teach(es) the network token system may allow the registered entities to register their payment cards or accounts with the network token system using their respective interfaces; A token registry (also referred to as a token vault or token database) can provide interfaces for various token requestors (e.g., mobile device, issuers, merchants, mobile wallet providers, etc.), merchants, acquirers, issuers, and payment processing network systems).
Regarding Claim 5, the combination of Dill and Cho teaches all the limitations of claim 1 above; and Dill further teaches wherein each of the plurality of cards are provisioned in the shared wallet based at least in part on an acceptable outcome of a respective fraud risk determination for provisioning each of the plurality of cards (Dill: Paragraph(s) 0047, 0144-0145 teach(es) The token assurance level may also be used to drive transaction fraud liability requirements; the token generation module may generate a token response with a token number, a token expiration date and a token assurance level).
Regarding Claim 8, the combination of Dill and Cho teaches all the limitations of claim 1 above; and Dill further teaches further comprising: …; obtaining information about a second selected card of the plurality of cards based on a selection from the user; requesting a second payment authorization token for the second selected card from the wallet network system; and sending the second payment authorization token to enable the second merchant to process the second transaction using the second selected card (Dill: Paragraph(s) 0042, 0144, 0149, 0033-0034, as stated above with respect to claim 1).
However, the combination does not explicitly teach sending the identifying information for the plurality of cards to enable the user to select one of the plurality of cards for a second transaction at a second merchant different from the first merchant.
Cho further teaches sending the identifying information for the plurality of cards to enable the user to select one of the plurality of cards for a second transaction at a second merchant different from the first merchant (Cho: Abstract; Paragraph(s) 0030, as stated above with respect to claim 1).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill and Cho to incorporate the teachings of Cho for sending the identifying information for the plurality of cards to enable the user to select one of the plurality of cards for a second transaction at a second merchant different from the first merchant.
There is motivation to combine Cho into the combination of Dill and Cho because Cho’s teachings of selecting one or more payment accounts from a list of payment accounts that are in the user's wallet would facilitate to secure payment credentials from the wallet application for tokenization (Cho: Paragraph(s) 0017, 0030).
Regarding Claim 9, the combination of Dill and Cho teaches all the limitations of claim 1 above; and Dill further teaches further comprising: performing an authentication of the user (Dill: Paragraph(s) 0046 teach(es) the network token system can determine a token assurance level based on the authentication of the consumer, payment account credentials and the token by executing one or more authentication methods).
Regarding Claim 11, the combination of Dill and Cho teaches all the limitations of claim 1 above; and Dill further teaches further comprising: performing a fraud risk determination for the first transaction with the first selected card (Dill: Paragraph(s) 0047, 0042 teach(es) The token assurance level may also be used to drive transaction fraud liability requirements).
Regarding Claim 12, the combination of Dill and Cho teaches all the limitations of claim 11 above; and Dill further teaches wherein performing the fraud risk determination further comprises: causing one or more fraud risk determinations to be performed by one or more third-party systems; and performing the fraud risk determination for the first transaction based in part on the one or more fraud risk determinations (Dill: Paragraph(s) 0035, 0197, 0047 teach(es) The token vaults may be managed by an issuer, network or an authorized third party; the updating entity (e.g., network token system, payment processing network, or issuer) may send the updated information to a third party that manages the token routing table and updates the token routing table file and sends to transaction processing entities; The token assurance level may also be used to drive transaction fraud liability requirements).
Regarding Claim 13, the combination of Dill and Cho teaches all the limitations of claim 12 above; and Dill further teaches wherein the one or more fraud risk determinations is performed by the wallet network system (Dill: Paragraph(s) 0034 teach(es) Embodiments of the invention include a network token system that provides a platform that can be leveraged by external entities (e.g., third party wallets, e-commerce merchants, payment enablers/payment service providers, etc.) or internal payment processing network systems that have the need to use the tokens to facilitate payment transactions).
Regarding Claim 15, the combination of Dill and Cho teaches all the limitations of claim 12 above; and Dill further teaches wherein the one or more fraud risk determinations is based at least in part on a device fingerprinting for a mobile device of the user (Dill: Paragraph(s) 0055 teach(es) token attributes may include a wallet identifier associated with the token, an additional account alias or other user account identifier (e.g., an email address, username, etc.), a device identifier, an invoice number, etc.).
Regarding Claim 17, the combination of Dill and Cho teaches all the limitations of claim 11 above; and Dill further teaches wherein the fraud risk determination is based at least in part on one or more of rules, one or more statistical models, or one or more machine-learning models (Dill: Paragraph(s) 0053, 0203 teach(es) if a transaction uses a token that is initiated by a different device than the device that the token was provisioned into, the transaction may be fraudulent).
Regarding Claim 18, the combination of Dill and Cho teaches all the limitations of claim 11 above; and Dill further teaches wherein the fraud risk determination is based at least in part on inputs comprising registered owner information for a mobile device of the user and registered owner information for the first selected card (Dill: Paragraph(s) 0144, 0047, 0054 teach(es) the network token system may allow the registered entities to register their payment cards or accounts with the network token system using their respective interfaces; The token assurance level may also be used to drive transaction fraud liability requirements; tokens may be provisioned by an issuer or a payment processing network onto a mobile device).
Regarding Claims 21-22, the combination of Dill and Cho teaches all the limitations of claims 19-20 above; and Dill further teaches wherein the plurality of cards are preloaded into the shared wallet stored in the wallet directory of the wallet system before the first transaction based on the plurality of cards being provisioned in the shared wallet based at least in part on information provided from the multiple different issuers (Dill: Paragraph(s) 0034, 0040, as stated above with respect to claims 19-20).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dill in view of Cho, as applied to claim 1 above, and in further view of Naik (WO 2024215307 A1).
Regarding Claim 6, the combination of Dill and Cho teaches all the limitations of claim 1 above; and Dill teaches wherein the shared wallet further comprises an email address of the user and … (Dill: Paragraph(s) 0055 teach(es) token attributes may include a wallet identifier associated with the token, an additional account alias or other user account identifier (e.g., an email address, username, etc.), a device identifier, an invoice number, etc.)
However, the combination does not explicitly teach a phone number of the user.
Naik from same or similar field of endeavor teaches a phone number of the user (Naik: Paragraph(s) 0069 teach(es) a token request message may include payment credentials, mobile device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and/or any other suitable information).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill and Cho to incorporate the teachings of Naik for a phone number of the user.
There is motivation to combine Naik into the combination of Dill and Cho because Naik’s teachings of a phone number would facilitate to identify the user for the process (Naik: Paragraph(s) 0069).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dill in view of Cho, as applied to claim 1 above, and in further view of Lim (KR 20200012685 A; refer to the English Translation).
Regarding Claim 7, the combination of Dill and Cho teaches all the limitations of claim 1 above; however the combination does not explicitly teach wherein the shared wallet further comprises a hash of a social security number of the user.
Lim from same or similar field of endeavor teaches wherein the shared wallet further comprises a hash of a social security number of the user (Lim: Page 10, lines 2-13; Page 15, lines 33-39 teach(es) the KYC transaction according to an embodiment of the present invention, the service account address information (for example, the KYC token wallet address of a specific ICO subject), the account address held by the service server, deposit and withdrawal allowance record Account information (e.g., the Ethereum wallet address of a particular user) that is the target of the, the hash value of the identifying information (e.g., the hash value of the social security number of the particular user); The identification information according to an embodiment of the present invention may mean a hash value such as a social security number, a name, facial data, and a UUID input by a user or a service principal to a service server).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill and Cho to incorporate the teachings of Lim for wherein the shared wallet further comprises a hash of a social security number of the user.
There is motivation to combine Lim into the combination of Dill and Cho because Lim’s teachings of a hash of a social security number would facilitate to identify the particular user for the process (Lim: Paragraph(s) Page 10, lines 2-13; Page 15, lines 33-39).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dill in view of Cho, as applied to claim 9 above, and in further view of Chikatamalla (US 20230067023 A1) and Naik (WO 2024215307 A1).
Regarding Claim 10, the combination of Dill and Cho teaches all the limitations of claim 9 above; however the combination does not explicitly teach wherein performing the authentication of the user further comprises: causing a multi-factor authentication to be performed based at least in part on using a … of a mobile device of the user.
Chikatamalla from same or similar field of endeavor teaches wherein performing the authentication of the user further comprises: causing a multi-factor authentication to be performed based at least in part on using a … number of a mobile device of the user (Chikatamalla: Paragraph(s) 0002-0003, 0070 teach(es) Multi-factor authentication (MFA) (or two-factor authentication) is an electronic authentication method in which a user is authorized only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism (e.g., a user-controlled password with a dynamic passcode or one-time password (OTP), etc.)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill and Cho to incorporate the teachings of Chikatamalla for wherein performing the authentication of the user further comprises: causing a multi-factor authentication to be performed based at least in part on using a … number of a mobile device of the user.
There is motivation to combine Chikatamalla into the combination of Dill and Cho because Chikatamalla’s teachings of a multi-factor authentication would facilitate the user authentication for the process (Chikatamalla: Paragraph(s) 0002-0003, 0070).
However, the combination of Dill, Cho, and Chikatamalla does not explicitly teach a phone number of a mobile device of the user.
Naik from same or similar field of endeavor teaches a phone number of a mobile device of the user (Naik: Paragraph(s) 0069 teach(es) a token request message may include payment credentials, mobile device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and/or any other suitable information).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill, Cho, and Chikatamalla to incorporate the teachings of Naik for a phone number of a mobile device of the user.
There is motivation to combine Naik into the combination of Dill, Cho, and Chikatamalla because Naik’s teachings of a phone number would facilitate to identify the user for the process (Naik: Paragraph(s) 0069).
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dill in view of Cho, as applied to claim 12 above, and in further view of Hay (EP 3471038 A1).
Regarding Claim 14, the combination of Dill and Cho teaches all the limitations of claim 12 above; however the combination does not explicitly teach wherein the one or more fraud risk determinations is based at least in part on a card security code for the first selected card.
Hay from same or similar field of endeavor teaches wherein the one or more fraud risk determinations is based at least in part on a card security code for the first selected card (Hay: Paragraph(s) 0084 teach(es) CVC3 is a type of card security code used for the purpose of minimising fraud in payment card transactions when the card is not physically present).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill and Cho to incorporate the teachings of Hay for wherein the one or more fraud risk determinations is based at least in part on a card security code for the first selected card.
There is motivation to combine Hay into the combination of Dill and Cho because Hay’s teachings of a card security code would facilitate minimising fraud in payment card transactions (Hay: Paragraph(s) 0084).
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dill in view of Cho, as applied to claim 12 above, and in further view of Tunnell (US 20170161709 A1).
Regarding Claim 16, the combination of Dill and Cho teaches all the limitations of claim 12 above; however the combination does not explicitly teach wherein the one or more fraud risk determinations is based at least in part on behavior analytics of the user.
Tunnell from same or similar field of endeavor teaches wherein the one or more fraud risk determinations is based at least in part on behavior analytics of the user (Tunnell: Paragraph(s) 0023, 0071-0073 teach(es) Authentication techniques that determine that the user is who he or she says he or she is, such as but not limited to biometrics, behavior metrics, PINs, and/or passwords, further increase fraud prevention, as well as determines the identity of the person at the time of a transaction).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill and Cho to incorporate the teachings of Tunnell for wherein the one or more fraud risk determinations is based at least in part on behavior analytics of the user.
There is motivation to combine Tunnell into the combination of Dill and Cho because Tunnell’s teachings of behavior metrics would facilitate determining the identity of the person at the time of a transaction (Tunnell: Paragraph(s) 0023, 0071-0073).
Response to Arguments
Applicant's arguments filed March 30, 2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument under Claim Rejections - 35 USC § 103 that “Dill does not teach or suggest a wallet system operated by an entity that is different from the first merchant, a wallet network system, and the multiple different issuers,” examiner respectfully argues that Dill teaches that the token requestor identifier may be associated with a wallet application that may be used by the consumer to initiate a transaction using the consumer device. The wallet application is different from the first merchant, the wallet network system, and the issuers (Dill: Paragraph(s) 0175, 0144, 0217-0218, 0149, 0070, 0081, 0123, 0091). It is recommended for the applicant to amend the claims with more technical details and contexts of wallet system, merchant, wallet network system, and issuers.
Regarding applicant’s further argument that “The system does not receive a user identifier from a merchant and use it to look up a shared wallet containing multiple cards from multiple issuers,” examiner respectfully argues the features as stated above in the 103 rejections (Dill: Paragraph(s) 0034, 0040, 0148-0149, 0050).
Regarding applicant’s still further argument that “Neither Dill nor Cho teaches the wallet system requesting the payment authorization token from the issuer of the selected card,” examiner respectfully argues that Dill teaches that the authorization module may also restore the token in the authorization response message received from the issuer before forwarding it to the acquirer computer (Dill: Paragraph(s) 0180).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571)270-1492. 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.
/CLAY C LEE/Primary Examiner, Art Unit 3699
Prosecution Insights