DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
This action is in reply to the remarks/arguments filed for Application 18/484,127 filed on 30 March 2026.
Claims 3-4, 9-10, and 15-16 have been previously cancelled.
Claims 1, 7, and 13 have been amended.
Claims 1-2, 5-8, 11-14, and 17-18 are currently pending, and have been examined.
Response to Arguments
A. Claim Rejections - 35 USC § 101:
Claims 1-2, 5-8, 11-14, and 17-18 stand rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
1. Applicant argues that the claims, as amended, recite a specific distributed payment-execution architecture – e.g., retrieving information on each loan including a loan type from a plurality of financial institutions associated with the borrower; determining payment allocations based on loan type for each loan; providing payment allocations to a plurality of loan servicing platforms for the plurality of lenders; each loan servicing platform executing payment for a respective loan for a respective payment allocation; and receiving borrower feedback on the plurality of payment allocations for use in updating the model, that meaningfully limits any abstract idea.
Examiner respectfully disagrees. While the claims may represent application to a useful end (e.g., solution to a particular problem), there are only field-of-use steps and/or instruction in order to perform the abstract idea identified while not reciting concepts that meaningfully limits the abstract idea as follows:
Regarding the step comprising “retrieving information on each loan including a loan type from a plurality of financial institutions associated with the borrower”, the limitation merely recites that data/information is received pertaining to a plurality of obligations, including the type of obligation, to which payment is required. Moreover, the specification does not disclose any particular manner with how the data/information is being received, other than to indicate that it is received. Nor does the specification indicate how a payment allocation is being processed in a particular manner based on the type of loan or obligation other than to merely indicate that payment is made for each loan or transaction type in a broad and/or general manner.
Regarding the step comprising “determining payment allocations based on loan type for each loan”, the limitation merely disclose that a payment allocation is calculated, which may be performed manually, for each particular loan type which may comprise nothing more than a business rule and/or instruction.
Regarding the step comprising “providing payment allocations to a plurality of loan servicing platforms for the plurality of lenders”, the limitation merely indicates that the payment and instruction for how a payment is to be allocated for a plurality of loans is transmitted to the lender platform for subsequent processing.
Regarding the step comprising “each loan servicing platform executing payment for a respective loan for a respective payment allocation”, the limitation merely discloses that the loan servicing platforms belonging to each lender merely executes the payment allocation according to the instruction transmitted. None of the plurality of loan servicing platforms are affected (e.g., improved, transformed) in any manner by any of the steps recited.
Regarding the step comprising “receiving borrower feedback on the plurality of payment allocations for use in updating the model”, the limitation merely indicates that data/information associated with a previous particular payment allocation is collected and/or received and incorporated in subsequent or future payment allocations.
As such, the claims as a whole do not result in anything significantly more than the abstract idea itself. For example, the claims fail to positively recite improvements to another technology or technical field, improvements to the functioning of any of the computer-related devices itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technology environment. At best, the current claims attempt to improve only abstract idea itself. Applicant’s argument is therefore unpersuasive.
2. Applicant further argues that the claims, as amended, are not directed to a judicial exception under Step 2A because the exception is integrated into a practical application.
Examiner respectfully disagrees. The judicial exception is not integrated into a practical application because, when analyzed under step 2A prong two, the additional elements of the claim such as a “computer program”, “machine learning model”, “electronic device”, “database”, represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally apply the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e. automate) implement the acts of using rules and/or instructions to perform a commercial and/or economic practice in an automatic manner comprising the steps of merely receiving (“retrieving information on each of the loans”), calculating (“determining … a plurality of messages, … a payment allocation”), transmitting (“providing the payment allocation”), processing (“executing a loan payment”), and updating (“by a feedback … received”) data/information associated with a financial-related transaction.
Simply implementing the abstract idea on a computer for the purpose of “automating” is not a practical application of the abstract idea. Moreover, nothing in the steps involve an improvement to the conventional functioning of a computer or to any other technology, applying or using a judicial exception with, or, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing aside from merely using a computer as a tool to perform an abstract idea while also generally applying the use of the judicial exception to a particular technological environment or field of use. As such, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are therefore directed to an abstract idea. Applicant’s argument is therefore unpersuasive.
3. Applicant further argues the claims recite significantly more under Step 2B.
Examiner respectfully disagrees. When analyzed under step 2B, 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 claims merely describe the concept of using rules and/or instructions to perform a commercial/economic practice in an automatic manner comprising the steps of merely receiving (“retrieving information on each of the loans”), calculating (“determining … a plurality of messages, … a payment allocation”), transmitting (“providing the payment allocation”), processing (“executing a loan payment”), and updating (“by a feedback … received”) data/information associated with a financial-related transaction using computer-related technology and/or devices that merely perform as designed to function. 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)). Hence, the claims are not patent eligible. Applicant’s argument is therefore unpersuasive.
The rejection is therefore maintained.
B. Claim Rejections - 35 USC § 103:
Claims 1-2, 5-8, 11-14, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Cella, US 11,727,505 B2 (“Cella”), in view of Coles et al., US 2024/0420103 A1 (“Coles”), further in view of Kurani et al., US 12,086,784 B1 (“Kurani”).
The Office has given consideration to the remarks and amendments made to the pending set of claims, but are considered moot in light of the grounds of rejection, provided below, for the current listing of amended 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-2, 5-8, 11-14, and 17-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, representative method claim 1 is directed towards allocating automatic payments associated with a financial transaction. Claim 1 recites the abstract idea of using rules and/or instructions to perform a commercial/economic practice in an automatic manner comprising the steps of merely receiving (“retrieving information on each of the loans”), calculating (“determining … a plurality of messages, … a payment allocation”), transmitting (“providing the payment allocation”), processing (“executing a loan payment”), and updating (“by a feedback … received”) data/information associated with a financial-related transaction, which is grouped under the certain methods of organizing human activity – fundamental economic principles, practices or concepts; sales activity; following set of instructions; commercial interactions (business relations); managing personal behavior of relationships or interactions between people (including social activities, teachings, following rules or instructions) grouping, in step 2A prong one.
Claim 1 recites: “receiving, by a computer program and from a borrower, a bulk payment for a plurality of loans that are with a plurality of lenders;
retrieving, by the computer program, information on each of the loans from a plurality of financial institutions associated with the borrower, wherein the information comprises a payment amount due for the loan and a loan type;
determining, by the computer program and using a machine learning model that is trained with prior payments to the loans by the borrower, a plurality of messages including one or more of an email, a test, a phone communication from the borrower, a report, and a plurality of payment allocations of the bulk payment for each of the loans based on the loan type for each of the loans;
providing, by the computer program, the plurality of payment allocations to a plurality of loan servicing platforms for the plurality of lenders, wherein each of the plurality of loan servicing platforms for each of the loans executes a payment to a respective one of the loans for a respective payment allocation of the plurality of payment allocations; and
updating, by the computer program and from the borrower, the machine learning model by a feedback on the plurality of payment allocations received from the borrower.”
Based on the underlined elements above, abstract ideas and/or concepts are identified. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because, when analyzed under step 2A prong two, the additional elements of the claim such as a “computer program”, “machine learning model”, “electronic device”, “database”, represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally apply the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e. automate) implement the acts of using rules and/or instructions to perform a commercial/economic practice in an automatic manner comprising the steps of merely receiving (“retrieving information on each of the loans”), calculating (“determining … a plurality of messages, … a payment allocation”), transmitting (“providing the payment allocation”), processing (“executing a loan payment”), and updating (“by a feedback … received”) data/information associated with a financial-related transaction.
When analyzed under step 2B, 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 claims merely describe the concept of using rules and/or instructions to perform a commercial/economic practice in an automatic manner comprising the steps of merely receiving (“retrieving information on each of the loans”), calculating (“determining … a plurality of messages, … a payment allocation”), transmitting (“providing the payment allocation”), processing (“executing a loan payment”), and updating (“by a feedback … received”) data/information associated with a financial-related transaction using computer-related technology and/or devices that merely perform as designed to function. 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)). Hence, claim 1 is not patent eligible.
Independent claim 7 recites substantially the same limitations as claim 1 above and are ineligible for the same reasons. The subject matter of claim 7 corresponds to the subject matter of claim 1 in terms of a system (e.g., machine). Therefore the reasoning provided for claim 7 applies to claim 1 accordingly.
Independent claim 13 recites substantially the same limitations as claim 1 above and are ineligible for the same reasons. The subject matter of claim 13 corresponds to the subject matter of claim 1 in terms of a computer readable storage medium (e.g., manufacture). Therefore the reasoning provided for claim 13 applies to claim 1 accordingly.
Dependent claims 2, 5-6, 8, 11-12, 14, and 17-18 add further details and contain limitations that narrow the scope of the invention. However, these details do not result in significantly more than the abstract idea itself. As explained in the December 16, 2014 Interim Eligibility Guidance from the USPTO (in reference to the BuySAFE, Inc. v. Google, Inc. decision), further narrowing the details of an abstract idea does not change the § 101 analysis since a more narrow abstract idea does not make it any less abstract.
Viewed individually and in combination, these additional elements do not provide meaningful limitations to transform the abstract idea such that the claims amount to significantly more than the abstraction itself.
Accordingly, the present pending claims are not patent eligible and are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections – 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office Action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5-8, 11-14, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Drucker et al., US 2020/0320493 A1 (“Drucker”), in view of Rogers et al., US 2019/0362583 A1 (“Rogers”), further in view of Kurani et al., US 12,086,784 B1.
Re Claim 1: (Currently Amended) Drucker discloses a method for executing smart payments, comprising:
receiving, by a computer program and from a borrower, a bulk payment for a plurality of loans that are with a plurality of lenders;
([0004] “… method includes: identifying, by the one or more processors, funds to be allocated; determining, by the one or more processors, a plurality of pending accounts for a respective plurality of payees; determining, by the one or more processors, an allocation for the funds amongst the plurality of pending accounts”; [0013] “… systems, methods, and apparatuses can be used to determine an improved or optimized allocation of funds for managing accounts … may include pending payments due to payee to other debtors … systems, methods, and apparatuses described herein can be used to allocate funds based on such priorities. The allocation of funds may also take into account … opportunities to make a payment to reduce or eliminate a recurring expense (e.g. pay down an interest-bearing loan)”).
Regarding the limitation comprising:
retrieving, by the computer program, information on each of the loans from a plurality of financial institutions associated with the borrower, wherein the information comprises a payment amount due for the loan and a loan type;
Rogers makes this teaching in a related endeavor ([0008] “… a method is provided for processing a transaction between a first party and a second party. Information defining terms of the transaction and identifying a presentation instrument are received at a host system. Preference information associated with the presentation instrument as retrieved with the host system. The preference information specifies terms for an allocation of transaction amounts among a plurality of transaction types. An amount for the transaction is allocated among the plurality of transaction types in accordance with terms of the transaction and the terms for the allocation”; [0010] “… in one embodiment, such terms specify one or more transaction types based on an identification of the second party. In another embodiment, such terms specify one or more particular transaction types based on an identification of a type of product included in the transaction. In a further embodiment, such terms specify one or more particular transaction types based on the amount for the transaction.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Rogers with the invention of Drucker as described above for the motivation of ensuring that payment for a particular transaction type is allocated according to terms for the transaction.
Regarding the limitation comprising:
determining, by the computer program and using a machine learning model that is trained with prior payments to the loans by the borrower, a plurality of messages including one or more of an email, a test, a phone communication from the borrower, and a report,
Kurani makes this teaching in a related endeavor (FIG. 38: “Training Inputs 3802”, “Machine Learning Model 3804”; C24 L57-67; C25 L1-13: “The machine learning model 704 may be trained based on general data and/or granular data (e.g., data based on a specific user 132) such that the machine learning model 704 may be trained specific to a particular user 132. Training inputs 702 and actual outputs 710 may be provided to the machine learning model 704. Training inputs 702 may include accounts receivable data, accounts payable data, account balance data, liquid asset data, illiquid asset data, 401k data, IRA data, and the like. Actual outputs 710 may include recommendations (e.g., investment opportunities, collateral backing opportunities, refinance opportunities, and the like) …”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kurani with the invention of Drucker as described above for the motivation of automating operations associated with a financial transaction in an efficient manner.
Regarding the limitation comprising:
[determining, by the computer program and using a machine learning model that is trained with prior payments to the loans by the borrower] …. a plurality of payment allocations of the bulk payment for each of the loans based on the loan type for each of the loans;
Rogers makes this teaching in a related endeavor ( [0010] “… in one embodiment, such terms specify one or more transaction types based on an identification of the second party. In another embodiment, such terms specify one or more particular transaction types based on an identification
of a type of product included in the transaction. In a further embodiment, such terms specify one or more particular transaction types based on the amount for the transaction.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Rogers with the invention of Drucker as described above for the motivation of ensuring that payment for a particular transaction type is allocated according to terms for the transaction.
Drucker further discloses:
providing, by the computer program, the plurality of payment allocations to a plurality of loan servicing platforms for the plurality of lenders, wherein each of the plurality of loan servicing platforms for each of the loans executes a payment to a respective one of the loans for a respective payment allocation of the plurality of payment allocations; and
([0005] “… cause the processor to: identify funds to be allocated; determine an allocation for the funds amongst a plurality of allocation options comprising (i) a pending account a payee, and (ii) a projected account, based on a priority for the pending account for the payee and a priority for the projected account; and implement the allocation for the funds”; [0016] “… the financial computing system 102 includes a computing system of a financial institution ( e.g. of a bank, a credit provider, or another financial service provider). The financial computing system 102 may route funds between two or more financial accounts, and/or may route charges or invoices to appropriate parties. For example, the financial computing system 102
may debit a first financial account and may credit, or cause another system to credit, a second financial account. The financial accounts may include checking accounts, credit accounts, savings accounts, or any other type of financial account. The financial computing system 102 may perform financial transactions requested by the account management system 104, including routing of funds according to an allocation of funds determined by the account management system 104.”)
Regarding the limitation comprising:
updating, by the computer program and from the borrower, the machine learning model by a feedback on the plurality of payment allocations received from the borrower.
Kurani makes this teaching in a related endeavor (C21 L64-67, C22 L1-11: “… SFE 606 may be configured to receive enterprise resources 128 data, including data from CRM applications 129 and data from ERP applications 130. Data received by the SFE 606 may include, for example, accounts receivable data, accounts payable data, account balance data (derived from one or more enterprises) … user 132 feedback …”; C97 L48-60: “In some embodiments, the SFE 606 may update the payment type settings for the ERP application 130 by transmitting an API call to the ERP application 130 to trigger updating of the payment type setting associated with the recipient identifier … The administrator associated with the account holder may update the payment setting (e.g., manually) responsive to receiving the notification.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kurani with the invention of Drucker as described above for the motivation of automating operations associated with a financial transaction in an efficient manner.
Re Claim 2: (Original) Drucker in view of Rogers in view of Kurani discloses the method of claim 1. Drucker further discloses:
wherein the plurality of loans are with a plurality of lenders.
([0013] “… systems, methods, and apparatuses can be used to determine an improved or optimized allocation of funds for managing accounts … may include pending payments due to payee to other debtors … systems, methods, and apparatuses described herein can be used to allocate funds based on such priorities. The allocation of funds may also take into account … opportunities to make a payment to reduce or eliminate a recurring expense (e.g. pay down an interest-bearing loan)”).
Re Claim 3: (Cancelled).
Re Claim 4: (Cancelled).
Re Claim 5: (Original) Drucker in view of Rogers in view of Kurani in view of Rogers discloses the method of claim 1. Drucker further discloses:
determining, by the computer program, that manual review of the payment allocation is required;
receiving, by the computer program, manual allocations of the bulk payment for each of the loans;
assigning, by the computer program, the manual allocations as the payment allocations.
([0005] “… cause the processor to: identify funds to be allocated; determine an allocation for the funds amongst a plurality of allocation options comprising (i) a pending account a payee, and (ii) a projected account, based on a priority for the pending account for the payee and a priority for the projected account; and implement the allocation for the funds”)
Re Claim 6: (Original) Drucker in view of Rogers in view of Kurani in view of Rogers discloses the method of claim 5. With regard to the limitation comprising:
training, by the computer program, the machine learning model with the manual allocations.
Kurani makes this teaching in a related endeavor (FIG. 38: “Training Inputs 3802”, “Machine Learning Model 3804”; C24 L57-67; C25 L1-13: “The machine learning model 704 may be trained based on general data and/or granular data (e.g., data based on a specific user 132) such that the machine learning model 704 may be trained specific to a particular user 132. Training inputs 702 and actual outputs 710 may be provided to the machine learning model 704. Training inputs 702 may include accounts receivable data, accounts payable data, account balance data, liquid asset data, illiquid asset data, 401k data, IRA data, and the like. Actual outputs 710 may include recommendations (e.g., investment opportunities, collateral backing opportunities, refinance opportunities, and the like) …”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kurani with the invention of Drucker as described above for the motivation of automating operations associated with a financial transaction in an efficient manner.
Re Claim 7: (Currently Amended) Claim 7, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 1. Accordingly, claim 7 is rejected in the same or substantially the same manner as claim 1.
Re Claim 8: (Original) Claim 8, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 2. Accordingly, claim 8 is rejected in the same or substantially the same manner as claim 2.
Re Claim 9: (Cancelled)
Re Claim 10: (Cancelled)
Re Claim 11: (Original) Claim 11, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 5. Accordingly, claim 11 is rejected in the same or substantially the same manner as claim 5.
Re Claim 12: (Original) Claim 12, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 6. Accordingly, claim 12 is rejected in the same or substantially the same manner as claim 6.
Re Claim 13: (Currently Amended) Claim 13, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 1. Accordingly, claim 13 is rejected in the same or substantially the same manner as claim 1.
Re Claim 14: (Original) Claim 14, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 2. Accordingly, claim 14 is rejected in the same or substantially the same manner as claim 2.
Re Claim 15: (Cancelled)
Re Claim 16: (Cancelled)
Re Claim 17: (Original) Claim 17, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 5. Accordingly, claim 17 is rejected in the same or substantially the same manner as claim 5.
Re Claim 18: (Original) Claim 18, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 6. Accordingly, claim 18 is rejected in the same or substantially the same manner as claim 6.
Conclusion
The prior art(s) made of record and not relied upon is/are considered pertinent to applicant's disclosure.
Blair et al. (US 8,150,763 B2) discloses systems and methods for staging transactions, payments and collections. The present invention relates to systems and methods for staging transactions and facilitating payments by consumers to a lender or merchant to consummate a financial transaction
and/or to maintain a financial relationship. In one embodiment, a method for accepting payments from a consumer includes receiving a promise-to-pay record from a lender (210), receiving a payment from the consumer (220), associating the payment with the promise-to-pay record (230), and sending a notice to the lender (240), with the notice having an indicator that the payment has been received.
Karamchedu et al. (US 2015/0324790 A1) discloses messaging-based payments. Embodiments for messaging-based payments are described. A messaging-based payment system (MBP) may be configured to facilitate payments between parties based via a messaging protocol, such as a text messaging protocol. The MBP may be configured to receive a request via the messaging protocol for a payment to be made from a first party to a second party. The request may include a payment amount as well as identifying information for the party making payment. In response to receipt of the request, the MBP may request an authorization of the payment from the first party. The request for authorization may be performed via the messaging protocol. After receiving authorization for the payment, the MBP may facilitate the requested payment from the first party to the second party. Payment may be made to an account of the second party or through a payment facilitator. Other embodiments may be described and claimed.
Claims 1-2, 5-8, 11-14, and 17-18 are rejected.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Clifford Madamba whose telephone number is 571-270-1239. The examiner can normally be reached on Mon-Thu 7:30-5:00 EST Alternate Fridays.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon, can be reached at 571-272-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CLIFFORD B MADAMBA/Primary Examiner, Art Unit 3692
Prosecution Insights