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
Response to Arguments
The claim objections are withdrawn in view of the amendments.
Applicant’s arguments regarding the 101 rejection of the claims have been considered but are not persuasive.
Applicant argues:
Step 2A, Prong One — Not directed to abstract idea: Examiner's characterization ("validating the recipient of a payment") is at an impermissibly high level of generality; omits material limitations. Claim 15 recites a specific computer-implemented control flow: conditional activation of an activatable element, transmission of both inputs to a server, validation of both inputs against aggregated data in a national shared database repository, machine-learning transformation into a single probability score, and display before payment completion.
Office Response:
"Technical Field" of the disclosure the frames invention as pre-transaction validation (abstract concept). - The repository is admitted to be known in the specification, so it cannot be a "particular" architecture in the sense of being novel or unconventional.
- The machine-learning transformation is not detailed, so it cannot be a "specific technical operation" in the sense of being a concrete implementation.
- Conditional activation of activatable element - Specification describes an "activatable element" broadly as any UI element (button, keystroke, mouse click) (¶ [0035]). Routine UI design is not a technical innovation.
Display before completion of payment - This is the intended result of the abstract idea (pre-transaction validation), not a separate technical constraint (¶ [0002]).
Applicant argues:
Step 2A, Prong Two — Integrated into practical application: Claims address a problem in computerized payment systems (inadequate confirmation that target account is the intended account). Solution involves a particular shared repository architecture (national shared database repository storing aggregated target account data from multiple entities, accessible by multiple independent systems) and a machine-learning transformation into a single probability score.
Office Response:
Problem is business risk mitigation, not a technical problem in computer networks. Shared repository and machine-learning are addressed above. Even if the shared repository were not admitted it is not described as any particular technological development and under BRI is considered conventional (as in the National Shared Repository disclosed).
Applicant argues:
Step 2B — Significantly more: Ordered combination is not well-understood, routine, and conventional. Examiner's rejection is conclusory and lacks factual support under *Berkheimer*. Under *BASCOM*, an inventive concept may reside in a nonconventional arrangement of individually conventional components.
Office Response:
The ordered combination argument under BASCOM is unpersuasive because one of the key elements of the alleged ordered combination (the national shared database repository) is admitted to be conventional. While BASCOM holds that an inventive concept may reside in the nonconventional arrangement of individually conventional components, the arrangement here — using a known database to look up account data — is not shown to be unconventional. The ordered combination of elements is not shown to be unconventional and demonstrates a conventional arrangement or routine sequence: receive inputs → enable button → lookup → transform → display.
The national shared database repository is admitted to be known or at least generic, and the machine-learning transformation is not described with sufficient particularity to establish that it is unconventional. The claim merely applies the abstract idea of payment validation using generic computer components and a known database.
Regarding the Berkheimer argument applicant asserts that “The Office Action identifies a processor, platform, activatable element, server, database, and machine learning as generically recited components, but does not establish that the claimed arrangement and interaction of those components as a whole was well-understood, routine, and conventional. The relevant inquiry is not merely whether processors, servers, databases, or machine-learning algorithms were individually known. Rather, the inquiry includes whether the claimed combination of elements, operating in the claimed manner, was widely prevalent or in common use in the relevant field. MPEP § 2106.05(d) explains that a well-understood, routine, and conventional determination applies to an element or combination of elements and requires appropriate factual support.”
The Office asserts that the applicants argument is misplaced on several counts. First, the Office never asserted that the additional elements were well-understood, routine and conventional (WURC). The Office stated “The claims include a system for performing the abstract idea including a processor, a platform, an activatable element, a server, a database 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 MPEP 2106.07(a)(III) states “At Step 2A Prong Two or Step 2B, there is no requirement for evidence to support a finding that the exception is not integrated into a practical application or that the additional elements do not amount to significantly more than the exception unless the examiner asserts that additional limitations are well-understood, routine, conventional activities in Step 2B.” As the Office did not state that the additional elements are WURC the Office is not required to provide evidence of such. Additionally, the “relevant inquiry” as stated by the applicant is not whether the combination of elements was widely prevalent but per MPEP 2106.05(d)(I): When making a determination whether the additional elements in a claim amount to significantly more than a judicial exception, the examiner should evaluate whether the elements define only well-understood, routine, conventional activity. In this respect, the well-understood, routine, conventional consideration overlaps with other Step 2B considerations, particularly the improvement consideration (see MPEP § 2106.05(a)), the mere instructions to apply an exception consideration (see MPEP § 2106.05(f)), and the insignificant extra-solution activity consideration (see MPEP § 2106.05(g)). Thus, evaluation of those other considerations may assist examiners in making a determination of whether a particular element or combination of elements is well-understood, routine, conventional activity. In addition, examiners should keep in mind the following points when determining whether additional elements define only well-understood, routine, conventional activity.
1. An additional element (or combination of additional elements) that is known in the art can still be unconventional or non-routine.
2. A factual determination is required to support a conclusion that an additional element (or combination of additional elements) is well-understood, routine, conventional activity.
It follows that it is proper to determine if an additional element, not necessarily the combination, as asserted, is WURC. It also follows that as the Office had previously determined that the additional elements even in combination, were evaluated per MPEP 2106.05(a), 2106.05(f) and 2106.05(g) as above, the WURC consideration is met. The application itself provides evidence that the elements are (WURC), the following elements are generically identified in the specification as processor (0031, any physical device), platform (0032, may include any application…), activatable element (0035, any element of a platform…, server (Fig. 3), database (007, repository is a national shared database, 0028, may be publicly accessible or independently owned 0039, a repository ay include…), and machine learning (7 instances from 0006-0042, cited as being used, or alternatively, AI, but not described as any particular technique or algorithm).
Applicant’s arguments regarding the 103 rejection of the claims have been considered but are not persuasive.
Applicant argues:
Paragraph [0039] does not state that the claimed national shared database repository is "old," "well known," "conventional," or "prior art."
Office response:
The disclosure recites in 0039, “For example, a national shared database repository may refer to the National Shared Database Resource, to which financial institutions regularly contribute their trusted account and transaction information.”. The Office notes that the repository is referred to specifically and also capitalized, indicating that it exists and is recognized. Therefore, the Office interpretation is an admission of prior art. The database/repository is not otherwise identified as a particular invention of the applicant.
The remaining 103 arguments are addressed in the rejections themselves.
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) 15-29 and 31-35 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):
15. A system for validating target account data, the system comprising:
a memory storing instructions; and
at least one processor configured to execute the stored instructions to:
generate a platform that enables payment initiation on an endpoint device;
access the platform that enables payment initiation;
receive, through the endpoint device, a first input associated with target account data;
receive, through the endpoint device, 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, transmit the first input and the second input to a server;
perform a lookup associated with the first input and the second input, to validate the first input and the second input, wherein the lookup is conducted in a national shared database repository storing aggregated target account data from a plurality of entities and accessible by a plurality of independent systems, wherein both the first input and the second input are validated against the aggregated target account data within the national shared database repository to validate the first input and the second input;
generate, using a machine learning algorithm, a transformed result based on a degree of correspondence, wherein the transformed result includes a single overall score representing a probability that the target account corresponds to an intended target account; and display, on the endpoint device prior to completion of the payment, the transformed result indicating that the target account corresponds to the intended target account.
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 claims include a system for performing the abstract idea including a processor, a platform, an activatable element, a server, a database 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 16-18 merely narrow the lookup process, claims 19-22, 24 and 25 narrow the result, and 23 and 26-28 merely narrow how the result is presented. Claims 29 and 31-33 are similarly rejected. Claims 34 and 35 merely identify the entities, narrowing the abstract idea.
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 15ertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 15, 18-22, 29, 31-33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane (20200327550) and further in view of Suermondt (2003/0018658) and applicant admitted prior art.
Yamane discloses:
A system for validating target account data, the system comprising:
a memory storing instructions:
at least one processor configured to execute the stored instructions (0004) to:
generate a platform that enables payment initiation on an endpoint device;
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, through the endpoint device, 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, through the endpoint device, 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, transmit the first input and the second input to a server (0004, account validation API, 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.);
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.),
generate, using a machine learning algorithm, a transformed result based on a degree of correspondence, wherein the transformed result includes a single overall score representing a probability that the target account corresponds to an intended target account (0045, an assurance score may be determined); and display, on the endpoint device prior to completion of the payment, the transformed result indicating that the target account corresponds to the intended target account ([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. the optional notification may be transmitted before, at the same time as, or after proceeding with processing of the payment request (at 645).).
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.
Yamane does not disclose:
wherein the lookup is conducted in a national shared database repository storing aggregated target account data from a plurality of entities and accessible by a plurality of independent systems, wherein both the first input and the second input are validated against the aggregated target account data within the national shared database 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). Shared database indicates that it is accessible by other systems. Yamane discloses the validation step as above (0055).
Claim 29 is similarly rejected.
19. The system of claim 15, wherein the transformed result includes a validation of at least one of the first input or the second input (verification by both the beneficiary system 150 and the verification system 180 is required as validation of the account number. In some implementations, an assurance score may be determined. The assurance score may be proportional to confidence that the destination account belongs to the intended beneficiary. In some implementations, the assurance score may be, for example, relatively “high” when both the beneficiary system 150 and the verification system 180 have validated the account.)
20. The system of claim 19, wherein the transformed result is presented to indicate the validation of at least one of the first input or the second input ( if (at 325) the service provider system 110 is sufficiently assured that the destination account belongs to the intended beneficiary (“Yes”), then at 330, a notification or other message may optionally be transmitted to the user device 130 to indicate, for example, that the destination account is verified.).
Claim 31 is similarly rejected.
21. The system of claim 20, wherein the transformed result presented to indicate the validation of at least one of the first input and the second input further includes an indication of a caution (Fig. 5B, alert).
Claim 33 is similarly rejected.
22. The system of claim 21, wherein the indication of caution includes a level of caution ([0060] In certain versions, after an alert or other notification (indicating, e.g., that validation of the account number is pending, validation is unsuccessful, or that confidence in the account number is low) has been received by the user device 130.).
24. The system of claim 20, wherein the transformed result includes an indication of a no-results (see claim 22 above.)
Claim 32 is similarly rejected.
Claim 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane (20200327550) and further in view of Suermondt (2003/0018658) and applicant admitted prior art as applied to claim 15 and further in view of Goel (US 7, 689,916).
Yamane does not disclose:
23. The system of claim 15, wherein the at least one processor is further configured to
display a pop-up window on a user device to present the transformed result.
However, Goel discloses a pop-up in the 1st para. Of the background. (4) Many web
pages and applications are constrained in screen space or back-end computing
resources and cannot always provide full detailed information or content to all users. In
these cases, users must click on a link to view detailed information either on a separate
page or as a pop-up.
Based on the disclosure above presenting information via a pop-up would have been obvious to one of ordinary skill for the reasons stated above by Goel. As the claims references “the transformed result”, it is clear that the transformed result is disclosed in claim 15 and need not be disclosed here.
Claims 16, 18, 25-28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane (20200327550) and further in view of Suermondt (2003/0018658) and applicant admitted prior art as applied to claim 15 and in view of Sgambati (10,346,620).
Yamane does not disclose:
The system of claim 15, wherein the lookup further comprises:
comparing the first input and the second input with data stored in the national shared database repository.
However, Sgambati discloses:
Abstract: The method can further include receiving a request for authentication for one or more queried data elements corresponding to a supplied identification data element. The method can include determining an authentication response for each of the queried data elements based on the authentication database. The method can further include transmitting the authentication response for each of the queried data elements to the requesting system.
The examiner asserts that the one or more queried data elements are first inputs and second inputs which are disclosed in claim 15 and are merely described as “associated with target account data”, meaning they could be any number of things. The data elements of Sgambati could be identification elements per claim 18 and thus may also be associated with target account data.
Sgambati further discloses:
18. The system of claim 15, wherein the lookup results in a match between the data in the national shared database repository and at least one of the first input and the second input (Brief summary para. 2, the authentication response for each of the queried data elements is positive when the queried data element matches a data element value stored in the data element field corresponding to the supplied identification data element.).
Per Sgambati:
25. The system of claim 15, wherein the lookup results in no matches between the data in the national shared database repository and one of the first input and the second input (Brief summary para. 2, Optionally, the authentication response for each of the queried data elements is…negative when the queried data element does not match the data element value stored in the data element field corresponding to the supplied identification data element, and not available when the data element value is blank for the data element field corresponding to the supplied identification data element.).
Per Sgambati:
26. The system of claim 25, wherein the transformed result is presented to indicate no matches between the national shared database repository and one of the first input and the second input (Abstract, The method can further include transmitting the authentication response for each of the queried data elements to the requesting system.).
Sgambati discloses the National shared database repository, and querying it for validation purposes, as recited in applicant’s specification therefore it would have been obvious to one of ordinary skill to combine with Yamane as it is a publicly known and available resource.
Yamane discloses:
27. The system of claim 26, wherein the transformed result presented to indicate no matches includes an indication of caution (See claim 22).
28. The system of claim 27, wherein the indication of caution includes a level of caution (See claim 22).
Claim 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane (20200327550) and further in view of Suermondt (2003/0018658) and applicant admitted prior art and Sgambati as applied to claim 16 and in view of Hoopes (2007/0204001).
Yamane does not disclose:
The system of claim 16, wherein the at least one processor is further configured to compare the first input and the second input with data stored in the national repository using fuzzy logic.
However, fuzzy logic is old and well known as a comparison technology per the prior art of Hoopes (0014). Hoopes undoubtedly discloses using fuzzy logic is “old and well-known” and describes it’s use. The specification likewise generally discloses using fuzzy logic in a similarly general fashion.
It would have been obvious to a POSITA to use a well-known technology like fuzzy logic when comparing data across databases.
Claims 34 and 35 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamane (20200327550) and further in view of Suermondt (2003/0018658) and applicant admitted prior art as applied to claims 15 and 29 and in view of He (US 20220084036 A1).
Yamane does not disclose, however Ye discloses
34. The system of claim 15, wherein the plurality of entities comprises a plurality of financial institutions that contribute trusted account and transaction information to the national shared database repository ([0025] FIG. 1 illustrates a block diagram representing a P2P payment transaction system 100 (i.e. an event system as also described herein), according to embodiments of the present technology. The system 100 collects data relating to social tokens associated with individuals or entities that may be a payer or payee in person-to-person (P2P) payment transactions. Some of the collected data may come from financial institutions 102, which provide account data on transactions conducted against accounts at those financial institutions (e.g., checks written from/deposited to an account, electronic debit/credit transactions against the account, and ACH transactions posted to the account), and account data relating to personal information on account holders and other information (such as account status) associated with each individual account at the financial institutions. 0023, In establishing an account with a P2P payment system, the payer may provide a social token, such as a cell phone number or an email address, that is associated with the payer. Other types of social tokens may include, for example, QR codes assigned to a user (e.g., by a financial institution, third party payment processor, etc.), P2P (e.g., Zelle) user handles, debit card, personal ID, or other proxy for the user or social token.)
He also discloses:
[0007] Some embodiments of the present technology include a system for determining the health of social tokens. The system may include a processing unit comprising one or more processors, and memory coupled with and readable by the processing unit and storing therein a set of instruction. When executed by the processing unit, the processing unit may cause the system to perform operations including, for example: receiving, by a processor of a data assessment system, data associated with a sender including a social token associated with the sender, wherein the data associated with the sender is used by the data assessment system to generate an account associated with the sender; receiving, by the processor of the data assessment system, from a plurality of entities, account data associated with a plurality of accounts maintained at the entities, wherein the account data includes at least data pertaining to events conducted against each of the plurality of accounts; generating, by the data assessment system, a health score for the social token associated with the sender, wherein generating the health score for the social token associated with the sender includes analyzing data associated with the sender, data associated with the social token associated with the sender, and account data received from the plurality of entities; receiving, from the sender at an application displayed on a graphical user interface (GUI) of a network device associated with the sender, data associated with an event initiated by the sender using the account associated with the sender, wherein the data associated with the event initiated by the sender includes at least a social token associated with a receiver of the event; generating, by the data assessment system, a health score for the social token associated with the receiver, wherein generating the health score for the social token associated with the receiver includes analyzing data associated with the receiver, data associated with the social token associated with the receiver.
He and Yamane are both directed to confirming target accounts and as such would have been an obvious combination to one of ordinary skill as He discloses the database used to make the queries of sender and target accounts.
Claim 35 is similarly rejected.
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
