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 .
DETAILED ACTION
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.
Claim(s) 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s):
A system for validating target account data, the system comprising:
at least one processor configured to:
access a platform that enables payment initiation;
receive a first input associated with target account data;
receive a second input associated with target account data;
upon receipt of the first input and the second input, enable selection of an
activatable element;
in response to selection of the activatable element, perform a lookup
associated with the first input and the second input, to validate the first input and
the second input,
receive a result of the lookup;
transform the result of the lookup using machine learning into a
transformed result; and
present the transformed result.
The underlined portion of the claims represent certain methods of organizing human activity, fundamental economic practices of mitigating risk, because the claims are directed to validating the recipient of a payment.
This judicial exception is not integrated into a practical application because the claim adds the words "apply it", or the like, to the abstract idea. The claims include a system for performing the abstract idea including a processor, a platform, an activatable element and machine learning, all of which are generically recited such that they cannot be considered particular machines, effect a transformation (other than data), reflect an improvement in the computer or technology or apply the abstract idea in some other meaningful way. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the reasons cited above.
The dependent claims merely narrow the abstract idea and in combination and as a whole, comprise the abstract idea and the words “apply it”, the like.
Claims 8, 10, 12, 14 and their dependents are similarly rejected. Claims 2-5 merely further define the result. Claim 6 confines the lookup to a repository, interpreted as a database, which is a further use of a computer or computer elements as a tool. Claim 7 merely defines the repository.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane (20200327550) and further in view of Suermondt (2003/0018658).
Yamane discloses:
1. A system for validating target account data, the system comprising:
at least one processor configured to execute the stored instructions (0004) to:
access a platform that enables payment initiation (0052, Referring to FIG. SA, after the payment solicitation 400/450 is received, an example user/graphical interface 500 may be used to submit a payment request to the service provider system 110, according to potential embodiments. Interface 500 may be presented by, for example, a client application 138 running on the user device 130, or a website of the service provider that is accessed via a browser running on the user device 130.);
receive a first input associated with target account data (0052, Interface 500 allows the user to identify a destination account at 505 by entering a routing number and account number);
receive a second input associated with target account data (0052, identify a name (and address or other data) of the intended beneficiary at 510);
upon receipt of the first input and the second input, enable selection of an activatable element (0054, Following selection of the next icon 525);
in response to selection of the activatable element, perform a lookup
associated with the first input and the second input, to validate the first input and the second input (0055, The service provider system 110 (and/or the user
device 130 in other potential implementations), once data on the payment
request has been entered/received, validates the information. 0057, at 610, the service provider system 110 may transmit a validation request (via, e.g., an API call) to validate the account via the verification system 180. If step 610 occurs before the payee name has been entered by the user, the verification system 180 may be used to discover what account owner is associated with the account. For example, the verification system 180 may have account data 182 (in a ledger, database, etc.) with a list of account numbers and owners, and the verification system 180 may accept an account number from the service provider system 110 and, at 615, return to the service provider system 110 a response identifying the owner or other entity associated with the account/account number.),
receive a result of the lookup (0057, For example, the verification system 180 may have account data 182 (in a ledger, database, etc.) with a list of account numbers and owners, and the verification system 180 may accept an account number from the service provider system 110 and, at 615, return to the service provider system 110 a response identifying the owner or other entity associated with the account/account number. The payee name, once received from the user at 620, may be compared with the owner or other entity identified in the response from the verification system 180 to validate the account number.);
transform the result of the lookup [using machine learning] into a transformed result (0045, an assurance score may be determined); and
present the transformed result ([0046] If (at 325) the service provider system 110 is not sufficiently assured that the destination account belongs to the intended beneficiary (“No”), then at 330, an alert or other notification is transmitted to the user device 130 to indicate, for example, that the destination account is not verified.).
Yamane does not disclose:
Using a machine learning algorithm
However, machine learning algorithms are old and well known per Suermondt (0035).
It would have been obvious to one of ordinary skill to perform the lookup analysis using machine learning for speed and efficiency.
The system of claim 1, wherein the transformed result includes a validation of the first input and the second input (see 0055 above).
The system of claim 1, wherein the transformed result includes an indication of a no-results.
The system of claim 1, wherein the transformed result includes a caution notification.
The system of claim 1, wherein the transformed result includes at least one of a validation of the first input and the second input, an indication of a no-result, or a caution notification.
Claims 3-5 represent printed matter and are not given patentable weight per MPEP 2111.05.
The system of claim 1, wherein the lookup is conducted in a repository to validate the first input and the second input (0057 database).
Claim 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane and further in view of Suermondt (2003/0018658) and admitted prior art.
Yamane does not disclose:
The system of claim 6, wherein the repository is a national repository.
However, applicant’s specification discloses that national databases are old and well known (0039, national shared database resource, to which financial institutions regularly contribute their trusted account and transaction information).
Claim 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane and further in view of Tetro (US 6,715,672 ).
A system for validating target account data, the system comprising:
at least one processor configured to:
access a platform that enables [repetitive] payment initiation;
receive a first input associated with target account data;
receive a second input associated with target account data;
upon receipt of the first input and the second input, enable selection of an activatable element;
in response to the selection of the activatable element, perform a first lookup in a first repository, to validate the first input and the second input;
upon performance of the first lookup, perform a second lookup in a second repository, to validate the first input and the second input;
present a result of the first and second lookup.
The above limitations are similar to those of claim 1 and are similarly rejected. Yamane does not disclose a second lookup however, corroboration of data using a second database is disclosed by Tetro (Description para. 12, In this manner, the input credit card information has been confirmed by the issuer as being valid and the address input by the user has matched an address stored in association with the user's name in the independent information database 18, thus corroborating the information input by the user in two independent databases in order to provide an added measure of fraud detection.)
One of ordinary skill would have been motivated to modify Yamane with corroborating data to increase validation certainty.
Claim 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane and further in view of Suermondt (2003/0018658) as applied to claim 1 and further in view of Tetro.
The system of claim 8, wherein the processor is further configured to:
receive the result of the first lookup and the second lookup;
transform the result of the first lookup and the second lookup using machine learning into a transformed result; and
present the transformed result.
The above limitations are similar to those of claim 1 and are similarly rejected.
Claims 10-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane and further in view of Suermondt (2003/0018658) as applied to claim 1 and further in view of Alpert (US 6,092,081).
10. A system for validating target account data, the system comprising:
at least one processor configured to:
access a platform that enables payment initiation;
receive a first input associated with target account data;
receive a second input associated with target account data;
enable selection of an activatable element;
in response to selection of the activatable element, perform a
lookup associated with the first input and the second input, to validate the
first input and the second input;
receive a result of the lookup;
transform the result of the lookup using machine learning into a
transformed result;
present a result of the lookup; and
cause a display of a tooltip, wherein the tooltip provides data
associated with the result.
The above limitations are similar to those of claim 1 and are similarly rejected. Yamane does not disclose a tooltip however, tooltips are old and well known per Alpert (Description, (36) In the lower box 520, we illustrate how these tags will appear to the user. When a user clicks on one of the colored boxes, the goal or commentary tags appear as popup windows on the display. Alternatively, the system can include known functions called "balloon help" and "tooltips" which display small amounts of text after the mouse pointer hovers over them for a few seconds.)
One of ordinary skill would have been motivated to modify the alert of Yamane as a pop-up and tooltip for convenience and reduce screen clutter.
11. The system of claim 10, wherein the data provided by the tooltip is instructional information.
Claim 11 represents printed matter and are not given patentable weight per MPEP 2111.05.
12. A system for validating target account data, the system comprising:
at least one processor configured to:
access a platform that enables payment initiation;
receive a first input associated with target account data;
receive a second input associated with target account data;
enable selection of an activatable element;
in response to selection of the activatable element, perform a lookup associated with the first input and the second input, to validate the first input and the second input;
present a result of the lookup, wherein the result includes a caution (printed matter as indicated previously);
wherein the at least one processor is further configured to cause the presentation of a pop-up window on a user device upon presentation of the result.
The above limitations are similar to those of claim 10 above and are similarly rejected.
13. The system of claim 12, wherein the result includes a no-result (printed matter as indicated above).
Claim 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane and further in view of Spence (2020/0005291 ).
14. A system for validating target account data, the system comprising:
at least one processor configured to:
access a platform that enables [repetitive] payment initiation;
receive a first input associated with target account data;
receive a second input associated with target account data;
upon receipt of the first input and the second input, automatically perform a lookup in a repository, to validate the first input and the second input; and
present a result of the lookup.
The above limitations are similar to those of claim 1 and are similarly rejected.
Yamane does not disclose repetitive payment imitation however, repetitive payments are old and well known per the prior art of Spence (0022, As previously discussed, in order to provide improved convenience for the user and to help prevent the user from accidentally defaulting on a payment for a continually provided service, the merchant 201 may store details of an electronic payment card held by the user so as to allow them to periodically charge the user's payment card for that service. This will have been agreed with the cardholder in advance. Such recurring payments are known as CPAs (as previously discussed) and may be flagged to the card scheme 203 by the merchant 201 including data indicating that a particular instructed card payment is a CPA payment when transmitting transaction data to the acquirer (that is, data indicative that the payment is a CPA payment is included in the transaction data, for example).)
One of ordinary skill would have been motivated to modify Yamane to accept CPAs for user and merchant convenience.
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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claim 1 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 19 of copending Application No. 18/977023 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 19 anticipates claim 1.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-14 of this application is patentably indistinct from claims 1-14 of Application No. 18/968495. Pursuant to 37 CFR 1.78(f), when two or more applications filed by the same applicant or assignee contain patentably indistinct claims, elimination of such claims from all but one application may be required in the absence of good and sufficient reason for their retention during pendency in more than one application. Applicant is required to either cancel the patentably indistinct claims from all but one application or maintain a clear line of demarcation between the applications. See MPEP § 822.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM E RANKINS whose telephone number is (571)270-3465. The examiner can normally be reached on 9-530 M-F.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett Sigmond can be reached on 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WILLIAM E RANKINS/ Primary Examiner, Art Unit 3694
/BENNETT M SIGMOND/ Supervisory Patent Examiner, Art Unit 3694