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 U.S.C § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine,
manufacture, or composition of matter, or any new and useful improvement
thereof, may obtain a patent therefor, subject to the conditions and requirements
of this title.
4. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is
directed to an abstract idea without significantly more.
Claims 1, 13, 18 are directed to a method and system, which are statutory categories of invention. (Step 1: YES).
Representative claim 1 recites the limitations of:
A computer-implemented method of dispositioning a transaction associated with a payment account, the method comprising:
receiving, via an interface system, a registration request for a computing device to host transactions associated with the payment account;
generating, via the interface system, a unique identifier for the computing device;
correlating, via the interface system, the payment account to the generated unique identifier for the computing device;
receiving, via the interface system, a transaction authorization request associated with the payment account; and
routing, via the interface system, the received transaction authorization request associated with the payment account to the computing device for dispositioning based on the correlation, wherein the routed transaction authorization request is configured to be dispositioned in accordance with a rule stored locally on the computing device.
These limitations, under their broadest reasonable interpretation, cover performance of
the limitation as certain methods of organizing human activity.
The claim recites elements that are in bold above, which covers performance of the
limitation as a commercial interaction, steps for dispositioning of a transaction associated with a payment account (e.g., A method of dispositioning a transaction associated with a payment account, the method comprising: receiving, a registration request for a computing device to host transactions associated with the payment account; generating, a unique identifier for the computing device; correlating, the payment account to the generated unique identifier; receiving, a transaction authorization request associated with the payment account; and routing, the received transaction authorization request associated with the payment account to the computing device for dispositioning based on the correlation, wherein the routed transaction authorization request is configured to be dispositioned in accordance with a rule stored)
If a claim limitation, under its broadest reasonable interpretation, covers performance of
the limitation as a Commercial Interaction, then it falls within the "Certain Methods of
Organizing Human Activity" grouping of abstract ideas.
Claims 13,18 are abstract for similar reasons.
(Step 2A-Prong 1: YES. The claims are abstract).
This judicial exception is not integrated into a practical application. Limitations that
are not indicative of integration into a practical application include: (1) 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 (MPEP 2106.05.f), (2) Adding insignificant extra solution activity to the
judicial exception (MPEP 2106.05.g), (3) Generally linking the use of the judicial
exception to a particular technological environment or field of use (MPEP 2106.05.h).
Claims 1, 13, 18 include the following additional elements:
- An interface system
- A computing device
- A device registration server
The interface system, computing device and device registration server are recited at a high level of generality and are being used in their ordinary capacity and are being used as a tool for implementing the steps of the identified abstract idea, see MPEP 2106.05(f), where applying a computer or using a computer as a tool to perform the abstract idea is not indicative of a practical application.
Therefore, the claim as a whole, looking at the additional elements individually and in combination, are no more than mere instructions to apply the exception using generic computing components and is not a practical application. MPEP 2106.05(f).
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.
Therefore claims 1, 13, 18 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO). The additional claimed elements are not integrated into a practical application)
Representative claim 1 fails STEP 2B because the claims as a whole, looking at the additional elements individually and in combination, are not sufficient to amount to significantly more than the identified abstract idea.
As discussed above with respect to integration of the abstract idea into a practical application, there are no additional elements recited in the claim beyond the judicial exception. Mere instructions to implement an abstract idea, on or with the use of generic computer components, or even without any computer components, cannot provide an inventive concept - rendering the claim patent ineligible. Thus claims 1,13, 18 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-12, 14-17, 19-20 further define the abstract idea that is present in their respective independent claims 1,13,18 and thus correspond to Certain Methods of Organizing Human Activity.
Therefore, the dependent claims do not include any additional elements that integrate
the abstract idea into a practical application or are sufficient to amount to significantly
more than the judicial exception when considered both individually and as an ordered
combination. Therefore, the dependent claims (2-12, 14-17, 19-20) are directed to an abstract idea. Thus, the claims 1-20 are not patent-eligible.
Claim Rejections- 35 U.S.C § 103
2. Claims 1-20 are being rejected under 35 U.S.C 103(a) as being unpatentable over US 2017/0169420 to Setlur et al, herein Setlur in view of US 2021/0097523 to Phillips et al, herein Phillips.
Regarding claim 1, Setlur discloses
A computer-implemented method of dispositioning a transaction associated with a payment account, the method comprising:
receiving, via an interface system, a registration request for a computing device to host transactions associated with the payment account (At least: [0005], [0037]);
[0005] Methods are disclosed by which users can execute digital payment transactions within a secure digital payments platform. Users download and configure a mobile application, also known as a “wallet app”, onto their mobile device (or “smartphone”). Using the mobile application, users register an account with a platform control system of the digital payments platform (or “platform”). Users can also add funds to the mobile application or link payment instruments (debit and credit cards) with which to execute digital payment transactions. Subsequent to successfully registering and configuring the app, a user can use his/her mobile device to approve and execute digital payment transactions in a variety of modes.
[0037] In order to execute payment transactions within the platform 100, users may complete a registration process. The process includes recordation of information identifying the user as well as information identifying one or more of his internet-enabled devices. In an embodiment, the user initiates the registration process using the client mobile device 106.
generating, via the interface system, a unique identifier for the computing device (At least: [0038], [0039]);
[0038] FIG. 3 is a flowchart illustrating a process for registering a user with the digital payments platform, according to one embodiment. The user firsts downloads 300 the client mobile application 120 on their client mobile device 106. The client mobile application 120 prompts the user to enter 302 a series of credentials into the client mobile application 120. In one embodiment, these credentials include an email address controlled by the user, or a mobile number associated with the client mobile device 106.
[0039] In order to complete the registration process, the user may be prompted to log in to the client mobile application 120. At this time, the client mobile application 120 determines 308 if the client mobile device 106 has a SIM card. If it does, the user enters a set of his/her credentials (typically, mobile number or email, and PIN). The user may also enter one or more kinds of biometric information, such as a fingerprint or retina scan, if the client mobile device 106 includes components configured to capture this kind of data. The client mobile device 106 transmits these credentials 310 along with information describing the SIM card present on the client mobile device 106. In one embodiment, the SIM information includes an identification number (ID) of the SIM card. The SIM ID may be encrypted using an asymmetric encryption algorithm, such as RSA. The credentials may be encrypted using this same asymmetric encryption algorithm as well. It should be noted that other cryptographic schemes may be utilized, such as symmetric encryption (AES) or message digest algorithms like SHA-256 or some other forms of cryptographic methods has and when they may become available.
correlating, via the interface system, the payment account to the generated unique identifier for the computing device (At least: [0025], [0045], [0050]);
[0025] When an issuer 104 issues a payment instrument to an accountholder, it retains a record of various information related to the payment instrument and the accountholder (or “user”). Some of the information stored by issuer 104 may include the name of the accountholder, the address of the accountholder, contact information for the accountholder, payment instrument identification number, expiration date of the payment instrument, and the amount of available funds on the payment instrument. The issuer 104 may also store one or more additional identification numbers specifically issued to the payment instrument. Some of the information stored by the issuer 104 may be physically printed on the payment instrument.
[0045] The Web SDK 124 is configured to receive a user's credentials (phone number or email and PIN) for the purposes of executing a payment transaction. The user's credentials are entered by a registered user of the platform 100 at the time he/she wishes to execute a payment transaction. The Web SDK 124 is further configured to transmit the credentials to the platform control system 102.
[0050] If instead the platform control system 102 is able to verify the SIM information and/or device information, the platform control system 102 then transmits 430 an identification of the user, the user's payment instrument selection, and select transaction details to the appropriate issuer 104. The issuer 104 verifies 432 if the user identifier and payment instrument selection match its own records and are associated with a valid and/or active payment instrument. In some embodiments, the issuer 104 may also verify, if necessary, that the selected payment instrument contains sufficient funds to execute the transaction. If any of these are not successful, then a single action transaction is not possible; the issuer 104 specifies 428 further authentication requirements as previously described, or terminates the transaction altogether (in the case of insufficient funds).
receiving, via the interface system, a transaction authorization request associated with the payment account (At least: [0048]
[0048] If the user is logged in, then the client mobile application 120 displays 416 the transaction approval request. In some embodiments, the user is presented with a single button which, if clicked, will signal approval or disapproval of the payment transaction. At this time, the user decides 418 to approve or disapprove the transaction. If the user disapproves 420 the transaction, the transaction reaches a terminal FAIL state. If the user approves 422 the transaction, the user clicks the button, performing the “single action” as previously described. In typical embodiments, at the time of approval, the user also selects one of multiple payment instrument choices with which to execute the transaction. In typical embodiments, a default payment instrument is selected, so that the user does not need to manually select a payment instrument. The user's approval, as well as his/her selection of a payment instrument, is transmitted by the client mobile application 120 to the platform control system 102. The platform control system 102 receives 424 the transaction approval and payment instrument selection. The platform control system 102 then determines 426 if it can verify SIM information and/or device information associated with the user. In some embodiments, the platform control system 102 retains SIM information and/or device information that are transmitted by the client mobile application 120 at the time of session activation at the client mobile device 106. It should be noted that transmission of this information can occur at some time prior to initiation of a payment transaction by a user, or it could occur when a user logs in to the client mobile application 120 subsequent to receiving a transaction approval request on his/her client mobile device 106. Verification of the SIM information and/or device information may involve, in some embodiments, decryption of encrypted data using a private decryption key. In other embodiments, the platform control system 102 performs the same encryption steps performed at the client mobile device 106 and compares its result against the SIM information and/or device information received from the client mobile device 106.
; and
routing, via the interface system, the received transaction authorization request associated with the payment account to the computing device for dispositioning based on the correlation (At least: Fig 9; [0068], [0069]);
[0068] FIG. 9 is a diagram illustrating the process of completing a single action payment transaction within a third-party mobile application, according to one embodiment. The object interaction diagram 900 describes the interactions that occur between the mobile SDK 130, the platform control system 102, the third-party mobile application 114, and the issuer 104 in the process of completing a single-action payment transaction from within the third-party mobile application 114. A user browsing within a third-party mobile application 114 on his/her client mobile device 106 decides to initiate a transaction. The third-party mobile application 114 transmits 902 a transaction approval request along with associated transaction details to the mobile SDK 130 (this may be referred to as “triggering” the mobile SDK 130). Before the user can approve the transaction, he/she must have an active session. If the mobile SDK 130 determines that the user does not currently have an active session, the user is prompted to log in. This causes the mobile SDK 130 to transmit 906 the user credentials, along with information about the SIM card and the device itself, to the platform control system 102. In some embodiments, the mobile SDK 130 may pass the user credentials to the client mobile application 120 executing on the same client mobile device 106, and request that the credentials, SIM information, and device information be shared with the platform control system 102. As described earlier, this information may be encrypted or otherwise obscured using one or more cryptographic techniques.
[0069] Next, if the user approves the transaction on the mobile SDK 130, the mobile SDK 130 (or the client application 120) returns 908 approval of the transaction, along with select transaction details (the amount to be paid and/or the merchant to be paid) as well as a selection of the payment instrument with which to execute the transaction. The platform control system 102 then transmits 910 an user identification along with the payment instrument information and select transaction details (e.g. amount and recipient) to the appropriate issuer 104. If the issuer 104 is able to verify the user identification as well as the payment instrument information (including availability of funds), the issuer 104 completes the single action transaction and returns 912 a transaction confirmation to the platform control system 102. The platform control system 102 may then transmit 914 a confirmation of the transaction to the mobile SDK 130 and/or the third-party mobile application 114.
Setlur does not disclose, Phillips in the same field of endeavor discloses:
wherein the routed transaction authorization request is configured to be dispositioned in accordance with a rule stored locally on the computing device (At lest: [0025], [0040]; Fig 1: 114 and associated text).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein the routed transaction authorization request is configured to be dispositioned in accordance with a rule stored locally on the computing device in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 2, Setlur discloses the computer-implemented method of claim 1. Setlur further discloses further comprising generating, via the interface system, the payment account in response to receiving the registration request (At least: [0031], [0032]; Fig 2).
Regarding claim 3, Setlur discloses the computer-implemented method of claim 1. Setlur further discloses further comprising confirming, via the interface system, that the payment account has been funded (At least: [0050], [0059]).
Claim 20 is being rejected using the same rationale as claim 3.
Regarding claim 4, Setlur discloses the computer-implemented method of claim 1. Setlur does not disclose, Phillips discloses wherein the rule is predetermined by a user of the computing device via an application accessed by the computing device (At least: [0023]).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein the rule is predetermined by a user of the computing device via an application accessed by the computing device in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 5, Setlur discloses the computer-implemented method of claim 1. Setlur further discloses wherein dispositioning the transaction authorization request in accordance with the rule comprises automatically declining the transaction authorization request (At least: [0048], [0057]).
Claim 16 is being rejected using the same rationale as claim 5.
Regarding claim 6, Setlur discloses the computer-implemented method of claim 5. Setlur does not disclose, Phillips discloses wherein the rule comprises a restricted type of transaction made in association with the payment account (At least: [0024]).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein the rule comprises a restricted type of transaction made in association with the payment account in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 7, Setlur discloses the computer-implemented method of claim 6. Setlur does not disclose, Phillips discloses wherein dispositioning the received transaction authorization request comprises determining a type of transaction associated with the transaction authorization request and correlating the type of transaction associated with the transaction authorization request with the restricted type of transaction, and wherein automatically declining the transaction authorization request is based on the correlation (At least: [0024]).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein dispositioning the received transaction authorization request comprises determining a type of transaction associated with the transaction authorization request and correlating the type of transaction associated with the transaction authorization request with the restricted type of transaction, and wherein automatically declining the transaction authorization request is based on the correlation in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 8, Setlur discloses the computer-implemented method of claim 7. Setlur does not disclose, Phillips discloses wherein the received transaction authorization request comprises a transaction code, and wherein determining the type of transaction associated with the transaction authorization request is based on the transaction code of the transaction authorization request (At least: [0035]).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein the received transaction authorization request comprises a transaction code, and wherein determining the type of transaction associated with the transaction authorization request is based on the transaction code of the transaction authorization request in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 9, Setlur discloses the computer-implemented method of claim 5. Setlur does not disclose, Phillips discloses wherein the rule comprises a restricted time of transaction made in association with the payment account (At least: [0024]),
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein the rule comprises a restricted time of transaction made in association with the payment account
in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 10, Setlur discloses the computer-implemented method of claim 9. Setlur does not disclose, Phillips discloses wherein dispositioning the received transaction authorization request comprises determining a time of transaction associated with the transaction authorization request, and correlating the time of transaction associated with the transaction authorization request with the restricted time of transaction, wherein automatically declining the transaction authorization request is based on the correlation (At least: [0024]).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein dispositioning the received transaction authorization request comprises determining a time of transaction associated with the transaction authorization request, and correlating the time of transaction associated with the transaction authorization request with the restricted time of transaction, wherein automatically declining the transaction authorization request is based on the correlation in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 11, Setlur discloses the computer-implemented method of claim 10. Setlur further discloses wherein correlation comprises correlating the information associated with the computing device with information associated with the payment account, wherein the information associated with the payment account comprises at least one of a primary account number, a user name, an expiration date, and a card verification value, or combinations thereof (At least: [0025], [0049]
Regarding claim 12, Setlur discloses the computer-implemented method of claim 1. Setlur further discloses wherein the registration request comprises information associated with the computing device, and wherein the information associated with the computing device comprises at least one of an IMEl, a phone number, and a MAC address, a SIM, a MIN, and a MSIN, or combinations thereof (At least: [0006], [0040], [0047]).
Regarding claim 13, Setlur discloses:
An interface system configured to disposition a transaction associated with a payment account, the system comprising (At least Fig 1 and associated text);
a device registration server communicably coupled to a plurality of computing devices, wherein the device registration server is configured to receive a registration request from a first computing device of the plurality of computing devices (At least: [0006], [0037], [0040]); and
a routing server communicably coupled to a payment system, wherein the routing server is configured to receive a transaction authorization request from the payment system, and wherein the routing server is further configured to route the transaction authorization request to a first computing device of the plurality of computing devices (At least: [0048]);
wherein the first computing device is configured to disposition the transaction authorization request (At least: Fig 9; [0068], [0069]).
Setlur does not disclose, Phillips in the same field of endeavor discloses wherein the first computing device is configured to disposition the transaction authorization request in accordance with a rule that governs transactions made in association with the payment account (At least: [0025], [0040]; Fig 1: 114), and wherein the rule is stored locally on the first computing device (At least: Fig 1: 114 and associated text).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein the first computing device is configured to disposition the transaction authorization request in accordance with a rule that governs transactions made in association with the payment account and wherein the rule is stored locally on the first computing device
in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 14, Setlur discloses the interface system of claim 13. Setlur further discloses wherein the registration request comprises computing device information and information associated with the payment account (At least: [0005])
Regarding claim 15, Setlur discloses the interface system of claim 14. Setlur further discloses wherein the device registration server is further configured to register the computing device to host transactions made in association with the payment account based on the computing device information and the information associated with the payment account (At least: [0005]).
Regarding claim 17, Setlur discloses the interface system of claim 16. Setlur does not disclose, Phillips discloses wherein the rule is predetermined by a user of the first computing device via an application accessed by the first computing device (AT least: [0023]).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein the rule is predetermined by a user of the first computing device via an application accessed by the first computing device in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 18, Setlur discloses a computer-implemented method of dispositioning a transaction associated with a payment account, the method comprising:
receiving, via an interface system, a registration request associated with the payment account, wherein the registration request comprises information associated with a computing device (At least: [0005], [0037], ;
registering, via the interface system, the computing device to host transactions made in association with the payment account based on the registration request (At least: [0005]);
receiving, via the interface system, a transaction authorization request associated with the payment account (At least: [0048]);
correlating, via the interface system, the payment account to the information associated with the computing device (At least: [0025], [0045], [0050])
Setlur discloses routing, via the interface system, the transaction authorization request to the computing device based on the correlation (At least: Fig 9; [0068], [0069]).
Setlur does not disclose, Phillips in the same field of endeavor discloses:
wherein the routed transaction authorization request is configured to be dispositioned in accordance with a rule stored locally on the computing device (At lest: [0025], [0040]; Fig 1: 114 and associated text).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include wherein the routed transaction authorization request is configured to be dispositioned in accordance with a rule stored locally on the computing device in order to ensure that the transaction is able to be authorized based on the specified rules (Phillips: [0040]).
Regarding claim 19, Setlur discloses the computer-implemented method of claim 18. Setlur further discloses further comprising:
receiving, via the interface system, a signal associated with an approval of the transaction authorization request from the registered computing device (At least: [0068], [0069]).
Setlur does not disclose, Phillips discloses transmitting, via the interface system, an instruction to transfer an asset associated with the payment account to an acquirer (At least: [0020], [0027]).
Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Setlur’s invention to include transmitting, via the interface system, an instruction to transfer an asset associated with the payment account to an acquirer in order to ensure that a secure and fraud resistant transaction may be conducted without requiring or permitting the merchant to store sensitive payment credentials, whereby the merchant simply forwards the received information to a merchant acquirer using standard payment authorization request processing techniques (Phillips: [0043]).
CONCLUSION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD Z SHAIKH whose telephone number is (571)270-3444. The examiner can normally be reached M-T, 9-600; Fri, 8-11, 3-5.
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, BENNETT SIGMOND can be reached at 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 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.
/MOHAMMAD Z SHAIKH/Primary Examiner, Art Unit 3694 8/20/2026
Prosecution Insights