DETAILED ACTION
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 November 13, 2025 (“November 2025 Response”). The November 2025 Response contained, inter alia, claim amendments (“November 2025 Claim Amendments”) and “REMARKS” (“November 2025 Remarks”).
Claims 1, 4-5, 7, 10-11, 13-17, and 19-23 are currently pending and have been examined.
Claim Rejections - 35 USC § 112 (pre-AIA ), 2nd paragraph
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 14-17, 19, and 23 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
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.”
Claims 15-17, 19, and 23 include all of the limitations of Claim 14; therefore, they are rejected for the same reasons given for Claim 14 above.
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 [and registering the mobile device to the same user as the first unit](“[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;
registering the mobile device to the same user as the first unit; 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
registering the mobile device (user device 1) 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]); and
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 Lam in the Lam/Imai combination, the feature of registering the mobile device 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 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 claims1. 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 November 2025 Remarks have been fully considered and addressed below.
On page 8, Applicant argues that “the Imai reference does not teach what is alleged and does not employ a transaction code that is based on the detail information….” 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. Therefore, Applicant’s argument is found unpersuasive.
On page 9, Applicant argues the combination of Lam and Imai citing “using…[Lam’s] one-time passcodes with those of Imai” “because Lam would not work for its intended purpose or its fundamental purpose would be changed” and because it “would render the authentication data in Lam duplicative or useless.” The Examiner does not find the argument persuasive because Applicant does not explain how it would “not work for its intended purpose or its fundamental purpose would be changed” or how it “would render the authentication data in Lam duplicative or useless.” As explained 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. As such, Applicant’s argument is not persuasive.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Philpott et al. (US 8,433,914 B1)(Provisional Application No. 61/307,893 filed on Feb. 25, 2010) which discloses “[a] transaction system combats malware and phishing-based MitM attacks on transaction processing systems by using digital signatures to integrity-protect the user-verified transaction data. With this system, a user submits a transaction from a client device (e.g., desktop web browser) over a communications channel to a server device, such as a transaction server. Before accepting the transaction, the transaction server securely delivers all relevant transaction data to a second device (e.g., the signing device), such as a smart phone, in the possession of the user. The signing device has its own distinct communication channel with the server device. The user verifies the data and the signing device creates a digital signature value for the transaction. The user submits the signature to the transaction server to confirm the transaction with the transaction server.” (Abstract).
Applicant’s amendment filed on November 13, 2025 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 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 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.