DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
2. The information disclosure statement (IDS) submitted on 11/20/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC §101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
5. In the instant case, claims 1, 15, and 17 are directed “methods and a server computer of variable cross platform interaction continuity”.
6. Claim 1 recites “creating an authorization request message for a transaction using multiple sources”. Specifically, claim 1 recites (abstract ideas emphasized in bold) “receiving, by a server computer from a user device operated by a user, interaction information associated with an interaction, wherein the interaction information comprises a user device identifier, and wherein the server computer stores data relating to a set of user devices of the user, the set of user devices including the user device;
responsive to receiving the interaction information, determining, by the server computer, that additional data from additional user devices are needed to generate an authorization request message for the interaction;
determining, by the server computer, a subset of the set of user devices that can provide the additional data;
generating, by the server computer, an interaction identifier for the interaction;
communicating, by the server computer, with the subset of the user devices using the interaction identifier to obtain the additional data;
generating, by the server computer, the authorization request message comprising the obtained additional data; and
transmitting, by the server computer, the authorization request message to an authorizing entity computer for authorization”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial and legal interactions), and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
7. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “a server computer”, “a user device”, “a set of user devices”, “additional user devices”, “a subset of the set of user devices”, and “an authorizing entity computer” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. With respect to “transmitting, by the server computer, the authorization request message to an authorizing entity computer for authorization” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
8. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform creating an authorization request message for a transaction using multiple sources and/or generally link the abstract idea to a particular technological environment or field of use, they do not improve computer functionality or provide an improvement to another technology or technological field.
9. Hence, claim 1 is not patent eligible.
10. Claims 15 and 17 also recite “creating an authorization request message for a transaction using multiple sources”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial and legal interactions), and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
11. As in the case of claim 1, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claims 15 and 17 such as “a server computer”, “a processor”, “a non-transitory computer readable medium”, “a user device”, “a set of user devices”, “additional user devices”, “a subset of the set of user devices”, and “an authorizing entity computer” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. With respect to “transmitting the authorization request message to an authorizing entity computer for authorization” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
12. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform creating an authorization request message for a transaction using multiple sources and/or generally link the abstract idea to a particular technological environment or field of use, they do not improve computer functionality or provide an improvement to another technology or technological field.
13. Hence, claims 15 and 17 are not patent eligible.
14. The following dependent claims recent additional elements not addressed above:
claim 9 recites “different operating systems”;
claim 10 and 18 recite “a first user device”, “a second user device”, and “a third user device”;
claim 11 recites “a first user device”, “a second user device”, “a third user device”, “a watch”, “a laptop computer”, “a card”, “a mobile phone”, “a desktop browser”, and “a mobile phone application”; and
claim 19 recites “a watch”, “a laptop computer”, “a card”, “a mobile phone”, “a desktop browser”, and “a mobile phone application”.
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the different operating systems, the first user device, the second user device, the third user device, the watch, the laptop computer, the card, the mobile phone, the desktop browser, and the mobile phone application.
Dependent claims 2-14, 16, and 18-20 merely expand upon the abstract ideas of the independent claims and are therefore rejected under the same rationale as claims 1, 15, and 17 respectively.
Conclusion of 35 USC §101
15. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
16. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
17. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
18. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
19. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
20. Claims 1-4, 6-11, and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over US20200005300A1 to Oberheide et al. in view of US9294476B1 to Lurey et al.
21. As per claim 1:
Oberheide et al. discloses the following limitations:
responsive to receiving the interaction information, determining, by the server computer, that additional data from additional user devices are needed to generate an authorization request message for the interaction ([0012] “…the method 100 may also include detecting a need for additional agent verification S140 and/or performing additional agent verification S145…”, [0031] “Additional agent verification may be triggered by a variety of conditions…”, [0036] “…additional agent verification may be triggered by determining that a transaction is suspicious (i.e., the transaction may not be initiated by an authorized entity)…”)
determining, by the server computer, a subset of the set of user devices that can provide the additional data ([0020] “…A rule may be setup for which authority devices to message, in what order, and the timing of the messaging…”, [0015] “… For example, after attempting to contact a primary authority device, the authentication platform may message a secondary authority device for authentication or authorization… Additionally, a first authority device may be registered for authenticating the identity of an agent of the transaction request, and a second authority device may be registered for authorizing an action of an agent…”)
generating, by the server computer, an interaction identifier for the interaction ([0018] “… An initial message may include a unique identifier, which can then be used to retrieve a full message. For example, the SMS message may include a URL link or code which can be used to retrieve a full message from an application or website…”)
communicating, by the server computer, with the subset of the user devices using the interaction identifier to obtain the additional data ([0018] “Step S130, which includes messaging the authority device with the transaction request, functions to push a notification to a secondary device for authentication or authorization…”, [0012] “…receiving an authority agent response from the authority device to the authentication platform…”, [0039] “S145 preferably includes collecting agent verification data directly from authority device users…”, [0020] “…For example, four authority devices may be messaged for authorization and at least three must confirm the transaction for it to be confirmed…”)
generating, by the server computer, the authorization request message comprising the obtained additional data ([claim 1] “…returning to the service provider, from the multi-factor authentication API server, an API response comprising authentication response data relating to the authentication response…”)
transmitting, by the server computer, the authorization request message to an authorizing entity computer for authorization ([0012] “…if the authority agent response confirms the transaction, communicating a confirmed transaction to the initiator S160…”, [claim 1] “…completing the digital transaction or denying the digital transaction based on the authentication response data.”)
Oberheide et al. does not disclose, however, Lurey et al., as shown, teaches the following limitations:
receiving, by a server computer from a user device operated by a user, interaction information associated with an interaction, wherein the interaction information comprises a user device identifier, and wherein the server computer stores data relating to a set of user devices of the user, the set of user devices including the user device; (Col.17, lines 41-42 “receiving, by the processor, a request for authentication of the user from a user device.”, col. 9, lines 61-63 “The user authentication application sends a log in command with a stored device token to a server in step 404”, col.2, lines 22-24 “determining, by one or more processors, a user identification list of one or more verified smart devices associated with the user”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system and application for providing a user authentication or verification of a user identity of Lurey et al. (‘476, abstract) with the teaching of Oberheide et al. for using push-based challenges on mobile device for the authentication and/or authorization of parties involved in a transaction (‘300, [0013]) for receiving the authentication (interaction) request directly from the user device, the request includes the device's stored device token a user device identifier and maintaining a user identification list of the user's verified smart devices (‘476, col.2, lines 22-24; col. 9, lines 61-63; col.17, lines 41-42).
Claims 15 and 17 are rejected using the same rationale that was used for the rejection of claim 1.
As per claim 15 Oberheide et al. additionally discloses the following limitations:
A server computer comprising: a processor; and a non-transitory computer readable medium, the non-transitory computer readable medium comprises code, executable by the processor, for performing operations comprising: ([0051] “Alternative embodiments may implement the above methods in a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components preferably integrated with an authentication platform …”, [0014] “… The authentication platform is preferably an internet accessible server that may be hosted on a distributed computing system, but may be hosted on any suitable platform …”)
22. As per claim 2:
Oberheide et al. discloses the following limitations:
wherein the user device is a first user device, the additional data comprises a cryptogram and user authentication data, the set of user devices includes a second user device and a third user device, and wherein the cryptogram is obtained from the second user device and the user authentication data is obtained from the third user device ([0015] “…Additionally, a first authority device may be registered for authenticating the identity of an agent of the transaction request, and a second authority device may be registered for authorizing an action of an agent…”, [0018] “…The messages transmitted over the communication channel may additionally be cryptographically signed and encrypted using an established setup between the authentication device and the authentication platform…”, [0040] “…Agent verification data may include knowledge data (e.g., a numerical passcode known to an authorized user of the authority device), biometric data (e.g., fingerprint data of a finger of an authorized user of the authority device, characteristic speech frequency of an authorized user of the authority device), or any other suitable data…”)
23. As per claim 3:
Oberheide et al. discloses the following limitations:
wherein the interaction information comprises identifying information associated with the user ([claim 1] “…the transaction request comprising user authentication credentials for performing a first factor of authentication at the service provider… the transaction request data comprises (i) details of the transaction request and (ii) multi-factor authentication account identification data…”)
24. As per claim 4:
Oberheide et al. discloses the following limitations:
wherein the identifying information comprises a credential ([claim 1] “…the transaction request comprising user authentication credentials for performing a first factor of authentication at the service provider…”)
25. As per claim 6:
Oberheide et al. discloses the following limitations:
wherein the data relating to the set of user devices comprises indications of whether or not the user devices can provide certain data types of the additional data and connection addresses for the user devices ([0015] “… Additionally, a first authority device may be registered for authenticating the identity of an agent of the transaction request, and a second authority device may be registered for authorizing an action of an agent…”, [0018] “…For example, in a persistent TCP/IP connection model, a mobile device moving from a service provider data network to a WiFi network may change IP addresses and therefore initiate a new persistent connection. Upon receiving that new connection and an identifier of the mobile device, the authentication platform preferably updates the state of the device for the account associated with that device. Then, the proper connection is preferably used for messaging the authority device…”)
Claim 16 is rejected using the same rationale that was used for the rejection of claim 6.
26. As per claim 7:
Oberheide et al. discloses the following limitations:
wherein the data relating to the set of user devices comprises user preferences for the use of the user devices ([0027] “…Policy information may be set by any suitable entity; e.g., an authentication system user, a service provider administrator, an authentication platform administrator…”, [0020] “…A rule may be setup for which authority devices to message, in what order, and the timing of the messaging…”)
27. As per claim 8:
Oberheide et al. does not disclose, however, Lurey et al., as shown, teaches the following limitations:
wherein communicating with the subset of the set of user devices comprises transmitting additional data request messages including the interaction identifier and receiving additional data response messages including the interaction identifier (Col.11, lines 10-13 “In step 820, a user authentication server generates a transaction token and sends the transaction token to a user authentication device associated with the user”, col.11, lines 14-17 “Upon user approval, the user authentication device transmits a token plus the transaction token back to the user authentication server in step 824.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system and application for providing a user authentication or verification of a user identity of Lurey et al. (‘476, abstract) with the teaching of Oberheide et al. for using push-based challenges on mobile device for the authentication and/or authorization of parties involved in a transaction (‘300, [0013]) for including into the request the server-generated transaction token and returning the device's response a token plus the transaction token (interaction identifier) (‘476, col.11, lines 10-13, 14-17).
28. As per claim 9:
Oberheide et al. discloses the following limitations:
wherein at least two user devices in the subset of user devices use different operating systems ([0031] “…conditions related to an authority device (e.g., an authority device is of a particular model, an authority device operates a particular operating system or authentication app version, an authority device is in an unusual location)…”, [0015] “…The mobile device is preferably a mobile phone, tablet computer, smartphone, personal data assistant (PDA), personal computer, and/or any suitable computing device…”)
29. As per claim 10:
Oberheide et al. discloses the following limitations:
wherein the user device is a first user device, and the set of user devices includes a second user device and a third user device, and wherein the first user device, the second user device, and the third user device have different form factors ([claim 1] “…receiving a transaction request from an initiator using an initiating user device distinct from the registered mobile user device for initiating the digital transaction…”, [0015] “…The mobile device is preferably a mobile phone, tablet computer, smartphone, personal data assistant (PDA), personal computer, and/or any suitable computing device…A plurality of devices may additionally be registered, as shown in FIG. 6…”)
Claim 18 is rejected using the same rationale that was used for the rejection of claim 10.
30. As per claim 11:
Oberheide et al. discloses the following limitations:
wherein the subset of the set of user devices comprises a first user device, a second user device and a third user device, which are different and each of the first user device, the second user device, and the third user device is one of the following types of user devices: a watch, a laptop computer, a card, a mobile phone, a desktop browser, and a mobile phone application ([0020] “…For example, four authority devices may be messaged for authorization and at least three must confirm the transaction for it to be confirmed…”, [0015] “…The mobile device is preferably a mobile phone, tablet computer, smartphone, personal data assistant (PDA), personal computer, and/or any suitable computing device…”)
31. As per claim 13:
Oberheide et al. discloses the following limitations:
receiving, by the server computer, the data relating to the set of user devices of the user during a user enrollment process ([0015] “Step S110, which includes registering an authority device for an account on an authentication platform, functions to identify a device of an agent that is permitted to authenticate or authorize transactions. The registration preferably occurs prior to a transaction request, and is preferably performed during an initial setup of an account on the authentication platform…”)
32. As per claim 14:
Oberheide et al. discloses the following limitations:
wherein the server computer determines current connection statuses of the user devices in the set of user devices, and wherein the subset of the set of user devices is determined using the current connection statuses ([0018] “…Upon receiving that new connection and an identifier of the mobile device, the authentication platform preferably updates the state of the device for the account associated with that device. Then, the proper connection is preferably used for messaging the authority device…”, [0015] “…A second authority device may provide a backup communication point if a primary authority device does not respond…”)
33. As per claim 19:
Oberheide et al. discloses the following limitations:
wherein the first user device, the second user device and the third user device are different and are one of the following types of user devices: a watch, a laptop computer, a card, a mobile phone, a desktop browser, and a mobile phone application ([0015] “…The mobile device is preferably a mobile phone, tablet computer, smartphone, personal data assistant (PDA), personal computer, and/or any suitable computing device…”, [0020] “…For example, four authority devices may be messaged for authorization and at least three must confirm the transaction for it to be confirmed…”)
34. As per claim 20:
Oberheide et al. discloses the following limitations:
wherein the interaction is a transaction ([0016] “…Exemplary transactions may include logging into a website, application or computer system; a user withdrawing money from an ATM; a user initiating a “forgotten password” procedure; a user attempting to enter a restricted area of a building or environment; a payment exchange between two entities; a user attempting to perform a restricted action in a computer system; and/or any suitable application requiring authentication and/or authorization…”, [0018] “…In one example an online bank transfer may have a message with transaction information including payer, payee, account numbers, transfer amount, and transaction date and time.”)
35. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over US20200005300A1 to Oberheide et al. in view of US9294476B1 to Lurey et al. and US20150264050A1 to Neuman et al.
36. As per claim 5:
Oberheide et al. discloses the following limitations:
wherein the authorization request message comprises the credential, the cryptogram, and the user authentication data ([0149] “…The Authentication Server sends back ‘received a valid login’ to the Provider including the following data (Note the preferred method specifically does not send the biometric data or other authentication data to the Provider): the user certificate which includes the Qid, the signed Qsid and Qliveness, the validity of the authentication passed to the Qserver (for example user authenticated successfully with pin and face)…”, [0208] “The Qapp then generates a response and sends it back to the Qserver 1103 which forwards it back to the Provider 1104. The response may include the user's approval answer, additional authentication information, and verification that the message was shown…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system and application for providing a user authentication or verification of a user identity of Lurey et al. (‘476, abstract) and a system for authenticating multiple different users to any of multiple different network service providers via the network of Neuman et al. (‘050, [0005]) with the teaching of Oberheide et al. for using push-based challenges on mobile device for the authentication and/or authorization of parties involved in a transaction (‘300, [0013]) for including into the message the user certificate (a credential), the signed Qsid and Qliveness (a cryptographically signed value, e.g., a cryptogram), and additional authentication information (e.g., user authentication data) (‘050, [0149], [0208]).
37. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over US20200005300A1 to Oberheide et al. in view of US9294476B1 to Lurey et al. and US20170032369A1 to Hugot.
38. As per claim 12:
Oberheide et al. discloses the following limitations:
receiving, by the server computer, an authorization response message from the authorizing entity computer, the authorization response message being responsive to the authorization request message ([0168] “The second server 104 sends to the first server 110 a message 230 that includes either a transaction authorization (i.e. in case of a financial validation) or a transaction refusal (i.e. in case of a financial invalidation), as a request response.”, [claim 1] “… the second server sends, through the first server and the payment network, to the terminal, a fifth message including either a transaction authorization or a transaction refusal.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a system and application for providing a user authentication or verification of a user identity of Lurey et al. (‘476, abstract) and a method for authorizing a data transaction based on user account information of Hugot (‘369, [0005]) with the teaching of Oberheide et al. for using push-based challenges on mobile device for the authentication and/or authorization of parties involved in a transaction (‘300, [0013]) for transmitting an authorization request to the second server, returning by the second server (e.g., an authorizing entity computer) to the first server a message containing either a transaction authorization or a transaction refusal (‘369, [0168], [claim 1]).
Conclusion
39. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US10013692B2 – Hubert et al. – Discloses transactions initiated by or on behalf of users between client systems and transaction systems are sent to authorization systems for approval. An authorization system contacts one or more registered devices for approval from a user of the registered devices for the transactions initiated by or on behalf of the users that are being handled by the transaction systems.
US20230342736A1 – Khadar et al. – Discloses methods for conducting a transaction involving a remote point-of-sale (POS) device that include receiving a transaction request message from a remote payment entity system, wherein the transaction request message is associated with a transaction involving a merchant system, the merchant system is located remote from the remote payment entity system, and the transaction request message includes an identifier of the merchant system.
40. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/Examiner, Art Unit 3692 /DAVID P SHARVIN/Primary Examiner, Art Unit 3692
Prosecution Insights