Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/14/2026 has been entered.
Response to Arguments
3. Applicant’s arguments filed on 05/14/2026, with respect to the 35 U.S.C. 103 rejection claims 1-7 and 15-20 are rejected under U.S. Publication No. 20220222650 hereinafter Shauh in view of U.S. Publication No. US 11810123 hereinafter Douglas, and further in view of U.S. Publication No. 20210209593 hereinafter Trujillo have been fully considered. However, upon further consideration, a new ground(s) of rejection is made in view of amended claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
4. Claims 1-6 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable
over U.S. Publication No. 20220222650 hereinafter Shauh in view of U.S. Publication
No. US 11810123 hereinafter Douglas, and further in view of U.S. Publication No.
7861924 hereinafter Block.
As per claim 1, Shauh discloses:
A system for processing access by database query (para 0061 "With the
account number or bill transaction number or product number or product name,
IVR system 310 can retrieve the payment amount due from the customer billing
database of the merchant. "), comprising:
at least one processor; a communication interface communicatively
coupled to the at least one processor; and a memory device storing executable
code that, when executed, causes the at least one processor (para 0169
"Turning now to FIG. 16, an example of functional modules in IVR/Chatbot
system 310, 510 and mobile payment server 325, 525 is illustrated. Mobile
payment server 325, 525, for example, includes an IVR/Chatbot system interface
module 610 which receives the mobile number, payment amount, etc. from
IVR/Chatbot system 310, 510 and sends authorization indication with approval or
reject to IVR/Chatbot system 310, 510. A mobile transaction processing
module 612 receives the mobile number, transaction information, e.g. payment
amount, currency code, merchant Id, merchant supported brand networks,
merchant name, summary of bill or purchase information, transaction identity,
message authentication code, etc. Mobile transaction processing
module 612 includes a mobile payment processor 613 and a URL
generator 614 which generates an URL link with the transaction information or
payment information.")
to: receive, across a communication channel, a request comprising user
information (Fig. 7, para 0061, The "preamble" is customer 15 making a
purchase request 30 of merchant 14 through a clerk. Customer 15 then provides
a mobile identity 32 of mobile device 20 as a purchase ID for verification of
purchase. In the present embodiment, mobile payment system 300 replaces
merchant clerk 14 of mobile payment system 10 with IVR system 310. IVR
system 310 receives an account number, bill transaction number, product
number or product name of purchase (for example the shipping address is in the
account number) in voice signals or telephone keypad tones from customer's
phone device 322.")
based on the user information, query a database (para 0061 "With the
account number or bill transaction number or product number or product name,
IVR system 310 can retrieve the payment amount due from the customer billing
database of the merchant. Thus, the customer "talks" to IVR system 310 instead
of merchant clerk 14. From this point, a mobile payment is made with steps
illustrated in FIG. 7.")
determine a unique identifier corresponding to a user based on a return
from the query to the database (Para 0063 "In step 2, IVR system 310 sends
voice signals 342 to customer's phone device 322 requesting the mobile number
for customer mobile device 320 capable of the mobile payment, e.g. "Please tell
me your mobile number of mobile payment or enter in the telephone keypad.
Para 0065 "In step 4, IVR system 310 sends 346 the mobile number received in
step 3 and payment amount to mobile payment server 325 as payment
information. Other information can be included in payment information, e.g.
merchant name, summary of bill or purchase information.");
using the unique identifier, transmit instructions to a user device
associated with the user, the instructions configured to cause the user device to
process the request (para 0066 "In step 5, mobile payment
server 325 creates 348 a URL (Uniform Resource Locator) link that identifies
mobile payment server 325. The URL link also includes transaction information
embedded therein, which can include, for example, transaction identity (TID),
and/or payment information (e.g. transaction amount, currency code, merchant
identity, merchant supported brand networks, etc.) and message authentication
code, e.g. a signature using crypto hash, to protect the integrity of the transaction
information." Para 0068 In step 7, customer mobile device 320 receives 352 the
SMS/MMS and the customer actively selects the URL link to trigger a HTTPS
connection setup with mobile payment server 325.");
receive, in response to the transmission, a response from the user device
(para 0069 "In step 8, mobile payment server 325 receives 354 a HTTPS setup
request from customer mobile device 320 which also includes the transaction
information in the URL link." Para 0071 "In step 10, with transaction information
embedded in the URL, the program scripts running in customer mobile
device 320 can retrieve the payment information. Customer mobile
device 320 displays 358 some detailed payment information, e.g. transaction
amount, merchant name, etc., and prompts the customer to authorize the
payment.");
based on the response from the user device, respond to the request by
transmitting a signal over the secure communication channel with instructions to
approve or decline the request (para 0073 "In step 12, customer mobile
device 320 sends payment response 362 to mobile payment server 325. The
payment response includes encrypted payment data which includes payment
token, payment amount, currency code, merchant identity, cryptogram of card
verification, etc." Para 0076 “In step 15, mobile payment server 325 sends 368 an authorization indication to customer mobile device 320 to indicate the results, e.g. approval or rejection.")
Shauh does not disclose:
secure communication channel
wherein the primary cardholder is approving or declining the request; [[and ]] wherein the request that is approved or declined is generated by a second user; and wherein the primary cardholder receives the request indirectly from a computing device comprising a card reader via an intermediary system.)
Douglas discloses:
secure communication channel (Col. 9 lines 33-51 "When the card
account holder/user scans, swipes or inserts a credit card having an EMV
number at a payment terminal machine associated with the transaction
administrator, the transaction data processing system 110 uses the hash
information to encrypt the EMV number at 2200, and transmits it to the
administrator data processing system 140 of the account administrator. In
response to consent of the user that the bank account information associated
with the credit card will be shared with the transaction administrator, the
transaction data processing system 110, at 2300, sends a provisioning request
to the administrator data processing system 140.)
Therefore, it would have been obvious to one of ordinary skill in the art
before the effective filing date of the claimed invention to modify the method for
making a mobile payment request of Shauh to include secure communication
channel, as taught by Douglas.
The motivation would have been to establish a secure communication channel to conduct mobile banking transactions by mobile device in a secure manner.
Shauh in view of Douglas does not disclose:
wherein the primary cardholder is approving or declining the request; wherein the request that is approved or declined is generated by a second user; and wherein the primary cardholder receives the request indirectly from a computing device comprising a card reader via an intermediary system
Block discloses:
wherein the primary cardholder is approving or declining the request, wherein the request that is approved or declined is generated by a second user (Col. 31 Lines 38-49 “ In a second example, a member (e.g., a male) may share access to an account (such as with a spouse) and it can sometimes happen that the location of the designated cell phone and an ATM location may not coincide. Therefore, the member may select a notification option which causes the service provider to notify the cell phone holder via a text message on the cell phone that "A transaction was just requested against your account at the ATM located at Wisconsin and M streets." Many methods of informing the holder that they have a text message can be used. For example, an audible (ring) or vibratory notification can be used. Additionally, messages other than in text format (e.g., a voice message) can be used.” Col. 31 Line 58- Col. 32 Line 3 “In an exemplary embodiment of the security system, a selectable option permits the cell phone holder to grant permission for the requested ATM transaction (e.g., by the spouse) to be remotely authorized. Permission can be granted by the security system to allow the ATM transaction to proceed upon receiving a consent from the designated cell phone. Consent can be automatically granted upon the system receiving a call from the designated cell phone to a certain phone number (or code) within a certain amount of time. For example, a person may initiate a consent call after verifying that their spouse is trying to use the ATM. The consent call phone number (or consent code or password) is also selectable by a member of the fraud prevention system.”);
and wherein the primary cardholder receives the request indirectly from a computing device comprising a card reader via an intermediary system (Fig. 22, Col. 22 Lines 9-24 “An exemplary method of operation of a fraud prevention service will now be explained with reference to FIG. 22. As shown, the system arrangement 400 includes ATMs 402, 404, 406, an ATM host 410 in communication with the ATMs, a cell phone locator system 412 in communication with the host, and a member's cell phone 408. An ATM 402 receives user identification data from a customer. The identification data may be received during a transaction request. The identification can be in the form of a name, account number, PIN, code, password, data sequence, biometric data, or some other information linking a person to an account. The identification can be input or provided by the customer to the ATM 402, such as from a card or a biometric type of input (iris scan, fingerprint, etc.). Alternatively, the identification may be determined from some other customer input or a customer item read by the ATM 402.” Col. 31 Lines 50-57 “If the location and/or timing of the requested ATM transaction is suspicious to the member then he can further investigate. For example, he may call his spouse for verification. If necessary, he can notify the ATM's bank and/or the police. Alternatively, the host (or the security service) may be programmed to notify proper authorities of a potential fraud in progress at the particular ATM Thus, the scenario is cardholder/fraud prevention-centric”).
Therefore, it would have been obvious to one of ordinary skill in the art
before the effective filing date of the claimed invention to modify the method for
making a mobile payment request of Shauh in view of Douglas to include
wherein the primary cardholder is approving or declining the request; wherein the request that is approved or declined is generated by a second user; and wherein the primary cardholder receives the request indirectly from a computing device comprising a card reader via an intermediary system, as taught by Block.
The motivation would have been to verify a transaction made by a second
user by contacting an authorized user.
As per claim 2, Shauh in view of Douglas and Block discloses:
The system for processing access by database query according to claim
1, the user device is a mobile device; and the user information comprises at least
one of the users account number, credit card number or debit card number,
transaction ID, and mobile device number (Shauh para 0072 "In step 11,
customer mobile device 320 receives the customer authorization 360 for the
payment using a password, PIN number, biometric input, e.g. fingerprint, facial
recognition, or other security methods. The downloaded program scripts can
detect the corresponding mobile wallet provider and use the corresponding API
of the mobile wallet to request the mobile payment core of customer mobile
device 320 to return the encrypted payment data. For example, the program
script downloaded from the URL link can detect the presence of each mobile
wallet and call the associated API. The encrypted payment data can include
payment token (i.e. substituted or virtual credit or debit card number, or device
PAN, namely Primary Account Number), payment amount, currency code,
merchant identity, cryptogram of card verification, etc. The API may require input
of payment information, e.g. payment amount, currency code, merchant identity,
etc. This is the reasons this payment information needs to download to customer
mobile device 320 in step 6 or step 9.").
As per claim 3, Shauh in view of Douglas and Block discloses:
The system for processing access by database query according to claim
1, wherein the transmitted instructions include a first specified passcode sent to a
communication interface of the user device via a first text message (Douglas
Col. 9 Line 62-Col. 10 Line 13 " At 2500, the administrator data processing
system 140 may transmit an authentication request to the user device to
authenticate the user/cardholder. The authentication request may include a text
message including a one-time code. In response, the user may enter some
credentials through the user device, such as the one-time code, a personal
identification code or number (PIN) associated with the credit card, and/or
biometric data of the user (e.g., finger prints, facial picture, voice, and the like).
At 2600, the user device transmits an authentication response including the
entered credentials to the administrator data processing system 140. The
entered credentials may be encrypted for security, for example, by the hash
information and/or any suitable encryption methods/algorithms. In some
embodiments, the bank account holder may set information/data sharing
preferences to give the bank account holder control of what gets shared. For
example, different merchants may be allowed for sharing different levels of bank
account information/data." Although Shauh discloses message authentication code in paragraph 0066, Douglas discloses sending a first a first specified passcode sent to a communication interface of the user device via a first text message. The motivation would have been to establish a secure communication channel to conduct mobile banking transactions by mobile device in a secure manner).
As per claim 4, Shauh in view of Douglas and Block discloses:
The system for processing access by database query according to claim
3, wherein the response that is received includes an input of a second specified
passcode via a second text message that is received via the communication
interface (Douglas Col. 9 Line 62-Col. 10 Line 13 "At 2500, the administrator
data processing system 140 may transmit an authentication request to the user
device to authenticate the user/cardholder. The authentication request may
include a text message including a one-time code. In response, the user may
enter some credentials through the user device, such as the one-time code, a
personal identification code or number (PIN) associated with the credit card,
and/or biometric data of the user (e.g., finger prints, facial picture, voice, and the
like). At 2600, the user device transmits an authentication response including the
entered credentials to the administrator data processing system 140. The
entered credentials may be encrypted for security, for example, by the hash
information and/or any suitable encryption methods/algorithms. In some
embodiments, the bank account holder may set information/data sharing
preferences to give the bank account holder control of what gets shared. For
example, different merchants may be allowed for sharing different levels of bank
account information/data." Although Shauh discloses message authentication
code in paragraph 0066, Douglas discloses sending a second a second
specified passcode sent to a communication interface of the user device
via a first text message. The motivation would have been to establish
a secure communication channel to conduct mobile banking transactions
by mobile device in a secure manner).
As per claim 5, Shauh in view of Douglas and Block discloses:
The system for processing access by database query according to claim
4, wherein a verification process is employed to determine if the first specified
passcode sent to the user device matches the second specified passcode
received as part of the response and provide a notification to the user device that
the request was approved (Douglas Col. 19 Lines 24-52 “For example, the
administrator data processing system may send to the user device
a text message including a one-time code and ask the user to enter the one-
time code, the administrator data processing system may require the user to call
a specific phone number from the user device, the administrator data processing
system may require the user to login to the credit card account from the user
device, and/or the administrator data processing system may ask the user to
enter a PIN, a passcode, a password, a biometric datum, etc. through the user
device. At S260, the account administrator data processing system transmits to
the user device a message comprising a request for confirmation that the
account provisioning information should be provisioned to the transaction data
processing system. In some embodiments, the message may include
the transaction data processing system and/or its associated administrators. At
S270, the administrator data processing system receives from the user device a
confirmation response including permission to provision the transaction data
processing system with the account provisioning information of the user account.
In some embodiments, this response may include limitations on the provisioning
information to be shared. At S280, the administrator data processing system
transmits the account provisioning information to the transaction data processing
system. At S290, the account administrator data processing system receives
from the transaction data processing system, a notification indicating a
successful provision result" Although Shauh discloses message authentication code in paragraph 0066, Douglas discloses sending a second a second specified passcode sent to a communication interface of the user device via a first text message. The motivation would have been to establish a secure communication channel to conduct mobile banking transactions by mobile device in a secure manner).
As per claim 6, Shauh in view of Douglas and Block discloses:
The system for processing access by database query according to claim
5, wherein the request is declined if the first specified passcode sent to the user
device does not match the second specified passcode received as part of the
response (Douglas Col. 9 Line 62-Col. 10 Line 13 and Col. 19 Lines 24-52
" At 2500, the administrator data processing system 140 may transmit an
authentication request to the user device to authenticate the user/cardholder.
The authentication request may include a text message including a one-time
code. In response, the user may enter some credentials through the user device,
such as the one-time code, a personal identification code or number (PIN)
associated with the credit card, and/or biometric data of the user (e.g., finger
prints, facial picture, voice, and the like)" It is well known within the art without
undue experimentation if two one-time passcodes fail to match, that
communication/verification process ends.” Although Shauh discloses
message authentication code in paragraph 0066, Douglas discloses
sending a first a first specified passcode sent to a communication interface
of the user device via a first text message. The motivation would have been
to establish a secure communication channel to conduct mobile banking
transactions by mobile device in a secure manner).
As per claim 15, the implementation of the system of claim 1 will execute
the computer-implemented method of claim 1. The claim is analyzed with
respect to claim 1.
As per claim 16, the claim is analyzed with respect to claim 3.
As per claim 17, the claim is analyzed with respect to claim 4.
As per claim 18, the claim is analyzed with respect to claim 5.
As per claim 19, the claim is analyzed with respect to claim 6.
5. Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over
Shauh in view of Douglas, and further in view of Block, and further in
view of U.S. Publication No. 20200279235 hereinafter Booth.
As per claim 7, Shauh in view of Douglas and Block discloses:
The system for processing access by database query according to claim 5
(Shauh para 0061),
Shauh in view of Douglas and Block does not disclose:
wherein the instructions to decline the request are included in the
transmitted signal if the second specified passcode is not received from the user
device
Booth discloses:
wherein the instructions to decline the request are included in the
transmitted signal if the second specified passcode is not received from the user
device (para 0082 "In various embodiments, in response to the authentication
challenge response failing validation (e.g., the authentication challenge response
did not match the authentication challenge), decisioning processor 130 may be
configured to transmit a second authentication challenge (or any other desired
number of authentication challenges) before declining the payment request (e.g.,
step 407)
Therefore, it would have been obvious to one of ordinary skill in the art
before the effective filing date of the claimed invention to modify the method for
making a mobile payment request of Shauh in view of Douglas and Block to
include wherein the instructions to decline the request are included in the
transmitted signal if the second specified passcode is not received from the user
device, as taught by Booth.
The motivation would have been to provide an option to decline a payment
request.
As per claim 20, the claim is analyzed with respect to claim 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-6pm.
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, Philip Chea can be reached at 5712723951. 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.
/GARY S GRACIA/Primary Examiner, Art Unit 2499
Prosecution Insights