DETAILED ACTION
This office action is in reply to the request for continued examination filed on 02/10/2026.
Claims 1, 9, and 18 have been amended.
Claims 1-20 are pending.
Claims 1-20 have been examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/10/2026 has been entered.
Response to Arguments
With regard to the Double Patenting rejection, even though the Applicant has amended claims 1, 9, and 18, the claim scope is still covered by that of Patent No. 11,972,401 (“the ‘401 Patent”). Therefore, the rejection is maintained.
With regard to the 101 rejection, the arguments have been considered but they are not persuasive. The applicant asserted that “amended claims 1, 9, and 18 are not directed to a judicial exceptions . . .” (pg. 11). However, The claim is directed to method of funds transfers via a federated directory (commercial interactions) which falls under Certain Methods of Organizing Human Activity. (Prong One).
When considering under Step 2A Prong Two, the limitations are not indicative of integration into a practical application: adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea – see MPEP 2106.05(f).
Therefore, the claims are not patent eligible.
With regard to the 103 rejection, the arguments have been considered and they are persuasive. The applicant asserted in page 15 that “[first], even attempting to analogize the cross-referencing of a phone number with a registered user of Muthu, Applicant submits that Muthu does not disclose, teach, or suggest ‘receiving . . . an identification of a data collision . . .,’ as recited in amended claim 1”.
Furthermore, Muthu teaches facilitating transfer of funds from a sender to a recipient, the method comprising: receiving a funds transfer request from the sender having a first account at a first financial institution, determining that the recipient is not registered with the payment network, transmitting an invitation to the recipient to join the payment network, receiving the token from the recipient in response to the invitation, collecting identifying information from the recipient including information, including an account number, regarding the second account, creating a first record for the recipient in a database of registered users, and creating a second record for the recipient in an out-of-network database, the second record including the account number for the second account.
Ward teaches photos of recent or prior payees are shown on a user device, such as a smart phone or tablet. The user or payer can select a photo, enter an amount to send, and confirm a payment. The payment provider then processes the payment with minimal input from the payer. Because the photos are of recent or previous payees, the user is able to make a person to person payment with less steps than conventional person to person payments.
Apple teaches an invention provide a mobile device with multiple access modes. The device in some embodiments has at least two access modes, a primary access mode and a secondary access mode, that provide different restrictions for accessing the applications and/or data that are stored on the device. In some embodiments, the primary access mode of the device provides unfettered access to all of the device's applications and/or data that are available to a user, while its secondary access mode provides access to a limited set of applications and/or data that are stored on the device. In some embodiments, the device provides tools to select applications for the secondary access mode.
None of the cited references, either individually or in combination, teaches the claim. It would not be obvious to one of ordinary skill in the art before the effective filing date to disclosed the claimed invention. Hence, the combination is not obvious.
Therefore, the 103 rejection is withdrawn.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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-20 of Patent No. 11972401 (reference patent). The claims are not patentably distinct from each other because they are both directed to performing funds transfer via a federated directory.
Current Application – 18609529
Patent No.– 11972401
Claim 1: A method, comprising: providing, via a user interface of a first computing system, a privacy settings menu comprising a plurality of selectable privacy settings enabling a user to set information that is publicly displayable and set information that is not publicly displayable; receiving, via a second interaction with the user interface of the first computing system, an identification of token selected from a plurality of tokens associated with the user; receiving, via a third interaction with the user interface of the first computing system, an identification of payment directory selected from a plurality of payment directories associated with the user, wherein subsequent to the identification of the payment directory the selected token is associated with the selected payment directory; receiving, via a fourth interaction with the user interface of the first computing system, an input comprising a transfer rule, the transfer rule identifying an association between the selected payment directory, a transfer timing, and an amount to transfer; receiving, via an interaction with the user interface of the first computing system, a privacy setting that sets at least one of a portion of a phone number or a personal characteristic of the user as publicly displayable; receiving, by the first computing system, a designated rail for a funds transfer from the user to a payee. wherein the designated rail for the funds transfer is selected in accordance with the transfer rule based on (i) the selected payment directory, (ii) the transfer timing, and (iii) the amount to transfer to the payee; receiving, by the first computing system and from a second computing system; receiving, by the first computing system and from a second computing system, an identification of a data collision regarding tokenized information associated with the payee and another user, wherein the data collision is based on tokenized information of the payee conflicting with tokenized information of the another user, and wherein the data collision includes a request to resolve the data collision; displaying, by the first computing system, a visual representation regarding the data collision including the at least one of the portion of the phone number or the personal characteristic of the user; displaying, by the first computing system and based on the request to resolve the data collision, a message to resolve the conflict of the tokenized information of the payee and the tokenized information of the another user; receiving, in response to the message to resolve the conflict, an indication from the user confirming that information regarding the payee is correct; subsequent to receiving the indication, sending, to the second computing system, an instruction that facilitates an identification of the payee, wherein the instruction is used to implement a rule to resolve the data collision regarding the tokenized information associated with the payee and the another user by deactivating an association of at least some overlapping tokenized information with the another user; and providing, via the user interface, a message indicating that the funds transfer from the user to the payee has been completed according to the designated transfer timing and the designated rail.
2. (Currently Amended) The method of claim 1,further comprising: receiving funds transfer request corresponding to the funds transfer and comprising at least one of a payment directory to transfer the funds from or a tag for the funds transfer corresponding to the funds transfer request.
3. (Original) The method of claim 2, wherein the funds transfer request comprises the tag, and wherein the tag at least one of identifies the reason for the funds transfer or is a textual description regarding a characteristics of the funds transfer.
4. (Original) The method of claim 1, further comprising displaying a visual representation regarding the instruction.
5. (Currently Amended) The method of claim 1, wherein the instruction is based on a type of data collision and the deactivation of the association of the at least some of the overlapping tokenized information with the another user is based on a seniority of the tokenized information of the another user.
6. (Original) The method of claim 1, further comprising: performing, in response to receiving the message, a device action, wherein the device action comprises at least one of: displaying an alert; sending an email to an email address of the user; or making an alert sound.
7. (Original) The method of claim 1, further comprising displaying a history of funds transfers made by the user.
8. (Original) The method of claim 1, further comprising displaying a history of fund transfers involving the user.
Claim 9: A mobile device, comprising: at least one memory; and at least one processor coupled to the at least one memory, the at least one processor configured to: provide, via a user interface, a privacy settings menu comprising a plurality of selectable privacy settings enabling a user to set information that is publicly displayable and set information that is not publicly displayable receive, via an interaction with the user interface, a privacy setting that sets at least one of a portion of a phone number or a personal characteristic of the user as publicly displayable; receive, via a second interaction with the user interface, an identification of a token selected from a plurality of tokens associated with the user; receive, via a third interaction with the user interface, an identification of a payment directory selected from a plurality of payment directories associated with the user, wherein subsequent to the identification of the payment directory the selected token is associated with the selected payment directory; receiving, via a fourth interaction with the user interface, an input comprising a transfer rule, the transfer rule identifying an association between the selected payment directory, a transfer timing, and an amount to transfer; receive a designated rail for a funds transfer from the user to a payee, wherein the designated rail for the funds transfer is selected in accordance with the transfer rule based on (i) the selected payment directory, (ii) the a designated transfer timing, and (iii) the [[an]] amount to transfer to the payee receive a designated rail for a funds transfer from the user to a payee based on a designated transfer timing and an amount to transfer to the payee; receive, from a computing system, an identification of a data collision regarding tokenized information associated with the payee and another user, wherein the data collision is based on tokenized information of the payee conflicting with tokenized information of the another user, and wherein the data collision includes a request to resolve the data collision; display, by a display device, a visual representation regarding the data collision including the at least one of the portion of the phone number or the personal characteristic of the user; display, by the display device and based on the request to resolve the data collision, a message to resolve the conflict of the tokenized information of the payee and the tokenized information of the another user; receive, in response to the message to resolve the conflict, an indication from the user confirming that information regarding the payee is correct; subsequent to receiving the indication, send an instruction to the computing system that facilitates an identification of the payee, wherein the instruction is used to implement a rule to resolve the data collision regarding the tokenized information associated with the payee and the another user by deactivating an association of at least some overlapping tokenized information with the another user; and control the display device to provide a message indicating that the funds transfer from the user to the payee has been completed according to the designated transfer timing and the designated rail.
10. (Previously Presented) The mobile device of claim 9, wherein the at least one processor is further configured to receive a fund transfer request corresponding to the funds transfer and comprising at least one of a payment directory to transfer the funds from or a tag for the funds transfer.
11. (Original) The mobile device of claim 10, wherein the funds transfer request comprises the tag, and wherein the tag at least one of identifies the reason for the funds transfer or is a textual description regarding a characteristics of the funds transfer.
12. (Original) The mobile device of claim 9, wherein the at least one processor is further configured to display, by the display device, a visual representation regarding the instruction.
13. (Currently Amended) The mobile device of claim 9, wherein the instruction is based on a type of data collision and the deactivation of the association of the at least some of the overlapping tokenized information with the another user is based on a seniority of the information of the another user.
14. (Original) The mobile device of claim 9, wherein the at least one processor is further configured to perform, in response to receiving the message, a device action, wherein the device action comprises at least one of displaying an alert, sending an email to an email address of the user, or making an alert sound.
15. (Original) The mobile device of claim 9, wherein the at least one processor is further configured to provide an alert based on a content of the message.
16. (Original) The mobile device of claim 9, wherein the at least one processor is further configured to display, by the display device, a history of fund transfers made by the user.
17. (Original) The mobile device of claim 9, wherein the at least one processor is further configured to display, by the display device, a history of fund transfers involving the user.
116Patent Application Attorney Docket No. 32060/50329R1 Claim 18: A non-transitory computer-readable medium storing instructions therein that, when executed by one or more processors, cause the one or more processors to perform operations comprising: providing, via a user interface, a privacy settings menu comprising a plurality of selectable privacy settings enabling a user to set information that is publicly displayable and set information that is not publicly displayable; receiving, via an interaction with the user interface, a privacy setting that sets at least one of a portion of a phone number or a personal characteristic of the user as publicly displayable; receiving, via a second interaction with the user interface, an identification of a token selected from a plurality of tokens associated with the user; receiving, via a third interaction with the user interface, an identification of a payment directory selected from a plurality of payment directories associated with the user, wherein subsequent to the identification of the payment directory the selected token is associated with the selected payment directory; receiving, via a fourth interaction with the user interface, an input comprising a transfer rule, the transfer rule identifying an association between the selected payment directory, a transfer timing, and an amount to transfer; receiving a designated rail for a funds transfer from the user to a payee, wherein the designated rail for the funds transfer is selected in accordance with the transfer rule based on(i) the selected payment directory, (ii) the a designated transfer timing, and (ii) the [[an]] amount to transfer to the payee; receiving a designated rail for a funds transfer from the user to a payee based on a designated transfer timing and an amount to transfer to the payee; receiving, from a computing system, an identification of a data collision regarding tokenized information associated with the payee and another user, wherein the data collision is based on tokenized information of the payee conflicting with tokenized information of the another user, and wherein the data collision includes a request to resolve the data collision; providing a visual representation regarding the data collision including the at least one of the portion of the phone number or the personal characteristic of the user; providing, based on the request to resolve the data collision, a message to resolve the conflict of the tokenized information of the payee and the tokenized information of the another user receiving, in response to the message to resolve the conflict, an indication from the user confirming that information regarding the payee is correct; subsequent to receiving the indication, sending an instruction to the computing system that facilitates an identification of the payee, wherein the instruction is used to implement a rule to resolve
20. (Original) The non-transitory computer-readable medium of claim 18, wherein the operations further comprise: receiving the designated transfer timing regarding the funds transfer that specifies that the funds transfer occurs within a designated time period, wherein the message indicates that the funds transfer has been completed according to the designated transfer timing.
Claim 1: A method, comprising:
receiving, by a mobile device of a user, a fund transfer request from the user and an amount to transfer to a payee;
sending, by the mobile device, the fund transfer request to a computing system;
receiving, by the mobile device and from the computing system, an identification of the payee based on the fund transfer request;
receiving, by the mobile device and from the computing system, an identification of a data collision regarding information associated with the payee and another user;
displaying, by the mobile device, a visual representation regarding the data collision;
receiving, by the mobile device, a designated rail for the fund transfer based on a designated transfer timing and the amount to transfer to the payee;
subsequent to receiving the identification of the data collision, prompting, by the mobile device, the user to verify that the information regarding the identification of the payee is correct;
receiving, by the mobile device, an indication from the user confirming that the information regarding the identification of the payee is correct;
subsequent to receiving the indication, sending, by the mobile device to the computing system, an instruction that facilities identification of the payee by resolving the data collision regarding the information associated with the payee and the another user by deactivating an association of at least some overlapping information with the another user;
receiving, by the mobile device, a message indicating that a fund transfer corresponding to the fund transfer request has been completed; and
providing to the user, via a user interface of the mobile device, the message indicating that the fund transfer has been completed.
2. (Currently Amended) The method of claim 1, wherein the fund transfer request further comprises at least one of a payment directory of the user to transfer the funds from and a tag for the [[fund]] funds transfer.
3. (Original) The method of claim 1, further comprising displaying, by the mobile device, a visual representation regarding the instruction.
4. (Previously Presented) The method of claim 1, further comprising displaying, by the mobile device, information regarding the data collision.
5. (Original) The method of claim 1, wherein the instruction is based on a type of data collision and the deactivation of the association of the at least some of the overlapping information with the another user is based on a seniority of the information of the another user.
6. (Original) The method of claim 1, further comprising performing, by the mobile device and in response to receiving the message, a mobile device action, wherein the mobile device action comprises at least one of: displaying, by the mobile device, an alert; sending a text message to a mobile number of the user; sending an email to an email address of the user; or making an alert sound.
7. (Original) The method of claim 6, comprising displaying, by the mobile device, a history of fund transfers made by the user.
8. (Original) The method of claim 1, further comprising displaying, by the mobile device, a history of fund transfers involving the user.
Claim 9: A mobile device, comprising:
at least one memory; and
at least one processor configured to:
receive a fund transfer request from a user regarding a funds transfer to a payee;
send the fund transfer request to a computing system;
receive an identification of the payee based on the fund transfer request;
receive, from the computing system, an identification of a data collision regarding information associated with the payee and another user;
subsequent to receiving the identification of the data collision, display, by a display device of the mobile device, a visual representation data collision;
receive a designated rail for the fund transfer based on a designated transfer timing and the amount to transfer to the payee;
prompt the user to verify that the information regarding the identification of the payee is correct;
receive an indication from the user confirming that the information regarding the identification of the payee is correct;
subsequent to receiving the indication, send an instruction to the computing system that facilitates identification of the payee by resolving the data collision regarding information associated with the payee and the another user by deactivating an association of at least some overlapping information with the another user; and
control the display device to provide a message indicating that the fund transfer has been completed to the user.
10. (Currently Amended) The mobile device of claim 9, wherein the fund transfer request further comprises at least one of a payment directory of the user to transfer the funds from or a tag for the [[fund]] funds transfer.
11. (Original) The mobile device of claim 9, wherein the at least one processor is further configured to display, by the display device, a visual representation regarding the instruction.
12. (Previously Presented) The mobile device of claim 9, wherein the at least one processor is further configured to display, by the display device, information regarding the data collision.
13. (Currently Amended) The mobile device of claim 9, wherein the instruction is based on a type of data collision and the deactivation of the association of the at least some of the overlapping information with the another user is based on a seniority of the information of the another user.
14. (Original) The mobile device of claim 9, wherein the at least one processor is further configured to perform, in response to receiving the message, a mobile device action, wherein the mobile device action comprises at least one of: displaying, by the display device, an alert; sending a text message to a mobile number of the user; sending an email to an email address of the user; or making an alert sound.
15. (Original) The mobile device of claim 9, wherein the at least one processor is further configured to provide an alert based on a content of the message.
16. (Original) The mobile device of claim 14, wherein the at least one processor is further configured to display, by the display device, a history of fund transfers made by the user.
Claim 18: A non-transitory computer-readable medium storing instructions therein that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
receiving a fund transfer request from a user regarding a funds transfer to a payee;
sending the fund transfer request to a computing system;
receiving an identification of the payee based on the fund transfer request;
receiving, from the computing system, an identification of a data collision regarding information associated with the payee and another user;
providing a visual representation regarding the data collision for display;
receiving a designated rail for the fund transfer based on a designated transfer timing and the amount to transfer to the payee;
subsequent to receiving the identification of the data collision, prompting the user to verify that the information regarding the identification of the payee is correct;
receiving an indication from the user confirming that the information regarding the identification of the payee is correct;
subsequent to receiving the indication, sending an instruction to the computing system that facilitates identification of the payee by resolving the data collision regarding information associated with the payee and the another user by deactivating an association of at least some overlapping information with the another user; and
providing a message indicating that the fund transfer has been completed to the user.
19. (Original) The non-transitory computer-readable medium of The non-transitory computer-readable medium of wherein the operations further comprise displaying a history of fund transfers involving the user.
20. (Currently Amended) The non-transitory computer-readable medium of The non-transitory computer-readable medium of wherein the operations further comprise: receiving the designated transfer timing regarding the [[fund]] funds transfer that specifies that the [[fund]] funds transfer occurs within a designated time period; wherein the message indicates that the [[fund]] funds transfer has been completed according to the designated transfer timing.
Both the present and Patent teach funds transferring via financial institutions. The current independent claims are anticipated by the issued patent as they are similar in scope and are disclosed by those of the issued patents.
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-20 are directed to a system, method, or product which are one of the statutory categories of invention. (Step 1: YES).
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claims 1-20 are directed to an abstract idea, Certain Method of Organizing Human Activity. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide generic computer functions that do not add meaningful limits to practicing the abstract idea.
Claims 1, 9 and 18 are grouped together. Claim 9, for instance, recites a mobile device, comprising: at least one memory; and at least one processor coupled to the at least one memory, the at least one processor configured to: provide, via a user interface, a privacy settings menu comprising a plurality of selectable privacy settings enabling a user to set information that is publicly displayable and set information that is not publicly displayable receive, via an interaction with the user interface, a privacy setting that sets at least one of a portion of a phone number or a personal characteristic of the user as publicly displayable; receive, via a second interaction with the user interface, an identification of a token selected from a plurality of tokens associated with the user; receive, via a third interaction with the user interface, an identification of a payment directory selected from a plurality of payment directories associated with the user, wherein subsequent to the identification of the payment directory the selected token is associated with the selected payment directory; receive, via a fourth interaction with the user interface, an input comprising a transfer rule, the transfer rule identifying an association between the selected payment directory, a transfer timing, and an amount to transfer; receive a designated rail for a funds transfer from the user to a payee, wherein the designated rail for the funds transfer is selected in accordance with the transfer rule based on (i) the selected payment directory, (ii) the transfer timing and an amount to transfer to the payee, and (iii) the amount to transfer to the payee; receive, from a computing system, an identification of a data collision regarding tokenized information associated with the payee and another user, wherein the data collision is based on tokenized information of the payee conflicting with tokenized information of the another user, and wherein the data collision includes a request to resolve the data collision; display, by a display device, a visual representation regarding the data collision including the at least one of the portion of the phone number or the personal characteristic of the user; display, by the display device and based on the request to resolve the data collision, a message to resolve the conflict of the tokenized information of the payee and the tokenized information of the another user; receive, in response to the message to resolve the conflict, an indication from the user confirming that information regarding the payee is correct; subsequent to receiving the indication, send an instruction to the computing system that facilitates an identification of the payee, wherein the instruction is used to implement a rule to resolve the data collision regarding the tokenized information associated with the payee and the another user by deactivating an association of at least some overlapping tokenized information with the another user; and control the display device to provide a message indicating that the funds transfer from the user to the payee has been completed according to the designated transfer timing and the designated rail. The limitations are directed to concept of funds transfer – business relations (commercial interactions). Hence, it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements such as a mobile device, a non-transitory computer-readable medium, a computing system, a processor, a display device recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Next the claim as a whole is analyzed to determine whether any element, or combination of elements, is sufficient to ensure the claim amounts to significantly more than an abstract idea. Claims 1, 9, and 18 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements are merely performing the abstract idea on a generic device i.e., abstract idea and apply it. There is no improvement to computer technology or computer functionality MPEP 2106.05(a) nor a particular machine MPEP 2106.05(b) nor a particular transformation MPEP 2106.05(c). Given the above reasons, a generic processing device helps for fund transferring transaction is not an Inventive Concept. Thus, the claim is not patent eligible.
The dependent claims have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea.
The dependent claims 2, 10 have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because the claims recite concept of funds transfer request and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea because the claims only recite additional elements (such as a mobile device, a processor) are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Therefore, the claims are not patent eligible.
The dependent claims 3, 11 have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because the claims recite concept of funds transfer request and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea because the claims only recite additional elements (such as a mobile device, a processor) are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Therefore, the claims are not patent eligible.
The dependent claims 4, 12 have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because the claims recite displaying a visual representation and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea because the claims recite additional elements (such as a processor, a display device) which are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Therefore, the claims are not patent eligible.
The dependent claims 5, 13 have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because the claims recite overlapping tokenized information and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea because the claim recites additional elements (such as a mobile device) which are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Therefore, the claims are not patent eligible.
The dependent claims 6, 14, 15 have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because the claims recite receiving a message and the recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea because the claim includes additional elements (such as a device, one processor, a mobile device) which are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Therefore, the claims are not patent eligible.
The dependent claims 7, 16, 19 have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because the claims recite displaying funds transfer and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea because recites additional elements (such as a processor, a non-transitory computer-readable medium) which are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Therefore, the claims are not patent eligible.
The dependent claims 8, 17 have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because the claims recite displaying funds transfer and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea because recites additional elements (such as a mobile device, a processor) which are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Therefore, the claims are not patent eligible.
The dependent claim 20 has been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because the claims recite receiving a designated transfer timing regarding funds transfer and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea because recites additional element (such as non-transitory computer-readable medium) which are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).. Therefore, the claims are not patent eligible.
Therefore, Claims 1-20 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOAN DUC BUI whose telephone number is (571)272-0833. The examiner can normally be reached on M-F 8-5:00 PM.
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, Michael W. Anderson, can be reached on (571) 270-0508. 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.
/TOAN DUC BUI/ Examiner, Art Unit 3693
/ERIC T WONG/ Primary Examiner, Art Unit 3693
Prosecution Insights