Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 2 September 2025 with respect to the 101 rejection have been fully considered but they are not persuasive. Application argues step 2B was not completed, but the Examiner disagrees because the analysis is shown on pages 3-4 that the additional elements do not recite significantly more than the abstract idea because the computer technology is used as a tool to automate/implement the abstract idea. Applicant argues the claims are directed to a technological solution that reduces computer processing resources. The Examiner disagrees that the current claims improve computer functionality beyond the abstract idea of conducting a transaction from the examples in MPEP 2106.05(a) of potential improvement in computer-functionality and appear to be the digital equivalent of affixing a barcode to a mail object in order to more reliably identify the sender and speed up mail processing or in this instance transaction processing. The generation of the real time identifier and what the real time identifier contains is not present in the claims and would not be obvious to one having ordinary skill in the art.
Applicant's arguments filed 2 September 2025 with respect to the 102 rejection have been fully considered but new grounds of rejection have been presented below. Applicant argues the claim amendments are not disclosed by the reference. The Examiner has updated the rejection below to address the claim amendments. Applicant argues Realini does not disclose limitations of the claims on page 14. The Examiner has provided additional clarification of the reference below in the updated grounds of rejection. Applicant argues the duplication of parts is not applicable in this instance because the steps involve a second transaction identifier request occurring at a different time. The Examiner disagrees because a second transaction identifier request at a different time that functions in the same manner as the previous steps and differ only in language such as “first” and “second” merchant or transaction request, which clearly indicates duplication of process since nothing different is occurring except an additional request is received from an additional party.
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-21 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, claim 1 is directed to a “method”. Claim 1 is directed to the abstract idea of “conducting a payment transaction” which is grouped under “organizing human activity… fundamental economic practice (conducting a purchase transaction involves mitigating risk and transactions are a building block of economic activity), managing personal behavior (following rules or instructions is similar to following rules or instructions to conduct a transaction), and commercial or legal interactions (conducting a transaction is a commercial interaction such as sales activity or behavior and business relations)” in prong one of step 2A (See 2019 Revised Patent Subject Matter Eligibility Guidance). Claim 1 recites receiving a real-time payment identifier request, the real-time payment identifier request comprising at least one of a phone number associated with the user device and an account identifier; communicating the real-time payment identifier request to a real-time payment platform located remotely from the user device; generating the real-time identifier, receiving a real-time payment identifier generated by the real-time payment platform based on the real-time payment identifier request; storing the real-time payment identifier; receiving a first transaction identifier request associated with at least one of the phone number and a user account identifier; receiving the real time payment identifier, retrieving a payment account identifier, communicating a transaction request, communicating the real-time payment identifier to the first merchant system in response to receiving the first transaction identifier request; receiving a second transaction identifier request associated with at least one of the phone number and the account identifier; and communicating the real-time payment identifier to the second merchant system in response to receiving the second transaction identifier request. Accordingly, the claim recites an abstract idea (See 2019 Revised Patent Subject Matter Eligibility Guidance). This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (See 2019 Revised Patent Subject Matter Eligibility Guidance), the additional elements of the claim such as a real-time payment application, a processor, a first merchant system, a second merchant system, a real-time payment identifier database, a real-time payment platform, and a user device represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use (MPEP 2106.05(f)&(h)). 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. implement) the acts of conducting a payment transaction.
When analyzed under step 2B (See 2019 Revised Patent Subject Matter Eligibility Guidance), 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 conducting a payment transaction using computer technology (e.g. a real-time payment application). 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)).
Dependent claims 2-7, 9-14, and 16-21 do not remedy the deficiencies of the independent claims and are rejected accordingly. The dependent claims further refine the abstract idea of the claims and do not integrate the abstract idea into a practical application. In this case, all claims have been reviewed and are found to be substantially similar and linked to the same abstract idea (see Content Extraction and Transmission LLC v. Wells Fargo (Fed. Cir. 2014)).
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.
Claim(s) 1-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Realini US 2009/0119190 in view of Singh US 2020/0327543.
As per claim 1:
Realini discloses a method comprising: receiving, by a real-time payment application stored on a user device (¶ [0019], Fig 38, [0458]), a real-time payment identifier request, the real-time payment identifier request comprising at least one of a phone number associated with the user device and an account identifier (¶ [0031], [0038]);
communicating, by the real-time payment application, the real-time payment identifier request to a real-time payment platform located remotely from the user device (¶ [0032]);
receiving, by the real-time payment application, the real-time payment identifier generated by the real-time payment platform based on the real-time payment identifier request (¶ [0038] “sequence number”, see also Singh for Transaction identifier below);
in response to receiving the real-time payment identifier, storing, by the real-time payment application, the real-time payment identifier in a real-time payment identifier database, wherein the real-time payment identifier database is stored on the user device (¶ [0139]);
receiving, by the real-time payment application, a first transaction identifier request associated with at least one of the phone number and the user account identifier from a first merchant system (¶ [0395], [0027]);
communicating, by the real-time payment application, the real-time payment identifier to the first merchant system in response to receiving the first transaction identifier request (¶ [0427], Fig 35);
receiving, by the real-time payment application, a second transaction identifier request associated with at least one of the phone number and the account identifier from a second merchant system (¶ [0521], [0395], MPEP 2144(VI)(B) Duplication of Parts, see also [0219], ¶ [0427], Fig 35); and
communicating, by the real-time payment application, the real-time payment identifier to the second merchant system in response to receiving the second transaction identifier request (¶ [0578], Fig 51, MPEP 2144(VI)(B) Duplication of Parts, see also [0219], ¶ [0427], Fig 35 ).
Realini fails to explicitly disclose but Singh does disclose automatically generating, by the real-time payment platform, a real-time payment identifier in response to the real-time payment identifier request (Fig 6A ‘612’, [0010], [0060]);
receiving, by the real-time payment platform, the real-time payment identifier (¶¶ [0060]-[0067], Fig 6A);
in response to receiving the real-time payment identifier, automatically retrieving, by the real-time payment platform, a payment account identifier corresponding to the phone number or the user account identifier (¶¶ [0060]-[0067], Figs 6A&6B);
communicating, by the real-time payment platform, a transaction request comprising the payment account identifier to an acquirer system corresponding to the first merchant system (¶¶ [0060]-[0067], Figs 6A, 6B).
It would have been obvious to one of ordinary skill in the art before the effective filing date to include the features as taught in Singh in Realini since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Both are in the art of mobile payments and it would have been obvious to a person skilled in the art to combine the art to improve transaction security and transaction identification.
As per claim 2:
Realini further discloses the method of claim 1, wherein the method further comprises: receiving, by the real-time payment application, a second real-time payment identifier request, the second real-time payment identifier request comprising a second account identifier (¶ [0031], MPEP 2144(VI)(B) Duplication of Parts, see also [0219], ¶ [0427], Fig 35);
communicating, by the real-time payment application, the second real- time payment identifier request to the real-time payment platform located remotely from the user device (¶ [0032] MPEP 2144(VI)(B) Duplication of Parts, see also [0219], ¶ [0427], Fig 35);
receiving, by the real-time payment application, a second real-time payment identifier generated by the real-time payment platform based on the real-time payment identifier request (¶ [0038], MPEP 2144(VI)(B) Duplication of Parts, see also [0219], ¶ [0427], Fig 35); and
storing, by the real-time payment application, the second real-time payment identifier on the user device (¶ [0139], MPEP 2144(VI)(B) Duplication of Parts, see also [0219], ¶ [0427], Fig 35).
As per claim 3:
Realini further discloses the method of claim 1, wherein the real-time payment identifier request is received from a user through the real-time payment application stored on the user device (¶¶ [0019], [0679], Fig 3).
As per claim 4:
Realini further discloses the method of claim 1, wherein the first transaction identifier request is received from a second application stored on the user device (¶¶ [0019], [0671], [0679], Fig 3).
As per claim 5:
Realini further discloses the method of claim 1, wherein receiving, by the real-time payment application, the first transaction identifier request occurs before the real-time payment identifier request is received by the real-time payment application, wherein the method further comprises: determining, by the real-time payment application, no real-time payment identifier has been previously received associated with at least one of the phone number associated with the user device and the account identifier (¶¶ [0294], [0392], [0689]); and
communicating, by the real-time payment application, a real-time payment identifier initiation notification to the user device in response to determining no real-time payment identifier has been previously received, wherein the real-time payment identifier initiation notification directs a user to communicate the real-time payment identifier request to the real-time payment application (¶¶ [0390], [0689]).
As per claim 6:
Realini further discloses the method of claim 1, wherein the method further comprises: in response to receiving the first transaction identifier request, communicating, by the real-time payment application, a one-time password to the user device (¶ [0217]);
receiving, by the real-time payment application, the one-time password from the first merchant system (¶ [0217]);
matching, by the real-time payment application, the one-time password received from the first merchant system to the one-time password communicated to the user device (¶ [0217]); and
communicating, by the real-time payment application, the real-time payment identifier to the first merchant system in response to matching the one-time password (¶ [0427], Fig 35).
As per claim 7:
Realini further discloses the method of claim 1, wherein the real-time payment identifier request is initiated during an initial setup process of the user device (¶¶ [0027], [0269], [0355]-[0361]).
As per claims 8-14 and 15-21:
Claims 8-14 and 15-21 are rejected under the rationales of claims 1-7, respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Howard US 2019/0095607 Kumnick US 10062079 Kumnick US 20180069936
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID P SHARVIN whose telephone number is (571)272-9863. The examiner can normally be reached M-F 9 am - 5 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, Ryan 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.
/DAVID P. SHARVIN/
Primary Examiner
Art Unit 3692
/DAVID P SHARVIN/Primary Examiner, Art Unit 3692