DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been examined in this application. This communication is the first action on the merits.
Priority
Application 19/457,876 filed on 01/23/2026 is a CON of PCT/KR2024/008966 06/27/2024 and claims benefit of REPUBLIC OF KOREA 10-2023-0097078 07/25/2023 and REPUBLIC OF KOREA 10-2023-0112260 08/25/2023.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 101
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.
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. (MPEP 2106). The claims are directed to a method and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
An electronic device comprising: at least one communication circuitry; at least one memory, comprising one or more storage media, storing instructions; and at least one processor communicatively coupled to the at least one communication circuitry and the at least one memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to: in response to an input requesting payment, obtain payment information related to a payment request,
in response to obtaining the payment information, output, via the at least one communication circuitry, to at least one external electronic device different from the electronic device, data including the payment information to cause the at least one external electronic device to display a screen including at least one piece of payment information on a display of the at least one external electronic device, and
output a payment signal for the payment based on the data including the payment information to the outside via the at least one communication circuitry in response to obtaining the payment information.
Claim 11 recites the limitations of:
An electronic device comprising: a display; at least one communication circuitry; at least one memory, comprising one or more storage media, storing instructions; and at least one processor communicatively coupled to the display, the at least one communication circuitry, and the at least one memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to: receive, via the at least one communication circuitry, data including payment information from an external electronic device connected based on short-range wireless communication with the electronic device,
based on the receiving, display, on the display, a screen including at least one piece of payment information,
while displaying the screen on the display, receive a request to output a payment signal for payment based on the data to the outside from the external electronic device, and
in response to receiving the request, output, via the at least one communication circuitry, the payment signal to the outside.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Furthermore, the claims cover the use of an electronic device to provide for collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction. As the steps could be performed by a human without a computer, the claim limitations fall within the mental processes grouping, and the claim recites an abstract idea.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting “An electronic device comprising: at least one communication circuitry; at least one memory, comprising one or more storage media, storing instructions; and at least one processor communicatively coupled to the at least one communication circuitry and the at least one memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to:”, “at least one external electronic device”, “a screen”, “a payment signal”, “An electronic device comprising: a display; at least one communication circuitry; at least one memory, comprising one or more storage media, storing instructions; and at least one processor communicatively coupled to the display, the at least one communication circuitry, and the at least one memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to: receive, via the at least one communication circuitry”, and “an external electronic device connected based on short-range wireless communication with the electronic device”, to perform the steps of “outputting” and “displaying”, nothing in the claim elements preclude the steps from practically being a certain method of organizing human activity or mental process. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the specification discloses “[0043] Any of the functions or operations described herein can be processed by one processor or a combination of processors. The one processor or the combination of processors is circuitry performing processing and includes circuitry like an application processor (AP, e.g. a central processing unit (CPU)), a communication processor (CP, e.g., a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a wireless fidelity (Wi-Fi) chip, a Bluetooth® chip, a global positioning system (GPS) chip, a near field communication (NFC) chip, connectivity chips, a sensor controller, a touch controller, a finger-print sensor controller, a display driver integrated circuit (IC), an audio CODEC chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system on chip (SoC), an IC, or the like.” “[0046] Referring to FIG. 1, the electronic device 101 in the network environment 100 may communicate with an electronic device 102 via a first network 198 (e.g., a short-range wireless communication network), or at least one of an electronic device 104 or a server 108 via a second network 199 (e.g., a long-range wireless communication network). According to an embodiment, the electronic device 101 may communicate with the electronic device 104 via the server 108. According to another embodiment, the electronic device 101 may include a processor 120, memory 130, an input module 150, a sound output module 155, a display module 160, an audio module 170, a sensor module 176, an interface 177, a connecting terminal 178, a haptic module 179, a camera module 180, a power management module 188, a battery 189, a communication module 190, a subscriber identification module (SIM) 196, or an antenna module 197. In some embodiments, at least one of the components (e.g., the connecting terminal 178) may be omitted from the electronic device 101, or one or more other components may be added in the electronic device 101. In some embodiments, some of the components (e.g., the sensor module 176, the camera module 180, or the antenna module 197) may be implemented as a single component (e.g., the display module 160).” “[00358] The electronic device according to various embodiments may be one of various types of electronic devices. The electronic devices may include, for example, a portable communication device (e.g., a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. According to an embodiment of the disclosure, the electronic devices are not limited to those described above.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “An electronic device comprising: at least one communication circuitry; at least one memory, comprising one or more storage media, storing instructions; and at least one processor communicatively coupled to the at least one communication circuitry and the at least one memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to:”, “at least one external electronic device”, “a screen”, “a payment signal”, “An electronic device comprising: a display; at least one communication circuitry; at least one memory, comprising one or more storage media, storing instructions; and at least one processor communicatively coupled to the display, the at least one communication circuitry, and the at least one memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to: receive, via the at least one communication circuitry”, and “an external electronic device connected based on short-range wireless communication with the electronic device”, to perform the steps of “outputting” and “displaying”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”. See MPEP 2106.05(g).
Claim 15 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claim 15 recites the additional elements of “A method performed by an electronic device comprising at least one communication circuitry, the method comprising:”.
Furthermore,
Claim 7 recites the additional elements of “the payment signal based on a first communication protocol to the outside” and “the other payment signal based on a second communication protocol”.
Claim 10 recites the additional elements of “at least one sensor”.
Claim 14 recites the additional elements of “the payment signal is generated based on a communication protocol different from a communication protocol based on which another payment signal generated by the external electronic device”.
For similar reasons as explained above with regard to claims 1 and 11, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1 and 11.
Dependent claims 2-10, 12-14, and 16-20 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-20 are not patent-eligible.
Claim Rejections - 35 USC § 103
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 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.
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.
Claims 1-3 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861.
As per claim 1,
Lin explicitly teaches:
An electronic device comprising: at least one communication circuitry; at least one memory, comprising one or more storage media, storing instructions; and at least one processor communicatively coupled to the at least one communication circuitry and the at least one memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to: in response to an input requesting payment, obtain payment information related to a payment request,
(Lin US20180121908 at paras. 87-89, 94) ("[0087] FIG. 7 illustrates the process of completing of a digital wallet payment from the primary device 102 on receiving the payment notification. At step 702, the digital wallet application 103 is executed, or made active if already executing, on the primary device 102. In some embodiments, the payment notification contains an active element configured to request the execution of the digital wallet application 103 by the operating system of the primary device 102 for the purpose of performing the payment. Alternatively, the user 101 can manually execute the digital wallet application 103 and can input the relevant transaction details into the application 103 in order to perform the digital wallet payment. [0088] At step 704, the user 101 selects a payment source from the candidate payment sources associated with the digital wallet (i.e. payment sources added to the digital wallet application 103, as described above), and enters corresponding authentication information to authenticate the digital wallet payment with this selected instrument, at step 706 (as described above). The digital wallet application 103 prompts the user 101 to confirm the digital wallet payment by the display of a GUI element, such as a dialogue box, at step 708. If the user 101 confirms the payment, then the digital wallet application 103 generates payment information representing the selected payment source, and transmits this information to the wallet server 108.")
in response to obtaining the payment information, output, via the at least one communication circuitry, to at least one external electronic device different from the electronic device, data including the payment information [to cause the at least one external electronic device to display a screen] including at least one piece of payment information [on a display of the at least one external electronic device], and
(Lin US20180121908 at paras. 87-89, 94) ("[0087] FIG. 7 illustrates the process of completing of a digital wallet payment from the primary device 102 on receiving the payment notification. At step 702, the digital wallet application 103 is executed, or made active if already executing, on the primary device 102. In some embodiments, the payment notification contains an active element configured to request the execution of the digital wallet application 103 by the operating system of the primary device 102 for the purpose of performing the payment. Alternatively, the user 101 can manually execute the digital wallet application 103 and can input the relevant transaction details into the application 103 in order to perform the digital wallet payment. [0088] At step 704, the user 101 selects a payment source from the candidate payment sources associated with the digital wallet (i.e. payment sources added to the digital wallet application 103, as described above), and enters corresponding authentication information to authenticate the digital wallet payment with this selected instrument, at step 706 (as described above). The digital wallet application 103 prompts the user 101 to confirm the digital wallet payment by the display of a GUI element, such as a dialogue box, at step 708. If the user 101 confirms the payment, then the digital wallet application 103 generates payment information representing the selected payment source, and transmits this information to the wallet server 108.")
Lin does not explicitly teach, however, Kumar does teach:
to cause the at least one external electronic device to display a screen…on a display of the at least one external electronic device...
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin and Kumar, because it allows for improved systems for redirecting to a trusted device for secured data transmission. (Kumar at Abstract and paras. 2-4).
Lin and Kumar do not explicitly teach, however, Rezayee does teach:
output a payment signal for the payment based on the data including the payment information to the outside via the at least one communication circuitry in response to obtaining the payment information.
(Rezayee US20220374861 at paras. 48-51) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems that provide for communication of payment data to be secure and reliable and allows for the process of requesting payment, including the reading of payment data and initiation of the payment transaction, to be efficient and quick so as to reduce burdens on the consumer and encourage the consumer to use a payment device for a payment transaction. (Rezayee at Abstract and paras. 2-4).
As per claim 2,
Lin explicitly teaches:
obtain, via the at least one communication circuitry, a result signal indicating that the payment has failed from a server associated with the payment information, and
(Lin US20180121908 at paras. 94-99) ("[0098] The transaction is then processed, at step 806, in accordance with standard procedures for processing a financial transaction involving an acquirer 132, a card association entity 134, and a corresponding issuer 136. At the conclusion of the transaction processing, a transaction notification is received by the merchant application 119 indicating the authorisation or denial of the payment for the transaction (at step 808). The cross device digital wallet payment system 100 is configured to display a notification of the successful completion of the transaction on the secondary device 104 used to initiate the transaction, and the primary device 102 used to perform the payment (at step 314). If the transaction notification indicates that the payment is authorised, the merchant application 119 is configured to display the success of the payment, and a corresponding digital receipt for the transaction, via GUI elements of the secondary device 104. [0099] The merchant application 119 is configured to transmit the transaction notification to the wallet server 108 via an API call. The logic module 110 is configured to process the transaction notification including extracting primary device data for the corresponding digital wallet from the directory service 114. The logic module 110 generates digital wallet transaction notification data and transmits this data to the primary device 102 via the communications network 106. The digital wallet transaction notification data is processed by the primary device 102 to provide an indication of the success or failure of the digital wallet payment to the user 101. In the described embodiments, a corresponding digital receipt is displayed to the user 101 via GUI elements of the primary device 102. In some embodiments, the wallet server 108 is configured to store an indication of the success or failure of the digital wallet payment associated with a particular cross device digital wallet payment request in a payment record table (as described above), or similar data structure.")
Lin does not explicitly teach, however, Kumar does teach:
in response to obtaining the result signal, output, to the at least one external electronic device, a request
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin and Kumar, because it allows for improved systems for redirecting to a trusted device for secured data transmission. (Kumar at Abstract and paras. 2-4).
Lin and Kumar do not explicitly teach, however, Rezayee does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: after outputting the payment signal to the outside,
(Rezayee US20220374861 at paras. 48-51) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
to cause the at least one external electronic device to output another payment signal for the payment based on the data to the outside.
(Rezayee US20220374861 at paras. 48-51) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems that provide for communication of payment data to be secure and reliable and allows for the process of requesting payment, including the reading of payment data and initiation of the payment transaction, to be efficient and quick so as to reduce burdens on the consumer and encourage the consumer to use a payment device for a payment transaction.. (Rezayee at Abstract and paras. 2-4).
As per claim 3,
Lin does not explicitly teach, however, Kumar does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: in response to obtaining the result signal, select some external electronic device among the at least one external electronic device based on priority information, and
(Kumar US20220051234 at paras. 23-24, 41, 54-56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service." "[0054] At operation 330, the device identifying module 220 identifies a second device that is trusted by the user. In some embodiments, the device identifying module 220 identifies one or more devices that the user previously used to make payments for previous purchases, and selects the second device from the one or more devices previously used by the user to make payments for previous purchases. The selecting of the second device may be based on a device selection rule. For example, a device selection rule specifies that a particular device is selected based on whether the user chose the particular device for receiving notifications. According to another example, a device selection rule specifies that only a device that has previously been used by the user to make payments may be selected.")
output, via the at least one communication circuitry, the request to the selected some external electronic device.
(Kumar US20220051234 at paras. 23-24, 41, 54-56) ("[0056] At operation 340, the communication module 230 transmits a communication including a notification to the second device. In some embodiments, the transmitting of the communication including the notification to the second device comprises causing a display of the notification in a user interface of the second device (e.g., a smart watch) associated with the user. Further details with respect to the method operations of the method 300 are described below with respect to FIGS. 4-7.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems for redirecting to a trusted device for secured data transmission. (Kumar at Abstract and paras. 2-4).
Claims 15-17 are substantially similar to claims 1-3, thus, they are rejected on similar grounds.
Claims 4 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Singh, U.S. Patent Application Publication Number 2024/0020677; in view of Bradley, U.S. Patent Application Publication Number 2021/0406886.
As per claim 4,
Lin explicitly teaches:
result signal indicating that the payment has failed...
(Lin US20180121908 at paras. 94-99) ("[0098] The transaction is then processed, at step 806, in accordance with standard procedures for processing a financial transaction involving an acquirer 132, a card association entity 134, and a corresponding issuer 136. At the conclusion of the transaction processing, a transaction notification is received by the merchant application 119 indicating the authorisation or denial of the payment for the transaction (at step 808). The cross device digital wallet payment system 100 is configured to display a notification of the successful completion of the transaction on the secondary device 104 used to initiate the transaction, and the primary device 102 used to perform the payment (at step 314). If the transaction notification indicates that the payment is authorised, the merchant application 119 is configured to display the success of the payment, and a corresponding digital receipt for the transaction, via GUI elements of the secondary device 104. [0099] The merchant application 119 is configured to transmit the transaction notification to the wallet server 108 via an API call. The logic module 110 is configured to process the transaction notification including extracting primary device data for the corresponding digital wallet from the directory service 114. The logic module 110 generates digital wallet transaction notification data and transmits this data to the primary device 102 via the communications network 106. The digital wallet transaction notification data is processed by the primary device 102 to provide an indication of the success or failure of the digital wallet payment to the user 101. In the described embodiments, a corresponding digital receipt is displayed to the user 101 via GUI elements of the primary device 102. In some embodiments, the wallet server 108 is configured to store an indication of the success or failure of the digital wallet payment associated with a particular cross device digital wallet payment request in a payment record table (as described above), or similar data structure.")
Lin, Kumar, and Rezayee do not explicitly teach, however, Singh does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: obtain, via the at least one communication circuitry, another result signal [indicating that the payment has failed] from the selected some external electronic device,
(Singh US20240020677 at paras. 23-25) ("[0023] In some embodiments, instead of using the default user profile on the smart assistant device, the system recognizes the user who is making the payment request and allows the requesting user to complete the payment using a trusted user device. The system will enable a user who has their voice profile and user device registered with the smart assistant ecosystem, as well as those users whose voice profile is not registered, to complete the payment. [0024] The user device may generate a payment token (encrypting banking details) against the transaction ID from locally stored banking details upon successfully authenticating the access of locally stored banking details (e.g., Apple Pay® local wallet on the user device). In an embodiment, the payment token can be sent through the smart assistant device to the payment service provider. Alternatively, the payment token can be sent directly from the user's device to the payment service provider. The token may be generated using a public key of the payment service provider or the concerned bank. The respective payment service provider or the bank can only read the banking details (e.g. credit card number, CVV, expiry date, etc.). Neither the smart assistant device nor the merchant is exposed to banking details, only the transaction details (transaction id, transaction value, time, merchant id, etc.) are. The user device may send the transaction status to the smart assistant device, which can update the transaction details (ID, status, etc.) against a purchase request to the merchant. [0025] In some embodiments, the user can also specify the device to which they want to transfer the transaction. For example, the user can issue a voice command to the smart assistant device indicating which device they would like to use to complete the transaction. The user may, for example say, “Hey Alexa, I want to pay on my iPhone” or “Hey Alexa, I will pay from my Samsung tablet.” The smart assistant device then identifies the indicated device and transfers the transaction to that device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, and Singh, because it allows for improved systems for transferring payment transactions initiated on a public voice-activated device to a private user device for completion. (Singh at Abstract and paras. 1-9).
Lin, Kumar, Rezayee, and Singh do not explicitly teach, however, Bradley does teach:
in response to obtaining the other result signal from the selected some external electronic device, based on priority information, select other some external electronic device among the at least one external electronic device, and output, via the at least one communication circuitry, the request to the selected other some external electronic device.
(Bradley US20210406886 at paras. 41-43) ("[0041] Upon selecting the default payment device, such as the electronic device 102A, the payment requesting device 104 transmits, via the second communication protocol, a message to facilitate performing the payment transaction, where the message includes the device identifier of the default payment device (312). For example, the payment requesting device 104 may transmit, via the second communication protocol, the message to the electronic payment system server 108 with the device identifier in the body of the message and/or information regarding the payment transaction in the body of the message, such as a payment transaction identifier. The electronic payment system server 108 may then initiate, via the second communication protocol, the payment transaction with the electronic device 102A. [0042] In one or more implementations, the payment requesting device 104 may transmit a message to the electronic device 102A that includes the device identifier of the electronic device 102A in a destination address of the message, or in a similar field that facilitates delivering the message to the electronic device 102A. The message may further include information regarding the payment transaction and/or the electronic payment system server 108. The electronic device 102A may utilize the received message to initiate the payment transaction with the electronic payment system server 108 via the second communication protocol. For example, the message may include an element, such as a link or graphical indicator, that initiates the payment when selected. In one or more implementations, the electronic device 102A may handoff the payment transaction to another of the electronic devices 102B-C, as is discussed further below with respect to FIG. 4. [0043] The payment requesting device 104 receives, via the second communication protocol and from the electronic payment system server 108, confirmation that the payment transaction was performed (314). The confirmation may further indicate that the payment transaction was performed by the electronic device 102A and/or that the payment transaction was handed off and performed by another of the electronic devices 102B-C. In one or more implementations, if the payment requesting device 104 does not receive the confirmation after a predetermined amount of time, the payment requesting device 104 may cancel the payment transaction and/or may handoff the payment transaction to another of the electronic devices 102B-C, such as based on the determined likelihoods, suitability scores, and/or the one or more payment factors.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, Singh, and Bradley, because it allows for improved systems for payment transaction handoff. (Bradley at Abstract and paras. 2-3).
Claim 18 is substantially similar to claim 4, thus, it is rejected on similar grounds.
Claims 5 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Singh, U.S. Patent Application Publication Number 2024/0020677; in view of Wood, U.S. Patent Application Publication Number 2017/0277498.
As per claim 5,
Lin explicitly teaches:
result signal indicating that the payment is successful...
(Lin US20180121908 at paras. 94-99) ("[0098] The transaction is then processed, at step 806, in accordance with standard procedures for processing a financial transaction involving an acquirer 132, a card association entity 134, and a corresponding issuer 136. At the conclusion of the transaction processing, a transaction notification is received by the merchant application 119 indicating the authorisation or denial of the payment for the transaction (at step 808). The cross device digital wallet payment system 100 is configured to display a notification of the successful completion of the transaction on the secondary device 104 used to initiate the transaction, and the primary device 102 used to perform the payment (at step 314). If the transaction notification indicates that the payment is authorised, the merchant application 119 is configured to display the success of the payment, and a corresponding digital receipt for the transaction, via GUI elements of the secondary device 104. [0099] The merchant application 119 is configured to transmit the transaction notification to the wallet server 108 via an API call. The logic module 110 is configured to process the transaction notification including extracting primary device data for the corresponding digital wallet from the directory service 114. The logic module 110 generates digital wallet transaction notification data and transmits this data to the primary device 102 via the communications network 106. The digital wallet transaction notification data is processed by the primary device 102 to provide an indication of the success or failure of the digital wallet payment to the user 101. In the described embodiments, a corresponding digital receipt is displayed to the user 101 via GUI elements of the primary device 102. In some embodiments, the wallet server 108 is configured to store an indication of the success or failure of the digital wallet payment associated with a particular cross device digital wallet payment request in a payment record table (as described above), or similar data structure.")
Lin, Kumar, and Rezayee do not explicitly teach, however, Singh does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: obtain another result signal [indicating that the payment is successful] from the selected some external electronic device, and
(Singh US20240020677 at paras. 23-25) ("[0023] In some embodiments, instead of using the default user profile on the smart assistant device, the system recognizes the user who is making the payment request and allows the requesting user to complete the payment using a trusted user device. The system will enable a user who has their voice profile and user device registered with the smart assistant ecosystem, as well as those users whose voice profile is not registered, to complete the payment. [0024] The user device may generate a payment token (encrypting banking details) against the transaction ID from locally stored banking details upon successfully authenticating the access of locally stored banking details (e.g., Apple Pay® local wallet on the user device). In an embodiment, the payment token can be sent through the smart assistant device to the payment service provider. Alternatively, the payment token can be sent directly from the user's device to the payment service provider. The token may be generated using a public key of the payment service provider or the concerned bank. The respective payment service provider or the bank can only read the banking details (e.g. credit card number, CVV, expiry date, etc.). Neither the smart assistant device nor the merchant is exposed to banking details, only the transaction details (transaction id, transaction value, time, merchant id, etc.) are. The user device may send the transaction status to the smart assistant device, which can update the transaction details (ID, status, etc.) against a purchase request to the merchant. [0025] In some embodiments, the user can also specify the device to which they want to transfer the transaction. For example, the user can issue a voice command to the smart assistant device indicating which device they would like to use to complete the transaction. The user may, for example say, “Hey Alexa, I want to pay on my iPhone” or “Hey Alexa, I will pay from my Samsung tablet.” The smart assistant device then identifies the indicated device and transfers the transaction to that device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, and Singh, because it allows for improved systems for transferring payment transactions initiated on a public voice-activated device to a private user device for completion. (Singh at Abstract and paras. 1-9).
Lin, Kumar, Rezayee, and Singh do not explicitly teach, however, Wood does teach:
in response to obtaining the other result signal, output, via the at least one communication circuitry, to the at least one external electronic device, a request to cause the at least one external electronic device to cease displaying the screen.
(Wood US20170277498 at paras. 287-289, 303-305) ("[0288] In some embodiments, electronic device 500 transmits the indication of the need for text input for text input user interface 1202 to multiple devices. For example, in FIG. 12JJ, both devices 511A and 511B have received the indication of the need for text input. As a result, device 511A is displaying text input alert 1242A, and device 511B is displaying text input alert 1242B, both indicating that text input is needed for text input user interface 1202. In some embodiments, to limit the number of devices that are concurrently providing text input to text input user interface 1202, if a user of one of devices 511A and 511B selects their respective text input alerts, the display of the text input alert on the other one of devices 511A and 511B is optionally ceased. For example, in FIGS. 12KK-12LL, a user of device 511B has swiped down text input alert 1242B to select it. As a result, device 511B displays user interface 1244 for entering text into text input user interface 1202, as shown in FIG. 12MM. Because text input alert 1242B on device 511B was selected, device 511A stops displaying text input alert 1242A, as shown in FIG. 12MM." "[0304] In some embodiments, while the text input alert is displayed on the display of the first electronic device, a visual indication, which indicates that text input can be provided to the text input user interface of the second electronic device using the first electronic device, is displayed (1372), by the second electronic device, on the separate display device, such as in FIG. 12E (e.g., a visual indication is displayed in the text input user interface that indicates to the user that text input can be provided using the first electronic device). This visual indication on the separate display device notifies users who can see the separate display of the ability to provide text input to the text input user interface using the first electronic device—something these users may not have known was possible. This increases the efficiency of the interactions between the users and the second electronic device, thus reducing power consumption associated with those interactions. In some embodiments, while displaying the text input alert on the display of the first electronic device, the first electronic device determines (1374) that text input is no longer needed for the text input user interface displayed on the separate display device, such as in FIG. 12V (e.g., the second electronic device optionally transmits, to the first electronic device, an indication that the text input is no longer needed. For example, completion of text entry, or navigation away from the text input user interface, optionally cause the second electronic device to indicate as much to the first electronic device). In response to determining that text input is no longer needed for the text input user interface displayed on the separate display device, the first electronic device optionally ceases (1376) display of the text input alert on the display of the first electronic device, such as in FIG. 12V (e.g., when text input is no longer needed, the text input alert is optionally no longer displayed).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, Singh, and Wood, because it allows for improved systems for providing navigational inputs to an electronic device using a multifunction device, and user interactions with such devices and that improves the user's experience with the device and decreases user interaction time. (Wood at Abstract and paras. 2-12).
Claim 19 is substantially similar to claim 5, thus, it is rejected on similar grounds.
Claims 6, 8, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Pareek, U.S. Patent Application Publication Number 2018/0322496.
As per claim 6,
Lin does not explicitly teach, however, Kumar does teach:
to the at least one external electronic device
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin and Kumar, because it allows for improved systems for redirecting to a trusted device for secured data transmission. (Kumar at Abstract and paras. 2-4).
Lin and Kumar do not explicitly teach, however, Rezayee does teach:
such that the other payment signal is generated in the at least one external electronic device.
(Rezayee US20220374861 at paras. 48-51) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems that provide for communication of payment data to be secure and reliable and allows for the process of requesting payment, including the reading of payment data and initiation of the payment transaction, to be efficient and quick so as to reduce burdens on the consumer and encourage the consumer to use a payment device for a payment transaction. (Rezayee at Abstract and paras. 2-4).
Lin, Kumar, and Rezayee do not explicitly teach, however, Pareek does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: based on payment failure type information included in the result signal, output, via the at least one communication circuitry, the request based on the result signal
(Pareek US20180322496 at paras. 9-11, 15-17) ("[0010] According to a first aspect of the present disclosure, there is provided a system for automated switching of payment devices during a payment transaction, comprising a facilitator module, the facilitator module comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the facilitator module at least to: (i) in response to a payment status message from an issuer of a primary payment device which is indicative of a partial approval or a decline of a payment transaction request for the primary payment device, retrieve, from a database, identification data for a secondary payment device which is associated with the primary payment device; (ii) generate a secondary payment instruction comprising the identification data of the secondary payment device, and an amount or a remaining amount of the payment transaction; and (iii) transmit the secondary payment instruction to an issuer of the secondary payment device." "[0016] In an embodiment, the facilitator module may be further caused to: receive confirmation of an invalid Personal Identification Number (PIN) of the primary payment device; transmit, from the issuer, information confirming the invalidity of the primary payment device PIN; retrieve, from the database, identification data for payment using the secondary payment device; transmit, to the user, a request for a Personal Identification Number (PIN) associated with the secondary payment device; and transmit the payment transaction request to the issuer of the secondary payment device based on a successful verification of the PIN associated with the secondary payment device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, and Pareek, because it allows for improved systems for automated switching of payment devices in a payment transaction, and a method performed by that system. (Pareek at Abstract and paras. 2-8).
As per claim 8,
Lin explicitly teaches:
obtain, via the at least one communication circuitry, a result signal indicating that the payment has failed from a server associated with the payment information, and in response to obtaining the result signal,
(Lin US20180121908 at paras. 94-99) ("[0098] The transaction is then processed, at step 806, in accordance with standard procedures for processing a financial transaction involving an acquirer 132, a card association entity 134, and a corresponding issuer 136. At the conclusion of the transaction processing, a transaction notification is received by the merchant application 119 indicating the authorisation or denial of the payment for the transaction (at step 808). The cross device digital wallet payment system 100 is configured to display a notification of the successful completion of the transaction on the secondary device 104 used to initiate the transaction, and the primary device 102 used to perform the payment (at step 314). If the transaction notification indicates that the payment is authorised, the merchant application 119 is configured to display the success of the payment, and a corresponding digital receipt for the transaction, via GUI elements of the secondary device 104. [0099] The merchant application 119 is configured to transmit the transaction notification to the wallet server 108 via an API call. The logic module 110 is configured to process the transaction notification including extracting primary device data for the corresponding digital wallet from the directory service 114. The logic module 110 generates digital wallet transaction notification data and transmits this data to the primary device 102 via the communications network 106. The digital wallet transaction notification data is processed by the primary device 102 to provide an indication of the success or failure of the digital wallet payment to the user 101. In the described embodiments, a corresponding digital receipt is displayed to the user 101 via GUI elements of the primary device 102. In some embodiments, the wallet server 108 is configured to store an indication of the success or failure of the digital wallet payment associated with a particular cross device digital wallet payment request in a payment record table (as described above), or similar data structure.")
Lin does not explicitly teach, however, Kumar does teach:
output, via the at least one communication circuitry, to the at least one external electronic device, a request [based on the result signal] to cause the at least one external electronic device to display, on the display, another screen
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data." "[0056] At operation 340, the communication module 230 transmits a communication including a notification to the second device. In some embodiments, the transmitting of the communication including the notification to the second device comprises causing a display of the notification in a user interface of the second device (e.g., a smart watch) associated with the user. Further details with respect to the method operations of the method 300 are described below with respect to FIGS. 4-7.")
based on the result signal...
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data." "[0056] At operation 340, the communication module 230 transmits a communication including a notification to the second device. In some embodiments, the transmitting of the communication including the notification to the second device comprises causing a display of the notification in a user interface of the second device (e.g., a smart watch) associated with the user. Further details with respect to the method operations of the method 300 are described below with respect to FIGS. 4-7.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin and Kumar, because it allows for improved systems for redirecting to a trusted device for secured data transmission. (Kumar at Abstract and paras. 2-4).
Lin and Kumar do not explicitly teach, however, Rezayee does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: after outputting the payment signal to the outside,
(Rezayee US20220374861 at paras. 48-51) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems that provide for communication of payment data to be secure and reliable and allows for the process of requesting payment, including the reading of payment data and initiation of the payment transaction, to be efficient and quick so as to reduce burdens on the consumer and encourage the consumer to use a payment device for a payment transaction. (Rezayee at Abstract and paras. 2-4).
Lin, Kumar, and Rezayee do not explicitly teach, however, Pareek does teach:
based on payment failure type information included in the result signal.
(Pareek US20180322496 at paras. 9-11, 15-17) ("[0010] According to a first aspect of the present disclosure, there is provided a system for automated switching of payment devices during a payment transaction, comprising a facilitator module, the facilitator module comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the facilitator module at least to: (i) in response to a payment status message from an issuer of a primary payment device which is indicative of a partial approval or a decline of a payment transaction request for the primary payment device, retrieve, from a database, identification data for a secondary payment device which is associated with the primary payment device; (ii) generate a secondary payment instruction comprising the identification data of the secondary payment device, and an amount or a remaining amount of the payment transaction; and (iii) transmit the secondary payment instruction to an issuer of the secondary payment device." "[0016] In an embodiment, the facilitator module may be further caused to: receive confirmation of an invalid Personal Identification Number (PIN) of the primary payment device; transmit, from the issuer, information confirming the invalidity of the primary payment device PIN; retrieve, from the database, identification data for payment using the secondary payment device; transmit, to the user, a request for a Personal Identification Number (PIN) associated with the secondary payment device; and transmit the payment transaction request to the issuer of the secondary payment device based on a successful verification of the PIN associated with the secondary payment device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, and Pareek, because it allows for improved systems for automated switching of payment devices in a payment transaction, and a method performed by that system. (Pareek at Abstract and paras. 2-8).
Claim 20 is substantially similar to claim 6, thus, it is rejected on similar grounds.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Smets, U.S. Patent Application Publication Number 2021/0127436.
As per claim 7,
Lin explicitly teaches:
in response to obtaining the result signal,
(Lin US20180121908 at paras. 94-99) ("[0098] The transaction is then processed, at step 806, in accordance with standard procedures for processing a financial transaction involving an acquirer 132, a card association entity 134, and a corresponding issuer 136. At the conclusion of the transaction processing, a transaction notification is received by the merchant application 119 indicating the authorisation or denial of the payment for the transaction (at step 808). The cross device digital wallet payment system 100 is configured to display a notification of the successful completion of the transaction on the secondary device 104 used to initiate the transaction, and the primary device 102 used to perform the payment (at step 314). If the transaction notification indicates that the payment is authorised, the merchant application 119 is configured to display the success of the payment, and a corresponding digital receipt for the transaction, via GUI elements of the secondary device 104. [0099] The merchant application 119 is configured to transmit the transaction notification to the wallet server 108 via an API call. The logic module 110 is configured to process the transaction notification including extracting primary device data for the corresponding digital wallet from the directory service 114. The logic module 110 generates digital wallet transaction notification data and transmits this data to the primary device 102 via the communications network 106. The digital wallet transaction notification data is processed by the primary device 102 to provide an indication of the success or failure of the digital wallet payment to the user 101. In the described embodiments, a corresponding digital receipt is displayed to the user 101 via GUI elements of the primary device 102. In some embodiments, the wallet server 108 is configured to store an indication of the success or failure of the digital wallet payment associated with a particular cross device digital wallet payment request in a payment record table (as described above), or similar data structure.")
Lin does not explicitly teach, however, Kumar does teach:
select some external electronic device among the at least one external electronic device
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data.")
output, via the at least one communication circuitry, the request to the selected some external electronic device.
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin and Kumar, because it allows for improved systems for redirecting to a trusted device for secured data transmission. (Kumar at Abstract and paras. 2-4).
Lin and Kumar do not explicitly teach, however, Rezayee does teach:
capable of generating the other payment signal
(Rezayee US20220374861 at paras. 48-51) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems that provide for communication of payment data to be secure and reliable and allows for the process of requesting payment, including the reading of payment data and initiation of the payment transaction, to be efficient and quick so as to reduce burdens on the consumer and encourage the consumer to use a payment device for a payment transaction.. (Rezayee at Abstract and paras. 2-4).
Lin, Kumar, and Rezayee do not explicitly teach, however, Smets does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: output, via the at least one communication circuitry, the payment signal based on a first communication protocol to the outside,
(Smets US20210127436 at paras. 69-74) ("[0069] More particularly, the first communication circuitry 106 may be configured to transmit data to or receive data from the communication device 100 using any type of suitable Contactless and Mobile EMV® technology." "[0071] The processor circuitry 108 is configured to control the first communication circuitry 106 to receive from the communication device 100 first data for initiating an electronic payment from a user of the communication device 100 to a user of the POS device 105. The processor circuitry 108 is configured to determine whether it is possible for the second communication circuitry 107 to receive second data from the communication device 100 or transmit second data from the communication device 100, the second data being associated with the electronic payment initiated by the first data. when it is determined that it is possible for the second communication circuitry to receive the second data from the communication device 100 or to transmit the second data to the communication device 100, the processor circuitry 108 is configured to control the second communication circuitry 107 to receive the second data from the communication device 100 or to transmit the second data to the communication device 100.")
based on a second communication protocol different from the first communication protocol, and
(Smets US20210127436 at paras. 69-74) ("[0069] More particularly, the first communication circuitry 106 may be configured to transmit data to or receive data from the communication device 100 using any type of suitable Contactless and Mobile EMV® technology." "[0070] The second communication circuitry 107 is configured to receive data from the communication device 100 or transmit data to the communication device 100 via a wireless network (implemented by transmission of data via radio signals). For example, the second communication circuitry may be configured to transmit data to or receive data from the communication device over a Bluetooth® interface, a Wireless Local Area Network (WLAN) interface (such as Wi-Fi®) or a mobile telecommunications interface (such as Long Term Evolution (LTE)). More generally, the second communication circuitry 107 is configured to transmit data to or receive data from the communication device 105 via a wireless network comprising at least the communication device 100 and POS device 105. A wireless network should be understood to refer to two or more data processing devices which are connected such that data can be transmitted between those devices without requiring those devices to be in sufficiently close proximity for data to be transmitted between those devices using electromagnetic induction (for example, within a distance of the order of a few centimetres or, more particularly, approximately 4 cm for NFC). At least two of the data processing devices of the wireless network are configured to transmit data to and/or receive data from each other wirelessly (using radio signals). It will be appreciated that the second communication circuitry 107 may be configured to receive the second data via a wired connection, wherein that second data has previously been transmitted wirelessly by the second communication circuitry 102 of the communication device 100 but received and re-transmitted by another element of the network (such as a mobile telecommunications base station or WLAN base station, for example) using a wired connection to the POS device 105. The second data may also be transmitted to the POS device 106 via one or more intermediary device such as a network-enabled cash register or the like to which the POS device 106 is connected. It will be appreciated that, when transmitting the second data, the second communication circuitry 107 in this case will transmit the second data using a wired connection. The second data will then be received by a suitable element of the network (via a cash register or the like, if applicable) and re-transmitted using a wireless connection for reception of the second data by the communication device 100. The second data is therefore still transmitted between the POS device 105 and the communication device 100 via a radio signal." "[0071] The processor circuitry 108 is configured to control the first communication circuitry 106 to receive from the communication device 100 first data for initiating an electronic payment from a user of the communication device 100 to a user of the POS device 105. The processor circuitry 108 is configured to determine whether it is possible for the second communication circuitry 107 to receive second data from the communication device 100 or transmit second data from the communication device 100, the second data being associated with the electronic payment initiated by the first data. when it is determined that it is possible for the second communication circuitry to receive the second data from the communication device 100 or to transmit the second data to the communication device 100, the processor circuitry 108 is configured to control the second communication circuitry 107 to receive the second data from the communication device 100 or to transmit the second data to the communication device 100.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, and Smets, because it allows for improved systems to provide for different communication technologies implemented within a single device to be used together in an efficient manner so as to provide improved functionality of that device, and improves user efficiency via a user interface by reducing human interactions with the system and simplifying session establishment, and provides users with improved choice, enabling more narrowly tailored functionality to each user for improved user satisfaction. (Smets at Abstract and paras. 2-8, 56).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Wood, U.S. Patent Application Publication Number 2017/0277498.
As per claim 9,
Lin explicitly teaches:
obtain, via the at least one communication circuitry, a result signal indicating that the payment is successful from a server associated with the payment information, and
(Lin US20180121908 at paras. 94-99) ("[0098] The transaction is then processed, at step 806, in accordance with standard procedures for processing a financial transaction involving an acquirer 132, a card association entity 134, and a corresponding issuer 136. At the conclusion of the transaction processing, a transaction notification is received by the merchant application 119 indicating the authorisation or denial of the payment for the transaction (at step 808). The cross device digital wallet payment system 100 is configured to display a notification of the successful completion of the transaction on the secondary device 104 used to initiate the transaction, and the primary device 102 used to perform the payment (at step 314). If the transaction notification indicates that the payment is authorised, the merchant application 119 is configured to display the success of the payment, and a corresponding digital receipt for the transaction, via GUI elements of the secondary device 104. [0099] The merchant application 119 is configured to transmit the transaction notification to the wallet server 108 via an API call. The logic module 110 is configured to process the transaction notification including extracting primary device data for the corresponding digital wallet from the directory service 114. The logic module 110 generates digital wallet transaction notification data and transmits this data to the primary device 102 via the communications network 106. The digital wallet transaction notification data is processed by the primary device 102 to provide an indication of the success or failure of the digital wallet payment to the user 101. In the described embodiments, a corresponding digital receipt is displayed to the user 101 via GUI elements of the primary device 102. In some embodiments, the wallet server 108 is configured to store an indication of the success or failure of the digital wallet payment associated with a particular cross device digital wallet payment request in a payment record table (as described above), or similar data structure.")
Lin and Kumar do not explicitly teach, however, Rezayee does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: after outputting the payment signal to the outside,
(Rezayee US20220374861 at paras. 48-51) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems that provide for communication of payment data to be secure and reliable and allows for the process of requesting payment, including the reading of payment data and initiation of the payment transaction, to be efficient and quick so as to reduce burdens on the consumer and encourage the consumer to use a payment device for a payment transaction.. (Rezayee at Abstract and paras. 2-4).
Lin, Kumar, and Rezayee do not explicitly teach, however, Wood does teach:
in response to obtaining the result signal, output, via the at least one communication circuitry, to the at least one external electronic device, a request to cause the at least one external electronic device to cease displaying the screen.
(Wood US20170277498 at paras. 287-289, 303-305) ("[0288] In some embodiments, electronic device 500 transmits the indication of the need for text input for text input user interface 1202 to multiple devices. For example, in FIG. 12JJ, both devices 511A and 511B have received the indication of the need for text input. As a result, device 511A is displaying text input alert 1242A, and device 511B is displaying text input alert 1242B, both indicating that text input is needed for text input user interface 1202. In some embodiments, to limit the number of devices that are concurrently providing text input to text input user interface 1202, if a user of one of devices 511A and 511B selects their respective text input alerts, the display of the text input alert on the other one of devices 511A and 511B is optionally ceased. For example, in FIGS. 12KK-12LL, a user of device 511B has swiped down text input alert 1242B to select it. As a result, device 511B displays user interface 1244 for entering text into text input user interface 1202, as shown in FIG. 12MM. Because text input alert 1242B on device 511B was selected, device 511A stops displaying text input alert 1242A, as shown in FIG. 12MM." "[0304] In some embodiments, while the text input alert is displayed on the display of the first electronic device, a visual indication, which indicates that text input can be provided to the text input user interface of the second electronic device using the first electronic device, is displayed (1372), by the second electronic device, on the separate display device, such as in FIG. 12E (e.g., a visual indication is displayed in the text input user interface that indicates to the user that text input can be provided using the first electronic device). This visual indication on the separate display device notifies users who can see the separate display of the ability to provide text input to the text input user interface using the first electronic device—something these users may not have known was possible. This increases the efficiency of the interactions between the users and the second electronic device, thus reducing power consumption associated with those interactions. In some embodiments, while displaying the text input alert on the display of the first electronic device, the first electronic device determines (1374) that text input is no longer needed for the text input user interface displayed on the separate display device, such as in FIG. 12V (e.g., the second electronic device optionally transmits, to the first electronic device, an indication that the text input is no longer needed. For example, completion of text entry, or navigation away from the text input user interface, optionally cause the second electronic device to indicate as much to the first electronic device). In response to determining that text input is no longer needed for the text input user interface displayed on the separate display device, the first electronic device optionally ceases (1376) display of the text input alert on the display of the first electronic device, such as in FIG. 12V (e.g., when text input is no longer needed, the text input alert is optionally no longer displayed).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, Singh, and Wood, because it allows for improved systems for providing navigational inputs to an electronic device using a multifunction device, and user interactions with such devices and that improves the user's experience with the device and decreases user interaction time. (Wood at Abstract and paras. 2-12).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Dayan, U.S. Patent Application Publication Number 2016/0232516.
As per claim 10,
Lin explicitly teaches:
for the payment based on at least one card among a plurality of cards, and
(Lin US20180121908 at paras. 87-90, 94) ("[0088] At step 704, the user 101 selects a payment source from the candidate payment sources associated with the digital wallet (i.e. payment sources added to the digital wallet application 103, as described above), and enters corresponding authentication information to authenticate the digital wallet payment with this selected instrument, at step 706 (as described above). The digital wallet application 103 prompts the user 101 to confirm the digital wallet payment by the display of a GUI element, such as a dialogue box, at step 708. If the user 101 confirms the payment, then the digital wallet application 103 generates payment information representing the selected payment source, and transmits this information to the wallet server 108. [0089] In other embodiments, the cross device digital wallet payment system 100 can be configured to allow the user 101 to perform an “express payment” in place of the payment source selection and authentication steps 702 and 704. Specifically, in these embodiments the user 101 can designate a particular candidate payment source as a default instrument to use for express checkouts. The user 101 can perform a payment with this default instrument without entering any associated authentication credentials. When executing the digital wallet application 103, the user 101 can select to perform an express checkout and proceed directly to confirmation of the digital wallet payment, at step 708." "[0090] The payment information of the selected (or default) payment source is received by the communications module 116 of the wallet server 108 and is transmitted to the logic module 110 for processing, at step 610. The logic module 110 resolves the received payment information to the corresponding payment information request received by the merchant application 119. In some embodiments, the details of the payment information provided by the digital wallet application 103 are recorded by the directory service 114 of the wallet server 108 in a payment record structure such as for example a ‘payment record’ database table. The payment record structure records requests for cross device digital wallet payments associated with a particular wallet profile of a user registered with the system 100, and the corresponding payment information provided by this user's digital wallet in response to the request. For example, the information recorded in each payment record structure entry may include: a wallet identifier; the payment notification details that were transmitted to the digital wallet specified by the wallet identifier; and the payment information provided by the digital wallet to complete the payment." "[0094] If the completion of the digital wallet payment is successful, then the wallet server 108 transmits the digital wallet payment information to the secondary device 104 (at step 310). At step 312, the digital wallet payment information is processed by the merchant application 119 to generate a financial payment transaction to complete the payment for the transaction initiated by the user 101 (as described above at step 502). As shown in FIG. 8, at step 802 the merchant application 119 transmits merchant details including merchant identification and acquirer information, the purchase information, and the received payment information to the payment gateway 130.")
obtain at least one piece of the payment information by
(Lin US20180121908 at paras. 87-90, 94) ("[0088] At step 704, the user 101 selects a payment source from the candidate payment sources associated with the digital wallet (i.e. payment sources added to the digital wallet application 103, as described above), and enters corresponding authentication information to authenticate the digital wallet payment with this selected instrument, at step 706 (as described above). The digital wallet application 103 prompts the user 101 to confirm the digital wallet payment by the display of a GUI element, such as a dialogue box, at step 708. If the user 101 confirms the payment, then the digital wallet application 103 generates payment information representing the selected payment source, and transmits this information to the wallet server 108. [0089] In other embodiments, the cross device digital wallet payment system 100 can be configured to allow the user 101 to perform an “express payment” in place of the payment source selection and authentication steps 702 and 704. Specifically, in these embodiments the user 101 can designate a particular candidate payment source as a default instrument to use for express checkouts. The user 101 can perform a payment with this default instrument without entering any associated authentication credentials. When executing the digital wallet application 103, the user 101 can select to perform an express checkout and proceed directly to confirmation of the digital wallet payment, at step 708." "[0090] The payment information of the selected (or default) payment source is received by the communications module 116 of the wallet server 108 and is transmitted to the logic module 110 for processing, at step 610. The logic module 110 resolves the received payment information to the corresponding payment information request received by the merchant application 119. In some embodiments, the details of the payment information provided by the digital wallet application 103 are recorded by the directory service 114 of the wallet server 108 in a payment record structure such as for example a ‘payment record’ database table. The payment record structure records requests for cross device digital wallet payments associated with a particular wallet profile of a user registered with the system 100, and the corresponding payment information provided by this user's digital wallet in response to the request. For example, the information recorded in each payment record structure entry may include: a wallet identifier; the payment notification details that were transmitted to the digital wallet specified by the wallet identifier; and the payment information provided by the digital wallet to complete the payment." "[0094] If the completion of the digital wallet payment is successful, then the wallet server 108 transmits the digital wallet payment information to the secondary device 104 (at step 310). At step 312, the digital wallet payment information is processed by the merchant application 119 to generate a financial payment transaction to complete the payment for the transaction initiated by the user 101 (as described above at step 502). As shown in FIG. 8, at step 802 the merchant application 119 transmits merchant details including merchant identification and acquirer information, the purchase information, and the received payment information to the payment gateway 130.")
Lin, Kumar, and Rezayee do not explicitly teach, however, Dayan does teach:
further comprising: at least one sensor, wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: obtain, via the at least one sensor, a user gesture
(Dayan US20160232516 at paras. 28-29, 33-34) ("[0033] If reauthorization is required, resolution module 44 and/or a resolution module of secondary device 32 can further determine if a higher level of reauthorization (i.e., greater security measure required), which may detract from the user experience, or a lower level of reauthorization (i.e., lower security measure required), which may result in a smoother user experience. In order to satisfy the lower level reauthorization requirement, resolution module 44 and/or a resolution module of secondary device 32 may use less secure data, such as GPS location information, network neighborhood information determined using Wi-Fi, etc. In order to satisfy the higher level reauthorization requirement, resolution module 44 and/or a resolution module of secondary device 32 may use more reliable data for particularly identifying the user of mobile computing device 30 and secondary device 32, such as fingerprint data, audio data for voice recognition, passwords, pin patterns, visual data for facial recognition, motion data (e.g., when requiring the user to perform a particular gesture using either mobile computing device 30 or secondary device 32), etc. While the various types of data are described as being used for lower level or higher level reauthorization requirements, any of the various types of data may be used for either or both levels of reauthorization requirement and a user may configure which types of data may be used for each level of reauthorization requirement. [0034] In some examples, a security challenge required to reauthorize the user may be performed using either mobile computing device 30 or secondary device 32. For example, if resolution module 44 requires the user to enter a password in order to reauthorize the user, the user may be able to enter the password by providing input to secondary device 32, which transmits the input to mobile computing device 30. As another example, the user may place his/her finger on a fingerprint sensor of secondary device 32 and secondary device 32 may generate the fingerprint information and provide it to resolution module 44.")
based on the data indicating the user gesture,
(Dayan US20160232516 at paras. 33-34) ("[0033] If reauthorization is required, resolution module 44 and/or a resolution module of secondary device 32 can further determine if a higher level of reauthorization (i.e., greater security measure required), which may detract from the user experience, or a lower level of reauthorization (i.e., lower security measure required), which may result in a smoother user experience. In order to satisfy the lower level reauthorization requirement, resolution module 44 and/or a resolution module of secondary device 32 may use less secure data, such as GPS location information, network neighborhood information determined using Wi-Fi, etc. In order to satisfy the higher level reauthorization requirement, resolution module 44 and/or a resolution module of secondary device 32 may use more reliable data for particularly identifying the user of mobile computing device 30 and secondary device 32, such as fingerprint data, audio data for voice recognition, passwords, pin patterns, visual data for facial recognition, motion data (e.g., when requiring the user to perform a particular gesture using either mobile computing device 30 or secondary device 32), etc. While the various types of data are described as being used for lower level or higher level reauthorization requirements, any of the various types of data may be used for either or both levels of reauthorization requirement and a user may configure which types of data may be used for each level of reauthorization requirement. [0034] In some examples, a security challenge required to reauthorize the user may be performed using either mobile computing device 30 or secondary device 32. For example, if resolution module 44 requires the user to enter a password in order to reauthorize the user, the user may be able to enter the password by providing input to secondary device 32, which transmits the input to mobile computing device 30. As another example, the user may place his/her finger on a fingerprint sensor of secondary device 32 and secondary device 32 may generate the fingerprint information and provide it to resolution module 44.")
authenticating a user.
(Dayan US20160232516 at paras. 33-34) ("[0033] If reauthorization is required, resolution module 44 and/or a resolution module of secondary device 32 can further determine if a higher level of reauthorization (i.e., greater security measure required), which may detract from the user experience, or a lower level of reauthorization (i.e., lower security measure required), which may result in a smoother user experience. In order to satisfy the lower level reauthorization requirement, resolution module 44 and/or a resolution module of secondary device 32 may use less secure data, such as GPS location information, network neighborhood information determined using Wi-Fi, etc. In order to satisfy the higher level reauthorization requirement, resolution module 44 and/or a resolution module of secondary device 32 may use more reliable data for particularly identifying the user of mobile computing device 30 and secondary device 32, such as fingerprint data, audio data for voice recognition, passwords, pin patterns, visual data for facial recognition, motion data (e.g., when requiring the user to perform a particular gesture using either mobile computing device 30 or secondary device 32), etc. While the various types of data are described as being used for lower level or higher level reauthorization requirements, any of the various types of data may be used for either or both levels of reauthorization requirement and a user may configure which types of data may be used for each level of reauthorization requirement. [0034] In some examples, a security challenge required to reauthorize the user may be performed using either mobile computing device 30 or secondary device 32. For example, if resolution module 44 requires the user to enter a password in order to reauthorize the user, the user may be able to enter the password by providing input to secondary device 32, which transmits the input to mobile computing device 30. As another example, the user may place his/her finger on a fingerprint sensor of secondary device 32 and secondary device 32 may generate the fingerprint information and provide it to resolution module 44.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, and Dayan, because it allows for an improved system for initiating a payment transaction, analyze the sensor data to determine a risk level for the payment transaction, and initiate the payment transaction with a payment system. (Dayan at Abstract and paras. 2-4).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Bradley, U.S. Patent Application Publication Number 2021/0406886.
As per claim 11,
Lin explicitly teaches:
data including payment information from an external electronic device
(Lin US20180121908 at paras. 87-90, 94) ("[0088] At step 704, the user 101 selects a payment source from the candidate payment sources associated with the digital wallet (i.e. payment sources added to the digital wallet application 103, as described above), and enters corresponding authentication information to authenticate the digital wallet payment with this selected instrument, at step 706 (as described above). The digital wallet application 103 prompts the user 101 to confirm the digital wallet payment by the display of a GUI element, such as a dialogue box, at step 708. If the user 101 confirms the payment, then the digital wallet application 103 generates payment information representing the selected payment source, and transmits this information to the wallet server 108. [0089] In other embodiments, the cross device digital wallet payment system 100 can be configured to allow the user 101 to perform an “express payment” in place of the payment source selection and authentication steps 702 and 704. Specifically, in these embodiments the user 101 can designate a particular candidate payment source as a default instrument to use for express checkouts. The user 101 can perform a payment with this default instrument without entering any associated authentication credentials. When executing the digital wallet application 103, the user 101 can select to perform an express checkout and proceed directly to confirmation of the digital wallet payment, at step 708." "[0090] The payment information of the selected (or default) payment source is received by the communications module 116 of the wallet server 108 and is transmitted to the logic module 110 for processing, at step 610. The logic module 110 resolves the received payment information to the corresponding payment information request received by the merchant application 119. In some embodiments, the details of the payment information provided by the digital wallet application 103 are recorded by the directory service 114 of the wallet server 108 in a payment record structure such as for example a ‘payment record’ database table. The payment record structure records requests for cross device digital wallet payments associated with a particular wallet profile of a user registered with the system 100, and the corresponding payment information provided by this user's digital wallet in response to the request. For example, the information recorded in each payment record structure entry may include: a wallet identifier; the payment notification details that were transmitted to the digital wallet specified by the wallet identifier; and the payment information provided by the digital wallet to complete the payment." "[0094] If the completion of the digital wallet payment is successful, then the wallet server 108 transmits the digital wallet payment information to the secondary device 104 (at step 310). At step 312, the digital wallet payment information is processed by the merchant application 119 to generate a financial payment transaction to complete the payment for the transaction initiated by the user 101 (as described above at step 502). As shown in FIG. 8, at step 802 the merchant application 119 transmits merchant details including merchant identification and acquirer information, the purchase information, and the received payment information to the payment gateway 130.")
payment information...
(Lin US20180121908 at paras. 87-90, 94) ("[0088] At step 704, the user 101 selects a payment source from the candidate payment sources associated with the digital wallet (i.e. payment sources added to the digital wallet application 103, as described above), and enters corresponding authentication information to authenticate the digital wallet payment with this selected instrument, at step 706 (as described above). The digital wallet application 103 prompts the user 101 to confirm the digital wallet payment by the display of a GUI element, such as a dialogue box, at step 708. If the user 101 confirms the payment, then the digital wallet application 103 generates payment information representing the selected payment source, and transmits this information to the wallet server 108. [0089] In other embodiments, the cross device digital wallet payment system 100 can be configured to allow the user 101 to perform an “express payment” in place of the payment source selection and authentication steps 702 and 704. Specifically, in these embodiments the user 101 can designate a particular candidate payment source as a default instrument to use for express checkouts. The user 101 can perform a payment with this default instrument without entering any associated authentication credentials. When executing the digital wallet application 103, the user 101 can select to perform an express checkout and proceed directly to confirmation of the digital wallet payment, at step 708." "[0090] The payment information of the selected (or default) payment source is received by the communications module 116 of the wallet server 108 and is transmitted to the logic module 110 for processing, at step 610. The logic module 110 resolves the received payment information to the corresponding payment information request received by the merchant application 119. In some embodiments, the details of the payment information provided by the digital wallet application 103 are recorded by the directory service 114 of the wallet server 108 in a payment record structure such as for example a ‘payment record’ database table. The payment record structure records requests for cross device digital wallet payments associated with a particular wallet profile of a user registered with the system 100, and the corresponding payment information provided by this user's digital wallet in response to the request. For example, the information recorded in each payment record structure entry may include: a wallet identifier; the payment notification details that were transmitted to the digital wallet specified by the wallet identifier; and the payment information provided by the digital wallet to complete the payment." "[0094] If the completion of the digital wallet payment is successful, then the wallet server 108 transmits the digital wallet payment information to the secondary device 104 (at step 310). At step 312, the digital wallet payment information is processed by the merchant application 119 to generate a financial payment transaction to complete the payment for the transaction initiated by the user 101 (as described above at step 502). As shown in FIG. 8, at step 802 the merchant application 119 transmits merchant details including merchant identification and acquirer information, the purchase information, and the received payment information to the payment gateway 130.")
Lin does not explicitly teach, however, Kumar does teach:
An electronic device comprising: a display; at least one communication circuitry; at least one memory, comprising one or more storage media, storing instructions; and at least one processor communicatively coupled to the display, the at least one communication circuitry, and the at least one memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to: receive, via the at least one communication circuitry,
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data.")
based on the receiving, display, on the display, a screen including at least one piece of [payment information], while displaying the screen on the display,
(Kumar US20220051234 at paras. 23-24, 41, 56) ("[0023] The device selection page may be provided to the user at various times. In some instances, the redirecting system provides the device selection page to the user when the user sets up the user's profile at the web site. Additionally or alternatively, the redirecting system provides the device selection page to the user when the user is leaving a payment page associated with a product or service or when the user logs in again to the web site. For example, the user navigates to the payment page for a product or service using a public computer (e.g., a library computer). The user does not trust the public computer to make a payment for the product or service. Upon the user leaving the web site (e.g., navigating away from the payment page), the redirecting system transmits a notification to the public computer stating “Would you like to complete the transaction (e.g., make the payment) on Mobile 1 or Tablet 1?” The user may select Tablet 1. Based on the user's selection, a communication including the user's selection is transmitted to the redirecting system. The redirecting system sends a further communication that includes a notification (e.g., a reminder to complete the payment for the product or service) to Tablet 1. The notification may include a Uniform Resource Locator (also “URL”) for the payment page referencing the product or service. [0024] In some instances, the redirecting system facilitates the completion of the transaction by the user without further authentication of the user. For example, based on a prior authentication of the user (e.g., the user providing correct login information to access the web site), the redirecting system transmits, to a device trusted for payment, the communication that includes the URL to the payment page referencing the product or service previously viewed by the user. Based on a selection (e.g., a click) by the user of the URL, the redirecting system causes a display of the payment page on the device trusted for payment and accepts payment for the product or service without requesting the user to provide authentication data.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin and Kumar, because it allows for improved systems for redirecting to a trusted device for secured data transmission. (Kumar at Abstract and paras. 2-4).
Lin and Kumar do not explicitly teach, however, Rezayee does teach:
receive a request to output a payment signal for payment based on the data to the outside from the external electronic device, and
(Rezayee US20220374861 at paras. 49-50) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
in response to receiving the request, output, via the at least one communication circuitry, the payment signal to the outside.
(Rezayee US20220374861 at paras. 49-50) ("[0048] The NFC transceiver 91 and antenna 96 may be used to wirelessly communicate with the payment reader 22, such as transmitting payment data for a payment transaction. In this regard, the ring 52 may store the payment data 56 in memory 58. When the ring 52 is positioned sufficiently close to the payment reader 22 to be within the magnetic field generated by the reader 22, the NFC transceiver 91 may use active or passive load modulation to communicate the payment data 56 to the payment reader 22." "[0051] In some embodiments, use of the mobile device 100 for payment transactions is unnecessary, and it is possible to use the ring 52 in other ways during a payment transaction. As an example, it is possible for the ring 52 to communicate payment data 56 with the payment reader 22 during a payment transaction without communicating with the mobile device 100. Information about the payment transaction received from the payment reader 22, such as whether the payment transaction is approved or the amount of the payment, may be stored in the ring 52 and accessed at a later time by the mobile device 100 or other device. In some embodiments, payment data 56 to be communicated to the payment reader 22, such as an account number or other identifier of a financial account to be used for the payment and information related to such account (e.g., a PIN or other authentication information) may be stored in the mobile device 100 and accessed by the ring 52 during or prior to the payment transaction. As an example, when the ring 52 is placed within the magnetic field of the payment reader 22, the control circuitry 72 in response to detection of the magnetic field may communicate with the mobile device 100 via the short-range transceiver 92 to retrieve the stored payment data 56 and then communicate the payment data 56 to the payment reader 22 via the NFC transceiver 91. In yet other embodiments, other interactions between the ring 52 and the mobile device 100 are possible.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems that provide for communication of payment data to be secure and reliable and allows for the process of requesting payment, including the reading of payment data and initiation of the payment transaction, to be efficient and quick so as to reduce burdens on the consumer and encourage the consumer to use a payment device for a payment transaction.. (Rezayee at Abstract and paras. 2-4).
Lin, Kumar, and Rezayee do not explicitly teach, however, Bradley does teach:
connected based on short-range wireless communication with the electronic device,
(Bradley US20210406886 at paras. 34-35, 46, 52-53, 68-69) ("[0034] The process 300 may be initiated when the payment requesting device 104, such as a content aggregation device, receives a request to perform a payment transaction (302). For example, the payment requesting device 104 may receive a request to rent/purchase a movie that requires a payment transaction to be performed for a payment amount, e.g., the rental or purchase cost. In one or more implementations, the request may be received as a voice command and/or the request may be received through a device communicatively coupled to the payment requesting device 104, such as a remote control. In response to the request, the payment requesting device 104 broadcasts, via the first communication protocol (such as BLE), a message associated with the payment transaction (304). The message may be, for example, an advertisement or beacon message that may request that any proximate electronic devices 102A-C respond with their current device identifiers for communicating via the second communication protocol, such as Wi-Fi or cellular. In one or more implementations, the device identifiers may change over time. In one or more implementations, the payment requesting device 104 may continually poll the proximate electronic devices 102A-C, such as on a periodic or a periodic basis, to continuously identify which of the electronic devices 102A-C are available when a request for a payment transaction occurs.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, Singh, and Bradley, because it allows for improved systems for payment transaction handoff. (Bradley at Abstract and paras. 2-3).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Bradley, U.S. Patent Application Publication Number 2021/0406886; in view of Yalamanchili, U.S. Patent Application Publication Number 2019/0289124; in view of Wang, U.S. Patent Application Publication Number 2018/0253139.
As per claim 12,
Lin, Kumar, Rezayee, and Bradley do not explicitly teach, however, Yalamanchili does teach:
in response to the running application being a designated application, suspend displaying the screen, and
(Yalamanchili US20190289124 at paras. 22, 29) ("[0022] In some embodiments, the user notification mode may be a deferred notification mode, which may specify that one or more notification feedback should be deferred until a future time or until some other criterion or criteria has been satisfied. For example, the mode may specify that notifications should be deferred until a foreground application on the mobile computing device is no longer in the foreground. In such an example, a user may continue to participate in a videoconference, watch a movie, play a game, share the user's screen, and so forth without interruption from notifications." "[0029] At decision block 212, a determination may be made as to whether the criteria associated with the selected user notification mode are satisfied. For example, the user notification mode may specify that notification feedback should be deferred if a particular application (e.g., a game) is in the foreground, or that only visual feedback should be applied if the device's built-in camera application is in the foreground. It will be understood that the notification mode determination routine 200, and not the foreground application, determines whether a notification mode based on the foreground application applies and takes precedence. For example, two different notification requests may result in different types of feedback being provided, even though both requests are received while the same application is in the foreground, because the second notification request satisfied the criteria of a higher-priority notification mode.")
in response to the running application being distinguished from the designated application, display the screen on the display.
(Yalamanchili US20190289124 at paras. 24, 30) ("[0024] In some embodiments, the notification modes can also include information that establishes a (relative or absolute) priority between different notification modes, and thereby establishes which notification modes should take precedence over others. For example, a first notification mode can specify that notifications should be deferred if the location of the mobile device is associated with a “home” designation and the current time is between 9:00 p.m. and 6:00 a.m., and a second notification mode can specify that notifications should be displayed if the foreground application on the mobile computing device is a web browser. A prioritization may be obtained that causes the second mode to take precedence over the first, such that the user will receive notifications if browsing the web at home after 9:00 p.m., but otherwise notifications will be deferred until 6:00 a.m." "[0030] If the determination at decision block 212 is that the criteria are satisfied for the selected user notification node, then the notification mode determination routine 200 branches to block 218, where the requested notification may be presented in the notification mode specified by the satisfied criterion.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, Bradley, and Yalamanchili, because it allows for improved systems to more effectively managing notifications, thereby reducing conflicts in the operation of software applications on the mobile computing device while improving receipt of desired notifications and improves the performance of a mobile computing device at the task of displaying relevant information. (Yalamanchili at Abstract and paras. 2-12).
Lin, Kumar, Rezayee, Bradley, and Yalamanchili do not explicitly teach, however, Wang does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: based on receiving the data, identify a running application,
(Wang US20180253139 at paras. 52, 57-59) ("[0052] For instance, a first call prompted in connection with a first application-level activity may include a first format or code that is unique to the first application-level activity. Similarly, a second call prompted in connection with a second application-level activity may include a second format or code that is unique to the second application-level activity. As one possibility, the call 312 may accomplish this by specifically identifying the corresponding application-level state (e.g. by naming an associated activity, etc.), as well as an indication of a specific status thereof (e.g. starting, stopping, degree, etc.). Even still, the call 312 may further identify the application, as well, in some optional embodiments." "[0059] Thus, if the application is not running in the background per decision 406, the call is translated into an IPC in operation 408. For reasons that will soon become apparent, the call may, in various embodiments, either explicitly or implicitly identify a particular application state (e.g. usage scenario) that prompted the call to be generated and sent. In such case, the translation of operation 408 may be such that this state indication is maintained either in its original or a translated form, so that such information may be available for subsequent processes.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, Bradley, Yalamanchili, and Wang, because it allows for an improved system for reducing an energy consumption of hardware on which an application is running. (Wang at Abstract and paras. 2-18).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Bradley, U.S. Patent Application Publication Number 2021/0406886; in view of Yalamanchili, U.S. Patent Application Publication Number 2019/0289124; in view of Wang, U.S. Patent Application Publication Number 2018/0253139; in view of Pareek, U.S. Patent Application Publication Number 2018/0322496.
As per claim 13,
Lin and Kumar do not explicitly teach, however, Rezayee does teach:
output the payment signal [generated based on payment failure type information] included in the result signal to the outside.
(Rezayee US20220374861 at paras. 49-50) ("[0049] During the transaction, the mobile device 100 may be used to interface with the user. As an example, if the payment transaction requires the user to enter a valid personal identification number (PIN), the control circuitry 72 may be configured to transmit a prompt for the user's PIN to the mobile device 100 via the short-range transceiver 92 and antenna 97. The user may enter his or her PIN to the mobile device 100, which then transmits such PIN to the ring 52. The short-range transceiver 92 may receive the PIN, and the control circuitry 72 may include the PIN as part of the payment data 56 transmitted to the payment reader 22 via the NFC transceiver 91 and antenna 96. [0050] In another example, the user may be requested to approve the payment request. As an example, the payment reader 22 may transmit details of the payment transaction, such as the amount of payment to be requested. This information may be received by the NFC transceiver 91 and transmitted to the mobile device 100 by the short-range transceiver 92. The mobile device 100 may display the information to the user and prompt the user to confirm that the request for payment in the amount indicated is approved. Upon receiving such confirmation by the user, the mobile device 100 may transmit an approval of the payment request to the short-range transceiver 92. Upon receiving such approval, the control circuitry 72 may transmit the payment data 56 to the payment reader 22 in order to initiate the payment transaction. Various other types of information regarding the payment transaction may be communicated by the ring 52 in other embodiments.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, and Rezayee, because it allows for improved systems that provide for communication of payment data to be secure and reliable and allows for the process of requesting payment, including the reading of payment data and initiation of the payment transaction, to be efficient and quick so as to reduce burdens on the consumer and encourage the consumer to use a payment device for a payment transaction. (Rezayee at Abstract and paras. 2-4).
Lin, Kumar, Rezayee, Bradley, Yalamanchili, and Wang do not explicitly teach, however, Pareek does teach:
wherein the instructions, when executed by the at least one processor individually or collectively, further cause the electronic device to: receive the request based on a result signal indicating that the payment has failed, and
(Pareek US20180322496 at paras. 9-11, 15-17) ("[0010] According to a first aspect of the present disclosure, there is provided a system for automated switching of payment devices during a payment transaction, comprising a facilitator module, the facilitator module comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the facilitator module at least to: (i) in response to a payment status message from an issuer of a primary payment device which is indicative of a partial approval or a decline of a payment transaction request for the primary payment device, retrieve, from a database, identification data for a secondary payment device which is associated with the primary payment device; (ii) generate a secondary payment instruction comprising the identification data of the secondary payment device, and an amount or a remaining amount of the payment transaction; and (iii) transmit the secondary payment instruction to an issuer of the secondary payment device." "[0016] In an embodiment, the facilitator module may be further caused to: receive confirmation of an invalid Personal Identification Number (PIN) of the primary payment device; transmit, from the issuer, information confirming the invalidity of the primary payment device PIN; retrieve, from the database, identification data for payment using the secondary payment device; transmit, to the user, a request for a Personal Identification Number (PIN) associated with the secondary payment device; and transmit the payment transaction request to the issuer of the secondary payment device based on a successful verification of the PIN associated with the secondary payment device.")
generated based on payment failure type information…
(Pareek US20180322496 at paras. 9-11, 15-17) ("[0010] According to a first aspect of the present disclosure, there is provided a system for automated switching of payment devices during a payment transaction, comprising a facilitator module, the facilitator module comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the facilitator module at least to: (i) in response to a payment status message from an issuer of a primary payment device which is indicative of a partial approval or a decline of a payment transaction request for the primary payment device, retrieve, from a database, identification data for a secondary payment device which is associated with the primary payment device; (ii) generate a secondary payment instruction comprising the identification data of the secondary payment device, and an amount or a remaining amount of the payment transaction; and (iii) transmit the secondary payment instruction to an issuer of the secondary payment device." "[0016] In an embodiment, the facilitator module may be further caused to: receive confirmation of an invalid Personal Identification Number (PIN) of the primary payment device; transmit, from the issuer, information confirming the invalidity of the primary payment device PIN; retrieve, from the database, identification data for payment using the secondary payment device; transmit, to the user, a request for a Personal Identification Number (PIN) associated with the secondary payment device; and transmit the payment transaction request to the issuer of the secondary payment device based on a successful verification of the PIN associated with the secondary payment device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, Bradley, Yalamanchili, Wang, and Pareek, because it allows for improved systems for automated switching of payment devices in a payment transaction, and a method performed by that system. (Pareek at Abstract and paras. 2-8).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Lin, U.S. Patent Application Publication Number 2018/0121908; in view of Kumar, U.S. Patent Application Publication Number 2022/0051234; in view of Rezayee, U.S. Patent Application Publication Number 2022/0374861; in view of Bradley, U.S. Patent Application Publication Number 2021/0406886; in view of Yalamanchili, U.S. Patent Application Publication Number 2019/0289124; in view of Wang, U.S. Patent Application Publication Number 2018/0253139; in view of Smets, U.S. Patent Application Publication Number 2021/0127436.
As per claim 14,
Lin, Kumar, Rezayee, Bradley, Yalamanchili, and Wang do not explicitly teach, however, Smets does teach:
wherein the payment signal is generated based on a communication protocol different from a communication protocol based on which another payment signal generated by the external electronic device for the payment is based.
(Smets US20210127436 at paras. 69-74) ("[0069] More particularly, the first communication circuitry 106 may be configured to transmit data to or receive data from the communication device 100 using any type of suitable Contactless and Mobile EMV® technology." "[0070] The second communication circuitry 107 is configured to receive data from the communication device 100 or transmit data to the communication device 100 via a wireless network (implemented by transmission of data via radio signals). For example, the second communication circuitry may be configured to transmit data to or receive data from the communication device over a Bluetooth® interface, a Wireless Local Area Network (WLAN) interface (such as Wi-Fi®) or a mobile telecommunications interface (such as Long Term Evolution (LTE)). More generally, the second communication circuitry 107 is configured to transmit data to or receive data from the communication device 105 via a wireless network comprising at least the communication device 100 and POS device 105. A wireless network should be understood to refer to two or more data processing devices which are connected such that data can be transmitted between those devices without requiring those devices to be in sufficiently close proximity for data to be transmitted between those devices using electromagnetic induction (for example, within a distance of the order of a few centimetres or, more particularly, approximately 4 cm for NFC). At least two of the data processing devices of the wireless network are configured to transmit data to and/or receive data from each other wirelessly (using radio signals). It will be appreciated that the second communication circuitry 107 may be configured to receive the second data via a wired connection, wherein that second data has previously been transmitted wirelessly by the second communication circuitry 102 of the communication device 100 but received and re-transmitted by another element of the network (such as a mobile telecommunications base station or WLAN base station, for example) using a wired connection to the POS device 105. The second data may also be transmitted to the POS device 106 via one or more intermediary device such as a network-enabled cash register or the like to which the POS device 106 is connected. It will be appreciated that, when transmitting the second data, the second communication circuitry 107 in this case will transmit the second data using a wired connection. The second data will then be received by a suitable element of the network (via a cash register or the like, if applicable) and re-transmitted using a wireless connection for reception of the second data by the communication device 100. The second data is therefore still transmitted between the POS device 105 and the communication device 100 via a radio signal." "[0071] The processor circuitry 108 is configured to control the first communication circuitry 106 to receive from the communication device 100 first data for initiating an electronic payment from a user of the communication device 100 to a user of the POS device 105. The processor circuitry 108 is configured to determine whether it is possible for the second communication circuitry 107 to receive second data from the communication device 100 or transmit second data from the communication device 100, the second data being associated with the electronic payment initiated by the first data. when it is determined that it is possible for the second communication circuitry to receive the second data from the communication device 100 or to transmit the second data to the communication device 100, the processor circuitry 108 is configured to control the second communication circuitry 107 to receive the second data from the communication device 100 or to transmit the second data to the communication device 100.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lin, Kumar, Rezayee, Bradley, Yalamanchili, Wang, and Smets, because it allows for improved systems to provide for different communication technologies implemented within a single device to be used together in an efficient manner so as to provide improved functionality of that device, and improves user efficiency via a user interface by reducing human interactions with the system and simplifying session establishment, and provides users with improved choice, enabling more narrowly tailored functionality to each user for improved user satisfaction. (Smets at Abstract and paras. 2-8, 56).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
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, Christine Tran can be reached on 571-272-8103. 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights