DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending and have been examined.
Claim Objections
Claim 1 is objected to because of the following informalities: the limitation “transmitting… an output being a command correlated…” appears to be grammatically incorrect. Applicant seems to be establishing the output and defining it at the same time which results in a confusing wording (not necessarily arising to the level of indefiniteness). Applicant respectfully suggests “transmitting… an output, wherein the output is a command…” Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claim 1; this claim is indefinite for the following reason:
The limitation “and directing the automated transaction machine to dispense the amount associated with the financial transaction” is indefinite because it is unclear what the scope of the claim means. It is unclear whether this portion of the claim defines/modifies the scope of the term “an output” or whether this is an actual claimed step in the method. It is unclear whether the scope of the claim is 1) transmitting.. an output… wherein the output directs the ATM to dispense… OR 2) directing the ATM to dispense is the next/final, actively claimed step in the methodology. For the sake of compact prosecution, based on the formatting of this portion of the claim 1, and the scope of claims 2 and 3; Examiner will interpret this limitation this language as further defining “an output” as transmitting.. an output… wherein the output directs the ATM to dispense…
Claims 2-13 are rejected due to their dependence on claim 1.
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 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite the abstract idea which may be summarized as executing payment processing.
Step 1 Analysis
Applicants claims are directed to a process (claims 1-20).
Step 2A, Prong 1 Analysis
Claim 1
Claims 1 recites the abstract idea/limitations of:
receiving a definition of at least one transaction function from a user that is physically remote,
the at least one transaction function including at least (i) an account associated with a financial transaction and (ii) an amount associated with the financial transaction and (iii) an alphanumeric designation of the at least one transaction function;
storing the definition of the at least one transaction function;
receiving the alphanumeric designation of the at least one transaction function;
retrieving the at least one transaction function in response to said receiving the alphanumeric designation;
and transmitting an output being a command correlated at least in part to the definition of the at least one transaction function and directing the automated transaction machine to dispense the amount associated with the financial transaction.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. The claims recite performing a commercial transaction and the risk mitigation associated with the performance (the matching of the transaction function). If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as a fundamental economic practice and commercial/legal interactions, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite to an abstract idea. The recited system components are just applying generic computer components to the recited abstract limitations.
Claim 14
Claims 14 recites the abstract idea/limitations of:
receiving from a user a financial transaction defined by a plurality of variables including at least the nature of the financial transaction, the account against which the financial transaction will be recorded, and the amount of the financial transaction, and an associated alphanumeric designation;
storing the financial transaction and associated alphanumeric designation;
subsequent to the storing, receiving a request to initiate the financial transaction based at least in part on user identifiable data and the associated alphanumeric sequence;
and initiating the financial transaction.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. The claims recite performing a commercial transaction and the risk mitigation associated with the performance (the use of the transaction function/alphanumeric designation). If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as a fundamental economic practice and commercial/legal interactions, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite to an abstract idea. The recited system components are just applying generic computer components to the recited abstract limitations.
Claim 18
Claims 18 recites the abstract idea/limitations of:
initiating a user session based upon user identifiable data;
subsequent to the initiating, receiving from the user an alphanumeric sequence;
transmitting the alphanumeric sequence;
and receiving confirmation of an association between the alphanumeric sequence and a financial transaction defined by a plurality of variables including at least the nature of the financial transaction, the account against which the financial transaction will be recorded, and the amount of the financial transaction.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. The claims recite performing a commercial transaction and the risk mitigation associated with the performance (the use of the transaction function/alphanumeric designation). If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as a fundamental economic practice and commercial/legal interactions, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite to an abstract idea. The recited system components are just applying generic computer components to the recited abstract limitations.
Step 2A, Prong 2 Analysis
This judicial exception is not integrated into a practical application because the claims only recites system components for implementing the abstract idea and extra-solution activity. The claims recite the additional limitations of a financial transaction processing system, a server computing device, a memory, an automated transaction machine, a server; and they are recited at a high level of generality. These system components amount to no more than mere instructions to apply the exception using a generic computer. These limitations generally link the use of the judicial exception to a technological environment and are not indicative of integration into a practical application. The limitations of:
receiving a definition of at least one transaction function;
storing the definition of the at least one transaction function;
receiving the alphanumeric designation of the at least one transaction function;
retrieving the at least one transaction function;
and transmitting an output;
receiving from a user a financial transaction defined by a plurality of variables;
storing the financial transaction and associated alphanumeric designation;
receiving a request to initiate the financial transaction;
receiving from the user an alphanumeric sequence;
transmitting the alphanumeric sequence;
and receiving confirmation of an association between the alphanumeric sequence and a financial transaction;
as drafted are insignificant extra-solution activity. These steps are mere data gathering and storing of information and do not qualify as a practical application of the judicial exception. See MPEP 2106.05(g). These additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims as a whole do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea without a practical application.
Step 2B Analysis
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a financial transaction processing system, a server computing device, a memory, an automated transaction machine, a server; amount to no more than mere components to implement the judicial exception using a generic computer components. For the same reason these elements are not sufficient to provide an inventive concept. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The limitations of:
receiving a definition of at least one transaction function;
storing the definition of the at least one transaction function;
receiving the alphanumeric designation of the at least one transaction function;
retrieving the at least one transaction function;
and transmitting an output;
receiving from a user a financial transaction defined by a plurality of variables;
storing the financial transaction and associated alphanumeric designation;
receiving a request to initiate the financial transaction;
receiving from the user an alphanumeric sequence;
transmitting the alphanumeric sequence;
and receiving confirmation of an association between the alphanumeric sequence and a financial transaction;
as drafted are insignificant extra-solution activity. These steps are mere data gathering and storing and do not qualify as significantly more than the judicial exception as they are well-understood, routine, and conventional activity when clamed in a merely generic manner (as it is here). See MPEP 2106.05(g). See Applicant’s specification paragraphs [0035-0047], [0081-0083], about implementation of the abstract idea using general purpose or special purpose computing devices; and MPEP 2106.05(f) where applying a computer as a tool is not indicative of significantly more. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Thus Applicant’s claims are not patent eligible.
Dependent Claims Analysis
As for dependent claims 2, 3, 6-10, 12, 13, 15-17, and 19, these claims recite limitations that further define the same abstract idea noted in independent claims 1, 14, and 18. Therefore, claims 2, 3, 6-10, 12, 13, 15-17, and 19 are considered ineligible subject matter for the reasons given above.
As for dependent claims 4, 5, 11, 13, and 20 these claims recite limitations that further define the same abstract idea noted in independent claims 1 and 18. In addition, the recite the additional elements of
receiving authentication data;
receiving, the alphanumeric designation;
receiving a confirmation of the authentication data;
receiving the alphanumeric designation of the at least one transaction function;
receiving a deposit in accordance with the pre-defined financial transaction;
This is considered insignificant extra-solution activity, because as drafted the limitations are mere data gathering and storing of information. These limitations do not qualify as a practical application of the judicial exception or significantly more. See MPEP 2106.05(g). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Therefore, claims 4, 5, 11, 13, and 20 are considered ineligible subject matter.
Thus, the dependent claims 2-13, 15-17, 19 and 20 are not patent-eligible either.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kuchenski, US Patent Application No 2018/0047000.
Regarding claim 1;
A method of operating a financial transaction processing system comprising:
receiving, at a server computing device of the financial transaction processing system, a definition of at least one transaction function from a user that is physically remote from the server computing device, the at least one transaction function including at least (i) an account associated with a financial transaction and (ii) an amount associated with the financial transaction and (iii) an alphanumeric designation of the at least one transaction function;
See Kuchenski [0033] FIG. 1 is a flow diagram showing an embodiment of how a user can create a mobile-wallet account by using a computing device to input a plurality of required data sets. A mobile-wallet account is a collection of one or more electronic data sets that include bank-account data sets and personal-information data sets.
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
[0036] FIG. 3 is a flow diagram showing an embodiment of how a financial-transaction token is created by a server and then sent electronically from that server to the currency recipient via the currency recipient's computing device. Block 300 shows that server 16 (FIG. 9) receives financial-transaction data set from computing device 4 (FIG. 9). In block 302, server 16 uses computer-readable logic to generate financial-transaction token e.g., an alphanumeric character string that identifies and is associated with financial-transaction data set
storing, in a memory of the financial transaction processing system, by the server computing device, the definition of the at least one transaction function;
See Kuchenski [0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
[0036] FIG. 3 is a flow diagram showing an embodiment of how a financial-transaction token is created by a server and then sent electronically from that server to the currency recipient via the currency recipient's computing device. Block 300 shows that server 16 (FIG. 9) receives financial-transaction data set from computing device 4 (FIG. 9). In block 302, server 16 uses computer-readable logic to generate financial-transaction token e.g., an alphanumeric character string that identifies and is associated with financial-transaction data set. In block 304, a financial-transaction token is sent from server 16 (FIG. 9) to the currency recipient's computing device. The financial-transaction token is used at a later time by the currency recipient to help initiate a pre-staged financial transaction; currency recipient initiates the pre-staged financial transaction by inputting the financial-transaction token into an ATM configured to receive tokens. The financial-transaction token figuratively acts as a key that enables ATM 50 to access and receive portions of both a financial-transaction data set and a mobile-wallet account.
receiving, at the server computing device, from an automated transaction machine of the financial transaction processing system, the alphanumeric designation of the at least one transaction function;
See Kuchenski [0038] FIG. 4 is a flow diagram showing an embodiment of how i) the cash recipient receives and uses a financial-transaction token to initiate a pre-staged financial transaction at ATM 50 that is configured to a receive token, and ii) how upon authenticating a token received from ATM 50, server 16 (FIG. 9) retrieves and forwards portions of a mobile-wallet account; portions of a financial transaction dataset; and a user-identification token to ATM 50. Upon receiving: the mobile-wallet account; portions of the financial transaction dataset; and the user-identification token, ATM 50 generates an ATM transmission message using those three items and forwards both the ATM transmission message and the user-identification token to ATM driver 60. ATM driver 60 directs the ATM transmission message to the appropriate EFT network 58.
[0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display.
retrieving, from the memory of the financial transaction processing system, with the server computing device, the at least one transaction function in response to said receiving the alphanumeric designation; and
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display.
transmitting, with the server computing device, to the automated transaction machine, an output being a command correlated at least in part to the definition of the at least one transaction function and directing the automated transaction machine to dispense the amount associated with the financial transaction.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display.
[0041] Block 410 shows that in response to receiving portions of a mobile-wallet account, portions of a financial-transaction dataset, and a user-identification token associated with a financial-transaction token from server 16 (FIG. 9), ATM 50 (FIG. 9) generates an ATM transmission message by executing an algorithm on portions of mobile-wallet account, portions of a financial-transaction dataset, and a user-identification token. Upon generating an ATM transmission message, ATM 50 (FIG. 9) then continues to execute the pre-staged financial transaction. ATM 50 (FIG. 9) does this by sending an ATM transmission message in combination with a unique transaction identifier to ATM driver 60 (FIG. 9).
Regarding claim 2;
The method of claim 1 further comprising:
executing the command with the automated transaction machine.
See Kuchenski [0039] In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
Regarding claim 3;
The method of claim 2 wherein said executing further comprises:
dispensing, with the automated transaction machine, the amount associated with the financial transaction in response said receiving the command and without the user indicating the amount of currency to the automated transaction machine.
See Kuchenski [0007] An embodiment enables a first party to pre-stage a one-time ATM transaction to dispense a fixed amount of currency, wherein the pre-staged transaction can be initiated by a second party by inputting a token, e.g., an alphanumeric character string, into an ATM configured to receive it. Because the second party only needs a token and an ATM configured to receive the token to initiate the pre-staged transaction, this embodiment allows an ATM transaction to be initiated by a party without using a debit card or mobile phone.
[0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
Regarding claim 4;
The method of claim 1 further comprising:
receiving, with the automated transaction machine, authentication data associated with the user one of prior to said receiving the alphanumeric designation of the at least one transaction function at the server computing device.
See Kuchenski [0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
Regarding claim 5;
The method of claim 4 wherein said receiving the alphanumeric designation of the at least one transaction function at the server computing device further comprises:
receiving, at the server computing device, from the automated transaction machine of the financial transaction processing system, the alphanumeric designation of the at least one transaction function and the authentication data.
See Kuchenski [0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
Regarding claim 6;
The method of claim 5 further comprising:
comparing, with the server computing device, after said retrieving, the amount associated with the financial transaction and the account associated with the financial transaction prior to said transmitting the output to the automated transaction machine with the server computing device, wherein said transmitting is responsive in part to said comparing.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
Regarding claim 7;
The method of claim 1 further comprising:
soliciting, with the automated transaction machine, authentication data and the alphanumeric designation of the at least one transaction function from the user prior to said receiving the alphanumeric designation of the at least one transaction function at the server computing device; and
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
executing the command with the automated transaction machine after said soliciting and without receiving other information from the user after said receiving the alphanumeric designation of the at least one transaction function at the server computing device.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
Regarding claim 8;
The method of claim 7 wherein said soliciting is further defined as:
soliciting, with the automated transaction machine, concurrently, the authentication data and the alphanumeric designation of the at least one transaction function from the user prior to said receiving the alphanumeric designation of the at least one transaction function at the server computing device.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
Regarding claim 9;
The method of claim 8 wherein said soliciting is further defined as:
soliciting, with the automated transaction machine, concurrently through a first screen displayed by a display screen of the automated transaction machine, the authentication data and the alphanumeric designation of the at least one transaction function from the user prior to said receiving the alphanumeric designation of the at least one transaction function at the server computing device.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
Regarding claim 10;
The method of claim 7 wherein said soliciting is further defined as:
soliciting, with the automated transaction machine, only the authentication data and the alphanumeric designation of the at least one transaction function from the user prior to said receiving the alphanumeric designation of the at least one transaction function at the server computing device.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
Regarding claim 11;
The method of claim 1 further comprising:
soliciting, with the automated transaction machine, authentication data from the user prior to said receiving the alphanumeric designation of the at least one transaction function at the server computing device;
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
receiving, with the automated transaction machine, after said soliciting, a confirmation of the authentication data from the server computing device;
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
receiving, with the automated transaction machine, after said receiving the authentication data from the server computing device, the alphanumeric designation of the at least one transaction function from the user; and
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
executing the command with the automated transaction machine after said receiving the alphanumeric designation of the at least one transaction function from the user without receiving an amount of currency from the user.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
[0007] An embodiment enables a first party to pre-stage a one-time ATM transaction to dispense a fixed amount of currency, wherein the pre-staged transaction can be initiated by a second party by inputting a token, e.g., an alphanumeric character string, into an ATM configured to receive it. Because the second party only needs a token and an ATM configured to receive the token to initiate the pre-staged transaction, this embodiment allows an ATM transaction to be initiated by a party without using a debit card or mobile phone.
Regarding claim 12;
The method of claim 11 wherein said executing is further defined as:
executing the command with the automated transaction machine after said receiving the alphanumeric designation of the at least one transaction function from the user without receiving information from the user other than the authentication data and the alphanumeric designation of the at least one transaction function.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
[0007] An embodiment enables a first party to pre-stage a one-time ATM transaction to dispense a fixed amount of currency, wherein the pre-staged transaction can be initiated by a second party by inputting a token, e.g., an alphanumeric character string, into an ATM configured to receive it. Because the second party only needs a token and an ATM configured to receive the token to initiate the pre-staged transaction, this embodiment allows an ATM transaction to be initiated by a party without using a debit card or mobile phone.
Regarding claim 13;
The method of claim 1 further comprising:
soliciting, with the automated transaction machine, authentication data from the user prior to said receiving the alphanumeric designation of the at least one transaction function at the server computing device;
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
receiving, with the automated transaction machine, after said soliciting, a confirmation of the authentication data from the server computing device; and
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
displaying, with a display screen of the automated transaction machine, in response to said receiving the confirmation, a plurality of graphical user interface elements each representing one of a plurality of transactions, wherein one of the plurality of graphical user interface elements permits entry of the alphanumeric designation of the at least one transaction function.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
Regarding claim 14;
A method of operating a server for performing a financial transaction comprising:
receiving from a user a financial transaction defined by a plurality of variables including at least the nature of the financial transaction, the account against which the financial transaction will be recorded, and the amount of the financial transaction, and an associated alphanumeric designation;
See Kuchenski [0033] FIG. 1 is a flow diagram showing an embodiment of how a user can create a mobile-wallet account by using a computing device to input a plurality of required data sets. A mobile-wallet account is a collection of one or more electronic data sets that include bank-account data sets and personal-information data sets.
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
[0036] FIG. 3 is a flow diagram showing an embodiment of how a financial-transaction token is created by a server and then sent electronically from that server to the currency recipient via the currency recipient's computing device. Block 300 shows that server 16 (FIG. 9) receives financial-transaction data set from computing device 4 (FIG. 9). In block 302, server 16 uses computer-readable logic to generate financial-transaction token e.g., an alphanumeric character string that identifies and is associated with financial-transaction data set
storing the financial transaction and associated alphanumeric designation in memory;
See Kuchenski [0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
[0036] FIG. 3 is a flow diagram showing an embodiment of how a financial-transaction token is created by a server and then sent electronically from that server to the currency recipient via the currency recipient's computing device. Block 300 shows that server 16 (FIG. 9) receives financial-transaction data set from computing device 4 (FIG. 9). In block 302, server 16 uses computer-readable logic to generate financial-transaction token e.g., an alphanumeric character string that identifies and is associated with financial-transaction data set. In block 304, a financial-transaction token is sent from server 16 (FIG. 9) to the currency recipient's computing device. The financial-transaction token is used at a later time by the currency recipient to help initiate a pre-staged financial transaction; currency recipient initiates the pre-staged financial transaction by inputting the financial-transaction token into an ATM configured to receive tokens. The financial-transaction token figuratively acts as a key that enables ATM 50 to access and receive portions of both a financial-transaction data set and a mobile-wallet account.
subsequent to the storing, receiving a request from an automated transaction machine (ATM) to initiate the financial transaction based at least in part on user identifiable data and the associated alphanumeric sequence; and
See Kuchenski [0038] FIG. 4 is a flow diagram showing an embodiment of how i) the cash recipient receives and uses a financial-transaction token to initiate a pre-staged financial transaction at ATM 50 that is configured to a receive token, and ii) how upon authenticating a token received from ATM 50, server 16 (FIG. 9) retrieves and forwards portions of a mobile-wallet account; portions of a financial transaction dataset; and a user-identification token to ATM 50. Upon receiving: the mobile-wallet account; portions of the financial transaction dataset; and the user-identification token, ATM 50 generates an ATM transmission message using those three items and forwards both the ATM transmission message and the user-identification token to ATM driver 60. ATM driver 60 directs the ATM transmission message to the appropriate EFT network 58.
[0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display.
initiating the financial transaction with the server.
See Kuchenski [0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display.
[0041] Block 410 shows that in response to receiving portions of a mobile-wallet account, portions of a financial-transaction dataset, and a user-identification token associated with a financial-transaction token from server 16 (FIG. 9), ATM 50 (FIG. 9) generates an ATM transmission message by executing an algorithm on portions of mobile-wallet account, portions of a financial-transaction dataset, and a user-identification token. Upon generating an ATM transmission message, ATM 50 (FIG. 9) then continues to execute the pre-staged financial transaction. ATM 50 (FIG. 9) does this by sending an ATM transmission message in combination with a unique transaction identifier to ATM driver 60 (FIG. 9).
Regarding claim 15;
The method of claim 14 where the financial transaction includes a withdrawal and where the initiating includes sending a dispense authorization to the ATM.
See Kuchenski [0043] The banking institution, via bank server 72 (FIG. 9), either accepts or rejects the transaction, and if accepted, bank server 72 (FIG. 9) sends an acceptance message to ATM 50 (FIG. 9). In response, ATM 50 (FIG. 9) dispenses a currency amount a to currency recipient via known electronic processing methods. But if the banking institution, via bank server 72, rejects the transaction, bank server 72 sends a rejection message to ATM 50. In response, ATM 50 does not disperse currency to the intended currency recipient and the transaction ends.
Regarding claim 16;
The method of claim 14 where the financial transaction includes a transfer and where the initiating includes sending funds from the account against which the financial transaction will be recorded, to another account against which the transfer will be credited, the other account included in the plurality of variables received from the user.
See Kuchenski [0004] One category of ATM includes machines capable of conducting a wide variety of traditional banking transactions including acceptance of cash and/or checks for deposit, check cashing, and withdrawals/dispensing of cash, also referred to herein as currency or notes.
[0005] Currency/notes, checks and other sheet materials, generally referred to as documents, that are accepted and/or dispensed by an ATM, are typically housed in containers, such as bins or removable cassettes, while documents are stored in the machine. Typically, documents are dispensed from cassettes and presented by an ATM through an aperture or opening in a user interface, typically in the front facing or top of a housing of the ATM. In some ATMs, documents may be accepted through the user interface for deposit and the like and then placed into a cassette.
[0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
Regarding claim 17;
The method of claim 14 where the financial transaction includes crediting funds to the account against which the financial transaction will be recorded, and the method further including receiving verification from the ATM of a deposit, the amount of the deposit included in the plurality of variables received from the user.
See Kuchenski [0005] Currency/notes, checks and other sheet materials, generally referred to as documents, that are accepted and/or dispensed by an ATM, are typically housed in containers, such as bins or removable cassettes, while documents are stored in the machine. Typically, documents are dispensed from cassettes and presented by an ATM through an aperture or opening in a user interface, typically in the front facing or top of a housing of the ATM. In some ATMs, documents may be accepted through the user interface for deposit and the like and then placed into a cassette.
Regarding claim 18;
A method of operating an automated transaction machine (ATM) for performing a financial transaction comprising:
initiating a user session based upon user identifiable data;
See Kuchenski [0033] FIG. 1 is a flow diagram showing an embodiment of how a user can create a mobile-wallet account by using a computing device to input a plurality of required data sets. A mobile-wallet account is a collection of one or more electronic data sets that include bank-account data sets and personal-information data sets.
[0035] Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
[0036] FIG. 3 is a flow diagram showing an embodiment of how a financial-transaction token is created by a server and then sent electronically from that server to the currency recipient via the currency recipient's computing device. Block 300 shows that server 16 (FIG. 9) receives financial-transaction data set from computing device 4 (FIG. 9). In block 302, server 16 uses computer-readable logic to generate financial-transaction token e.g., an alphanumeric character string that identifies and is associated with financial-transaction data set
subsequent to the initiating, receiving from the user an alphanumeric sequence;
transmitting the alphanumeric sequence to a server associated with a financial institution; and
See Kuchenski [0036] FIG. 3 is a flow diagram showing an embodiment of how a financial-transaction token is created by a server and then sent electronically from that server to the currency recipient via the currency recipient's computing device. Block 300 shows that server 16 (FIG. 9) receives financial-transaction data set from computing device 4 (FIG. 9). In block 302, server 16 uses computer-readable logic to generate financial-transaction token e.g., an alphanumeric character string that identifies and is associated with financial-transaction data set
receiving from the server confirmation of an association between the alphanumeric sequence and a financial transaction defined by a plurality of variables including at least the nature of the financial transaction, the account against which the financial transaction will be recorded, and the amount of the financial transaction.
See Kuchenski [0038] FIG. 4 is a flow diagram showing an embodiment of how i) the cash recipient receives and uses a financial-transaction token to initiate a pre-staged financial transaction at ATM 50 that is configured to a receive token, and ii) how upon authenticating a token received from ATM 50, server 16 (FIG. 9) retrieves and forwards portions of a mobile-wallet account; portions of a financial transaction dataset; and a user-identification token to ATM 50. Upon receiving: the mobile-wallet account; portions of the financial transaction dataset; and the user-identification token, ATM 50 generates an ATM transmission message using those three items and forwards both the ATM transmission message and the user-identification token to ATM driver 60. ATM driver 60 directs the ATM transmission message to the appropriate EFT network 58.
[0039] Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display.
Regarding claim 19;
The method of claim 18 further comprising:
dispensing cash in accordance with the pre-defined financial transaction.
See Kuchenski [0043] The banking institution, via bank server 72 (FIG. 9), either accepts or rejects the transaction, and if accepted, bank server 72 (FIG. 9) sends an acceptance message to ATM 50 (FIG. 9). In response, ATM 50 (FIG. 9) dispenses a currency amount a to currency recipient via known electronic processing methods. But if the banking institution, via bank server 72, rejects the transaction, bank server 72 sends a rejection message to ATM 50. In response, ATM 50 does not disperse currency to the intended currency recipient and the transaction ends.
Regarding claim 20;
The method of claim 18 further comprising:
receiving a deposit in accordance with the pre-defined financial transaction.
See Kuchenski [0005] Currency/notes, checks and other sheet materials, generally referred to as documents, that are accepted and/or dispensed by an ATM, are typically housed in containers, such as bins or removable cassettes, while documents are stored in the machine. Typically, documents are dispensed from cassettes and presented by an ATM through an aperture or opening in a user interface, typically in the front facing or top of a housing of the ATM. In some ATMs, documents may be accepted through the user interface for deposit and the like and then placed into a cassette.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
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 M 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.
/MICHAEL J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights