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
This action is in response to remarks received 04/01/2026.
This application claims earliest priority from international filings CN 202111667222.5, filed 12/31/2021.
Claims 1, 7, 19-20, 25 & 26 have been amended and claims 10-18 cancelled.
Claims 1, 7, 19, 20 & 25 being independent claims and claims 2-6, 8-9, 21-24 and 26-29 are dependent.
Applicant’s arguments, see pages 22-26, filed 04/01/2026, with respect to the rejection(s) of claim(s) 1-9 and 19-29 under 35 USC 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Gang Di et al. (US 2025/0238800 A1, herein Di).
Claims 1-9 and 19-29 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 04/01/2026 have been fully considered but they are not persuasive.
With respect to arguments under 35 USC § 101, the arguments have been considered, however, the Examiner respectfully disagrees.
Under Step 2A, Prong One, the claims are directed to an abstract idea.
Applicant contends that the amended claims are not directed to an abstract idea and instead provide a technical solution. This argument is not persuasive.
The claimed invention, even as amended, is directed to digital currency transaction processing, including receiving a transaction request, acquiring feature negotiation information form a hardware carrier, determining a transaction type, calculating a deduction amount, sending a transaction request to an operator or interoperability platform, executing deduction based on wallet type, organizing wallets into parent-child relationships, and receiving and outputting deduction information.
These steps describe fundamental economic practices and commercial interactions, specifically financial transaction management and payment processing, which fall within the category of certain methods of organizing human activity.
The additional limitations concerning a personal wallet, parent/child wallet relationship, and interoperability platform; do not change the character of the claim. These are conceptual financial relationships and data classifications, not technological improvements. Managing balances between wallets and defining hierarchical wallet relationships is still an abstract financial concept, analogous to account management and fund allocation. Accordingly, the claims recite an abstract idea.
Under Step 2A, Prong Two, the claims do not integrate the abstract idea into a practical application.
Applicant argues that the invention provides a technical solution involving hardware wallets, backend storage, and improved architecture. This argument is not persuasive
The additional elements cited by the Applicant include: a terminal, a hardware carrier, a security chip and a backend system of a digital operator; however, these elements are described at a high-level of generality and perform only generic computing functions, such as: storing data, transmitting requests, processing transactions, and determining values.
The claimed “quasi-account mode”, storage distinctions (frontend vs. backend), and “feature negotiation information” merely reflect data organization and allocation decisions, which do not constitute a technological improvement to computer functionality.
Applicant’s argument that the invention reduces storage limitations or improves performance is not supported by specific technical mechanisms in the claims. The claims do not recite: a specific improvement to memory structure, a new data structure, a specific protocol, or a technological improvement in how the hardware operates. Instead, the claims merely use generic computing components as tools to implement the abstract idea. The alleged anonymity and lack of association with the user identity constitute business or privacy rules, not technical improvements. The alleged improvement to reducing storage limitations by storing digital currency strings in a backend system instead of on a hardware wallet constitutes a reallocation of data storage rather than an improvement to how the hardware wallet or memory operates, and therefore does not represent a technological improvement. The use of a security chip as a storage medium and the lack of association between user identity and account value relate to data storage choices and privacy policies, and do not reflect any improvement to cryptographic techniques, security protocols, or hardware operations.
Accordingly, the claims do not integrate the abstract idea into a practical application.
Under Step 2B, the claims do not recite additional elements that amount to significantly more than the abstract idea.
Applicant asserts that the claimed architecture and features provide an inventive concept. This argument is not persuasive. This argument is not persuasive. The additional elements, individually and in combination: generic terminal, hardware carrier/security chip, backend server, and interoperability platform, amount to well-understood, routine, and conventional components performing their expected functions: data storage, communication, processing, and transaction execution.
The “parent-child wallet” relationship and backend storage of currency strings represent conventional account structuring and data management, which do not add significantly more than the abstract idea. The alleged “three-tier architecture” and transaction flow describe an arrangement of components for processing financial transactions and do not recite a specific improvement to computer architecture or system functionality.
The claimed arrangement does not result in: an improvement to computer functionality, an unconventional technical solution, or a transformation of the abstract idea into patent-eligible subject matter. Instead, the claims merely apply the abstract idea using generic computer implementation.
For at least the reasons discussed above, the claims are directed to an abstract idea (Step 2A, Prong One), the claims do not integrate the abstract idea into a practical application (Step 2A, Prong Two), and the claims do not include significantly more than the abstract idea (Step 2B). Accordingly, the rejection under 35 USC § 101 is maintained.
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–9 and 19–29 are rejected under 35 U.S.C. § 101 as being directed to patent-ineligible subject matter. Claims 1, 7, 19, 20, and 25 are independent. Claims 2–6 and 8–9 depend from claim 1, claims 21–24 depend from claim 19 or 20, and claims 26–29 depend from claim 25, and are rejected for the same reasons.
Under Step 1 of the Alice/Mayo framework, the claimed subject matter falls within the statutory categories of process, machine, and article of manufacture. However, meeting a statutory category does not by itself render the claims patent eligible.
Under Step 2A, Prong One, the claims are directed to a judicial exception, namely abstract ideas involving fundamental economic practices and commercial interactions.
Specifically, the claims recite limitations including:
receiving a transaction request in response to a connection to a digital currency wallet;
acquiring feature negotiation information from a hardware carrier of the digital currency wallet;
determining a transaction type based on feature negotiation information;
acquiring a deduction amount corresponding to the transaction request;
generating an interoperability-based transaction request based on the deduction amount and the feature negotiation information;
sending the interoperability-based transaction request to an interoperability platform to invoke a corresponding operator interface to transmit request to digital currency operator;
receiving deduction information after execution;
the digital currency operator receiving an operator transaction request and determining a balance of a corresponding digital currency wallet and a deduction amount according to the operator transaction request;
determining a type of the digital currency wallet;
executing deduction of the digital currency wallet;
generating and returning deduction information;
identifying a wallet type;
designating a personal wallet as a parent wallet and another wallet as a child wallet;
storing feature negotiation information in a hardware carrier;
using a security chip as a storage medium;
recording value of digital currency in the form of an account without associating user identity with the account; and
storing digital currency strings in a backend system.
These limitations, when considered as a whole, describe receiving, processing, routing, and executing digital currency transactions, determining transaction types, calculating and applying deductions, verifying balances, and organizing wallet relationships, which constitute managing financial transaction, intermediating between parties, and organizing financial information.
Such activities are fundamental economic practices and commercial interactions, as well as methods of organizing human activity, which are abstract ideas.
Accordingly, the claims recite a judicial exception.
Under Step 2A, Prong Two, the claims are evaluated to determine whether the abstract idea is integrated into a practical application.
The additional elements recited in the claims include a terminal, processors, storage apparatuses, digital currency wallets, an interoperability platform, near-field communication or Bluetooth connections, password input interfaces, visual screens, a hardware carrier, a security chip, and a backend system.
These elements are described at a high-level of generality and perform their ordinary and conventional functions, such as receiving and transmitting data, storing information, processing transaction data, and facilitating communication between systems.
The limitations relating to acquiring feature negotiation information from a hardware carrier, storing such information in a hardware carrier, using a security chip as a storage medium, storing digital currency strings in a backend system, recording digital currency value in an account without associating user identity with the account, determining wallet types, assigning parent-child wallet relationships, and executing deduction based on wallet type represent data collection, data storage, and organization of financial/account information, and do not reflect any improvement to computer functionality, network technology, or security mechanisms.
The interoperability platform is used as a generic intermediary to route transaction requests and does not impose any meaningful limitation beyond implementing the abstract idea.
The claims therefore use generic computing components as tools to perform the abstract idea and do not effect a transformation or provide any technical improvement.
Accordingly, the claims do not integrate the abstract idea into a practical application under Step 2A, Prong Two.
Under Step 2B, the claims are evaluated to determine whether they include additional elements that amount to significantly more than the abstract idea.
The additional elements, including the terminal, processors storage devices, interoperability platform, hardware carrier, security chip, backend system, and communication interfaces, are well-understood, routine, and conventional components that perform their standard functions of data processing, storage, and transmission.
The limitations directed to: acquiring and storing feature negotiation information, using a security chip as a storage medium, storing digital currency data in a backend system, recording digital currency value without associating user identity, determining wallet types, assigning parent-child wallet relationships, determining balances and deduction amounts, and executing deduction transaction reflect conventional data handling and financial transaction processing operations.
When considered individually and as an ordered combination, these elements do not provide an non-conventional arrangement or a technical improvement, but instead merely implement the abstract idea using generic computing components. Accordingly, the claims do not include additional elements that amount to significantly more than the abstract idea.
The dependent claims further limit the abstract idea by adding conventional financial logic such as determining whether a deduction amount exceeds a balance, invoking a personal wallet to recharge a child wallet, generating transaction identifiers, or organizing wallets in a parent-child relationship. These limitations, including identity non-association and backend storage configurations, merely describe additional aspects of the abstract financial process and data organization, and do not add any unconventional or technological features that transform the abstract idea into patent-eligible subject matter.
Therefore, because the claims are directed to an abstract idea and do not recite significantly more than the abstract idea itself, even when considering the amended limitations directed to feature negotiation using hardware carrier, storage using a security chip, backend storage of digital currency data, identity non-association, and parent-child wallet relationships, claims 1–9 and 19–29 are rejected under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
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.
Claim(s) 1-9 and 19-29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dan Kikinis et al. (US 2020/0394626 A1, herein Kikinis) in view of Di.
As per claim 1. Kikinis teaches a digital currency transaction method, applied to a terminal, comprising:
receiving a transaction request in response to a connection to a digital currency wallet, and acquiring feature negotiation information from a hardware carrier of the digital currency wallet (see Kikinis ¶¶ [88-90], where a user initiates a transaction at a terminal by scanning a QR or 2D barcode using a wallet application, and the terminal extracts payment and network information from the wallet);
determining a transaction type on a basis of the feature negotiation information (see Kikinis ¶¶ [91-92], which discloses a decision tree that determines the best network based on extracted transaction and network attributes.);
acquiring a deduction amount corresponding to the transaction request, and generating an interoperability-based transaction request on the basis of the deduction amount and the feature negotiation information in response to determining that the transaction type is an interoperability-based transaction (see Kikinis ¶¶ [89 & 108], which discloses validation of merchant identity and transaction details including amount prior to approval and a multi-layered cryptocurrency framework enabling cross-network digital currency transfers; Also see ¶¶ [75, 145, 154, 167 & 169], which collectively disclose specifying, validating, and executing a transaction amount for a digital currency transfer, where the transaction amount corresponds to an amount deducted from a digital currency wallet upon execution of the transaction.);
sending the interoperability-based transaction request to an interoperability platform, so as to invoke a corresponding operator interface by means of the interoperability platform to send the interoperability-based transaction request to a corresponding digital currency operator (see Kikinis ¶¶ [92 & 108], which disclose continuing the transaction to a core platform that routes the transaction to the appropriate digital currency framework); and
receiving deduction information generated after the digital currency operator executes deduction on a basis of the interoperability-based transaction request, and outputting the deduction information (see Kikinis ¶ [89], which discloses receipt generation after completion of the transaction, indicating completion of the transaction corresponding to deduction; Also see ¶¶ [75, 145, 154, 167 & 169], which collectively disclose execution of a digital currency transaction for a specified amount and generation of transaction records reflecting completion of the transfer, where such records correspond to deduction information output after execution of the transaction).
wherein the deduction executed by the digital currency operator comprises:
receiving an operator transaction request, and determining the balance of the corresponding digital currency wallet and the deduction amount according to the operator transaction request (Kikinis ¶¶ [67, 70, 87, 106, 133, 154, 158 & 171]);
identifying the type of the digital currency wallet (Kikinis ¶¶ [144, 154-155 & 158]);
wherein the digital currency wallet is a digital currency wallet that records the value of digital currency in a form of an account […] (Kikinis ¶¶ [183 & 194]).
It can be argued that Kikinis does not explicitly teach, however, Di further teaches:
[and does not establish an association relation between a user identity and the value of the digital currency in the account, uses a security chip as a storage medium, the feature negotiation information of the wallet is stored in the hardware carrier, and digital currency strings are stored in the backend system of a digital currency operator] (Di ¶¶ [51, 54, 61, 73 & 81])
designating, by the digital currency operator, the personal wallet as the parent wallet of the digital currency wallet, and taking the digital currency wallet as the child wallet of the parent wallet in response to determining that the type of the digital currency wallet isa personal wallet type (Di ¶¶ [13, 52 & 61]);
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system of Kikinis to incorporate the security chip-based storage and backend-managed digital currency processing of Di in order to improve transaction security, and enable centralized control over digital currency balances and deductions, which are well-known design considerations in digital currency and electronic payment systems. The combination represents the predictable use of prior elements according to their established functions.
As per claims 19 & 20, the claims recite analogous limitations as claim 1 above and interpreted under the same premise.
As per claim 2, the combination of Kikinis and Di teach the method as claimed in claim 1, Kikinis further teaches wherein before the generating an interoperability-based transaction request on the basis of the deduction amount and the feature negotiation information, the method further comprises:
generating a same-operator transaction request in response to determining that the transaction type is a same-operator transaction (see Kikinis ¶¶ [100, 108 & 134]);
sending the same-operator transaction request to a corresponding digital currency operator (see Kikinis ¶¶ [92 & 108]); and
receiving deduction information generated after the digital currency operator executes deduction on a basis of the same-operator transaction request, and outputting the deduction information (see Kikinis ¶¶ [75, 89, 145, 154, 167 & 169]).
As per claim 21, the claim recites analogous limitations as claim 2 above and interpreted under the same premise.
As per claim 3, the combination of Kikinis and Di teach the method as claimed in claim 1, Kikinis further teaches wherein before the sending the interoperability-based transaction request to an interoperability platform, the method further comprises:
determining whether the deduction amount exceeds a password-free limit, displaying a password input interface under a condition that the deduction amount exceeds the password-free limit, acquiring a password input by a user, and verifying the acquired password (see Kikinis ¶¶ [134, 156 & 171]); and
executing a sending process of the interoperability-based transaction request or a sending process of the same-operator transaction request in response to a verification passes (see Kikinis ¶¶ [92 & 108 ]).
As per claim 22, the claim recites analogous limitations as claim 3 above and interpreted under the same premise.
As per claim 4, the combination of Kikinis and Di teach the method as claimed in claim 1, Kikinis further teaches wherein before the receiving a transaction request, the method further comprises:
establishing the connection to the digital currency wallet by means of a near field communication protocol or a Bluetooth connection technology (see Kikinis ¶¶ [88-91 & 185]).
As per claim 5, the combination of Kikinis and Di teach the method as claimed in claim 1, Kikinis further teaches wherein after the receiving a transaction request, the method further comprises:
sending a feature negotiation request to the digital currency wallet (see Kikinis ¶¶ [120, 163 & 166-167]);
receiving transaction parameters returned by the digital currency wallet (see Kikinis ¶¶ [134, 156 & 171]);
determining a corresponding transaction model on a basis of the transaction parameters (see Kikinis ¶¶ [91-94]); and
executing a transaction process based on the transaction request on a basis of the transaction model (see Kikinis ¶¶ [76, 80, 83, 108 & 157]).
As per claim 23, the claim recites analogous limitations as claim 5 above and interpreted under the same premise.
As per claim 6, the combination of Kikinis and Di teach the method as claimed in claim 1, Kikinis further teaches wherein after the receiving deduction information generated after the digital currency operator executes deduction on a basis of the interoperability-based transaction request, the method further comprises:
acquiring a balance, a recharge amount, a deduction amount, a type of the digital currency wallet and a transaction type identifier in the deduction information; and displaying the balance, the recharge amount, the deduction amount, the type of the digital currency wallet and the transaction type identifier on a visual screen (see Kikinis ¶¶ [67, 70, 80 & 87]).
As per claim 7, Kikinis teaches digital currency transaction method, applied to a digital currency operator, comprising:
a terminal receiving a transaction request in response to a connection to a digital currency wallet, and acquiring feature negotiation information from a hardware carrier of the digital currency wallet (see Kikinis ¶¶ [88-90]);
the terminal determining a transaction type on a basis of the feature negotiation information (see Kikinis ¶¶ [91-92]);
the terminal acquiring a deduction amount corresponding to the transaction request, and generating an interoperability-based transaction request on the basis of the deduction amount and the feature negotiation information in response to determining that the transaction type is an interoperability-based transaction (see Kikinis ¶¶ [75, 89, 145, 154, 167 & 169]);
the terminal sending the interoperability-based transaction request to an interoperability platform, so as to invoke a corresponding operator interface by means of the interoperability platform to send the interoperability-based transaction request to a corresponding digital currency operator (see Kikinis ¶¶ [92 & 108]);
the digital currency operator receiving an operator transaction request, and determining a balance of a corresponding digital currency wallet and a deduction amount according to the operator transaction request (see Kikinis ¶¶ [75, 145, 154, 167 & 169]); and
the digital currency operator determining a type of the digital currency wallet, executing deduction of the digital currency wallet according to the type of the digital currency wallet, the balance of the digital currency wallet and the deduction amount, generating and returning deduction information (see Kikinis ¶¶ [75, 145, 154, 167 & 169]); and
the terminal receiving deduction information generated after the digital currency operator executes deduction on a basis of the interoperability-based transaction request, and outputting the deduction information (see Kikinis ¶¶ [75, 145, 154, 167 & 169]).
the digital currency operator receiving an operator transaction request, and determining the balance of the corresponding digital currency wallet and the deduction amount according to the operator transaction request (Kikinis ¶¶ [67, 70, 87, 106, 133, 154, 158 & 171]);
the digital currency operator identifying the type of the digital currency wallet (Kikinis ¶¶ [144, 154-155 & 158]);
It can be argued that Kikinis does not explicitly teach, however, Di further teaches:
the digital currency operator designating, by the digital currency operator, the personal wallet as the parent wallet of the digital currency wallet, and taking the digital currency wallet as the child wallet of the parent wallet in response to determining that the type of the digital currency wallet is a personal wallet type (Di ¶¶ [13, 52 & 61]);
wherein the digital currency wallet is a digital currency wallet that records the value of digital currency in a form of an account and does not establish an association relation between a user identity and the value of the digital currency in the account, uses a security chip as a storage medium, the feature negotiation information of the wallet is stored in the hardware carrier, and digital currency strings are stored in the backend system of a digital currency operator (Di ¶¶ [51, 54, 61, 73 & 81]).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system of Kikinis to incorporate the security chip-based storage and backend-managed digital currency processing of Di in order to improve transaction security, and enable centralized control over digital currency balances and deductions, which are well-known design considerations in digital currency and electronic payment systems. The combination represents the predictable use of prior elements according to their established functions.
As per claims 25 & 26, the claims recite analogous limitations as claim 7 above and interpreted under the same premise.
As per claim 8, the combination of Kikinis and Di teach the method as claimed in claim 7, Kikinis further teaches:
wherein the executing deduction of the digital currency wallet according to the type of the digital currency wallet, the balance of the digital currency wallet and the deduction amount comprises:
determining whether the deduction amount is greater than the balance of the digital currency wallet in response to determining that the type of the digital currency wallet is a type of a personal wallet, and invoking a personal wallet associated with the digital currency wallet to recharge the digital currency wallet and executing deduction corresponding to the deduction amount on a recharged digital currency wallet under a condition that the deduction amount is greater than the balance of the digital currency wallet (see Kikinis ¶¶ [67, 70, 87, 145, 154 & 169]); and
deducting the deduction amount from the balance of the digital currency wallet under a condition that the deduction amount is not greater than the balance of the digital currency wallet (see Kikinis ¶¶ [67, 70, 87, 145, 154 & 169]).
As per claim 27, the claim recites analogous limitations as claim 8 above and interpreted under the same premise.
As per claim 9, the combination of Kikinis and Di teach the method as claimed in claim 7, Kikinis further teaches:
wherein the generating deduction information comprises:
acquiring a sender identifier corresponding to the operator transaction request, and generating a transaction type identifier according to the sender identifier (see Kikinis ¶¶ [75, 79, 145, 154 & 167]);
determining a balance and a recharge amount of the digital currency wallet after deduction is executed (see Kikinis ¶¶ [75, 79, 145, 154 & 167]); and
generating and returning the deduction information according to the balance, the recharge amount, the deduction amount, the type of the digital currency wallet and the transaction type identifier (see Kikinis ¶¶ [75, 79, 145, 154 & 167]).
As per claim 28, the claim recites analogous limitations as claim 9 above and interpreted under the same premise.
As per claim 24, the combination of Kikinis and Di teach the method as claimed in claim 8, Kikinis further teaches:
wherein there is a parent-child ownership relation between the digital currency wallet and the personal wallet, wherein the personal wallet is a corresponding parent wallet, and the digital currency wallet is a child wallet (see Kikinis ¶¶ [67, 70 & 87]).
As per claim 29, the claim recites analogous limitations as claim 24 above and interpreted under the same premise.
Conclusion
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 TONY P KANAAN whose telephone number is (571)272-2481. The examiner can normally be reached Monday- Friday 7:30am - 3:30 pm 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, Matthew Gart can be reached at 5712723955. 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.
/T.P.K./Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
Prosecution Insights