DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 12/29/2025.
Claims 1 and 14 are amended.
Claims 1-14 are pending.
Claims 1-14 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive.
101
Applicant argues “This sequence of server-to-server communications, identifier-based account resolution, and controlled generation of a substitute payment number cannot be performed as a "human activity" and is not a "fundamental economic practice," but rather a technical process for securely handling tokenized payment credentials in digital wallet environments. …Applicant respectfully submits that independent claim 1 is directed to a technological solution for managing payment data security in electronic commerce systems, not to an abstract method of organizing human activity under Step 2A, Prong One.” Examiner disagrees.
First, the claims are drawn to a fundamental economic practice. Applicant’s claims recite communications to the result of generating a payment number to be used in a transaction. Even in combination, the communications recite the receipt and transmission of information surrounding the generating of a payment number for a transaction, similar to fundamental economic practices involving the request and receipt of payment numbers for a transaction. Additionally, the “technological solution for managing payment data security in electronic commerce systems” is also drawn to the abstract idea in mitigating risk for a fundamental economic practice.
The limitations do not provide a technical solution, they recite a business process, and “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int’l v. IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology.” MPEP 2106.05(a) (II). Neither the wallet server nor the processing server’s computers nor technology, appear to be improved. The rejection is maintained.
103
Nagasundaram teaches wherein neither the wallet server nor the external computing device need possess nor transmit the transaction account number associated with the token identifier; identifying, by the processing server, the transaction account number stored therein that is associated with the token identifier (¶ 40-42, 59, 88, 90, 98, 99, 114);
Nagasundaram - A NTTID purpose identifier may identify the transaction token as a non-transactable token that may be stored on a merchant system or other system instead of a real account number. This is done to ensure that the merchant system is not storing financial credentials of users and that it is PCI-DSS compliant. …The data type identifier 203 may represent the type of token represented by the transaction token format or the purpose for the token represented by the transaction token format. For example, the data type identifier may indicate that the transaction token is associated with a primary account number (PAN), (¶ 88, 90)
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 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, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12198133 (“Patent Document”). Although the claims at issue are not identical, they are not patentably distinct from each other. Claim 1 of the Patent Document recites all the limitations of claim 1 of the instant application; however, claim 1 of the Instant Application differs since it further recites additional claim limitations but this limitation is covered in Claim 4 of the Patent Document.
Instant Application
Patent Document
1. A method for supplying controlled payment numbers (CPNs) for use on behalf of tokenized payment accounts in digital wallets for e-commerce, comprising:
1. A method for supplying a controlled payment number (CPN) for use on behalf of a tokenized payment account in a digital wallet for e-commerce, comprising:
receiving, by a wallet server, from an external computing device, a token identifier (i) associated with a tokenized payment account stored in a memory accessible by a digital wallet of the external computing device and (ii) associated with a transaction account number stored on a processing server separate from the external computing device and the wallet server; wherein neither the wallet server nor the external computing device need possess nor transmit the transaction account number associated with the token identifier
receiving, by a wallet server, at least a token identifier from an external computing device, the token identifier being associated with a tokenized payment account in the external computing device, wherein neither the wallet server nor the external computing device possesses nor transmits a transaction account number associated with the token identifier;
transmitting, by the wallet server, a CPN request to the processing server, the CPN request includes the token identifier;
transmitting, by the wallet server, at least the token identifier and a request flag to a processing server indicating a request for the CPN;
receiving, by the processing server, the CPN request from the wallet server;
receiving, by the processing server, at least the token identifier and the request flag from the wallet server;
identifying, by the processing server, the transaction account number stored therein that is associated with the token identifier, wherein the transaction account number corresponds to the tokenized payment account;
identifying, by the processing server, the transaction account number associated with the token identifier, wherein the transaction account number corresponds to the payment account;
generating, by the processing server, a CPN corresponding to the tokenized payment account; and
identifying, by the processing server, the CPN corresponding to the payment account;
receiving, by the wallet server, the identified controlled payment number from the processing server; and
transmitting, by the processing server, the generated CPN to the external computing device via the wallet server.
transmitting, by the wallet server, the identified controlled payment number to the external computing device.
With regard to the “generating…” step of the Instant Application, Claim 4 of the Patent Document recites the additional elements “4. The method of claim 1, wherein identifying the controlled payment number comprises: transmitting, by the processing server, the transaction account number to a generation server; generating, by the generation server, the controlled payment number; mapping, by the generation server, the controlled payment number to the transaction account number; and receiving, by the processing server, the controlled payment number from the generation server.”
The claims are directed to the same subject matter, perform the same method steps and a person of ordinary skill in the art would not be free to practice one of the claimed inventions without infringing upon the other inventions. The instant application claims are generic to the limitations in the Patent Document. Each limitation in the instant application is fully encompassed in the Patent Document 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 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 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 (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, and claim 8 is directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “receiving… identifier … transmitting… request… receiving… request… identifying, …. transaction account number … generating, … a CPN … and transmitting… the generated CPN ….” The recited limitations fall within the certain methods of organizing human activity grouping of abstract ideas, specifically, fundamental economic principles for mitigating risk, for example, requesting and generating a token of an account number. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application.
According to the disclosure(¶ 30), “A controlled payment number may be a number that is of the same format as a traditional transaction account number, but may be subject to one or more transaction controls, such as controls on transaction amounts, number of transactions, merchants, time and/or date, currency type, transaction type, or a combination thereof. A controlled payment number may be generated for the transaction account and mapped to that transaction account by the processing server 114 or generating server 116, as applicable.” The generated controlled payment number is a token of a traditional account number. Generating a representation of information is not an additional element.
Accordingly, even in combination, these elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “receiving… identifier … transmitting… request… receiving… request… identifying, …. transaction account number … generating, … a CPN … and transmitting… the generated CPN” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of a fundamental economic practice as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Dependent claims 2, 3. 7. 9, 10, and 14 provide descriptive language surrounding the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
Dependent claims 4-6, and 11-13 discuss functions in more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 2-7, and 9-14 are also rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 8 recite “neither the wallet server nor the external computing device need possess nor transmit the transaction account number associated with the token identifier….”. The claims are unclear and indefinite. According to the disclosure(¶ 22, 24, 38, 55), “Examples of account information may include a PAN (primary account number or “account number”), …The consumer may register their transaction account with the wallet server 112 using the digital wallet on the computing device 102. As part of the registration, the consumer may supply details regarding the transaction account to the wallet server 11…The wallet server 112 may store account details for the transaction account and may generate a token identifier to represent the transaction account…The receiving device 202 may also be configured to receive data signals electronically transmitted by wallet servers 112, which may be superimposed or otherwise encoded requests for controlled payment numbers, such as may include token identifiers and one or more transaction control values, or controlled payment numbers and other accompanying account details… In one embodiment, the external computing device and wallet server may never receive or possess the transaction account number.” The limitations are unclear if Applicant’s limitations explain that the device and server do not “need” to possess nor transmit the account number, or that the device and server simply do not possess nor transmit this information. Not needing to possess or transmit information is not the same as not possessing or transmitting the information. Furthermore, it is unclear how an algorithm would determine the computing device and wallet server not “needing” to perform a function or possess information. The claims are unclear and indefinite. Dependent claims 2-7, and 9-14 are also rejected.
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, 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 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over Dey et al. (US 20230102161) (“Dey”), and further in view of Nagasundaram et al. (US20150112870) (“Nagasundaram”).
Regarding claims 1 and 8, Dey discloses receiving, by a wallet server, from an external computing device, a token identifier (i) associated with a tokenized payment account stored in a memory accessible by a digital wallet of the external computing device and (ii) associated with a transaction account number stored on a processing server separate from the external computing device and the wallet server, wherein neither the wallet server nor the external computing device need possess nor transmit the transaction account number associated with the token identifier (¶ 25-30, 46-64, 88-91; claim 1);
Claim Interpretation – According to the disclosure(¶ 24, 38), “The consumer may register their transaction account with the wallet server 112 using the digital wallet on the computing device 102. As part of the registration, the consumer may supply details regarding the transaction account to the wallet server 11…The wallet server 112 may store account details for the transaction account and may generate a token identifier to represent the transaction account…The receiving device 202 may also be configured to receive data signals electronically transmitted by wallet servers 112, which may be superimposed or otherwise encoded requests for controlled payment numbers, such as may include token identifiers and one or more transaction control values, or controlled payment numbers and other accompanying account details. ”
Dey - A “token” may be a substitute value for a credential. …For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.”… In some embodiments, a token value may be generated such that the recovery of the original PAN, other account identifier, or virtual access credential from the token value may not be computationally derived…. The user may then add additional accounts to be associated with the FVC and the FVC token via, for example, the wallet application 200. For example, the transaction processing network computer 210 may provide, to the user, a list of available accounts that may be associated with the FVC. The user may make a selection of one or more accounts (in addition to the first account issued by the first issuer 216), and return the selection to the transaction processing network computer 210…. In some embodiments, the initial token generation request may include an identifier for a first user account issued, for example, by the first issuer 216. Thus, when the token is generated, the token could be associated with the first account and the FVC… (¶ 26, 64)
transmitting, by the wallet server, a CPN request to the processing server, the CPN request includes the token identifier(¶ 41, 62-67);
Dey - The wallet application 200 may send device identifying information and credentials (e.g. device identifier and secret key) along with account information (e.g. account holder name, account number, CVV2, expiration date) to the wallet provider 202, which in turn calls the token issuer 204 to request a new token… In some embodiments, the initial token generation request may include an identifier for a first user account issued, for example, by the first issuer 216. Thus, when the token is generated, the token could be associated with the first account and the FVC. (¶ 62, 64)
receiving, by the processing server, the CPN request from the wallet server(¶ 41, 62-67);
Dey - The wallet application 200 may send device identifying information and credentials (e.g. device identifier and secret key) along with account information (e.g. account holder name, account number, CVV2, expiration date) to the wallet provider 202, which in turn calls the token issuer 204 to request a new token… In some embodiments, the initial token generation request may include an identifier for a first user account issued, for example, by the first issuer 216. Thus, when the token is generated, the token could be associated with the first account and the FVC. (¶ 62, 64)
identifying, by the processing server, the transaction account stored therein that is associated with the token identifier, wherein the transaction account number corresponds to the tokenized payment account (¶ 26, 46-64);
Dey - For example, a payment token may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) or a virtual access credential. …According to various embodiments, the transaction processing network computer 110 may acquire credentials associated with a plurality of accounts of a user. The transaction processing network computer 110 may then generate the FVC having a FVC identifier. The transaction processing network computer 110 may also determine a token associated with the FVC. The token may act as a proxy for the FVC identifier. In some embodiments, the transaction processing network computer 110 may generate the token. (¶ 26, 46)
generating, by the processing server, a CPN corresponding to the tokenized payment account; and (¶ 26; 46, 61-65 claim 1);
Dey - According to various embodiments, the transaction processing network computer 110 may acquire credentials associated with a plurality of accounts of a user. The transaction processing network computer 110 may then generate the FVC having a FVC identifier. The transaction processing network computer 110 may also determine a token associated with the FVC. The token may act as a proxy for the FVC identifier. In some embodiments, the transaction processing network computer 110 may generate the token. (¶ 46)
transmitting, by the processing server, the generated CPN to the external computing device via the wallet server(¶ 47-65; claim 1);
Dey - the transaction processing network computer 110 may inform the authorizing entities 112, 114, 116 of the active association between the FVC (or the token associated with the FVC) and the account generated by respective authorizing entities 112, 114, 116… The transaction processing network computer 210 may then notify the issuers 216, 218 for each of the accounts about the association between the account generated by the respective issuers and the FVC token. (¶ 50, 64)
Dey does not disclose identifying, by the processing server, the transaction account number stored therein that is associated with the token identifier.
Nagasundaram teaches wherein neither the wallet server nor the external computing device need possess nor transmit the transaction account number associated with the token identifier; identifying, by the processing server, the transaction account number stored therein that is associated with the token identifier (¶ 40-42, 59, 88, 90, 98, 99, 114);
Nagasundaram - A NTTID purpose identifier may identify the transaction token as a non-transactable token that may be stored on a merchant system or other system instead of a real account number. This is done to ensure that the merchant system is not storing financial credentials of users and that it is PCI-DSS compliant. …The data type identifier 203 may represent the type of token represented by the transaction token format or the purpose for the token represented by the transaction token format. For example, the data type identifier may indicate that the transaction token is associated with a primary account number (PAN), (¶ 88, 90)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dey and Nagasundaram
in order to provide further protection for user personal information during a transaction (Nagasundaram; ¶ 2-4).
Regarding claims 2 and 9, Dey discloses wherein the CPN is subject to one or more transaction controls (¶ 34, 42, 48, 49, 54, 67-70, 78).
Regarding claims 3 and 10, Nagasundaram teaches wherein the CPN is a one-time use number (¶ 57, 108, 159).
Regarding claims 4 and 11, Dey discloses wherein generating the CPN comprises: transmitting, by the processing server, the transaction account number to a generation server; generating, by the generation server, the CPN; mapping, by the generation server, the generated CPN to the transaction account number; and receiving, by the processing server, the generated CPN from the generation server (¶ 49-54, 62-67, 73-83).
Regarding claims 5 and 12, Dey discloses mapping, by the processing server, the CPN to the transaction account number (¶ 26-28, 49-54, 62-67, 73).
Regarding claims 6 and 13, Nagasundaram teaches receiving, by the processing server, a transaction message for an electronic payment transaction, the transaction message including at least the CPN; and replacing, by the processing server, the CPN in the transaction message with the transaction account number (¶ 40-42, 59, 88, 90, 98, 99, 114).
Regarding claims 7 and 14, Dey discloses wherein the transaction message is formatted according to one or more standards including at least one of the ISO 8583 or ISO 20022 standards (¶ 16, 18, 26, 29, 30, 37).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kumnick (US 20150319158) teaches one time use tokens.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
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 H PATEL can be reached on (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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699
Prosecution Insights