DETAILED ACTION
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 .
This application is a CON of 18/120,908 03/13/2023
18/120,908 is a CON of 17/738,821 05/06/2022 PAT 11605077
17/738,821 is a CON of 17/549,783 12/13/2021 PAT 11593800
17/549,783 is a CON of 16/551,627 08/26/2019 PAT 11373182
17/738,821 is a CON of 16/551,627 08/26/2019 PAT 11373182
16/551,627 is a CON of 15/209,685 07/13/2016 PAT 10395247
15/209,685 is a CIP of 14/587,745 12/31/2014 PAT 10318936
14/587,745 is a CIP of 13/782,587 03/01/2013 PAT 10395223
13/782,587 has PRO 61/657,339 06/08/2012
13/782,587 has PRO 61/607,882 03/07/2012
Status of Claims
Claims 1-20 are currently pending and rejected.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-18 of U.S. Patent No. 9,691,056. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 10,078,821. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-26 of U.S. Patent No. 10,318,936. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 10,395,247. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 11,321,682. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 11,361,290. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 11,373,182. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 11,593,800. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 11,605,077. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 11,715,075. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims and the parent claims both describe a fund transfer process/system using public identifier and private identifier. The present independent claims are broadened version of the parent claims, thus every limitations in the present claims are taught by the parent claims.
Claim Rejection – 35 U.S.C. 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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The rationale for this finding is explained below. In the instant case, the claims are directed towards system and method for facilitating transferring funds between people. The concept is clearly related to managing transactions between people, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The claims do not include limitations that are “significantly more” than the abstract idea because the claims do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Note that the limitations, in the instant claims, are done by the generically recited computer device. The limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. Therefore, claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Step 1: The claims 1-20 are directed to a process, machine, manufacture, or composition matter.
In Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), the Supreme Court applied a two-step test for determining whether a claim recites patentable subject matter. First, we determine whether the claims at issue are directed to one or more patent-ineligible concepts, i.e., laws of nature, natural phenomenon, and abstract ideas. Id. at 2355 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1296–96 (2012)). If so, we then consider whether the elements of each claim, both individually and as an ordered combination, transform the nature of the claim into a patent-eligible application to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself.
Step 2A: The claims are directed to an abstract idea.
Prong One
The present claims are directed towards system and method for managing transactions between people. The concept comprises sending a registration request comprising a public identifier (e.g., email or phone number) from a user, validating the public identifier by sending a message to the user using the public identifier, sending a confirmation message to funds transfer network to validate that the public identifier is usable to contact the user and to register the user by storing a record in a directory that associates the public identifier with a private identifier. No actual payment is actually performed in the process, and the process is mostly just registering a user for an account at the funds transfer network. The present claims are related to managing transaction between people, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The performance of the claim limitations using generic computer components (i.e., one or more processors) does not preclude the claim limitation from being in the certain methods of organizing human activity grouping. Accordingly, this claim recites an abstract idea.
Prong Two
Independent claim 1 recites one or more processors as additional elements. Depending claims 2-10 do not recite any other additional element. Independent claim 11 recites one or more processors and one or more non-transitory computer-readable media as additional elements. Dependent claims 12-20 do not recite any other additional element. The additional elements are claimed to perform basic computer functions, such as sending registration request, sending message to user’s public identifier (e.g., email or phone number) to validate the public identifier, sending a confirmation message to funds transfer network, storing user registration information including public identifier and private identifier. The recitation of the computer elements amounts to mere instruction to implement an abstract concept on computers. The computer implementation is arguably an extra-solution. The present claims could be performed without computer. For example, use home address as public identifier, validate home address by mailing a letter to the address, and recording registration information on paper. The present claims do not solve a problem specifically arising in the realm of computer networks. Rather, the present claims implement an abstract concept using existing technology in a networked computer environment. The present claims do not recite limitation that improve the functioning of computer, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B: The claims do not recite additional elements that amount to significantly more than the abstract idea.
As discussed earlier, independent claim 1 recites one or more processors as additional elements. Depending claims 2-10 do not recite any other additional element. Independent claim 11 recites one or more processors and one or more non-transitory computer-readable media as additional elements. Dependent claims 12-20 do not recite any other additional element. The additional elements are claimed to perform basic computer functions, such as sending registration request, sending message to user’s public identifier (e.g., email or phone number) to validate the public identifier, sending a confirmation message to funds transfer network, storing user registration information including public identifier and private identifier. According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. The present claims do not improve the functioning of computer. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Claim Rejection – 35 U.S.C. 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, 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 1-9 and 11-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vancini et al. (Patent No.: US 9,928,490), in view of Provident Bank (Provident Bank, Universal Payment Identification Code (UPIC) guide) and Musser et al. (Pub. No.: US 2012/0215688) and Giordano et al. (Pub. No.: US 2008/0011825) and The Payers (PayPal introduces global payments platform PayPal X, 11/5/2009, https://thepaypers.com/online-payments/paypal-introduces-global-payments-platform-paypal-x--739940#) and Lindbom et al. (Pub. No.: US 2012/0089508).
As per claim 1 and 11, Vancini teaches a method implemented on one or more processors (see column 5 line 35-63), the method comprising:
before a sender initiates a funds transfer request to pay a user (see column 4 line 9-24, “Users including senders and recipients may register their information with the information directory 128 in advance”):
sending a registration request comprising a public identifier of a user to a computer-implemented funds transfer network to cause the computer-implemented funds transfer network to send a message to the user using the public identifier of the user to perform a validation that the public identifier is usable to contact the user, wherein the registration request is a request to register an account of the user for real-time payments through the computer-implemented funds transfer network (see column 1 line 66-67, column 5 line 35-63, “The information directory 164 may be used when an identifier other than a bank account/routing number is used (e.g., an e-mail address, phone number, Universal Payment Identification Code (UPIC), other randomly generated number, proxy or token). As describe above in connection with the information directory 128 and 158, the information directory 164 is a database that is maintained to allow the payment service to convert/correlate the recipient’s cell phone number (or e-mail address, or proxy or token) to a bank account number/routing number of the recipient’s bank account…Users including senders and recipients may register their information with the information directory 164 in advance”; also see column 5 line 20-63, and column 6 line 61 through column 7 line 34 for registering; also see column 9 line 27-44 and column 10 line 34-46, prior art teaches sending notice to user in the form of an e-mail, a SMS, an automated voice message, etc. to notify user incoming fund transfer; in other words, when user responds to the notice he/she validates the public identifier), and
wherein the registration request is sent to the computer-implemented funds transfer network based on a user registration request received from the user through a non-bank entity (see col 4 line 65 through col 5 line 19, Vancini teaches “the payment service may be a third-party vendor…the payment service may be a web portal provided for an online community for individuals where such individuals obtain user names/login IDs or otherwise become registered members…Examples of online communities include MSN, iPhone users, Facebook, Linkedin, and so on. The payment service may, for example, be an additional service that is offered by the web portal to the members of the online community. As another example, the payment service may be provided by one of the banks”; clearly, the payment service in Vancini can be either a non-bank entity or a bank; the prior art teaches two embodiments that are exchangeable; as such, Vancini teaches the registration request can be sent from the user through a non-bank entity); and
sending a confirmation message to the computer-implemented funds transfer network to validate that the public identifier is usable to contact the user and to cause the computer-implemented funds transfer network to register the user by storing a record in a directory of the computer-implemented funds transfer network that associates the public identifier (see column 9 line 27-44 and column 10 line 34-46, “At step 750, the recipient account and verification information is stored in the information directory 164”; also see column 5 line 35 through column 6 line 21) with a private identifier, wherein the private identifier is associated with the account of the user (see column 1 line 28-56, “receiving a fund transfer request that includes an identifier for a recipient”; see column 5 line 35 through column 6 line 21, “the information that is stored in the information directory 164 may include information sufficient for the member bank to identify the user, but not necessarily the bank account number/routing number, or other sensitive information such as the social security number of the user”; prior art extracts “information sufficient for the member bank to identify the user” from the information directory based on the recipient’s identifier/e-mail in the fund transfer request; even though prior art does not explicitly use a private identifier to identify a recipient, it uses “information sufficient for the member bank to identify the user”, which can be interpreted as some sort of private identifier that is known to the recipient financial institution),
wherein: the private identifier is not shared with the user; and the private identifier stored in the directory of the computer-implemented funds transfer network is usable by the computer-implemented funds transfer network, when a sender initiates a funds transfer request to pay the user using the public identifier of the user, to cause funds to be made available in real-time in the account of the user (see column 5 line 35 through column 6 line 21, “the information that is stored in the information directory 164 may include information sufficient for the member bank to identify the user, but not necessarily the bank account number/routing number, or other sensitive information such as the social security number of the user. In the context of a given transaction, such information may be passed along by the payment service computer system 160 to the bank computer system 120 or 150”, where 120 is the sender bank computer system and 150 is the recipient bank computer system; “and the bank computer system 120 or 150 may access its own information directory 128 or 158 to obtain more detailed account information”, prior art teaches the payment service computer system extracts recipient information from the information directory based on the recipient identifier, and passes along the recipient information to the sender financial institution to enable a fund transfer to the recipient financial institution, and the recipient financial institution has its own information directory to identify the account number of the recipient based on the received recipient information).
Examiner notes even though Vancini does not explicitly use the term “private identifier” to identify a recipient, it uses “information sufficient for the member bank to identify the user” (see column 5 line 35 through column 6 line 21), which can be interpreted as some sort of private identifier that is known to the recipient financial institution. Vancini essentially teaches the same process as the present claims without calling the recipient information stored in the information directory “private identifier”. Vancini does teach using Universal Payment Identification Code or UPIC in place of bank account/routing number to identify the recipient. According to Provident Bank, “A Universal Payment Identification Code (UPIC) is a unique account identifier that looks and acts like a real account number on ACH payment transactions…without exposing actual banking information” and “UPICs are issued and maintained by financial institutions”. Thus, Vancini can be interpreted as teaching a private profile identifier that was generated by the recipient financial institution, the recipient having a recipient account at the recipient financial institution, the private profile identifier being a unique identifier for the recipient at the recipient financial institution, the recipient financial institution associating the private profile identifier with an account number of the recipient account at the recipient financial institution.
Examiner also cites Musser to support the argument that private identifier for fund transfer was known. Musser teaches cause the computer-implemented funds transfer network to register the user by storing a record in a directory of the computer-implemented funds transfer network that associates the public identifier; wherein: the private identifier is not shared with the user; and the private identifier stored in the directory of the computer-implemented funds transfer network is usable by the computer-implemented funds transfer network, when a sender initiates a funds transfer request to pay the user using the public identifier of the user, to cause funds to be made available in real-time in the account of the user (see paragraph 0009 and 0061, “The financial institution network 140 can also includes a database 144 that stores conversion information 146, such as an association between DDA’s, the private virtual identifier, and/or the public virtual identifier. Upon receipt of a DDA payment request from the transaction server 122 of the payment network, the servers 142 of the financial institution networks 142 can retrieve DDA information associated with the private virtual identifier included in the request using the conversion information 146 in the database 144”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Vancini with teaching from Musser to include cause the computer-implemented funds transfer network to register the user by storing a record in a directory of the computer-implemented funds transfer network that associates the public identifier; wherein: the private identifier is not shared with the user; and the private identifier stored in the directory of the computer-implemented funds transfer network is usable by the computer-implemented funds transfer network, when a sender initiates a funds transfer request to pay the user using the public identifier of the user, to cause funds to be made available in real-time in the account of the user. The modification would have been obvious, because it is merely applying a known technique (i.e. associating a private identifier to a payment account in a directory) to a known method (i.e. online fund transfer) ready to provide predictable result (i.e. add an extra layer of security).
Examiner notes, Vancini teaches users including senders and recipients may register their information (phone number or e-mail address or other proxy) with the information directory in advance (see column 4 line 9-24 and column 5 line 35-63). However, the combination of Vancini and Provident Bank and Musser does not explicitly teach the amended limitation before a sender initiates a funds transfer request to pay a user: sending a registration request comprising a public identifier of the user to computer-implemented funds transfer network to send a message to the user using the public identifier of the user to perform a validation that the public identifier is usable to contact the user; and sending a confirmation message to the computer-implemented funds transfer network to validate that the public identifier is usable to contact the user and to cause the computer-implemented funds transfer network to register the user by storing a record in a directory of the computer implemented funds transfer network.
Giordano teaches before a sender initiates a funds transfer request to pay a user: sending a registration request comprising a public identifier of the user to computer-implemented funds transfer network to send a message to the user using the public identifier of the user to perform a validation that the public identifier is usable to contact the user (see paragraph 0043-0044 and 0046, “The operation can be divided into two parts: a registration process and a transaction process. During the registration process (FIG. 2), the consumer registers for the payment service and his mobile phone(s) are provisioned to make payments”, prior art teaches sending registration request prior to fund transfer request; see paragraph 0047, “the registration module 128 may verify the provided mobile phone number by sending a conformation sms message containing a confirmation code to the mobile phone. The consumer is required to send the confirmation code back to the service center 120 in order to be verified”; also see paragraph 0034, “The consumer profiles can be stored in database 125 and indexed by the user ID and the mobile phone number”, mobile phone number is a public identifier); and
sending a confirmation message to the computer-implemented funds transfer network to validate that the public identifier is usable to contact the user and to cause the computer-implemented funds transfer network to (i) register the user by storing a record in a directory of the computer implemented funds transfer network (see paragraph 0034, “The consumer profiles can be stored in a database 125 and indexed by the user ID and the mobile phone number”; see paragraph 0048, “The registration module 128 creates 220 a consumer profile for the consumer and stores the received consumer information in the consumer profile within database 125”) and (ii) send an enrollment conformation message to the user that the user is enrolled with the computer-implemented funds transfer network and enabled to receive funds in real-time in the account of the user through the computer-implemented funds transfer network (see paragraph 0047, “the registration module 128 may verify the provided mobile phone number by sending a conformation sms message containing a confirmation code to the mobile phone. The consumer is required to send the confirmation code back to the service center 120 in order to be verified” and “the registration module 128 may confirm with the payment processing networks 160 that the consumer’s payment account is valid and that the consumer is the account holder”; see paragraph 0056, Upon completion of steps 210-240, the registration module 128 may optionally send 250 a confirmation to the terminal 202 through the Internet, indicating that the registration process is completed and the consumer can start using the payment system 100 through the device 114”; also see FIG. 2, after the registration module 128 sends the 250 enrollment conformation message to the terminal 202, the enrollment confirmation message is forwarded to the user’s mobile phone 114).
PNG
media_image1.png
481
661
media_image1.png
Greyscale
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the combination of Vancini and Provident Bank and Musser with teaching from Giordano to include before a sender initiates a funds transfer request to pay a user: sending a registration request comprising a public identifier of the user to computer-implemented funds transfer network to send a message to the user using the public identifier of the user to perform a validation that the public identifier is usable to contact the user; and sending a confirmation message to the computer-implemented funds transfer network to validate that the public identifier is usable to contact the user and to cause the computer-implemented funds transfer network to register the user by storing a record in a directory of the computer implemented funds transfer network. The modification would have been obvious, because it is merely applying a known technique (i.e. requiring users to be provisioned/registered with the P2P payment service prior to initiating payment request) to a known method (i.e. online fund transfer) ready to provide predictable result (i.e. ensure both sender and recipient are properly registered before fund transfer).
The combination of Vancini, Provident Bank, Musser, and Giordano does not explicitly teach wherein the registration request is sent to the computer-implemented funds transfer network based on a user registration request received from the user through a non-bank entity that is different from an entity operating the computer-implemented funds transfer network.
The Payers teaches the registration request is sent to the computer-implemented funds transfer network based on a user registration request received from the user through a non-bank entity that is different from an entity operating the computer-implemented funds transfer network (see page 2, “PayPal has also rolled out a beta of its Adaptive Accounts API, which enable developers to create PayPal accounts for their customers from within their applications…Those who do not have a PayPal account can sign up for one within the third-party application and pay via PayPal from within that application”; in this case, the third-party application is a non-bank entity that is different from PayPal – the entity operating the computer-implemented funds transfer network; prior art teach users register PayPal account via third-party application).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the combination of Vancini and Provident Bank and Musser and Giordano with teaching from The Payers to include the registration request is sent to the computer-implemented funds transfer network based on a user registration request received from the user through a non-bank entity that is different from an entity operating the computer-implemented funds transfer network. The modification would have been obvious, because it is merely applying a known technique (i.e. allowing user to register with payment network via third-party) to a known method (i.e. online fund transfer) ready to provide predictable result (i.e. allow user to register with payment network without being directed to the payment network website).
The combination of Vancini and Provident Bank and Musser and Giordano and The Payers does not explicitly teach “receive funds in real-time in the account of the user through the computer-implemented funds transfer network before a recipient financial institution that maintains the account of the user receives the funds through a settlement network” and “to cause the funds to be made available in real-time in the account of the user before the recipient financial institution receives the funds through the settlement network”, as amended.
Lindbom teaches receive funds in real-time in the account of the user through the computer-implemented funds transfer network before a recipient financial institution that maintains the account of the user receives the funds through a settlement network; and to cause the funds to be made available in real-time in the account of the user before the recipient financial institution receives the funds through the settlement network (see paragraph 0031, “since the RIB sever 110 is facilitating inter-currency transfers using its own, pre-funded accounts, it becomes possible to enable the immediate transfer of available funds from a remitting party to a beneficiary party without waiting the later transfer of real money to settle the transaction”).
As per claim 2 and 12, Vancini does not explicitly teach wherein the private identifier is associated with an account number of the account of the user stored in a database of the computer-implemented funds transfer network that is different from the directory.
Musser teaches the private identifier is associated with an account number of the account of the user stored in a database of the computer-implemented funds transfer network that is different from the directory (see paragraph 0009 and 0061, “The financial institution network 140 can also includes a database 144 that stores conversion information 146, such as an association between DDA’s, the private virtual identifier, and/or the public virtual identifier. Upon receipt of a DDA payment request from the transaction server 122 of the payment network, the servers 142 of the financial institution networks 142 can retrieve DDA information associated with the private virtual identifier included in the request using the conversion information 146 in the database 144”).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify Vancini with teaching from Musser to include private identifier is associated with an account number of the account of the user stored in a database of the computer-implemented funds transfer network that is different from the directory. The modification would have been obvious, because it is merely applying a known technique (i.e. associating a private identifier to a payment account in a directory) to a known method (i.e. online fund transfer) ready to provide predictable result (i.e. add an extra layer of security).
As per claim 3 and 13, Vancini teaches wherein the registration request further comprises an account number of the account of the user (see column 1 line 66-67, column 5 line 35-63, “The information directory 164 may be used when an identifier other than a bank account/routing number is used (e.g., an e-mail address, phone number, Universal Payment Identification Code (UPIC), other randomly generated number, proxy or token). As describe above in connection with the information directory 128 and 158, the information directory 164 is a database that is maintained to allow the payment service to convert/correlate the recipient’s cell phone number (or e-mail address, or proxy or token) to a bank account number/routing number of the recipient’s bank account…Users including senders and recipients may register their information with the information directory 164 in advance”).
As per claim 4 and 14, Vancini teaches wherein the account number is a debit account number (see column 1 line 66-67, column 5 line 35-63, “The information directory 164 may be used when an identifier other than a bank account/routing number is used (e.g., an e-mail address, phone number, Universal Payment Identification Code (UPIC), other randomly generated number, proxy or token). As describe above in connection with the information directory 128 and 158, the information directory 164 is a database that is maintained to allow the payment service to convert/correlate the recipient’s cell phone number (or e-mail address, or proxy or token) to a bank account number/routing number of the recipient’s bank account…Users including senders and recipients may register their information with the information directory 164 in advance”).
As per claim 5 and 15, Vancini teaches sending a payment request comprising a recipient public identifier of a recipient to the computer-implemented funds transfer network to cause the computer-implemented funds transfer network to cause a funds transfer from the account of the user to an account of the recipient (see column 4 line 37-64 and column 6 line 22-60).
As per claim 6 and 16, Vancini does not explicitly teach wherein the account of the recipient is maintained by a recipient financial institution that is a member of the computer-implemented funds transfer network.
Musser teaches wherein the account of the recipient is maintained by a recipient financial institution that is a member of the computer-implemented funds transfer network (see paragraph 0009 and 0061, “The financial institution network 140 can also include a database 144 that stores conversion information 146, such as an association between DDA’s, the private virtual identifier, and/or the public virtual identifier. Upon receipt of a DDA payment request from the transaction server 122 of the payment network, the servers 142 of the financial institution networks 142 can retrieve DDA information associated with the private virtual identifier included in the request using the conversion information 146 in the database 144”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Vancini with teaching from Musser to include wherein the account of the recipient is maintained by a recipient financial institution that is a member of the computer-implemented funds transfer network. The modification would have been obvious, because it is merely applying a known technique (i.e. associating a private identifier to a payment account in a directory) to a known method (i.e. online fund transfer) ready to provide predictable result (i.e. add an extra layer of security).
As per claim 7 and 17, Vancini teaches wherein the computer-implemented funds transfer network is operated by an entity that is different from the recipient financial institution (see FIG. 2 of Vancini, which is very similar to FIG. 1 of the present application; information directory, which stores public identifier and information sufficient to identify the recipient by the recipient financial institution, is owned by a payment service computer system that is external to the recipient financial institution and the sender financial institution).
As per claim 8 and 18, Vancini teaches wherein the public identifier comprises an email address of the user (see column 4 line 9-24; column 5 line 35 through column 6 line 21, “The payment service computer system 160 includes network interface logic 162 and an information directory 164…The information directory 164 may be used when an identifier other than a bank account/routine number is used (e.g. an email-address, phone number, Universal Payment Identification Code (UPIC), other randomly generated number, proxy or token)…The arrangement allows the sender to uniquely identify the recipient (e.g., with an e-mail address or other identifier), without necessarily having private/personal information regarding the recipient (i.e., the recipient’s bank account/routing number).
As per claim 9 and 19, Vancini teaches wherein the public identifier comprises a phone number of the user (see column 4 line 9-24; column 5 line 35 through column 6 line 21, “The payment service computer system 160 includes network interface logic 162 and an information directory 164…The information directory 164 may be used when an identifier other than a bank account/routine number is used (e.g. an email-address, phone number, Universal Payment Identification Code (UPIC), other randomly generated number, proxy or token)…The arrangement allows the sender to uniquely identify the recipient (e.g., with an e-mail address or other identifier), without necessarily having private/personal information regarding the recipient (i.e., the recipient’s bank account/routing number).
Claim 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vancini et al. (Patent No.: US 9,928,490), in view of Provident Bank (Provident Bank, Universal Payment Identification Code (UPIC) guide) and Musser et al. (Pub. No.: US 2012/0215688) and Giordano et al. (Pub. No.: US 2008/0011825) and The Payers (PayPal introduces global payments platform PayPal X, 11/5/2009, https://thepaypers.com/online-payments/paypal-introduces-global-payments-platform-paypal-x--739940#) and Lindbom et al. (Pub. No.: US 2012/0089508), and further in view of Logan et al. (Pub. No.: US 2012/0260322).
As per claim 10 and 20, Vancini does not teach wherein the public identifier of the user is periodically revalidated to be usable to contact the user.
Logan teaches the public identifier of the user is periodically revalidated to be usable to contact the user (see paragraph 0022, “replying parties ask users for their email address or other contact information if one is not on file, and may revalidate this information at regular interval”).
It would have been obvious to one of ordinary skill int the art at the effective filing date of the present application to modify Vancini with teaching from Logan to include the public identifier of the user is periodically revalidated to be usable to contact the user. The modification would have been obvious, because it is merely applying a known technique (i.e. revalidating email or other contract information periodically) to a known method (i.e. online fund transfer) ready to provide predictable result (i.e. ensure the public identifier is usable to contact the user).
Response to Remarks
Rejection under 35 U.S.C. 101
Applicant's arguments filed on 07/31/2025 have been fully considered but they are not persuasive.
Step 2A Prong 2, Amended claims 1 and 11 do not integrate the idea into a practical application
Applicant argued that the “additional elements provide a combination of steps that improves the technical field of secure electronic funds transactions and uses the ideas in meaningful way that is not generally linking to a technological environment, similar to the eligible claims in DDR Holding, LLC v. Hotels.com,L.P”. Examiner disagrees and points out that transfer money at non-financial institutions is not an Internet centric problem. Using a public identifier in place of an account number and a private identifier (an internal proxy identifier) to enhance information security is also not a solution rooted in computer technology. Phone number could be used as account number, any type of secrete code by be used as private identifier by transfer network, data can be stored in written form, and communications can be implemented via phone network. None of the recited claim feature improve computer function. The present claims do not solve a problem specifically arising in the realm of computer networks. Rather, the present claims implement an abstract concept using existing technology in a networked computer environment. The present claims do not recite limitation that improve the functioning of computer, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B, Amending claims 1 and 11 do not recite inventive concept by adding limitations that are not well-understood, routine, and conventional
Applicant argued that the “amended independent claims 1 and 11 add specific limitations that are improvements beyond what is well-understood, routine, or conventional in the field” without providing any explanation. Examiner disagrees and point out that the present claims only recite a generic computer comprising one or more processors and a computer readable memory. Such combination and arrangement of computer elements are conventional. The additional elements are claimed to perform basic computer functions, such as sending registration request, sending message to user’s public identifier (e.g., email or phone number) to validate the public identifier, sending a confirmation message to funds transfer network, storing user registration information including public identifier and private identifier. According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. The present claims do not improve the functioning of computer.
Moreover, the amended features, “receive funds in real-time in the account of the user through the computer-implemented funds transfer network before a recipient financial institution that maintains the account of the user receives the funds through a settlement network” and “to cause the funds to be made available in real-time in the account of the user before the recipient financial institution receives the funds through the settlement network”, do not improve computer function. It is a feature related to business rule rather than technology. Such features were also well-known prior to the present invention. For example, Lindbom et al. (Pub. No.: US 2012/0089508) teaches, “since the RIB sever 110 is facilitating inter-currency transfers using its own, pre-funded accounts, it becomes possible to enable the immediate transfer of available funds from a remitting party to a beneficiary party without waiting the later transfer of real money to settle the transaction” (see paragraph 0031). Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Examiner maintains the ground of rejection under 35 U.S.C. 101.
Rejection under 35 U.S.C. 103
In the response filed on 01/05/2026, Applicant amended the independent claims by modifying the following limitations - “receive funds in real-time in the account of the user through the computer-implemented funds transfer network before a recipient financial institution that maintains the account of the user receives the funds through a settlement network” and “to cause the funds to be made available in real-time in the account of the user before the recipient financial institution receives the funds through the settlement network”. Real-time fund transfer and making funds available prior to settlement was well-known prior to the present application. Examiner cites a new prior art, Lindbom et al. (Pub. No.: US 2012/0089508), to address the amended feature. Rejection under 35 U.S.C. 103 has been updated.
Updated rejection is provided in this Office Action.
Conclusion
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, Christine Behncke can be reached on (571) 272-8103. 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.
/HAO FU/Primary Examiner, Art Unit 3697 FEB-2026