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 .
Response to Arguments
2. Applicant’s arguments filed on 01/30/2026, with respect to the 35 U.S.C. 103 rejection of claims 1-7 and 15-20 as being unpatentable over U.S. Publication No. 20220222650 hereinafter Shauh in view of U.S. Publication No. US 11810123 hereinafter Douglas 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.
3. Claims 1-7 and 15-20 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. 20210209593 hereinafter Trujillo.
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 user is a primary cardholder; 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.
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 user is a primary cardholder; 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
Trujillo discloses:
wherein the user is a primary cardholder; 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 (para 0031 “In step 202, the companion cardholder 235 may request limited transactional authorization from the credit card account associated with the primary cardholder 225. For example, the companion cardholder 235 may request permission from the primary cardholder 225 prior to making any transactions using the credit card account. The request may include a requested amount and/or a period of time for the limited transactional authorization. In some embodiments, the request may further include a requested location at which to perform the transaction, and/or a requested user with which to perform a transaction.” Para 0032 “In some embodiments, the companion cardholder 235 may be prompted to perform an authentication process, e.g., via the companion cardholder device 240 prior to transmitting the request. Such an authentication process may serve to, e.g., verify the identity of the companion cardholder 235. In such embodiments, the companion cardholder 235 may be permitted to transmit the request after a successful authentication. It is understood that the authentication process may be performed utilizing any appropriate authentication method. For example, an authentication process may include a password-enabled authentication process and/or a biometric authentication performed through fingerprint sensing, facial recognition, iris scanning, or the like.” Para 0034 “The primary cardholder 225 may then receive the request via a user interface on the primary cardholder device 230, as will be described in further detail below with reference to FIG. 4A. In some embodiments, a verification process may be performed to determine the authenticity of the received request. For example, a request transmitted by the companion cardholder 235 via the companion cardholder device 240 may include the digital signature as described above. In such instances, the received digital signature may need to be verified.” Para 0035 “In step 204, the primary cardholder 225 may modify, approve, or deny the request made by the companion cardholder 235 (or, as described previously, may grant authorization to the companion cardholder independent of a request). For example, the primary cardholder 225 may modify the requested amount, period of time, and/or location (e.g., the requested third user 145) for the limited transactional authorization requested by the companion cardholder 235.”)
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 user is a primary cardholder; 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, as taught by Trujillo.
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 Trujillo 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 Trujillo 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 Trujillo 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 Trujillo 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 Trujillo 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.
4. 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 Trujillo, and further in
view of U.S. Publication No. 20200279235 hereinafter Booth.
As per claim 7, Shauh in view of Douglas and Trujillo discloses:
The system for processing access by database query according to claim 5
(Shauh para 0061),
Shauh in view of Douglas and Trujillo 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 Trujillo 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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