DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. 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
2. Applicant filed the amendment on 03/23/2026. Claims 1-20 are pending. Claims 1, 3-4, 6-7, 9, 11-12, and 14-20 are amended.
Claim Rejections - 35 USC §101
3. 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.
4. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
5. In the instant case, claims 1, 9, and 15 are directed to a “system, method and at least one non-transitory computer-readable storage for executing cross-network operations”.
6. Claim 9 recites “processing a payment transaction message”. Specifically, the claim recites “receiving a payment transaction message including one or more identifiers initiated between a merchant and a customer for at least one of a good or service; querying … based on the one or more identifiers contained in the payment transaction message, the query retrieves a registration record, wherein the registration record includes an identification … wherein … and an enrichment operation that is different than the at least one good or service; generating an operation request message based on … and enrichment operation; transmitting at least a portion of the operation request message …; in response to the transmitting, receiving an operation result message … including an output result of the enrichment operation being applied to the payment transaction message; and transmitting … a response message indicating the output result of the enrichment operation being applied to the payment transaction message”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
7. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 9 such as “an instream transaction services computer system”, “an in-network system for processing instream transaction”, “a memory”, “at least one processor”, “a plurality of services platforms”, “a registration database”, “at least one of a marketplace provider”, “the at least one marketplace provider include computing devices hosted on a separate off-network system”, and “a requestor computer system” do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use. Therefore, as they do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, they do not improve computer functionality nor improve another technology or technical field. With respect to “receiving a payment transaction message including one or more identifiers initiated between a merchant and a customer for at least one of a good or service”, “transmitting at least a portion of the operation request message to the identified marketplace provider”, “receiving an operation result message from the identified marketplace provider including an output result of the enrichment operation being applied to the payment transaction message”, and “transmitting, to a requestor computer system, a response message indicating the output result of the enrichment operation being applied to the payment transaction message”, is simply transmitting data; “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
8. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of processing a payment transaction message using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
9. Hence, claim 9 is not patent eligible.
10. Claims 1 and 15 also recite “processing a payment transaction message”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
11. As in the case of claim 9, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claims 1 and 15 such as “an instream transaction services computer system”, “an in-network system for processing instream transaction”, “a memory”, “at least one processor”, “a marketplace registration database”, “at least one of a marketplace provider”, “the at least one marketplace provider include computing devices hosted on a separate off-network system”, “a requestor computer system”, “at least one non-transitory computer-readable storage medium”, and “at least one processor of a marketplace operation computer associated with an in-network system for processing instream transaction” do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use. Therefore, as they do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, they do not improve computer functionality nor improve another technology or technical field. With respect to “receive a payment transaction message including one or more identifiers initiated between a merchant and a customer for at least one of a good or service”, “transmit at least a portion of the operation request message to the identified marketplace provider”, “receive an operation result message from the identified marketplace provider including an output result of the enrichment operation being applied to the payment transaction message”, and “transmit, to a requestor computer system, a response message indicating the output result of the enrichment operation being applied to the payment transaction message”, is simply transmitting data; “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
12. When analyzed under step 2B (MPEP 2106.04 II), the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of processing a payment transaction message using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
13. Hence, claims 1 and 15 are not patent eligible.
14. The following dependent claims recent additional elements not addressed above:
claims 2, 10, and 16 recite “a gateway” and “an application programming interface (API)”;
claims 3, 11, and 17 recite “an in-network party associated with a processing network”; and
claims 5, 13, and 19 recite “a computing device”.
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the gateway, the application programming interface, the in-network party associated with the processing network, and the computing device.
Dependent claims 2-8, 10-14, and 16-20 merely expand upon the abstract ideas of the independent claims 1, 9, and 15, and are therefore rejected under the same rationale as claims1, 9, and 15.
Conclusion of 35 USC §101
15. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
16. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
17. 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 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.
18. 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.
19. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
20. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US20170221066A1 to Ledford et al. in view of US20160379191A1 to Nielson et al.
21. As per claim 1:
Ledford et al. discloses the following limitations:
An instream transaction services computer system associated with an in-network system for processing instream transaction, the computer system comprising a memory and at least one processor in communication with the memory, the memory storing instructions executable to cause the at least one processor to: ([0030], [0114], [0121] discloses an in-network transaction services computer system comprising a memory and processor executing program instructions, that processes transactions inline (routing them between Fis and to a value added service system))
receive a payment transaction message including one or more identifiers initiated between a merchant and a customer for at least one of a good or service ([0125], [0285], [0076] discloses the network receiving an electronic payment transaction message carrying multiple identifiers (UT-ID, account numbers, routing numbers, consumer name, biller remittance identifier) for a payment between a consumer (customer) and a biller/creditor (merchant) for goods/services such as bill payment or e-commerce)
query a marketplace registration database based on the one or more identifiers contained in the payment transaction message ([0126] discloses the network querying a database/directory based on identifiers carried in the payment transaction message), …, wherein the registration record includes an identification of at least one of a marketplace provider ([0116]-[0117] discloses identifying value added service system and third party elements as providers), wherein the at least one marketplace provider include computing devices hosted on a separate off-network system ([0117]-[0118] discloses that the value-added service system and third party elements are separate from the in-network system and include their own computers and servers) and an enrichment operation that is different than the at least one good or service ([0114], [0116] discloses enrichment operations (directory services, fraud management, token services, analysis, reporting) that are different from the payment’s underlying good or service)
generate an operation request message based on the identified at least one marketplace provider and the enrichment operation ([0125], [0114], [0128], [0116] discloses generating a payment transaction message that together with the network’s routing to a value-added service system, serves as the operation request to the off-network provider, routing the message to the value-added service system, message generation that supports specific enrichment operations)
transmit at least a portion of the operation request message to the identified marketplace provider ([0114], [0116], [0148], [0178] discloses transmitting/routing at least a portion of the message (e.g., the remittance advice) from the in-network system to the value-added service system that identified through routing logic, for processing)
in response to the transmission, receive an operation result message from the identified marketplace provider including an output result of the enrichment operation being applied to the payment transaction message ([0134]-[0135] discloses that the value-added services returns the result of its enrichment (e.g., detokenization that maps a token to real account/routing data) back to network, where the resulting fields are inserted into the payment transaction message)
transmit, to a requestor computer system, a response message indicating the output result of the enrichment operation being applied to the payment transaction message ([0133], [0135] discloses the network forwarding/transmitting the resulting payment transaction message (now containing the enriched/translated routing and account data) to the creditor FI and sending status/notification messages back to the originating FI (the requestor).
Ledford et al. does not disclose, however, Nielson et al., as shown, teaches the following limitations:
[query] … the query retrieves a registration record ([0026], [0032] discloses that registration records (buyer and merchant) are stored in data warehouse and retrieved during the query)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing a payment service wherein a transaction processor configured to process a transaction request of Nielson et al. (‘191, [0012]) with teaching of Ledford et al. for forwarding the electronic payment transaction message to the at least one creditor financial institution such that the amount of payment is credited to a position of the at least one creditor financial institution in real-time (‘066, [0019]) for storing in a database, the merchant registration data is stored in data warehouse, which is a secure database inaccessible from the transaction processor (‘191, [0026], [0032]).
Claims 9 and 15 are rejected using the same rationale that was used for the rejection of claim 1.
22. As per claim 2:
Ledford et al. discloses the following limitations:
The instream transaction services computer system according to Claim 1, wherein the operation request message includes computer instructions executable to cause said at least one processor to ([0114] discloses describing the in-network core processing system executing instructions to route/process the operation request to a value-added service system)
transmit the operation request message via a gateway for an application programming interface (API), the API defining a plurality of parameters corresponding to a plurality of data fields of a communications standard for exchange of financial transaction data between financial institutions ([0117], [0183], [0199] discloses messages transmitted via gateway/application interface that comply with FI-to-FI communications standards (ISO 20022, ISO 8583) and define a plurality of data fields)
Claims 10 and 16 are rejected using the same rationale that was used for the rejection of claim 2.
23. As per claim 3:
Ledford et al. discloses the following limitations:
The instream transaction services computer system according to Claim 1, wherein the requestor is an in-network party associated with a processing network where the payment transaction message was initiated, the in-network party including at least one of a cardholder who initiates the payment transaction … ([0108], [0109], [0124], [0150] discloses identification of Fis (debtor FI, creditor FI), debtor station, and creditor station as the in-network parties that initiate / are associated with the payment transaction message and a consumer/debtor initiating the payment by sending an authorization / payment transaction message)
Ledford et al. does not disclose, however, Nielson et al., as shown, teaches the following limitations:
a merchant at which the payment transaction was initiated, an issuer associated with the cardholder, and an acquirer associated with the merchant ([0029], [0031], [0032], [0035], [0037], [0045], discloses identification the merchant as the in-network party at which the transaction is initiated and submitted, a credit card issuer / bank associated with the buyer, and merchant acquirers as in-network parties)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing a payment service wherein a transaction processor configured to process a transaction request of Nielson et al. (‘191, [0012]) with teaching of Ledford et al. for forwarding the electronic payment transaction message to the at least one creditor financial institution such that the amount of payment is credited to a position of the at least one creditor financial institution in real-time (‘066, [0019]) for transmitting an authorization request to the transaction processor, performing the authorization process with the transaction processor in order to determine an amount of money the buyer is authorized to spend, and submitting the transaction by the third party associated with the merchant (‘191, [0032], [0037], [0045]).
Claims 11 and 17 are rejected using the same rationale that was used for the rejection of claim 3.
24. As per claim 4:
Ledford et al. discloses the following limitations:
The instream transaction services computer system according to Claim 1, wherein marketplace providers do not include an issuer, a merchant, and an acquirer ([0116], [0117] discloses identification value-added services system and third party elements as service providers separate from the debtor FI and creditor FI)
and wherein the marketplace providers include computing devices hosted on a separate off-network system ([0117], [0118] discloses description value-added services and third party elements that are separate from the in-network system)
Claims 12 and 18 are rejected using the same rationale that was used for the rejection of claim 4.
25. As per claim 5:
Ledford et al. discloses the following limitations:
The instream transaction services computer system according to Claim 1, wherein the operation request message includes instructions executable to cause said at least one processor to ([0114] discloses that the processor executing instructions to route messages to the value-added service system for further processing)
generate the operation request message based on the identified at least one marketplace provider and enrichment operation ([0114], [0125] discloses generation of a payment transaction message that is then routed to a value-added service system), wherein the operation request message is formatted according to a communications standard for exchange of financial transaction data between financial institutions ([0125], [0199] discloses names FI-to-FI financial-messaging standards (ISO 20022, ISO 8583) and uses message types (pacs.008, pain.013 pacs.002) compliant with those standards), the communications standard defining a plurality of data fields to be included within messages compliant with the communications standard ([0125], [0199] discloses a plurality of standardized data fields (UT-ID, creditor name, account number, routing number, payment amount, biller remittance ID, etc.) carried in standard format messages), and wherein the operation request message is configured to cause a computing device associated with the marketplace provider to execute the enrichment operation on the transaction data ([0116], [0148], [0178] discloses the routed message causing the value-added service system (the marketplace provider’s computing device) to perform enrichment operations (tokenization, detokenization, fraud management) on the transaction data)
Claims 13 and 19 are rejected using the same rationale that was used for the rejection of claim 5.
26. As per claim 6:
Ledford et al. discloses the following limitations:
The instream transaction services computer system according to Claim 1, wherein the processor is further configured to ([0030] discloses a processor configured to perform the described functions)
receive an initiating operation request message from the requestor computer system ([0144], [0150] discloses the network and Fis receiving an initiating request for payment / payment authorization message from the requestor (creditor station, debtor station, or FI))
translate the initiating operation request message to generate the operation request message ([0150], [0148], [0134] discloses translating an initiating request for payment message (pain.013) into a payment transaction message (pacs.008), as well as token / BANPC translations between message formats)
Claims 14 and 20 are rejected using the same rationale that was used for the rejection of claim 6.
27. As per claim 7:
Ledford et al. discloses the following limitations:
The instream transaction services computer system according to Claim 1, wherein the processor is further configured to ([0030] discloses a processor configured to perform the described functions)
generate one or more marketplace registration records registering requestors for at least one of an enrichment operation and marketplace provider, wherein the marketplace registration record includes one or more identifiers including at least one of an account identifier, a requestor identifier, or a marketplace identifier ([0115], [0128], [0134] discloses participant onboarding/registration and a BANPC and its database that stores identifier to FI account/routing associations)
build the marketplace registration database by storing one or more generated marketplace registration records ([0128], [0134] discloses building / maintaining a database (BANPC database / directory) populated with the registration / token records)
28. As per claim 8:
Ledford et al. discloses the following limitations:
The instream transaction services computer system according to Claim 1, wherein the enrichment operation comprises services from among an insurance service, a tax calculation service, a cross-border service, a data enrichment service, a transaction notification service, a digital receipts service, a loyalty service, a virtual card mapping service, a digital payment credential provisioning service, a fraud evaluation service, a virtual card mapping service, a digital payment credential provisioning service, and a fraud evaluation service ([0076], [0116], [0128], [0250], [0318] discloses fraud management (fraud evaluation service) and tokenization (analogous to a virtual card mapping / digital payment credential provisioning service), as well as value-added directory service and reporting)
Response to Arguments
29. After careful consideration of applicant arguments, the examiner finds them to be not persuasive. Claims 1-20 are rejected.
Rejections under 35 U.S.C. § 112
30. Claims 1-20 rejections under 112(b) are withdrawn due to amendments to claims 1, 3, 6-7, 9-11, and 15-17.
Rejections under 35 U.S.C. § 102
31. Applicant arguments toward claims 1-3, 6-11, 14-17, and 20 rejections are persuasive, claims 1-3, 6-11, 14-17, and 20 rejections are withdrawn.
Rejections under 35 U.S.C. § 103
32. Applicant arguments are no longer applicable because they are moot in light of the new ground of rejection.
Rejection under 35 USC § 101
33. Applicant’s arguments toward 35 U.S.C. § 101 rejection is not persuasive. Amended independent claims do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
34. Applicant is of the opinion that “[e]nabling off-network enrichment operations is a technical operation and a technical improvement that improves the ability to communicate between in-network parties and off- network parties described in the specification. This in turn improves the ability to apply an enrichment operation provided by an off-network party to a transaction request message originating between in-network parties. Claim 1 includes additional technical operations such as ‘generate an operation request message based on the identified at least one marketplace provider and the enrichment operation’ that further establish that the claims are not directed to any abstract idea.”
Examiner respectfully disagrees.
Claims as a whole directed to processing a payment transaction message which is grouped under “Certain methods of organizing human activity” is similar to commercial interactions. As per Applicant’s Specification (para 18) “Described in detail herein are example embodiments of systems and methods for applying off-network marketplace operations to a home payment network payment transaction”.
35. Applicant is of the opinion that “the following recitations…: receive a payment transaction message including one or more identifiers initiated between a merchant and a customer for at least one of a good or service;
query a marketplace registration database based on the one or more identifiers contained in the payment transaction message, the query retrieves a registration record, wherein the registration record includes an identification of at least one of a marketplace provider, wherein the at least one marketplace provider include computing devices hosted on a separate off-network system and an enrichment operation that is different than the at least one good or service;… represent both a practical application of any alleged abstract idea, and an inventive concept with recitations that amount to ‘significantly more’ and are non-conventional, non-routine, and not well-understood, thereby rendering the claims eligible under Section 101.”
Examiner respectfully disagrees.
Mentioned above the claim features performed by using the computer components. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)).
Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to the abstract idea.
36. Applicant is of the opinion that “the above-listed recitations of the pending claims represent unconventional technical operations performed between in-network computer systems and off-network computer(s) that are not routine and not well understood, and amount to more than merely using generic computing components. For example, conventional techniques are unable to apply enrichment operations by off-network parties during payment transaction processing. By way of querying a market database using identifiers contained in a payment transaction message, for example, enables communication with off-network parties. These aspects, reflected in the claims, are non-conventional, not well-understood, and not routine, and amount to significantly more than any abstract idea alone.”
Examiner respectfully disagrees.
The rejection was not based on routine or conventional elements. To the contrary, the claim is directed to the abstract idea of processing a payment transaction message (e.g., (claim 1) “transmit … a response message indicating the output result of the enrichment operation being applied to the payment transaction message”; (Specification, para 17) “…the embodiments of the systems and methods described herein relate generally to payment transactions that are initiated over a home payment network…”) and does not improve functioning of a computer or computer technology.
The claims are not patent eligible.
Conclusion
37. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20140258032A1 – Psota et al. – Discloses methods for facilitating buyers, sellers, and third parties in obtaining information related to each other's transaction histories, such as a supplier's shipment history, the types of materials typically shipped, a supplier's customers, a supplier's expertise, what materials and how much a buyer purchases, buyer and shipper reliability, similarity between buyers, similarity between suppliers, and the like.
US20190147450A1 – Bharghavan et al. – Discloses a method of real-time ISO transactions is enriched with normalized merchant data, including a normalized merchant name, a normalized merchant location, by transmitting the raw merchant data to an external resource and receiving the normalized raw merchant data from the external resource.
US20120284187A1 – Hammad et al. – Discloses a method and system for processing payment transactions that are conducted using a payment account or portable consumer device, wherein the portable consumer device may be in any suitable form, including cards, key fobs, devices containing a contactless element, smart cards (having contacts or without contacts), etc.
US8645270B2 – Mallean et al.– Discloses a method, a server, and a computer use an enhanced customer interaction channel based on a predetermined payment key associated with a specific company and location wherein the predetermined payment key uniquely identifies the specific company and location and enables the enhanced customer interaction channel based on existing payment processing systems.
38. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
39. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/DAVID P SHARVIN/Primary Examiner, Art Unit 3692
Prosecution Insights