CTNF 18/701,667 CTNF 90931 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Examiner notes that prosecution has been reopened to clarify the rejections made below. The previous Final Action dated 29 December 2025 is withdrawn/superseded and the period for reply has been restarted, which is 3 months from this action, extendable an additional 3 months. This action is Non-final. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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 MPEP 2106.04(a)(2)). 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 MPEP 2106.04(a)(2)). This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (See MPEP 2106.04(d)), the additional elements, of the claim, analyzed alone and in combination with the abstract ideas, represent the use of a computer as a tool to perform an abstract idea and/or does no more than apply 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 MPEP 2106.05), 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,3,5-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)). Claims 4, 11 and 18 introduce the additional element “second application” on the user device. Alone and in combination with the other additional elements it also amounts to merely applying the abstract idea to a technical environment where a device has multiple applications running such as a wallet app, a shopping app, a web browser, email app, etc., each representing a different business or service. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-21-aia AIA Claim (s) 1-4, 7-11, 14-18 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chumbley US 2018/0108008 in view of Kumnick US 2015/0319158 . As per claim 1 Chumbley teaches a method comprising: receiving, by a real-time payment application stored on a user device, 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-a user account identifier (see ¶56, “User 110 may enter account information or account data imprinted or stored on portable device 112 into user device 120. This may be done using an interface provided by an application, such as a digital wallet application, that is stored in the memory of user device 120 or by an interface provided by a website associated with digital wallet server computer 140”. Note the “real-time payment application” reads on either the “digital wallet application” or the browser accessing the “website associated with digital wallet server”); 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 (see ¶61 “User 110 may generate a request for the resource provider specific token” ) ; automatically generating, by the real-time payment platform, a real-time payment identifier in response to the real-time payment identifier request (see ¶ 62, reads on the generating of the instance of the “resource provider specific token” in ”Token service 162 receives the request and then retrieves a resource provider specific token from token vault 164 and records that the retrieved token is associated with digital wallet server computer 140 .”); 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 (see ¶62 “The digital wallet server computer then sends the resource provider specific token over network 130 to user device 120 where it is displayed or stored by user device 120.”); 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 (see ¶62 “The digital wallet server computer then sends the resource provider specific token over network 130 to user device 120 where it is displayed or stored by user device 120.”); 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 (see ¶ 66 “For example, user 210 may use a contactless element in user device 220 to interact with a contactless reader in an access device of resource provider system 270. In another embodiment, user 210 may establish a connection with resource provider system 270 via the Internet in an e-commerce transaction.”); 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 (see ¶ “Once user 210 and/or user device 220 has established a connection with resource provider system 270, user 210 may transmit or cause the transmission of the resource provider specific token to resource provider system 270”) ; receiving, by the real-time payment platform, the real-time payment identifier (see ¶ 69 “To conduct a transaction or automatic transactions according to system 200, resource provider system 270 may generate an authorization request comprising transaction data such as a transaction amount, a resource provider identifier specific to the resource service provider (e.g. merchant ID), and account data comprising data entered into data form 274 by user 210 or user device 220 including the resource provider specific token and user details. The authorization request is sent to transport computer 280, which then forwards the authorization request to processing network 250”) : 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 (see ¶ 69 “Token provider server computer 260 receives the authorization request and may communicate with token vault 264 to determine an account linked to the token contained in the request. Token service 262 may receive, from token vault 264, an account identifier and an identifier for the entity that issued the account.”); 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 (see ¶ 72 “Upon validation of the authorization request, token service 262 may replace the resource provider token in the authorization request with a real account number . The real account number may be retrieved from account data received from digital wallet server computer 240 or may be retrieved from token vault 264 based on account data received from digital wallet server computer 240. For example, token service 262 may receive a generic account token linked to the resource provider specific token and may call out to token vault 264 to retrieve the real account number associated with the generic account token. Token provider server computer 260 may then transmit the authorization request to processing network 250, which then forwards the request to an issuer of the real account number such as first authorizing entity system 292.”); 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 (see ¶63 “User 110 may request a plurality of resource provider specific tokens for a plurality of resource providers.“ one of ordinary skill would recognize this method was intended to be repeated for teach of the “plurality of resource providers”); and communicating, by the real-time payment application, [a] real-time payment identifier to the second merchant system in response to receiving the second transaction identifier request (see ¶63 “User 110 may request a plurality of resource provider specific tokens for a plurality of resource providers.“ one of ordinary skill would recognize this method was intended to be repeated for teach of the “plurality of resource providers”); Chumbley does not teach: communicating, […], the real-time payment identifier to the second merchant system. However Kumnick teaches: communicating, […] the real-time payment identifier (reads on “payment token”) to the second merchant system (see figure 5, and ¶ 65 “multiple token requestors 115 may possess the same payment token, but they each may have a different token code for that payment token.”) . It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the method of Chumbley, by method of sending the real-time payment identifier to the second merchant system, (along with the “token code”), as taught by Kumnick, because the result “allows the single value token to be widely distributed without sacrificing security” (see Kumnick ¶ 23) and the result would clearly be predictable. As per claim 2, Chumbley teaches: 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 (see ¶ 63 “ User 110 may request a plurality of resource provider specific tokens for a plurality of resource providers.) ; 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 (see ¶¶61-62) ; 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 (see ¶63) ; and storing, by the real-time payment application, the second real-time payment identifier on the user device (see ¶63) . As per claim 3, Chumbley teaches: 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 (see ¶ 61, reads on either the “digital wallet application” or the browser used to browse the “website”, in “The request may be generated using the interface provided by a digital wallet application stored on user device 120 or website associated with digital wallet server computer 140.”) . As per claim 4, Chumbley teaches: The method of claim 1, wherein the first transaction identifier request is received from a second application (reads on the web browser) stored on the user device (see ¶ 65, “The resource provider system 270 may comprise a resource provider website 272. The resource provider website 272 may comprise a data form 274 (e.g. payment form), which may be a form consisting of text fields for entering account data.”) . As per claim 7, Chumbley teaches: The method of claim 1, wherein the real-time payment identifier request is initiated during an initial setup process of the user device (see ¶ 63 “User 110 may enter account information or account data into user device 120 for any number of accounts that he or she wishes to conduct transactions with using any number of portable devices. The entered account information for each of these accounts or tokens that represent the entered account information may be stored in user device 120 and/or digital wallet database 142 and linked to the created account (e.g. digital wallet account) for user 110 or user device 120.” ) . Claim 8 is rejected under the same rationale as claim 1 above. Claim 9 is rejected under the same rationale as claim 2 above. Claim 10 is rejected under the same rationale as claim 3 above. Claim 11 is rejected under the same rationale as claim 4 above. Claim 14 is rejected under the same rationale as claim 7 above. As per claim 15, Chumbley teaches: A system for real-time transactions, comprising at least one real-time payment application including at least one processor programmed or configured to: receive a real-time payment identifier request, the real-time payment identifier request comprising at least one of a phone number associated with a user device and a user account identifier (see ¶56, “User 110 may enter account information or account data imprinted or stored on portable device 112 into user device 120. This may be done using an interface provided by an application, such as a digital wallet application, that is stored in the memory of user device 120 or by an interface provided by a website associated with digital wallet server computer 140”. Note the “real-time payment application” reads on either the “digital wallet application” or the browser accessing the “website associated with digital wallet server”); communicate the real-time payment identifier request to a real-time payment platform located remotely from the user device (see ¶62 “Once the request for the resource provider specific token comprising the resource provider identifier, account selection, and wallet ID has been generated, the request is transmitted by user device 120 over network”); receive a real-time payment identifier generated by the real-time payment platform based on the real-time payment identifier request (see ¶ 62 “Token service 162 receives the request and then retrieves a resource provider specific token from token vault 164 and records that the retrieved token is associated with digital wallet server computer 140.”); store the real-time payment identifier (reads on the “provider specific token”) in a real-time payment identifier database, wherein the real-time payment identifier database is stored on the user device (see ¶63 “The plurality of resource provider specific tokens may be stored in digital wallet database 142 and/or user device 120.”) receive a first transaction identifier request associated with at least one of the phone number and the user account identifier from a first merchant system, wherein the first transaction identifier request is received from the first merchant (reads on “resource provider”) system (reads on the “website”) via a second application (reads on the web browser) stored on the user device (see ¶ 65 “The resource provider system 270 may comprise a resource provider website 272. The resource provider website 272 may comprise a data form 274 (e.g. payment form), which may be a form consisting of text fields for entering account data.”); communicate the real-time payment identifier to the first merchant system in response to receiving the first transaction identifier request ( see ¶ 67 “Once user 210 and/or user device 220 has established a connection with resource provider system 270, user 210 may transmit or cause the transmission of the resource provider specific token to resource provider system 270.”) receive a second transaction identifier request associated with at least one of the phone number and the account identifier from a second merchant system (see ¶63 “User 110 may request a plurality of resource provider specific tokens for a plurality of resource providers.“ one of ordinary skill would recognize this method was intended to be repeated for teach of the “plurality of resource providers”); and communicate [a] real-time payment identifier to the second merchant system in response to receiving the second transaction identifier request (see ¶63 “User 110 may request a plurality of resource provider specific tokens for a plurality of resource providers.“ one of ordinary skill would recognize this method was intended to be repeated for teach of the “plurality of resource providers”). Chumbley does not teach: communicating, […], the real-time payment identifier to the second merchant system. However Kumnick teaches: communicating, […] the real-time payment identifier to the second merchant system (see figure 5, and ¶ 65 “multiple token requestors 115 may possess the same payment token”) . I t would have been obvious to one of ordinary skill in the art at the time of the invention to modify the method of Chumbley, by method of sending the real-time payment identifier to the second merchant system, (along with the “token code”), as taught by Kumnick, because the result “allows the single value token to be widely distributed without sacrificing security” (see Kumnick ¶ 23) and the result would clearly be predictable. Claim16 is rejected under the same rationale as claim 2 above. Claim 17 is rejected under the same rationale as claim 3 above. Claim 18 is rejected under the same rationale as claim 4 above. Claim 21 is rejected under the same rationale as claim 7 above . 07-21-aia AIA Claim (s) 5, 12 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chumbley US 2018/0108008 in view of Kumnick US 2015/0319158 in further view of Purves US 2017/0213200 . As per claims 5, 12, and 19: Chumbley and Kumnick fail to explicitly disclose but Purves does disclose t he 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 (see ¶ 33 “a user may enroll with the checkout program but may not yet have established an alias and credential for online access to an issuer's online platform (e.g., an online banking platform).” , 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 (see ¶ 33, “During enrollment, the checkout widget 202 may, alone or in conjunction with the payment processor server 104 and/or the issuer server 106, determine that a personal account number input by the user is associated with an issuer account but the user has not yet set up an alias and credential for accessing an issuer's online platform.”) ; 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 (see ¶ 33 “If not set up, the checkout widget 202 may present an authentication widget 206 for displaying a field prompting a user to provide an alias and to create a credential”) . I t would have been obvious to one of ordinary skill in the art at the time of the invention to modify the method of Chumbley, by determining and communicating a real-time payment identifier before setting up an alias as taught in Purves because it would provide further functionality to remind a user at checkout to signup for the issuer’s online platform and the checkout program ([0034]), allow new users to easily access the system, and the result would be predictable. Allowable Subject Matter over the Prior Art Claims 6, 13, and 20 are not taught or disclosed by the known prior art and would be allowable pending all outstanding, non-prior art rejections . Conclusion 07-96 AIA 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 2018/0069936 Agarwalla US 2021/0042732 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 Application/Control Number: 18/701,667 Page 2 Art Unit: 3692 Application/Control Number: 18/701,667 Page 3 Art Unit: 3692 Application/Control Number: 18/701,667 Page 4 Art Unit: 3692 Application/Control Number: 18/701,667 Page 5 Art Unit: 3692 Application/Control Number: 18/701,667 Page 6 Art Unit: 3692 Application/Control Number: 18/701,667 Page 7 Art Unit: 3692 Application/Control Number: 18/701,667 Page 8 Art Unit: 3692 Application/Control Number: 18/701,667 Page 9 Art Unit: 3692 Application/Control Number: 18/701,667 Page 12 Art Unit: 3692 Application/Control Number: 18/701,667 Page 13 Art Unit: 3692 Application/Control Number: 18/701,667 Page 14 Art Unit: 3692 Application/Control Number: 18/701,667 Page 15 Art Unit: 3692 Application/Control Number: 18/701,667 Page 16 Art Unit: 3692 Application/Control Number: 18/701,667 Page 17 Art Unit: 3692
Prosecution Insights