DETAILED ACTION
Continued Examination Under 37 CFR 1.114
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 June 23, 2026 has been entered.
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Acknowledgements
This Office Action is in response to the response filed on June 23, 2026 (“June 2026 Response”). The June 2026 Response contained, inter alia, claim amendments (“June 2026 Claim Amendments”) and “REMARKS” (“June 2026 Remarks”).
Claims 1, 4-5, 7, 10-11, 13-17, and 19-23 are currently pending and have been examined.
Response to Amendment
In the June 2026 Claim Amendments and with respect to Claim 14, Applicant deleted the words “another device that is registered to the same user as” in line 10 of the claim. Applicant also deleted the word “a” and added the word “the” in line 25 of the claim.
37 C.F.R. §1.121 as discussed in MPEP §714 II. C. sets forth the manner of making claim amendments. In particular, MPEP §714 II. C. (B) states that amended claims must be presented with markings to indicate the changes that have been made relative to the immediate prior version.
Because Applicant amended Claim 14 by adding and deleting words to the claim, and because 37 C.F.R. §1.121 (as discussed in MPEP §714 II. C.) requires “[t]he changes in any amended claim must be shown by strike-through (for deleted matter) or underlining (for added matter) with 2 exceptions: (1) for deletion of five or fewer consecutive characters, double brackets may be used (e.g., [[eroor]]); (2) if strike-through cannot be easily perceived (e.g., deletion of number “4” or certain punctuation marks), double brackets must be used (e.g., [[4]]”, and Applicant did not use the requisite markings, the June 2026 Claim Amendments are a Non-Compliant Amendment. See MPEP §714 II. F.
Because this application is not in condition for allowance, because the failure to use the requisite markings noted above is considered an error that would not otherwise prevent the subsequent examination of this application, to show a good faith effort by the Examiner to advance prosecution, and in accordance with the spirit of the guidance set forth in the USPTO memorandum1 by Focarino, Peggy, tilted “Non-Compliant Amendment,”2 the Examiner hereby deems (for this one time only) the June 2026 Claim Amendments compliant.
However, Applicant is given actual notice that should any future amendment be non-compliant because the amendment does not (for any reason) comply with 37 C.F.R. §1.121 (as discussed in MPEP §714), the amendment will be considered a non-compliant amendment and the Examiner will issue a “Notice of Non-Compliant Amendment (37 CFR 1.121)” See USPTO Form PTOL-324.
Because the Examiner has (for this one time only) deemed the June 2026 Claim Amendments compliant, an Office Action on the merits is set forth below.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Claims 1, 7, 14-15, and 20-23 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lam et al. (WO 2010/128451 A2)(“Lam”) in view of Imai et al. (WO 2009/149723 A1)(“Imai”) and further in view of Moas et al. (US 2010/0180328 A1)(“Moas”).
As to Claim 1, Lam discloses a method carried out by a first unit (user computing device 130), a server (server 110) and a second unit (mobile device 150) for providing multi-factor transaction verification (“An application hosted in a server is in communication with a user computing device via a first communication network and the server application is in further communication with a user mobile device via a second communication network.” Abstract, “METHODS OF ROBUST MULTI-FACTOR AUTHENTICATION AND AUTHORIZATION AND SYSTEMS THEREOF,” Title) comprising:
initiating an electronic transaction over a first channel (first communication network 120) by the first unit and the server [after a first level of user authentication] (“[t]he user computing device 130 exchanges data with the server 110 via first communication network 120.” page 10, lines 32-33, page 11, line 1);
providing to the server by the first unit, transaction information provided by a user, that comprises detail information known to the user about the transaction (“[t]he authorization process 300 begins with step 310 in which the user computing device 130 captures the transaction data entered by the user and compiles said transaction data into a predetermined format readable by the server application 115. In the next step 320, the server application 115 parses the received transaction data…” page 18, lines 10-17);
perform a second level user authentication of the user [after the first level of user authentication] by:
during the electronic transaction over the first channel, receiving from the server, by the second unit, a transaction confirmation request for the transaction (“server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “…the user reads the…transaction summary displayed on the…mobile device 150…” Page 18, lines 31-33, “In applications that call for more stringent authorization requirements and hence higher level of assurance, the server application 115 may act in accordance with predefined security policies to demand both the user mobile and computing devices 150 & 130 to return appropriate responses when the user mobile device 150 is challenged (322). A flag or identifier in the challenge code may be used to instruct the user mobile device 150 to compute and return a response accordingly. ” page 19, lines 17-25) and receiving from the server the [same] transaction information provided by the user that comprises [the detail] information about the transaction, via a second channel (a second communication network 140), different from the first channel, based on the transaction (“…a user submitting some transactions data from the user computing device to the server application.” page 6, lines 7-9, “server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “a user mobile device 150 which exchanges data with the server 110 via a second communication network 140” page 11, lines 1-3);
providing through a user interface, by the second unit [that is registered to the same user as the first unit], the received transaction information from the server, without user intervention, that comprises [a replication of the detail] information about the transaction previously provided by the user for evaluation by the user of the second unit (“…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “…the user reads the…transaction summary displayed on the…mobile device 150” page 18, lines 31-33);
requesting by the second unit, in response to the transaction confirmation request, confirmation of the transaction by the user of the second unit (“server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “In applications that call for more stringent authorization requirements and hence higher level of assurance, the server application 115 may act in accordance with predefined security policies to demand both the user mobile and computing devices 150 & 130 to return appropriate responses when the user mobile device 150 is challenged (322). A flag or identifier in the challenge code may be used to instruct the user mobile device 150 to compute and return a response accordingly.” page 19, lines 17-25, “[t]he user mobile device then computes a unique response to the challenge when instructed by the user after inspecting the received…transaction summary displayed on the…mobile device” page 6, lines 13-17);
generating, by the second unit, a transaction confirmation code (“compute a response,” page 7, lines 5-6) using the received transaction information [that is the same transaction information provided to the server by the user] that was presented in the user interface without user intervention, in response to a transaction confirmation by the user of the second unit (“he may instruct the user mobile device 150…” page 19, lines 1-3, “the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9, “[t]he user mobile device then computes a unique response to the challenge when instructed by the user after inspecting the received…transaction summary displayed on the…mobile device” page 6, lines 13-17), wherein the second unit generates the transaction confirmation code by electronically signing the received transaction information from the server using at least one of: a shared secret key assigned to the second unit and to the server, or by using an asymmetric cryptographic algorithm (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9);
sending, by the second unit, the transaction confirmation code that is generated by the second unit using the received transaction information from the server, to the server for verification (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9, “server application verifies the response...” page 8, lines 25-26, “…user mobile device 150…returning the response to the server application 115” page 12, lines 29-33);
[in response to a shared secret key being used to generate the transaction confirmation code], generating, by the server, an expected transaction confirmation code for the second unit (“In the next step 350, the server application 115 verifies the received digital signature… This is possible as the corresponding user public key is kept by the server application…” page 20, lines 4-9, “The matching user public cryptographic key is kept by the server application for use to verify said digital signature” page 20, lines 30-33) based on the transaction information from the first unit (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9), that comprises detail information known to the user about the transaction (“[t]he user mobile device then computes a unique response to the challenge when instructed by the user after inspecting the received…transaction summary displayed on the…mobile device” page 6, lines 13-17)[comparing, by the server, the expected transaction confirmation code with the received transaction confirmation code from the second unit and] verifying, by the server, whether the transaction should be allowed (“In the next step 350, the server application 115 verifies the received digital signature…” page 20, lines 5-6, “The server application 115 determines whether said verification process is successful in step 360…” page 20, lines 14-16);
or
in response to using an asymmetric cryptographic algorithm to generate the transaction confirmation code (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9), verifying by the server, whether the transaction should be allowed (“In the next step 350, the server application 115 verifies the received digital signature…” page 20, lines 5-6, “The server application 115 determines whether said verification process is successful in step 360…” page 20, lines 14-16).
Lam does not directly disclose
after a first level of user authentication; and
the transaction information received from the server at the second unit, is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server; and
the second unit is registered to the same user as the first unit; and
in response to a shared secret key being used to generate the transaction confirmation code, comparing, by the server, the expected transaction confirmation code with the received transaction confirmation code from the second unit.
Imai teaches
after a first level of user authentication (“The user employs data from a first set of login/authentication information received from a bank to log into the banking website.” page 8, second paragraph, “In a next step…can be initiated by using the PC 4 to transfer the transaction data via the Internet to the bank.” page 8, third paragraph); and
the transaction information received from the server at the second unit (end-user’s mobile phone 6), is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server (“the bank or, more precisely, a bank transaction server,” page 5, third paragraph)(“In a next step…can be initiated by using the PC 4 to transfer the transaction data via the Internet to the bank.” page 8, third paragraph, “After having received the transaction data, the bank sends the transaction data to the end-user’s mobile phone 6 for authentication” “The mobile phone 6 displays the transaction, i.e. all important transaction information including (in case of a money transfer) the recipient, the amount and the account numbers.” page 8, fourth paragraph, “the transaction data may include at least an identification of the recipient of the transfer, the account numbers of the involved parties and the amount of money to be transferred.” page 6, fourth paragraph).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Lam by the features of Imai, and in particular to include in Lam’s initiating of an electronic transaction and performing a second level user authentication, the feature of it being after a first level of user authentication, as taught by Imai, because it would increase the security of the transaction; and to include in Lam’s transaction information received from the server at the second unit, the feature that it is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server, as taught by Imai, because it would enable “the end-user to carefully check all important transaction information before authenticating the transaction” (Imai, page 6, third paragraph), thereby, enhancing the security of the transaction.
Moas teaches
a second unit (user device 1) is registered to the same user as the first unit (“a PC,” [0124])(“Plural communication channels may be provided also by using a different device for transferring some information for the authentication process” [0049], “it will be necessary for the user to register the user device 1 with the authentication server 4 before the authentication process can proceed…” [0086], “it is envisaged that the present invention could be used to separate the channels of communication, so that a mobile telephone for example is the user device having the OTP function but that the transaction is being…on a separate machine (e.g. a PC or shop terminal)” [0124]),
in response to a shared secret key being used to generate the transaction confirmation code (“In the present embodiment the user is assigned or chooses a user identification code, which is an example of a secret key.” “The secret keys are communicated to the authentication server during a registration process.” [0050]), comparing, by the server (“Authentication server,” [0077]), an expected transaction confirmation code (“Authentication server…to generate an OTP,” [0077]) with the received transaction confirmation code (“OTP is supplied to authentication server.” “For example, in a mobile phone based implementation, both the transaction number and OTP may be communicated via SMS.” [0076]) from the second unit (“Authentication server uses the OTP function associated with this user to generate an OTP using the PIN stored at registration and the transaction number sent to the user device in respect of this transaction” [0077], “Server compares this OTP with the one supplied with the user and, if they match, allows the transaction to complete.” [0078]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai combination by the features of Moas, and in particular to include in Lam in the Lam/Imai combination, the feature of the second unit is registered to the same user as the first unit, as taught by Moas, because it would help to prevent unauthorized individuals from gaining access to the transaction; and to include in the Lam/Imai combination, the feature of in response to a shared secret key being used to generate the transaction confirmation code, comparing, by the server, the expected transaction confirmation code with the received transaction confirmation code from the second unit, as taught by Moas, because it would help to ensure the authenticity of the transaction, and it would provide added assurance that the received transaction confirmation code is legitimate.
As to Claim 7, Lam discloses an electronic transaction system (“A system for user authentication and transaction authorization is provided.” page 8, lines 11-12) comprising:
a server (server 110) operative to provide a transaction session and communicate via a second channel (a second communication network 140) with a second unit (mobile device 150)(“…a user submitting some transactions data from the user computing device to the server application.” page 6, lines 7-9, “server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “a user mobile device 150 which exchanges data with the server 110 via a second communication network 140” page 11, lines 1-3);;
a first unit (user computing device 130) operative to initiate an electronic transaction with the server, via a first channel (first communication network 120), [after a first level of user authentication affirmation] (“[t]he user computing device 130 exchanges data with the server 110 via first communication network 120.” page 10, lines 32-33, page 11, line 1) and provide transaction information known to the user to the server (“[t]he authorization process 300 begins with step 310 in which the user computing device 130 captures the transaction data entered by the user and compiles said transaction data into a predetermined format readable by the server application 115.” page 18, lines 10-17), the transaction information being provided by a user [after the first level authentication affirmation] comprising detail information about the transaction (“[t]he authorization process 300 begins with step 310 in which the user computing device 130 captures the transaction data entered by the user and compiles said transaction data into a predetermined format readable by the server application 115. In the next step 320, the server application 115 parses the received transaction data…” page 18, lines 10-17);
the second unit, [that is registered to the same user as the first unit,] operative to perform second level authentication of the user [after the first level user authentication affirmation] by:
receiving during the transaction over the first channel, a transaction confirmation request for the electronic transaction (“server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “…the user reads the…transaction summary displayed on the…mobile device 150…” Page 18, lines 31-33, “In applications that call for more stringent authorization requirements and hence higher level of assurance, the server application 115 may act in accordance with predefined security policies to demand both the user mobile and computing devices 150 & 130 to return appropriate responses when the user mobile device 150 is challenged (322). A flag or identifier in the challenge code may be used to instruct the user mobile device 150 to compute and return a response accordingly.” page 19, lines 17-25) and the [same] transaction information that comprises [the detail] information about the transaction via the second channel, based on the electronic transaction from the server (“…a user submitting some transactions data from the user computing device to the server application.” page 6, lines 7-9, “server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “a user mobile device 150 which exchanges data with the server 110 via a second communication network 140” page 11, lines 1-3);
providing through a user interface, the received transaction information from the server, without user intervention, that comprises [a replication of the detail] information previously provided by the user about the transaction from the server for evaluation by the user of the second unit (“…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “…the user reads the…transaction summary displayed on the…mobile device 150” page 18, lines 31-33);
requesting, in response to the transaction confirmation request, confirmation of the transaction by the user (“server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “In applications that call for more stringent authorization requirements and hence higher level of assurance, the server application 115 may act in accordance with predefined security policies to demand both the user mobile and computing devices 150 & 130 to return appropriate responses when the user mobile device 150 is challenged (322). A flag or identifier in the challenge code may be used to instruct the user mobile device 150 to compute and return a response accordingly.” page 19, lines 17-25, “[t]he user mobile device then computes a unique response to the challenge when instructed by the user after inspecting the received…transaction summary displayed on the…mobile device” page 6, lines 13-17);
generating a transaction confirmation code (“compute a response,” page 7, lines 5-6) using the received transaction information [that is the same transaction information provided to the server by the user] that was presented in the user interface without user intervention, in response to a transaction confirmation by the user (“he may instruct the user mobile device 150…” page 19, lines1-3, “the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9, “[t]he user mobile device then computes a unique response to the challenge when instructed by the user after inspecting the received…transaction summary displayed on the…mobile device” page 6, lines 13-17), wherein generating the transaction confirmation code is done by electronically signing the received transaction information from the server [using at least: a shared secret key assigned to the second unit and to the server] (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9);
sending the transaction confirmation code that is generated by the second unit using the received transaction information from the server, to the server for verification (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9, “server application verifies the response...” page 8, lines 25-26, “…user mobile device 150…returning the response to the server application 115” page 12, lines 29-33); and
wherein the server is operative to cryptographically generate an expected transaction confirmation code for the second unit (“In the next step 350, the server application 115 verifies the received digital signature… This is possible as the corresponding user public key is kept by the server application…” page 20, lines 4-9, “The matching user public cryptographic key is kept by the server application for use to verify said digital signature” page 20, lines 30-33) based on the transaction information from the first unit, that comprises detail information known to the user about the transaction (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9) [and compare the expected transaction confirmation code with the received transaction confirmation code from the second unit] to verify whether the transaction should be allowed (“In the next step 350, the server application 115 verifies the received digital signature…” page 20, lines 5-6, “The server application 115 determines whether said verification process is successful in step 360…” page 20, lines 14-16).
Lam does not directly disclose
after a first level of user authentication affirmation; and
the transaction information received from the server at the second unit, is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server; and
the second unit is registered to the same user as the first unit;
wherein the generating is: using at least: a shared secret key assigned to the second unit and to the server; and
comparing the expected transaction confirmation code with the received transaction confirmation code from the second unit.
Imai teaches
after a first level of user authentication affirmation (“The user employs data from a first set of login/authentication information received from a bank to log into the banking website.” page 8, second paragraph, “In a next step the online transaction…can be initiated by using the PC 4 to transfer the transaction data via the Internet to the bank.” page 8, third paragraph); and
the transaction information received from the server at the second unit (end-user’s mobile phone 6), is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server (“the bank or, more precisely, a bank transaction server,” page 5, third paragraph)(“In a next step…can be initiated by using the PC 4 to transfer the transaction data via the Internet to the bank.” page 8, third paragraph, “After having received the transaction data, the bank sends the transaction data to the end-user’s mobile phone 6 for authentication” “The mobile phone 6 displays the transaction, i.e. all important transaction information including (in case of a money transfer) the recipient, the amount and the account numbers.” page 8, fourth paragraph, “the transaction data may include at least an identification of the recipient of the transfer, the account numbers of the involved parties and the amount of money to be transferred.” page 6, fourth paragraph).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Lam by the features of Imai, and in particular to include in Lam’s initiating of an electronic transaction and performing a second level user authentication, the feature of it being after a first level of user authentication affirmation, as taught by Imai, because it would increase the security of the transaction; and to include in Lam’s transaction information received from the server at the second unit, the feature that it is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server, as taught by Imai, because it would enable “the end-user to carefully check all important transaction information before authenticating the transaction” (Imai, page 6, third paragraph), thereby, enhancing the security of the transaction.
Moas teaches
a second unit (user device 1) is registered to the same user as the first unit (“a PC,” [0124])(“Plural communication channels may be provided also by using a different device for transferring some information for the authentication process” [0049], “it will be necessary for the user to register the user device 1 with the authentication server 4 before the authentication process can proceed…” [0086], “it is envisaged that the present invention could be used to separate the channels of communication, so that a mobile telephone for example is the user device having the OTP function but that the transaction is being…on a separate machine (e.g. a PC or shop terminal)” [0124]),
generating a transaction confirmation code (OTP,” [0075]) using at least: a shared secret key (“In the present embodiment the user is assigned or chooses a user identification code, which is an example of a secret key. Typically, the user identification code is a Personal Identification Number (PIN).” “The secret keys are communicated to the authentication server during a registration process.” [0050]) assigned to the second unit and to the server (“OTP application uses PIN and transaction code to generate an OTP,” [0075]);
comparing an expected transaction confirmation code (“Authentication server…to generate an OTP,” [0077]) with the received transaction confirmation code (“OTP is supplied to authentication server.” “For example, in a mobile phone based implementation, both the transaction number and OTP may be communicated via SMS.” [0076]) from the second unit (“Authentication server uses the OTP function associated with this user to generate an OTP using the PIN stored at registration and the transaction number sent to the user device in respect of this transaction” [0077], “Server compares this OTP with the one supplied with the user and, if they match, allows the transaction to complete.” [0078]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai combination by the features of Moas, and in particular to include in Lam in the Lam/Imai combination, the feature of the second unit is registered to the same user as the first unit, as taught by Moas, because it would help to prevent unauthorized individuals from gaining access to the transaction; to include in the generating of a transaction confirmation of the Lam/Imai combination, the feature of using at least: a shared secret key assigned to the second unit and to the server, as taught by Moas, because it would help to ensure the authenticity of the transaction; and to include in the Lam/Imai combination, the feature of comparing the expected transaction confirmation code with the received transaction confirmation code from the second unit, as taught by Moas, because it would provide added assurance that the received transaction confirmation code is legitimate.
As to Claim 14, Lam discloses a wireless mobile device (“the user mobile device may be a cellular telephony device capable of exchanging data with the server application” page 8, lines 6-9) comprising:
a wireless transceiver (“the user mobile device may be a cellular telephony device capable of exchanging data with the server application” page 8, lines 6-9);
one or more processors operatively coupled to the wireless transceiver (“the user mobile device 150 is capable of providing an environment for executing the response computation securely, as well as safekeeping all the secret parameters and cryptographic keys associated with said computation. Said secure environment may be provided by a software, firmware or hardware-based…” page 13, lines 10-17);
memory comprising executable instructions that when executed cause the one or more processors (“the user mobile device 150 is capable of providing an environment for executing the response computation securely, as well as safekeeping all the secret parameters and cryptographic keys associated with said computation. Said secure environment may be provided by a software, firmware or hardware-based…” page 13, lines 10-17) to perform second level authentication of a user [after a first level of user authentication] occurs by:
receiving from the transceiver, a transaction confirmation request for an electronic transaction (“server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “…the user reads the…transaction summary displayed on the…mobile device 150…” Page 18, lines 31-33, “In applications that call for more stringent authorization requirements and hence higher level of assurance, the server application 115 may act in accordance with predefined security policies to demand both the user mobile and computing devices 150 & 130 to return appropriate responses when the user mobile device 150 is challenged (322). A flag or identifier in the challenge code may be used to instruct the user mobile device 150 to compute and return a response accordingly. ” page 19, lines 17-25) and transaction information from a server (server 110)(“…a user submitting some transactions data from the user computing device to the server application.” page 6, lines 7-9, “server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “a user mobile device 150 which exchanges data with the server 110 via a second communication network 140” page 11, lines 1-3), provided by a user [after the first level of user authentication] that comprises [detail] information known to the user about the transaction, based on the electronic transaction between a first unit (user computing device 130) and the server (“[t]he authorization process 300 begins with step 310 in which the user computing device 130 captures the transaction data entered by the user and compiles said transaction data into a predetermined format readable by the server application 115. In the next step 320, the server application 115 parses the received transaction data…” page 18, lines 10-17, (“…a user submitting some transactions data from the user computing device to the server application.” page 6, lines 7-9, “server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “a user mobile device 150 which exchanges data with the server 110 via a second communication network 140” page 11, lines 1-3);
providing through a user interface, the same received transaction information, without user intervention, that comprises [a replication of detail] information about the transaction for evaluation by the user of the mobile device (“…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “…the user reads the…transaction summary displayed on the…mobile device 150” page 18, lines 31-33);
requesting, in response to the transaction confirmation request, confirmation of the transaction by the user of the mobile device (“server application sends…” page 6, L.11-12, “…proceeds to send…a transaction summary and a challenge to the user mobile device 150” page 18, lines 26-29, “In applications that call for more stringent authorization requirements and hence higher level of assurance, the server application 115 may act in accordance with predefined security policies to demand both the user mobile and computing devices 150 & 130 to return appropriate responses when the user mobile device 150 is challenged (322). A flag or identifier in the challenge code may be used to instruct the user mobile device 150 to compute and return a response accordingly.” page 19, lines 17-25, “[t]he user mobile device then computes a unique response to the challenge when instructed by the user after inspecting the received…transaction summary displayed on the…mobile device” page 6, lines 13-17);
generating a transaction confirmation code (“compute a response,” page 7, lines 5-6) using the received transaction information [that is the same transaction information provided to the server by the user] through the wireless mobile device that was presented in the user interface without user intervention, in response to a transaction confirmation by the user of the mobile device (“he may instruct the user mobile device 150…” page 19, lines1-3, “the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9, “[t]he user mobile device then computes a unique response to the challenge when instructed by the user after inspecting the received…transaction summary displayed on the…mobile device” page 6, lines 13-17), wherein generating the transaction confirmation code is done by electronically signing the received transaction information [using at least: a shared secret key assigned to the mobile device and to a server] (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9); and
sending, via the wireless transceiver, the transaction confirmation code that is generated using the received transaction information to the web server for verification (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9, “server application verifies the response...” page 8, lines 25-26, “…user mobile device 150…returning the response to the server application 115” page 12, lines 29-33).
Lam does not directly disclose
after a first level of user authentication; and
the transaction information received from the server, is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server; and
wherein the generating of the transaction confirmation code is done using at least: a shared secret key assigned to the mobile device and to a server.
Imai teaches
after a first level of user authentication (“The user employs data from a first set of login/authentication information received from a bank to log into the banking website.” page 8, second paragraph, “In a next step…can be initiated by using the PC 4 to transfer the transaction data via the Internet to the bank.” page 8, third paragraph); and
the transaction information received from the server at the second unit (end-user’s mobile phone 6), is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server (“the bank or, more precisely, a bank transaction server,” page 5, third paragraph)(“In a next step…can be initiated by using the PC 4 to transfer the transaction data via the Internet to the bank.” page 8, third paragraph, “After having received the transaction data, the bank sends the transaction data to the end-user’s mobile phone 6 for authentication” “The mobile phone 6 displays the transaction, i.e. all important transaction information including (in case of a money transfer) the recipient, the amount and the account numbers.” page 8, fourth paragraph, “the transaction data may include at least an identification of the recipient of the transfer, the account numbers of the involved parties and the amount of money to be transferred.” page 6, fourth paragraph).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Lam by the features of Imai, and in particular to include in Lam’s initiating of an electronic transaction and performing a second level user authentication, the feature of it being after a first level of user authentication, as taught by Imai, because it would increase the security of the transaction; and to include in Lam’s transaction information received from the server, the feature that it is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server, as taught by Imai, because it would enable “the end-user to carefully check all important transaction information before authenticating the transaction” (Imai, page 6, third paragraph), thereby, enhancing the security of the transaction.
Moas teaches
generating a transaction confirmation code (OTP,” [0075]) using at least: a shared secret key (“In the present embodiment the user is assigned or chooses a user identification code, which is an example of a secret key. Typically, the user identification code is a Personal Identification Number (PIN).” “The secret keys are communicated to the authentication server during a registration process.” [0050]) assigned to the mobile device and to a server (“OTP application uses PIN and transaction code to generate an OTP,” [0075]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai combination by the features of Moas, and in particular to include in the generating of the transaction confirmation code of Lam/Imai combination, the feature of using at least a shared secret key assigned to the mobile device and to a server, as taught by Moas, because it would help to ensure the authenticity of the transaction.
As to Claim 15, the Lam/Imai/Moas combination discloses as discussed above.
Lam further discloses wherein the one or more processors are operative to generate the transaction confirmation code by electronically signing the received transaction information using a cryptographic key associated with the mobile device (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9); wherein the cryptographic key is at least one of the shared secret key assigned to the mobile device and to the server, or a private signing key of a public/private key pair used in an asymmetric cryptographic algorithm (“the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9).
As to Claim 20, the Lam/Imai/Moas combination discloses as discussed above. Lam further discloses wherein providing through a user interface, by the second unit, the received transaction information comprises providing the replication of the detail information (Imai teaches this feature as discussed above in the rejection of Claim 1: “In a next step…can be initiated by using the PC 4 to transfer the transaction data via the Internet to the bank.” page 8, third paragraph, “After having received the transaction data, the bank sends the transaction data to the end-user’s mobile phone 6 for authentication” page 8, fourth paragraph) in clear text (“send a…transaction summary to the user mobile device 150…the user reads the…transaction summary…” page 18, lines 25-33, page 19, lines 1-4, as such since the user is able to read the transaction summary it is in clear text).
As to Claim 21, the Lam/Imai/Moas combination discloses as discussed above.
Lam does not directly disclose comprising registering a seed with the second unit and wherein generating the transaction confirmation code comprises using the seed and the received transaction information from the server to generate the transaction confirmation code.
Moas teaches registering a seed (“OTP functions can include…embedded hard coded values,” [0096] and [0102], “The OTP function is an algorithm consisting of a random selection of predefined functions,” [0093], wherein the seed is the “embedded hard coded values,” [0102]) with the second unit (“In the case where the OTP application is pre-installed on a user device, the OTP application may need to be registered at the authentication server. Registration can conveniently be performed by using a registration security code provided with the user device when purchased. The security code may be supplied to the authentication server, together with user identification details in order to associate the OTP application (and therefore the OTP function or functions) with the new user.” [0048]) and wherein generating the transaction confirmation code (“OTP” [0053]) comprises using the seed and the received transaction information (“transaction number,” [0052], “The transaction code may be provided to the user device by an SMS message or by any convenient communication channel.” [0087]) from the server (“The transaction code may be provided to the user device by an SMS message or by any convenient communication channel.” [0087]) to generate the transaction confirmation code (“OTP application uses PIN and transaction code to generate an OTP,” [0075]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Moas, and in particular to include in the Lam/Imai/Moas combination, the feature of registering a seed with the second unit and wherein generating the transaction confirmation code comprises using the seed and the received transaction information from the server to generate the transaction confirmation code, as taught by Moas, because it would help to prevent bad actors from reproducing the confirmation code; thereby, reducing the risk of fraudulent transactions.
As to Claim 22, the Lam/Imai/Moas combination discloses as discussed above.
Lam does not directly disclose wherein the second unit comprises a registered seed and wherein generating the transaction confirmation code comprises using the seed and the received transaction information from the server to generate the transaction confirmation code.
Moas teaches the second unit comprises a registered (“In the case where the OTP application is pre-installed on a user device, the OTP application may need to be registered at the authentication server. Registration can conveniently be performed by using a registration security code provided with the user device when purchased. The security code may be supplied to the authentication server, together with user identification details in order to associate the OTP application (and therefore the OTP function or functions) with the new user.” [0048]) seed (“OTP functions can include…embedded hard coded values,” [0096] and [0102], “The OTP function is an algorithm consisting of a random selection of predefined functions,” [0093], wherein the seed is the “embedded hard coded values,” [0102]) and wherein generating the transaction confirmation code (“OTP” [0053]) comprises using the seed and the received transaction information (“transaction number,” [0052], “The transaction code may be provided to the user device by an SMS message or by any convenient communication channel.” [0087]) from the server (“The transaction code may be provided to the user device by an SMS message or by any convenient communication channel.” [0087]) to generate the transaction confirmation code (“OTP application uses PIN and transaction code to generate an OTP,” [0075]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Moas, and in particular to include in the second unit of the Lam/Imai/Moas combination, the feature of a registered seed and wherein generating the transaction confirmation code comprises using the seed and the received transaction information from the server to generate the transaction confirmation code, as taught by Moas, because it would help to prevent bad actors from reproducing the confirmation code; thereby, reducing the risk of fraudulent transactions.
As to Claim 23, the Lam/Imai/Moas combination discloses as discussed above.
Lam does not directly disclose wherein the one or more processors are operative to generate the transaction confirmation code by using a seed registered to the wireless mobile device and using the received transaction information from the server.
Moas teaches the one or more processors are operative to generate the transaction confirmation code (“OTP” [0053]) by using a seed registered (“In the case where the OTP application is pre-installed on a user device, the OTP application may need to be registered at the authentication server. Registration can conveniently be performed by using a registration security code provided with the user device when purchased. The security code may be supplied to the authentication server, together with user identification details in order to associate the OTP application (and therefore the OTP function or functions) with the new user.” [0048]) to the wireless mobile device (“OTP functions can include…embedded hard coded values,” [0096] and [0102], “The OTP function is an algorithm consisting of a random selection of predefined functions,” [0093], wherein the seed is the “embedded hard coded values,” [0102]) and using the received transaction information (“transaction number,” [0052], “The transaction code may be provided to the user device by an SMS message or by any convenient communication channel.” [0087]) from the server (“The transaction code may be provided to the user device by an SMS message or by any convenient communication channel.” [0087])(“OTP application uses PIN and transaction code to generate an OTP,” [0075]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Moas, and in particular to include in the one or more processors of the Lam/Imai/Moas combination, the feature of being operative to generate the transaction confirmation code by using a seed registered to the wireless mobile device and using the received transaction information from the server, as taught by Moas, because it would help to prevent bad actors from reproducing the confirmation code; thereby, reducing the risk of fraudulent transactions.
Claims 4-5, 10-11, and 16-17 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lam in view of Imai in view of Moas and further in view of Smith (US 2010/0191648 A1)(“Smith”).
As to Claim 4, the Lam/Imai/Moas combination discloses as discussed above.
Lam further discloses displaying on the second unit a user interface that visually presents the received transaction information in clear text (“send a…transaction summary to the user mobile device 150…the user reads the…transaction summary…” page 18, lines 25-33, page 19, lines 1-4).
Lam does not directly disclose wherein the user interface comprises controls operable to confirm or cancel the transaction.
Smith teaches wherein the user interface comprises controls operable to confirm or cancel the transaction (see “send,” or “cancel” depicted in Fig.6, see “send,” or “cancel,” depicted in Fig.9, “In the user interface (190), the user may enter the code (193) (e.g., “1”) in the reply message and select the “send” (195) button to confirm the deposit request (or select the “cancel” (197) button to ignore the message and thus block the request).” [0073]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Smith, and in particular to include in the user interface of Lam in the Lam/Imai/Moas combination, the controls operable to confirm or cancel the transaction, as taught by Smith, because it would help the “user to confirm and…to authorize a genuine transaction submitted by the user,” (Lam, page 18, lines 7-9).
As to Claim 5, the Lam/Imai/Moas combination discloses as discussed above.
Lam does not directly disclose sending a transaction cancellation message to the server from the second unit in response to user cancellation of the transaction via a cancellation indication entered by the user of the second unit in response to presentation of the received transaction information from the server.
Smith teaches sending a transaction cancellation message to the server from a second unit (mobile phone 117) in response to user cancellation of the transaction via a cancellation indication entered by the user of the second unit in response to presentation of the received transaction information from the server (see “send,” or “cancel” depicted in Fig.6, see “send,” or “cancel,” depicted in Fig.9, “The text message (191) from the interchange (101) includes the amount requested by the user (e.g., via the user interface (180))” [0072], “In the user interface (190), the user may enter the code (193) (e.g., “1”) in the reply message and select the “send” (195) button to confirm the deposit request (or select the “cancel” (197) button to ignore the message and thus block the request).” [0073]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Smith, and in particular to include in the Lam/Imai/Moas combination, the feature of sending a transaction cancellation message to the server from the second unit in response to user cancellation of the transaction via a cancellation indication entered by the user of the second unit in response to presentation of the received transaction information from the server, as taught by Smith, because it would help the “user to confirm and…to authorize a genuine transaction submitted by the user,” (Lam, page 18, lines 7-9).
As to Claim 10, the Lam/Imai/Moas combination discloses as discussed above.
Lam further discloses wherein the second unit is a wireless mobile unit and is operative to provide a user interface that visually presents the received transaction information in clear text on the user interface (“send a…transaction summary to the user mobile device 150…the user reads the…transaction summary…” page 18, lines 25-33, page 19, lines 1-4).
Lam does not directly disclose wherein the user interface comprises controls operable to confirm or cancel the transaction.
Smith teaches wherein the user interface comprises controls operable to confirm or cancel the transaction (see “send,” or “cancel” depicted in Fig.6, see “send,” or “cancel,” depicted in Fig.9, “In the user interface (190), the user may enter the code (193) (e.g., “1”) in the reply message and select the “send” (195) button to confirm the deposit request (or select the “cancel” (197) button to ignore the message and thus block the request).” [0073]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Smith, and in particular to include in the user interface of Lam in the Lam/Imai/Moas combination, the controls operable to confirm or cancel the transaction, as taught by Smith, because it would help the “user to confirm and…to authorize a genuine transaction submitted by the user,” (Lam, page 18, lines 7-9).
As to Claim 11, the Lam/Imai/Moas/Smith combination discloses as discussed above.
Lam does not directly disclose wherein the second unit is operative to send a transaction cancellation message to the server in response to user cancellation of the transaction via a cancellation indication entered by the user of the second unit in response to presentation of the received transaction information from the server.
Smith teaches wherein the second unit (mobile phone 117) is operative to send a transaction cancellation message to the server in response to user cancellation of the transaction via a cancellation indication entered by the user of the second unit in response to presentation of the received transaction information from the server (see “send,” or “cancel” depicted in Fig.6, see “send,” or “cancel,” depicted in Fig.9, “The text message (191) from the interchange (101) includes the amount requested by the user (e.g., via the user interface (180))” [0072], “In the user interface (190), the user may enter the code (193) (e.g., “1”) in the reply message and select the “send” (195) button to confirm the deposit request (or select the “cancel” (197) button to ignore the message and thus block the request).” [0073]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas/Smith combination by the feature of Smith, and in particular to include in the second unit of Lam in the Lam/Imai/Moas/Smith combination, the feature of being operative to send a transaction cancellation message to the server in response to user cancellation of the transaction via a cancellation indication entered by the user of the second unit in response to presentation of the received transaction information from the server, as taught by Smith, because it would help the “user to confirm and…to authorize a genuine transaction submitted by the user,” (Lam, page 18, lines 7-9).
As to Claim 16, the Lam/Imai/Moas combination discloses as discussed above.
Lam further discloses wherein the one or more processors are operative to display a user interface that visually presents the received transaction information in clear text (“send a…transaction summary to the user mobile device 150…the user reads the…transaction summary…” page 18, lines 25-33, page 19, lines 1-4).
Lam does not directly disclose wherein the user interface comprises controls operable to confirm or cancel the transaction.
Smith teaches wherein the user interface comprises controls operable to confirm or cancel the transaction (see “send,” or “cancel” depicted in Fig.6, see “send,” or “cancel,” depicted in Fig.9, “In the user interface (190), the user may enter the code (193) (e.g., “1”) in the reply message and select the “send” (195) button to confirm the deposit request (or select the “cancel” (197) button to ignore the message and thus block the request).” [0073]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Smith, and in particular to include in the user interface of Lam in the Lam/Imai/Moas combination, the controls operable to confirm or cancel the transaction, as taught by Smith, because it would help the “user to confirm and…to authorize a genuine transaction submitted by the user,” (Lam, page 18, lines 7-9).
As to Claim 17, the Lam/Imai/Moas combination discloses as discussed above.
Lam does not directly disclose wherein the one or more processors are operative to send a transaction cancellation message to a server in response to user cancellation of the transaction via a cancellation indication entered by the user of the device in response to presentation of the received transaction information from the server.
Smith teaches wherein the one or more processors are operative to send a transaction cancellation message to a server in response to user cancellation of the transaction via a cancellation indication entered by the user of the device in response to presentation of the received transaction information from the server (see “send,” or “cancel” depicted in Fig.6, see “send,” or “cancel,” depicted in Fig.9, “The text message (191) from the interchange (101) includes the amount requested by the user (e.g., via the user interface (180))” [0072], “In the user interface (190), the user may enter the code (193) (e.g., “1”) in the reply message and select the “send” (195) button to confirm the deposit request (or select the “cancel” (197) button to ignore the message and thus block the request).” [0073]).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Smith, and in particular to include in the one or more processors of the Lam/Imai/Moas combination, the feature of being operative to send a transaction cancellation message to a server in response to user cancellation of the transaction via a cancellation indication entered by the user of the device in response to presentation of the received transaction information from the server, as taught by Smith, because it would help the “user to confirm and…to authorize a genuine transaction submitted by the user,” (Lam, page 18, lines 7-9).
Claims 13 and 19 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lam in view of Imai in view of Moas and further in view of Meiroff et al. (US 10,719,814 B1)(“Meiroff”).
As to Claim 13, the Lam/Imai/Moas combination discloses as discussed above.
Lam does not directly disclose wherein the second unit is operative to store and display on a user interface, transaction history data corresponding to a plurality of electronic transactions that were confirmed or cancelled using the second unit.
Meiroff teaches a unit is operative to store and display on a user interface, transaction history data corresponding to a plurality of electronic transactions that were confirmed or cancelled using the unit (“Additionally, the system may support sender review of a transaction journal (TJ), that is, a history of recent transactions, including funds transfers made in accordance with the invention. Preferably, the information displayed to the sender as part of the transaction journal would comprise: the transaction date, time and terminal ID; the dispense transaction amount and currency code; the equivalent source transaction amount and currency code; the transaction reference number; and a transaction description (withdrawal, fee or canceled by sender).” C.10, L.6-15).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Meiroff, and in particular to include in the second unit of the Lam/Imai/Moas combination, the feature of being operative to store and display on a user interface, transaction history data corresponding to a plurality of electronic transactions that were confirmed or cancelled using the second unit, as taught by Meiroff, because it would help the “user to confirm…a genuine transaction submitted by the user,” (Lam, page 18, lines 7-9).
As to Claim 19, the Lam/Imai/Moas combination discloses as discussed above.
Lam does not directly disclose wherein the one or more processors are operative to store and display on a user interface, transaction history data corresponding to a plurality of electronic transactions that were confirmed or cancelled using the mobile device.
Meiroff teaches one or more processors are operative to store and display on a user interface, transaction history data corresponding to a plurality of electronic transactions that were confirmed or cancelled using a mobile device (“personal computer,” C.6, L.67)(“Additionally, the system may support sender review of a transaction journal (TJ), that is, a history of recent transactions, including funds transfers made in accordance with the invention. Preferably, the information displayed to the sender as part of the transaction journal would comprise: the transaction date, time and terminal ID; the dispense transaction amount and currency code; the equivalent source transaction amount and currency code; the transaction reference number; and a transaction description (withdrawal, fee or canceled by sender).” C.10, L.6-15).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the Lam/Imai/Moas combination by the feature of Meiroff, and in particular to include in the one or more processors of the Lam/Imai/Moas combination, the feature of being operative to store and display on a user interface, transaction history data corresponding to a plurality of electronic transactions that were confirmed or cancelled using the mobile device, as taught by Meiroff, because it would help the “user to confirm…a genuine transaction submitted by the user,” (Lam, page 18, lines 7-9).
Claim Interpretation
The Examiner hereby adopts the following definitions under the broadest reasonable interpretation standard. In accordance with In re Morris, 127 F.3d 1048, 1056, 44 USPQ2d 1023, 1029 (Fed. Cir. 1997), the Examiner points to these other sources to support interpretation of the claims3. Additionally, these definitions are only a guide to claim terminology since claim terms must be interpreted in context of the surrounding claim language. Finally, the following list is not intended to be exhaustive in any way:
cleartext: “Intelligible data, the semantic content of which is available.” The Authoritative Dictionary of IEEE Standards Terms, 7th Ed., IEEE, Inc., New York, NY, 12/2000.
public key cryptography: n. “See public key encryption.” Computer Dictionary, 5th Edition, Microsoft Press, Redmond, WA, 2002.
public key encryption: n. “An asymmetric scheme that uses a pair of keys for encryption: the public key encrypts data, and a corresponding secret key decrypts it. For digital signatures, the process is reversed: the sender uses the secret key to create a unique electronic number that can be read by anyone possessing the corresponding public key, which verifies that the message is truly from the sender.” Computer Dictionary, 5th Edition, Microsoft Press, Redmond, WA, 2002.
35 USC § 112 (pre-AIA ), 6th paragraph
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
“a first unit operative to initiate an electronic transaction with the server, via a first channel, in response to a first level of user authentication affirmation and provide transaction information known to the user to the server, the transaction information comprising detail information about the transaction” as recited in Claim 7; and
“the second unit, that is registered to the same user as the first unit, operative to perform second level authentication of the user after the first level user authentication affirmation by:
receiving during the transaction over the first channel, a transaction confirmation request for the electronic transaction and the same transaction information that comprises detail information about the transaction via the second channel, based on the electronic transaction from the server;
providing through a user interface, the received transaction information, without user intervention, that comprises a replication of the detail information previously provided by the user about the transaction from the server for evaluation by the user of the second unit;
requesting, in response to the transaction confirmation request, confirmation of the transaction by the user;
generating a transaction confirmation code using the received transaction information that is the same transaction information provided to the server by the user that was presented in the user interface without user intervention, in response to a transaction confirmation by the user, wherein generating the transaction confirmation code is done by electronically signing the received transaction information using at least a shared secret key assigned to the second unit and to the server;
sending the transaction confirmation code that is generated using the received transaction information to the server for verification” as recited in Claim 7.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Response to Arguments
Applicant's arguments filed in the June 2026 Remarks have been fully considered and addressed below.
On page 8 of the June 2026 Remarks, Applicant states:
Claims 14-17, 19, and 23 are rejected under 35 U.S.C. l 12(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Applicant has amended claim 14 to expedite prosecution. The first unit is a different unit from the wireless mobile device and not as interpreted by the Examiner.
Applicant is reminded that the previous rejection stated that:
Claim 14 recites “a wireless mobile device” in line 1, and “based on the electronic transaction between another device that is registered to the same user as a first unit, and the server” at line 10. It is noted that other claims recite “the second unit is registered to the same user as the first unit” wherein the “the second unit is a wireless mobile unit” (e.g.: see Claim 10). As such, it is unclear in Claim 14 if “another device” is referring to the “wireless mobile device” or if it is referring to another device that is not the wireless mobile unit, not the first unit, and not the server. For purposes of applying the prior art, the Examiner will interpret the claimed limitation as “based on the electronic transaction between the wireless mobile device that is registered to the same user as a first unit, and the server.”
Claim 14 recites “the web server” in line 25. However, there is no previous recitation of a web server in the claim. For purposes of applying the prior art, the Examiner will interpret “the web server” in line 25 as “a web server.”
As such, in the last rejection, the Examiner did in fact interpret the first unit as a different unit from the wireless mobile device.
On pages 8-10, Applicant argues that in Lam
…the generated transaction code by the mobile device is not based on ‘the transaction information received from the server…’ However, the Imai reference does not teach what is alleged, and does not employ a transaction code that is based on the detail information and instead teaches merely to display the detail transaction information on the mobile device but not to use the detail transaction information as ‘authentication data’ (i.e., a code).
The Examiner respectfully disagrees. In response to Applicant’s arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). It is first noted that as discussed in the respective rejection, Lam discloses generating, by the second unit, a transaction confirmation code (“compute a response,” page 7, lines 5-6) using the received transaction information [that is the same transaction information provided to the server by the user] that was presented in the user interface without user intervention, in response to a transaction confirmation by the user of the second unit (“he may instruct the user mobile device 150…” page 19, lines 1-3, “the challenge may be a transaction summary and the user mobile device may compute response by signing the received transaction summary with a user private cryptographic key typically used in asymmetric cryptography” page 7, lines 4-9, “[t]he user mobile device then computes a unique response to the challenge when instructed by the user after inspecting the received…transaction summary displayed on the…mobile device” page 6, lines 13-17). While Lam does not explicitly disclose that the “transaction summary” used to generate the transaction confirmation code is the same exact information provided to the server by the user, Imai does explicitly teach that the transaction information received from the server at the second unit (end-user’s mobile phone 6), is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server (“the bank or, more precisely, a bank transaction server,” page 5, third paragraph)(“In a next step…can be initiated by using the PC 4 to transfer the transaction data via the Internet to the bank.” page 8, third paragraph, “After having received the transaction data, the bank sends the transaction data to the end-user’s mobile phone 6 for authentication” “The mobile phone 6 displays the transaction, i.e. all important transaction information including (in case of a money transfer) the recipient, the amount and the account numbers.” page 8, fourth paragraph, “the transaction data may include at least an identification of the recipient of the transfer, the account numbers of the involved parties and the amount of money to be transferred.” page 6, fourth paragraph). As also discussed in the respective rejection, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Lam by the features of Imai, and in particular to include in Lam’s transaction information received from the server at the second unit, the feature that it is the same transaction information provided by the user that comprises the detail information about the transaction, and comprises a replication of the detail information about the transaction previously provided by the user to the server, as taught by Imai, because it would enable “the end-user to carefully check all important transaction information before authenticating the transaction” (Imai, page 6, third paragraph), thereby, enhancing the security of the transaction. Contrary to Applicant’s assertions, Imai is not relied upon to generate the transaction code based on the transaction information as illustrated above. Therefore, Applicant’s argument is found unpersuasive.
On page 10 of the June 2026 Remarks, Applicant argues that one would not combine Lam’s summary of transaction with the one-time passcode of Imai because they both would not work for their intended purposes. However, the rejection does not rely on Imai’s teaching of the one-time passcode. Furthermore, it is noted that the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). Therefore, Applicant’s argument which is based on using Imai’s OTP is found unpersuasive.
On page 10 of the June 2026 Remarks, Applicant argues that Moas does not teach what Lam and Imai lack and also teaches a OTP. The Examiner respectfully disagrees that Lam and Imai are insufficient as applied in the rejections. Thus, the argument is found unpersuasive.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Baharis et al. (US 8,752,125 B2) which discloses “In the first step of the process 301, the user operates their browser 20 typically running on a personal computer to log into their Internet banking website which is hosted by web server 40 by sending data over the Internet 30. Details of a proposed transaction are posted to the web server at step 302--e.g. a proposal to transfer $10,000. These details are then relayed to an Internet-banking system 50 at step 303. At step 304 the Internet banking system confirms that the transaction is allowed. At step 305 the web server serves a new page to the browser for the user to enter an authentication code that is to be generated by the user's mobile phone 10. At step 306, the Internet banking system 50 sends a transaction authentication request to transaction authentication server 60 which constructs an authentication request including a cryptographic hash of the details and sends the authentication as a short message service message (SMS) on a preset port number at step 307. At step 308 the SMS message launches the security application on the user's handset via the java community process standards JSR-118 MIDP-2.0 Push Registry implementation. The security application is a Java 2 Micro Edition (J2ME) java application that has been registered to listen on the preset port. At step 309 the user gives permission to run the security application and is prompted to enter their user PIN and the transaction details are displayed to them. At step 310 the security application then digitally signs the cryptographic hash using the PIN code and a private key stored on the personal mobile terminal to produce a unique numeric code that functions as an authentication code. As the code is using the user's private key, the authentication code can only be provided by someone having access to a personal mobile terminal having the user's software application and the user's PIN. At step 311 the user then having satisfied themselves that the transaction details displayed on the handset are correct enters the authentication code into the entry box on the webpage and submits the funds transfer request. The numeric code is sent at step 312 to the web server and relayed at step 313 to the Internet banking system. At step 314 it is passed to the transaction authentication server which is asked to validate the authentication code. The authentication server 60 replies at step 315 to indicate that the authentication code is correct. A funds transfer confirmation message is sent to the web server at step 316 and then passed to the browser at step 317. At step 318 the security application automatically exits 60 seconds after displaying the authentication code.” (C.5, L.3-46)
The NPL reference titled: “SecureSMSPay: Secure SMS Mobile Payment model” which discloses “Step 5: the payer bank will check the balance of the payer charging account, and then send the encrypted PayConf SMS to the payer’s mobile using the symmetric session key between the payer and his/her bank asking the payer for confirmation (response with Yes/No). Step 6: the J2ME application on the payer's mobile will first prompt the payer to enter the offline PIN to generate the session key from the protected master key on the mobile. Then it will use it to decrypt the PayConf SMS and ask the payer for confirmation. After step 6 is accomplished, the payment response will proceed in the following steps:…” (Page 4).
All claims are identical to or patentably indistinct from, or have unity of invention with claims in the application prior to the entry of the submission under 37 CFR 1.114 (that is, restriction (including a lack of unity of invention) would not be proper) and all claims could have been finally rejected on the grounds and art of record in the next Office action if they had been entered in the application prior to entry under 37 CFR 1.114. Accordingly, THIS ACTION IS MADE FINAL even though it is a first action after the filing of a request for continued examination and the submission under 37 CFR 1.114. See MPEP § 706.07(b). 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 MONICA A MANDEL whose telephone number is (571)270-7046. The examiner can normally be reached Monday and Thursday 10:00 AM-6:00 PM.
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, Ilana Spar can be reached at (571) 270-7537. 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.
/M.A.M/Examiner, Art Unit 3622
/ILANA L SPAR/Supervisory Patent Examiner, Art Unit 3622
1 See MPEP §707.06 “Citation of Decisions, Orders Memorandums, and Notices” expressly authorizing examiners to cite to Commissioner’s Memorandums which have not yet been incorporated into the MPEP.
2 Available at http://www.uspto.gov/patents/law/exam/memoranda.jsp
3 While most definition(s) are cited because these terms are found in the claims, the Examiner may have provided additional definition(s) to help interpret words, phrases, or concepts found in the definitions themselves or in the prior art.
Prosecution Insights