Electronic device, method, and non-transitory computer-readable storage medium for making payment

Abstract

Disclosed is an electronic device. The electronic device may be configured to acquire, in response to an input requesting payment, payment information related to the payment request. The electronic device may be configured to transmit data including the payment information to at least one external electronic device different from the electronic device via at least one communication circuit in response to obtaining the payment information, wherein the data causes the at least one external electronic device to display a screen, including at least a portion of the payment information, on a display of the at least one external electronic device. The electronic device may be configured to radiate a signal for payment based on data including the payment information to the outside via at least one communication circuit in response to acquiring the payment information.

Description

Electronic device, method, and non-transitory computer-readable storage medium for performing payment

[0001] The following descriptions relate to electronic devices, methods, and non-transitory computer-readable storage media for performing payments.

[0002] Electronic devices come in various forms, such as smartphones that users can carry around with them or wearable devices that can be attached to parts of the user's body. These electronic devices are rapidly becoming more sophisticated thanks to advances in information technology (IT), and can provide users with a variety of functions.

[0003] Electronic devices can provide payment services to users. For example, the electronic device can process payments by transmitting payment information to a payment device using near field communication (NFC) or magnetic stripe transmission (MST).

[0004] An electronic device is disclosed. The electronic device may include at least one communication circuit. The electronic device may include at least one processor. The electronic device may include at least one memory storing instructions. The instructions, when executed by the at least one processor, may be configured to cause the electronic device, in response to an input requesting payment, to obtain payment information related to the payment request. The instructions, when executed by the at least one processor, may be configured to cause the electronic device, in response to obtaining the payment information, to transmit data including the payment information to at least one external electronic device through the at least one communication circuit, such that the electronic device causes the electronic device and at least one external electronic device to display a screen including at least one piece of the payment information on a display of the at least one external electronic device. The instructions, when executed by the at least one processor, may be configured to cause the electronic device, in response to obtaining the payment information, to emit, through the at least one communication circuit, a payment signal for the payment based on the data including the payment information to the outside.

[0005] A method is disclosed. The method may be performed by an electronic device including at least one communication circuit. The method may include, in response to an input requesting payment, obtaining payment information related to the payment request. The method may include, in response to obtaining the payment information, transmitting data including the payment information to at least one external electronic device through the at least one communication circuit, the data causing the electronic device and at least one external electronic device to display a screen including at least one piece of the payment information on a display of the at least one external electronic device. The method may include, in response to obtaining the payment information, emitting a payment signal for the payment based on the data including the payment information to the outside through the at least one communication circuit.

[0006] A non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium may include a program storing instructions. The instructions, when executed by at least one processor of an electronic device including at least one communication circuit, may cause the electronic device, in response to an input requesting a payment, to obtain payment information related to the payment request. The instructions, when executed by the at least one processor, may cause the electronic device, in response to obtaining the payment information, to transmit data including the payment information to at least one external electronic device through the at least one communication circuit, such that the electronic device and at least one external electronic device display a screen including at least one piece of the payment information on a display of the at least one external electronic device. The instructions, when executed by the at least one processor, may cause the electronic device, in response to obtaining the payment information, to emit, through the at least one communication circuit, a payment signal for the payment based on the data including the payment information to the outside.

[0007] An electronic device is disclosed. The electronic device may include a display. The electronic device may include at least one communication circuit. The electronic device may include at least one processor. The electronic device may include at least one memory storing instructions. The instructions, when executed by the at least one processor, may be configured to cause the electronic device to receive data including payment information from an external electronic device that is communicably connected to the electronic device based on short-range wireless communication via the at least one communication circuit. The instructions, when executed by the at least one processor, may be configured to cause the electronic device, based on receiving the data including the payment information, to display a screen including at least one piece of the payment information on the display. The instructions, when executed by the at least one processor, may be configured to cause the electronic device, while displaying the screen on the display, to receive a request from the external electronic device to externally emit a signal for payment based on the data. The instructions, when executed by the at least one processor, may be configured to cause the electronic device, in response to receiving the request, to externally emit the signal for the payment based on the data through the at least one communication circuit.

[0008] A method is disclosed. The method may be performed by an electronic device including a display and at least one communication circuit. The method may include receiving data including payment information from an external electronic device that is communicably connected to the electronic device based on short-range wireless communication via the at least one communication circuit. The method may include displaying a screen including at least one piece of payment information on the display based on the data received. The method may include receiving a request from the external electronic device to externally emit a signal for payment based on the data while the screen is displayed on the display. The method may include, in response to receiving the request, emitting the signal for payment based on the data via the at least one communication circuit.

[0009] A non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium may include a program storing instructions. The instructions, when executed by at least one processor of an electronic device including a display and at least one communication circuit, may cause the electronic device to receive data including payment information from an external electronic device that is communicatively connected to the electronic device based on short-range wireless communication via the at least one communication circuit. The instructions, when executed by the at least one processor, may cause the electronic device, based on receiving the data including the payment information, to display a screen including at least one piece of payment information on the display. The instructions, when executed by the at least one processor, may cause the electronic device, while displaying the screen on the display, to receive a request from the external electronic device to externally emit a signal for payment based on the data. The instructions, when executed by the at least one processor, may cause the electronic device, in response to receiving the request, to externally emit the signal for the payment based on the data through the at least one communication circuit.

[0010] FIG. 1 is a block diagram of an electronic device within a network environment according to various embodiments.

[0011] Figure 2a is a block diagram of an electronic device within a payment environment.

[0012] Figure 2b is a block diagram of an electronic device within a payment environment.

[0013] FIG. 3 is a flowchart illustrating an operation of an electronic device obtaining a token according to one embodiment.

[0014] FIG. 4 is a flowchart illustrating an operation of an electronic device triggering entry into payment mode according to one embodiment.

[0015] FIG. 5 is a flowchart illustrating an operation of an electronic device triggering another electronic device depending on whether a payment is successful, according to one embodiment.

[0016] FIG. 6 is a flowchart illustrating an operation of an electronic device triggering another electronic device depending on whether a payment is successful, according to one embodiment.

[0017] FIG. 7 is a flowchart illustrating an operation of an electronic device according to one embodiment of the present invention to trigger another electronic device depending on whether a payment by the other electronic device is successful.

[0018] FIG. 8 is a flowchart illustrating an operation of an electronic device according to one embodiment of the present invention to trigger another electronic device depending on whether a payment by the other electronic device is successful.

[0019] FIG. 9 is a flowchart illustrating an operation of another electronic device triggering another electronic device depending on whether a payment is successful, according to one embodiment.

[0020] FIG. 10 is a flowchart illustrating an operation of another electronic device triggering another electronic device depending on whether a payment is successful, according to one embodiment.

[0021] FIG. 11 is a flowchart illustrating an operation of another payment framework emitting a payment signal according to one embodiment.

[0022] FIG. 12 is a flowchart illustrating an operation of another payment framework transmitting a payment signal according to one embodiment.

[0023] FIG. 13 is a flowchart illustrating an operation in which another electronic device requests another electronic device to display a message depending on whether a payment is successful, according to one embodiment.

[0024] FIG. 14A illustrates an example of a screen displayed by electronic devices according to one embodiment.

[0025] FIG. 14b illustrates an example of a screen displayed by electronic devices according to one embodiment.

[0026] FIG. 15A illustrates an example of a message displayed by electronic devices according to one embodiment.

[0027] FIG. 15b illustrates an example of a message displayed by electronic devices according to one embodiment.

[0028] FIG. 16 is a flowchart illustrating an operation of an electronic device triggering entry into payment mode according to one embodiment.

[0029] FIG. 17 is a flowchart illustrating an operation of an electronic device triggering payment of another electronic device according to one embodiment.

[0030] FIG. 18 is a flowchart illustrating an operation of an electronic device triggering payment of another electronic device according to one embodiment.

[0031] FIG. 19 is a flowchart illustrating an operation of an electronic device triggering payment of another electronic device according to one embodiment.

[0032] FIG. 1 is a block diagram of a first electronic device (101) within a network environment (100) according to various embodiments.

[0033] Referring to FIG. 1, in a network environment (100), a first electronic device (101) may communicate with a second electronic device (102) via a first network (198) (e.g., a short-range wireless communication network), or may communicate with 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 one embodiment, the first electronic device (101) may communicate with the electronic device (104) via the server (108). According to one embodiment, the first electronic device (101) may include a processor (120), a memory (130), an input module (150), an audio output module (155), a display module (160), an audio module (170), a sensor module (176), an interface (177), a connection 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 (196), or an antenna module (197). In some embodiments, the first electronic device (101) may have at least one of these components (e.g., the connection terminal (178)) omitted, or one or more other components added. In some embodiments, some of these components (e.g., the sensor module (176), the camera module (180), or the antenna module (197)) may be integrated into one component (e.g., the display module (160)).

[0034] The processor (120) may, for example, execute software (e.g., a program (140)) to control at least one other component (e.g., a hardware or software component) of the first electronic device (101) connected to the processor (120) and perform various data processing or operations. According to one embodiment, as at least a part of the data processing or operations, the processor (120) may store commands or data received from other components (e.g., a sensor module (176) or a communication module (190)) in a volatile memory (132), process the commands or data stored in the volatile memory (132), and store result data in a non-volatile memory (134). According to one embodiment, the processor (120) may include a main processor (121) (e.g., a central processing unit or an application processor) or an auxiliary processor (123) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together with the main processor (121). For example, when the first electronic device (101) includes a main processor (121) and an auxiliary processor (123), the auxiliary processor (123) may be configured to use lower power than the main processor (121) or to be specialized for a given function. The auxiliary processor (123) may be implemented separately from the main processor (121) or as a part thereof.

[0035] The auxiliary processor (123) may control at least a part of functions or states associated with at least one component (e.g., a display module (160), a sensor module (176), or a communication module (190)) of the first electronic device (101), for example, on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (123) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (180) or a communication module (190)). In one embodiment, the auxiliary processor (123) (e.g., a neural network processing device) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, in the first electronic device (101) itself where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (108)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0036] The memory (130) can store various data used by at least one component (e.g., processor (120) or sensor module (176)) of the first electronic device (101). The data can include, for example, software (e.g., program (140)) and input data or output data for commands related thereto. The memory (130) can include volatile memory (132) or non-volatile memory (134).

[0037] The program (140) may be stored as software in the memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).

[0038] The input module (150) can receive commands or data to be used in a component (e.g., processor (120)) of the first electronic device (101) from an external source (e.g., a user) of the first electronic device (101). The input module (150) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0039] The audio output module (155) can output audio signals to the outside of the first electronic device (101). The audio output module (155) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. In one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0040] The display module (160) can visually provide information to an external party (e.g., a user) of the first electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector, and a control circuit for controlling the device. In one embodiment, the display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0041] The audio module (170) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (170) can acquire sound through the input module (150), output sound through the sound output module (155), or an external electronic device (e.g., a second electronic device (102)) (e.g., a speaker or headphones) directly or wirelessly connected to the first electronic device (101).

[0042] The sensor module (176) can detect the operating status (e.g., power or temperature) of the first electronic device (101) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (176) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0043] The interface (177) may support one or more designated protocols that may be used to directly or wirelessly connect the first electronic device (101) to an external electronic device (e.g., the second electronic device (102)). In one embodiment, the interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0044] The connection terminal (178) may include a connector through which the first electronic device (101) may be physically connected to an external electronic device (e.g., a second electronic device (102)). According to one embodiment, the connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0045] The haptic module (179) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. According to one embodiment, the haptic module (179) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0046] The camera module (180) can capture still images and videos. According to one embodiment, the camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.

[0047] The power management module (188) can manage the power supplied to the first electronic device (101). According to one embodiment, the power management module (188) can be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

[0048] A battery (189) may power at least one component of the first electronic device (101). In one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0049] The communication module (190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the first electronic device (101) and an external electronic device (e.g., the second electronic device (102), the electronic device (104), or the server (108)), and the performance of communication through the established communication channel. The communication module (190) may operate independently from the processor (120) (e.g., an application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (190) may include a wireless communication module (192) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (194) (e.g., a local area network (LAN) communication module, or a power line communication module). Among these communication modules, the corresponding communication module can communicate with an external electronic device (104) via a first network (198) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (199) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (192) can verify or authenticate the first electronic device (101) within a communication network such as the first network (198) or the second network (199) by using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (196).

[0050] The wireless communication module (192) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (192) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (192) may support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (192) may support various requirements specified in the first electronic device (101), an external electronic device (e.g., electronic device (104)), or a network system (e.g., second network (199)). According to one embodiment, the wireless communication module (192) can support a peak data rate (e.g., 20 Gbps or more) for realizing eMBB, a loss coverage (e.g., 664 dB or less) for realizing mMTC, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 6 ms or less for round trip) for realizing URLLC.

[0051] The antenna module (197) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). In one embodiment, the antenna module (197) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). In one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (198) or the second network (199), may be selected from the plurality of antennas, for example, by the communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device via the at least one selected antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (197).

[0052] According to various embodiments, the antenna module (197) may form a mmWave antenna module. In one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high-frequency band.

[0053] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0054] According to one embodiment, commands or data may be transmitted or received between the first electronic device (101) and an external electronic device (104) via a server (108) connected to a second network (199). Each of the external electronic devices (102 or 104) may be the same or a different type of device as the first electronic device (101). According to one embodiment, all or part of the operations executed in the first electronic device (101) may be executed in one or more of the external electronic devices (102, 104, or 108). For example, when the first electronic device (101) is to perform a certain function or service automatically or in response to a request from a user or another device, the first electronic device (101) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the first electronic device (101). The first electronic device (101) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The first electronic device (101) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In another embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server utilizing machine learning and / or a neural network.According to one embodiment, an external electronic device (104) or server (108) may be included in the second network (199). The first electronic device (101) may be applied to intelligent services (e.g., smart homes, smart cities, smart cars, or healthcare) based on 5G communication technology and IoT-related technology.

[0055] Fig. 2a is a block diagram of a first electronic device (101) within a payment environment (201). Fig. 2b is a block diagram of a first electronic device (101) within a payment environment (205).

[0056] Referring to FIGS. 2A and 2B , payment environments (201, 205) may include at least one of a first electronic device (101), a second electronic device (102), or a third electronic device (103). The first electronic device (101), the second electronic device (102), and the third electronic device (103) may be owned by a single user. For example, the first electronic device (101), the second electronic device (102), and the third electronic device (103) may be electronic devices logged into the payment server (211) with a user account of a single user. However, the present invention is not limited thereto. The first electronic device (101), the second electronic device (102), or the third electronic device (103) may be owned by two or more different users. Each of the first electronic device (101), the second electronic device (102), or the third electronic device (103) may be owned by a different owner. For example, the second electronic device (102) or the third electronic device (103) may be an electronic device that has been pre-authenticated and / or pre-registered with the payment server (211) by the first electronic device (101). Here, the pre-authentication and / or pre-registration of the second electronic device (102) or the third electronic device (103) with the payment server (211) may mean that the first electronic device (101) is registered with the payment server (211) so that the first electronic device (101) can proceed with payment using the information necessary for payment acquired by the first electronic device (101) through the second electronic device (102) or the third electronic device (103).

[0057] At least two electronic devices, a first electronic device (101), a second electronic device (102), or a third electronic device (103), can be identified based on short-range communication (e.g., Bluetooth, Wi-Fi direct, or IrDA).

[0058] The first electronic device (101) may include a processor (120), a memory (130), a display (260), and a communication circuit (290). The memory (130) may include a payment application (241) and a payment framework (242). The first electronic device (101) of FIGS. 2A and 2B may correspond to the first electronic device (101) of FIG. 1. The processor (120) of FIGS. 2A and 2B may correspond to the processor (120) of FIG. 1. The memory (130) of FIGS. 2A and 2B may correspond to the memory (130) of FIG. 1. The display (260) of FIGS. 2A and 2B may correspond to the display module (160) of FIG. 1. The communication circuit (290) of FIGS. 2A and 2B may correspond to the communication module (190) of FIG. 1. The payment application (241) and payment framework (242) of FIGS. 2A and 2B may be included in the program (140) of FIG. 1. For example, the payment application (241) may be included in the application (146) of FIG. 1. For example, the payment framework (242) may be included in the middleware (144) of FIG. 1. In some embodiments, the first electronic device (101) may not be equipped with a display (260).

[0059] The second electronic device (102) may include a processor (221), a memory (231), a display (261), and a communication circuit (291). The memory (130) may include a payment application (243) and a payment framework (244). The second electronic device (102) of FIGS. 2A and 2B may correspond to the second electronic device (102) of FIG. 1. The processor (221) of FIGS. 2A and 2B may correspond to the processor (120) of FIG. 1. The memory (231) of FIGS. 2A and 2B may correspond to the memory (130) of FIG. 1. The display (261) of FIGS. 2A and 2B may correspond to the display module (160) of FIG. 1. The communication circuit (291) of FIGS. 2A and 2B may correspond to the communication module (190) of FIG. 1. The payment application (243) and payment framework (244) of FIGS. 2A and 2B may be included in the program (140) of FIG. 1. For example, the payment application (243) may be included in the application (146) of FIG. 1. For example, the payment framework (244) may be included in the middleware (144) of FIG. 1.

[0060] The third electronic device (103) may include a processor (223), a memory (233), a display (263), and a communication circuit (293). The memory (130) may include a payment application (245) and a payment framework (246). The third electronic device (103) of FIGS. 2A and 2B may correspond to the first electronic device (101) or the second electronic device (102) of FIG. 1. The processor (223) of FIGS. 2A and 2B may correspond to the processor (120) of FIG. 1. The memory (233) of FIGS. 2A and 2B may correspond to the memory (130) of FIG. 1. The display (263) of FIGS. 2A and 2B may correspond to the display module (160) of FIG. 1. The communication circuit (293) of FIGS. 2A and 2B may correspond to the communication module (190) of FIG. 1. The payment application (245) and payment framework (246) of FIGS. 2A and 2B may be included in the program (140) of FIG. 1. For example, the payment application (245) may be included in the application (146) of FIG. 1. For example, the payment framework (246) may be included in the middleware (144) of FIG. 1.

[0061] Referring to FIG. 2A, the payment environment (201) may include a payment server (211), a financial server (213), and a token server (215). The payment server (211) may include a processor (225) and a communication circuit (295). The processor (225) of the payment server (211) may correspond to the processor (120) of FIG. 1. The communication circuit (295) of the payment server (211) may correspond to the communication module (190) of FIG. 1. The financial server (213) may include a processor (226) and a communication circuit (296). The processor (226) of the financial server (213) may correspond to the processor (120) of FIG. 1. The communication circuit (296) of the financial server (213) may correspond to the communication module (190) of FIG. 1. The token server (215) may include a processor (227) and a communication circuit (297). The processor (227) of the token server (215) may correspond to the processor (120) of FIG. 1. The communication circuit (297) of the token server (215) may correspond to the communication module (190) of FIG. 1.

[0062] Referring to FIG. 2B, the payment environment (205) may include a payment server (211), a financial server (213), a payment network (217), and a payment device (219). The payment network (217) may include a processor (228) and a communication circuit (298). The processor (228) of the payment network (217) may correspond to the processor (120) of FIG. 1. The communication circuit (298) of the payment network (217) may correspond to the communication module (190) of FIG. 1. The payment device (219) may include a processor (229) and a communication circuit (299). The processor (229) of the payment device (219) may correspond to the processor (120) of FIG. 1. The communication circuit (299) of the payment device (219) may correspond to the communication module (190) of FIG. 1.

[0063] The first electronic device (101) can obtain information necessary for payment through the payment server (211). For example, the information necessary for payment may include information about a payment method (e.g., a credit card) (e.g., at least one of a primary account number (PAN), an expiration date, or a card verification value (CVV)) and / or a token. The first electronic device (101) can obtain information about a payment method (e.g., a credit card) (e.g., a PAN, an expiration date, or a CVV) from a financial server (213) through the payment server (211). Here, the financial server (213) may be a server that issues a card to a user of the first electronic device (101) and manages information about the issued card. The operation of the first electronic device (101) obtaining a token may be described with reference to FIG. 3.

[0064] The payment server (211) can manage user accounts, information about payment methods (e.g., credit cards) (e.g., PAN, card expiration date, or CVV), and tokens. The payment server (211) can be a server for providing payment services to users through electronic devices (101, 102, 103). The payment server (211) can be a management server for electronic payment and / or mobile payment. The payment server (211) can receive payment-related information from the first electronic device (101), and transmit the received payment-related information externally or process it in the payment server (211). The payment server (211) can include a token requester server. Here, the token requester server can transmit and receive information between the first electronic device (101) and the token server (215). The token requester server can provide an interface for processing payment-related information. For example, a token requester server may issue, delete, or activate payment-related information (e.g., tokens).

[0065] The financial server (213) can issue cards. The financial server (213) can generate payment information that is provided to the user. The user can store the payment information generated by the financial server (213) in the first electronic device (101) using the payment application (241). In addition, the financial server (213) can be functionally connected to the token server (215) to transmit and receive payment information.

[0066] The token server (215) can issue and / or manage payment data (e.g., tokens). The token server (215) can perform functions related to tokens. Here, the functions related to tokens can include at least one of token setting, identification and verification (ID&V), replenishment, token creation, modification, deletion, or life cycle management. Here, the token can be a value that replaces the PAN, which is card information. The token can be generated based on a BIN (bank identification number). In addition, the generated token can be encrypted by the financial server (213), or transmitted to the payment server (211) in an unencrypted state and then encrypted by the payment server (211). The encrypted token information can be transmitted to the first electronic device (101) via the payment server (211) and then decrypted by the first electronic device (101). However, the present invention is not limited thereto. The token can be transmitted directly from the token server (215) to the first electronic device (101) without going through the payment server (211).

[0067] The payment device (219) may be a point of sale (POS). The payment device (219) may obtain a payment signal output from at least one of the electronic devices (101, 102, 103). For example, the payment device (219) may obtain a payment signal based on magnetic secure transmission (MST) and / or near field communication (NFC).

[0068] The payment device (219) can transmit the acquired payment signal to the payment server (211) and / or the financial server (213) via the payment network (217). Here, the payment network (217) can transmit the signal acquired from the payment device (219) to a destination participating in the network.

[0069] FIG. 3 is a flowchart illustrating an operation of a first electronic device (101) acquiring a token according to one embodiment.

[0070] Figure 3 can be explained with reference to Figures 1, 2a and 2b.

[0071] Referring to FIG. 3, in operation 310, a payment application (241) of a first electronic device (101) may request a token. The payment application (241) may request a token from a payment server (211). The payment application (241) may request a token corresponding to information (e.g., a primary account number (PAN)) about a payment method (e.g., a credit card) from the payment server (211). Here, the token may be data based on the payment method. The token may be data generated based on information about the payment method. The token may be transferred between entities participating in the payment during electronic payment. Here, at least one of the information about the payment method or the token may be referred to as payment information.

[0072] The payment server (211) can provide services for electronic and / or mobile payments. The payment server (211) can manage user accounts or card information linked to user accounts. The payment server (211) can issue, delete, or activate payment-related data (e.g., tokens).

[0073] In operation 320, the payment server (211) may transmit a token request. The payment server (211) may request a token from the token server (215). The payment server (211) may request a token corresponding to information (e.g., PAN, card expiration date, or CVV) about a payment method (e.g., credit card) from the token server (215). Here, the token server (215) may manage the token. The token server (215) may issue and / or manage payment data (e.g., token). The token server (215) may perform functions related to the token. Here, the functions related to the token may include at least one of token setting, identification and verification (ID&V), replenishment, creation, modification, deletion, or life cycle management of the token.

[0074] In operation 330, the token server (215) may generate a token. The token server (215) may generate a token corresponding to information (e.g., PAN, card expiration date, or CVV) regarding a payment method (e.g., credit card). Here, the token may include at least one of a token ID (identification), a token expiration time, a token requester ID, or a cryptogram. The token ID may include identification information of the token. The token expiration time may include information related to a time when the use of the token expires. The token requester ID may include identification information related to the first electronic device (101) that requested the token and / or the payment server (211). The cryptogram may be data in which at least a portion of the token is encrypted. For example, the cryptogram may be generated based on a key for encrypting at least a portion of the token. In some embodiments, at least one of information about a payment method or information related to a token (e.g., a token ID, a token expiration time, a token requester ID, or a cryptogram, or a key) may be referred to as payment information.

[0075] In operation 340, the token server (215) may transmit a token. The token server (215) may transmit the token to the payment server (211). The token server (215) may transmit the token corresponding to information (e.g., PAN, card expiration date, or CVV) about a payment method (e.g., credit card) to the payment server (211). According to an embodiment, the token server (215) may transmit the token and a key to the payment server (211).

[0076] In operation 350, the payment server (211) may transmit a token. The payment server (211) may transmit the token to the payment application (241) of the first electronic device (101). The payment server (211) may transmit the token corresponding to information (e.g., PAN, card expiration date, or CVV) regarding a payment method (e.g., credit card) to the payment application (241). According to an embodiment, the payment server (211) may transmit the token and a key to the payment application (241).

[0077] In operation 360, the payment application (241) may store a token. The payment application (241) may store the token in the memory (130). The payment application (241) may store the token in a secure area (or secure element (SE)) of the memory (130). The payment application (241) may store the token in an area managed by a trusted execution environment (TEE) of the memory (130). However, the present invention is not limited thereto.

[0078] According to an embodiment, the payment application (241) may store tokens and keys in memory (130).

[0079] FIG. 4 is a flowchart illustrating an operation of a first electronic device (101) triggering entry into payment mode according to one embodiment.

[0080] FIG. 4 may be described with reference to FIG. 1, FIG. 2A, FIG. 2B, and FIG. 3. According to an embodiment, the operations of FIG. 4 may be performed while electronic devices (101, 102, and 103) are wirelessly connected to each other. However, the present invention is not limited thereto. For example, a first electronic device (101) may establish a wireless communication connection with other electronic devices (102, 103) based on the identification of a user input according to operation 401. Thereafter, the remaining operations of FIG. 4 may be performed. The wireless communication connection between the electronic devices (101, 102, and 103) may be based on short-range communication (e.g., Bluetooth, Wi-Fi direct, or IrDA).

[0081] The first electronic device (101), the second electronic device (102), and the third electronic device (103) may be owned by a single user. For example, the first electronic device (101), the second electronic device (102), and the third electronic device (103) may be electronic devices logged into the payment server (211) with a single user account. However, the present invention is not limited thereto. The first electronic device (101), the second electronic device (102), or the third electronic device (103) may be owned by two or more different users. Each of the first electronic device (101), the second electronic device (102), or the third electronic device (103) may be owned by a different owner. For example, the second electronic device (102) or the third electronic device (103) may be an electronic device that has been pre-authenticated and / or pre-registered with the payment server (211) by the first electronic device (101). Here, the fact that the second electronic device (102) or the third electronic device (103) is pre-authenticated and / or pre-registered with the payment server (211) may mean that the first electronic device (101) is registered with the payment server (211) so that the first electronic device (101) can proceed with payment using the information required for payment obtained by the first electronic device (101) through the second electronic device (102) or the third electronic device (103).

[0082] Referring to FIG. 4, in operation 401, the payment application (241) of the first electronic device (101) can identify a user input. The user input may be an input requesting payment. The user input may be an input for identifying a card. However, the present invention is not limited thereto. The user input may be an input used to authenticate a user. For example, the user input may include a gesture input. The gesture input may include a pattern input for authenticating a user. The user input may include an input for entering a password or a personal identification number (PIN) for authenticating a user. The user input may include an input of the user's biometric information (e.g., iris, fingerprint).

[0083] For example, the payment application (241) can identify a user input (or user gesture) based on a sensor (e.g., a sensor module (176) of FIG. 1) and / or an input module (e.g., an input module (150) of FIG. 1) provided in the first electronic device (101).

[0084] The payment application (241) can identify a card corresponding to a user input. The payment application (241) can identify a card corresponding to the user input among a plurality of cards. The payment application (241) can identify a card indicated by the user input among a plurality of cards registered in association with a user account. Here, the registration of a plurality of cards in association with a user account may mean that they are registered with the payment server (211). The registration of a plurality of cards in association with a user account may mean that the payment server (211) manages a plurality of cards in association with the user account.

[0085] In operation 410, the payment application (241) may authenticate the user. The payment application (241) may authenticate the user based on a user input. For example, the payment application (241) may authenticate the user based on whether the user input is a registered user input. For example, the payment application (241) may authenticate the user based on whether the user input is a registered gesture. Here, the registration of the user input may mean that data representing the user input is registered in the memory of the first electronic device (101). The registration of the user input may mean that data representing the user input is registered in a server (not shown) that manages user authentication. For example, the user may be authenticated by comparing the user input with the registered data. However, the present invention is not limited thereto. The payment application (241) may authenticate the user based on the user's biometric information (e.g., iris, fingerprint). For example, the payment application (241) may authenticate the user based on whether the biometric information is registered biometric information. Here, the registration of biometric information may mean that data about the biometric information is registered in the memory of the first electronic device (101). The registration of biometric information may mean that data about the biometric information is registered in a server (not shown) that manages user authentication. For example, the user may be authenticated by comparing the biometric information with the registered data. Here, the payment application (241) may obtain biometric information through a sensor (e.g., the sensor module (176) of FIG. 1). The payment application (241) may authenticate the user by comparing the obtained biometric information with previously stored biometric information of the user. Depending on the embodiment, authentication of the biometric information may be performed through an external server (e.g., fast identity online (FIDO)).

[0086] In operation 421, the payment application (241) may transmit card information (e.g., PAN, card expiration date, or CVV). The payment application (241) may transmit the card information to the payment application (243) of the second electronic device (102). The payment application (241) may transmit at least one of card information, a token ID, or an authentication result to the payment application (243). The payment application (241) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment application (243). For example, the payment application (241) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment application (243) via a command (e.g., deliverSelectCard). Here, the parameter of the command (e.g., deliverSelectCard) may include at least one of card information, a token, a token ID (tokenId), or an authentication result (fingerprint).

[0087] The payment application (241) may transmit data including payment information to the payment application (243) of the second electronic device (102) so that the payment application (243) may display information including at least a portion of the payment information on the display. Here, at least a portion of the payment information may include at least one of information regarding the payment method or information related to the token (e.g., a token ID, a token expiration time, a token requester ID, a cryptogram, or a key). Here, the information displayed on the display may include an image object for a card selected by the user. The information displayed on the display may include an image object for payment-related information (e.g., a time limit, a signature) of the card selected by the user.

[0088] In operation 425, the payment application (241) may transmit card information (e.g., PAN, card expiration date, or CVV). The payment application (241) may transmit the card information to the payment application (245) of the third electronic device (103). The payment application (241) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment application (245). For example, the payment application (241) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment application (245) via a command (e.g., deliverSelectCard).

[0089] In operation 431, the payment application (241) may command card selection. The payment application (241) may command the payment framework (242) to select a card. The payment application (241) may transmit a command for card selection including card information to the payment framework (242). The payment application (241) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment framework (242). For example, the payment application (241) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment framework (242) via a command (e.g., selectCard). Here, the parameter of the command (e.g., selectCard) may include at least one of card information, a token, a token ID (tokenId), or an authentication result (fingerprint).

[0090] In operation 441, the payment framework (242) may transmit a response to the card selection. The payment framework (242) may transmit the response to the card selection to the payment application (241). For example, the payment framework (242) may notify the payment application (241) that the card selection is complete through a response (e.g., RESULT_CODE_SUCCESS). Here, the parameter of the command (e.g., RESULT_CODE_SUCCESS) may include information about a previous state. Here, the previous state may include information currently being displayed on the display. The previous state may include information displayed on the display generated by an application running immediately before the execution of the payment application (241). The previous state may include information displayed on the display generated by an activated application other than the payment application (241). The previous state may include information about the activity on the top screen of the first electronic device (101).

[0091] In operation 451, the payment application (241) may output a payment user interface (UI) on the display. Here, the payment UI may include an image object for a card selected by the user. The payment UI may include an image object for payment-related information (e.g., time limit, signature) for the card selected by the user. However, the payment UI is not limited thereto. The payment UI may include a UI in a form that can interact with the user. For example, the payment UI may be based on at least one of a graphical UI (GUI), a natural UI (NUI) (e.g., haptic output), an auditory UI (AUI) (e.g., sound output), or a physical UI (PUI) (or a tangible UI (TUI)). When the payment UI is based on a NUI, the payment application (241) may output a haptic based on a haptic module (179) upon receiving a card selection response. Here, the payment application (241) can change the pattern of stimulation (e.g., mechanical stimulation or electrical stimulation) depending on the selected card. If the payment UI is based on AUI, the payment application (241) can output an audio signal based on the audio output module (155) upon receiving a card selection response. Here, the payment application (241) can change the sound output depending on the selected card.

[0092] The payment application (241) that outputs the payment UI can be identified as operating in pre-payment mode. Here, pre-payment mode may refer to a situation prior to outputting a payment signal. Pre-payment mode may refer to a situation in which the payment application (241) outputs the payment UI.

[0093] In operation 433, the payment application (243) of the second electronic device (102) may command card selection. The payment application (243) may command the payment framework (244) to select a card. The payment application (243) may transmit a command for card selection including card information to the payment framework (244). The payment application (243) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment framework (244). For example, the payment application (243) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment framework (244) via a command (e.g., selectCard).

[0094] At step 443, the payment framework (244) may transmit a response to the card selection. The payment framework (244) may transmit the response to the card selection to the payment application (243). For example, the payment framework (244) may notify the payment application (243) that the card selection is complete via a response (e.g., RESULT_CODE_SUCCESS). Here, the parameter of the command (e.g., RESULT_CODE_SUCCESS) may include information about the previous state.

[0095] In operation 453, the payment application (243) may display a payment UI (or payment display) on the display. Here, the payment UI may include an image object for the card selected by the user. The payment UI may include an image object for payment-related information (e.g., time limit, signature) for the card selected by the user.

[0096] The payment application (243) can output a payment UI through the display (261). Here, the payment UI can include a UI in a form that can interact with the user. For example, the payment UI can be based on at least one of a GUI, a NUI, an AUI, or a PUI. If the payment UI is based on the NUI, the payment application (243) can output a haptic based on a haptic module (not shown) based on receiving a card selection response. If the payment UI is based on the AUI, the payment application (243) can output a sound signal based on an audio output module (not shown) based on receiving a card selection response.

[0097] The payment application (243) that outputs the payment UI can be identified as operating in pre-payment mode. Here, pre-payment mode may refer to a situation prior to outputting a payment signal. Pre-payment mode may refer to a situation in which the payment application (243) outputs the payment UI.

[0098] In operation 435, the payment application (245) of the third electronic device (103) may command card selection. The payment application (245) may command the payment framework (246) to select a card. The payment application (245) may transmit a command for card selection including card information to the payment framework (246). The payment application (245) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment framework (246). For example, the payment application (245) may transmit at least one of card information, a token ID, a token, a key, or an authentication result to the payment framework (246) through a command (e.g., selectCard).

[0099] At step 445, the payment framework (246) may transmit a response to the card selection. The payment framework (246) may transmit the response to the card selection to the payment application (245). For example, the payment framework (246) may notify the payment application (245) that the card selection is complete via a response (e.g., RESULT_CODE_SUCCESS). Here, the parameter of the command (e.g., RESULT_CODE_SUCCESS) may include information about the previous state.

[0100] In operation 455, the payment application (245) may output a payment UI on the display. Here, the payment UI may include a UI in a form that can interact with the user. For example, the payment UI may be based on at least one of a GUI, a NUI, an AUI, or a PUI. If the payment UI is based on the NUI, the payment application (245) may output a haptic based on a haptic module (not shown) based on receiving a card selection response. If the payment UI is based on the AUI, the payment application (245) may output a sound signal based on an audio output module (not shown) based on receiving a card selection response.

[0101] The payment application (245) that outputs the payment UI can be identified as operating in pre-payment mode. Here, pre-payment mode may refer to a situation prior to outputting a payment signal. Pre-payment mode may refer to a situation in which the payment application (245) outputs the payment UI.

[0102] In operation 460, the payment application (241) may command payment to start. The payment application (241) may command the payment framework (242) to start payment. The payment application (241) may transmit at least one of card information, a token ID, a token, a key, an authentication result, a payment setting, or a callback method to the payment framework (242) via a command (e.g., StartPay). Here, the parameter of the command (e.g., StartPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), or a callback method (callback). Here, the authentication result (secureObject) may be a value indicating whether user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method of generating and / or outputting a signal based on magnetic secure transmission (MST) and / or near field communication (NFC). The callback method (callback) may specify a method (or interface) for returning the result of payment execution. However, the present invention is not limited thereto.

[0103] In operation 470, the payment framework (242) may output a payment signal. The payment framework (242) may emit a payment signal based on MST. The payment framework (242) may transmit a payment signal based on NFC. The payment framework (242) may output a payment signal based on MST and / or NFC. For example, the framework (242) may simultaneously output a payment signal based on MST and a payment signal based on NFC. For example, the framework (242) may sequentially output a payment signal based on MST and a payment signal based on NFC. For example, the framework (242) may output only one signal selected from the payment signal based on MST or the payment signal based on NFC.

[0104] The payment framework (242) may output a signal based on at least one of information about the payment method or information related to the token (e.g., a token ID, a token expiration time, a token requester ID, a cryptogram, or a key). The payment framework (242) may output a signal including at least one of information about the payment method or information related to the token (e.g., a token ID, a token expiration time, a token requester ID, a cryptogram, or a key).

[0105] Based on the payment framework (242) outputting a payment signal, the payment application (241) can output a UI. For example, the payment application (241) can output a UI indicating that the payment signal is being output. Here, the UI indicating that the payment signal is being output can be based on at least one of the GUI, the NUI, or the AUI. If the UI indicating that the payment signal is being output is based on the NUI, the payment application (241) can output a haptic based on the haptic module (179) while the payment signal is being output. If the UI indicating that the payment signal is being output is based on the NUI, the payment application (241) can output a sound signal based on the audio output module (155) while the payment signal is being output.

[0106] According to an embodiment, based on the payment framework (242) outputting a payment signal, the payment application (241) may request other electronic devices (102, 103) to output a UI indicating that a payment signal is being output. However, the present invention is not limited thereto.

[0107] A payment application (241) that outputs a payment signal can be identified as operating in payment mode. Here, payment mode may refer to a situation in which a payment signal is output. Payment mode may refer to a situation in which a payment signal is output by the payment framework (242).

[0108] As described above, the first electronic device (101) can provide the user with the convenience of making payments through multiple devices with a single authentication by displaying a UI for payment on other electronic devices (102, 103) of the user when making a payment through the payment device (219).

[0109] FIG. 5 is a flowchart illustrating an operation of an electronic device triggering another electronic device depending on whether a payment is successful, according to one embodiment.

[0110] FIG. 5 can be explained with reference to FIG. 1, FIG. 2a, FIG. 2b, FIG. 3, and FIG. 4.

[0111] Referring to FIG. 5 , in operation 510, the payment framework (242) of the first electronic device (101) can identify whether payment has been successful. The payment framework (242) can obtain a signal indicating whether payment has been successful (e.g., a signal indicating payment has failed or a signal indicating payment has been successful) from a server related to payment information. Here, the server related to payment information can include at least one of a payment server (211), a financial server (213), a token server (215), a payment network (217), or a payment device (219).

[0112] The payment framework (242) can receive data indicating whether the payment was successful or not from at least one of the payment server (211), the financial server (213), the token server (215), the payment network (217), or the payment device (219). The payment framework (242) can identify whether the payment was successful or not based on the received data. For example, when the payment device (219) obtains the payment signal output through operation 470 of FIG. 4, the payment signal obtained by the payment device (219) can be transmitted to the payment network (217), the financial server (213), the payment server (211), or the token server (215). Based on the payment signal, at least one of the payment server (211), the financial server (213), the token server (215), the payment network (217), or the payment device (219) can directly and / or indirectly transmit data indicating whether the payment was successful or not to the payment framework (242). For example, if a payment signal is not received, the payment device (219) may directly transmit data indicating that a payment signal is not received to the payment framework (242). For example, if at least one of the payment network (217), the financial server (213), the payment server (211), or the token server (215) determines that a payment based on a payment signal is not successful, data indicating that a payment signal is not received may be indirectly transmitted to the payment framework (242) via the payment server (211).

[0113] In operation 520, the payment framework (242) may transmit whether the payment was successful. The payment framework (242) may transmit whether the payment was successful to the payment application (241). The payment framework (242) may transmit data indicating whether the payment was successful to the payment application (241). The payment framework (242) may transmit a response including data indicating whether the payment was successful to the payment application (241). Here, the response may be RESULT_CODE_PAYMENT_SUCCESS or RESULT_CODE_PAYMENT_FAILURE.

[0114] The payment application (241) that receives the payment success / failure information may be identified as operating in post-payment mode. Here, post-payment mode may refer to a situation after receiving the payment success / failure information based on the payment signal after outputting the payment signal.

[0115] In operation 530, the payment application (241) can determine whether the payment was successful. The payment application (241) can determine whether the payment was successful based on data indicating whether the payment was successful. For example, the payment application (241) can determine whether the payment was successful based on a code included in the response. For example, if the response includes RESULT_CODE_PAYMENT_SUCCESS, the payment application (241) can determine that the payment was successful. For example, if the response includes RESULT_CODE_PAYMENT_FAILURE, the payment application (241) can determine that the payment was failed. Here, RESULT_CODE_PAYMENT_FAILURE may include an error code (failErrorCode). RESULT_CODE_PAYMENT_FAILURE may include an error code as shown in Table 1 or Table 2 below. However, the present invention is not limited thereto.

[0116] Error code description P-6 Failure to save the last change time of the user's payment method P-7 Failure to retrieve the last change time of the user's payment method P-8 Failure to retrieve information related to the user's payment method P-10 Failure to initialize the user's payment method P-11 Failure to retrieve payment company details P-12 Failure to retrieve payment company authentication information P-13 Failure to retrieve payment company user-related information P-14 Failure to save payment company user agreement status P-15 Failure to retrieve payment company user agreement information P-16 Failure to encrypt data P-17 Failure to decrypt data P-18 Undefined internal server error P-19 Backend server error P-20 Backend interface connection error P-21 Database (DB) query error P-22 DB connection error P-23 Payment company error not defined in the payment service P-24 Failure to retrieve user's payment method authentication information P-25 User's payment method authentication session timeout

[0117] Error Code Description C-20 Undefined PG (payment gateway) authentication agency error C-21 PG authentication is not possible for the service (check with the service administrator of the payment service) C-22 PG authentication number sending failed (try again later) C-23 PG authentication telecommunication company server maintenance in progress (try again later) C-24 PG service delay due to many authentication users (try again later) C-25 Authentication failure error (information mismatch between mobile phone user and payment method user) C-26 Payment service account server response error C-27A Server authentication encryption / decryption error C-28A Payment service account issued by server authentication error C-29 Undefined A server authentication agency error C-30 CI authentication agency system error C-31B Payment service account issued by server authentication error C-32C Waiting for server authentication C-33C Server authentication already confirmed C-34C Server authentication failed C-35C Server transaction information does not exist (mobile ID mismatch) C-36C Server authentication time Excess C-37C server undefined error

[0118] The payment application (241) may perform operation 541 based on determining that the payment is successful. The payment application (241) may perform operation 550 based on determining that the payment is successful. The order of performing operations 541 and 550 may be changed.

[0119] In operation 541, the payment application (241) may command a payment stop. The payment application (241) may command the payment framework (242) to stop the payment. The payment application (241) may command the payment framework (242) to stop the payment through a command (StopPay).

[0120] In operation 543, the payment framework (242) may stop outputting payment signals. The payment framework (242) may stop emitting payment signals based on MST. The payment framework (242) may stop transmitting payment signals based on NFC. The payment framework (242) may stop outputting payment signals based on MST and / or NFC.

[0121] In operation 550, the payment application (241) may return to a previous state. For example, the payment application (241) may return to a previous state based on information about the previous state. For example, the payment application (241) may display a previously displayed screen on the display based on information about the previous state. Here, information about the previous state may be obtained through operation 441 of FIG. 4 .

[0122] In operation 561, the payment application (241) may command recovery. The payment application (241) may command recovery to the payment application (243). The payment application (241) may command recovery to the payment application (243) via a command (Restore). Here, the payment application (241) may transmit the recovery command (or recovery request) to the payment application (243) so that the payment application (243) of the second electronic device (102) stops displaying the display (or payment UI).

[0123] In operation 565, the payment application (243) may return to the previous state. For example, the payment application (243) may return to the previous state based on information about the previous state. For example, the payment application (243) may display a previously displayed screen on the display based on information about the previous state. Here, information about the previous state may be obtained through operation 443 of FIG. 4 .

[0124] In operation 571, the payment application (241) may command recovery. The payment application (241) may command recovery to the payment application (245). The payment application (241) may command recovery to the payment application (245) via a command (Restore). Here, the payment application (241) may transmit the recovery command (or recovery request) to the payment application (245) so that the payment application (245) of the third electronic device (103) stops displaying the display (or payment UI).

[0125] At operation 575, the payment application (243) may return to a previous state. For example, the payment application (245) may return to a previous state based on information about the previous state. For example, the payment application (245) may display a previously displayed screen on the display based on information about the previous state. Here, information about the previous state may be obtained through operation 445 of FIG. 4 .

[0126] FIG. 6 is a flowchart illustrating an operation of an electronic device triggering another electronic device depending on whether a payment is successful, according to one embodiment.

[0127] FIG. 6 may be described with reference to FIGS. 1, 2a, 2b, 3, 4, and 5. Operations 510, 520, 530, 541, and 543 of FIG. 6 may correspond to operations 510, 520, 530, 541, and 543 of FIG. 5, respectively.

[0128] Referring to FIG. 6, in operation 510, the payment framework (242) of the first electronic device (101) can identify whether the payment is successful.

[0129] In operation 520, the payment framework (242) can convey whether the payment was successful.

[0130] In operation 530, the payment application (241) can determine whether the payment was successful.

[0131] The payment application (241) may perform operation 601 based on determining that the payment has failed. The payment application (241) may perform operation 610 based on determining that the payment has failed. The order of performing operations 601 and 610 may be changed.

[0132] In operation 601, the payment application (241) may command a payment stop. The payment application (241) may command the payment framework (242) to stop the payment. The payment application (241) may command the payment framework (242) to stop the payment through a command (StopPay).

[0133] In operation 603, the payment framework (242) may stop outputting payment signals. The payment framework (242) may stop emitting payment signals based on MST. The payment framework (242) may stop transmitting payment signals based on NFC. The payment framework (242) may stop outputting payment signals based on MST and / or NFC.

[0134] In operation 610, the payment application (241) may identify a payment terminal. Here, the payment terminal may be one of the user's electronic devices (101, 102, 103). For example, the payment terminal may be one of the electronic devices (102, 103) other than the first electronic device (101).

[0135] In one embodiment, the payment application (241) may identify a payment terminal based on the priorities of the user's electronic devices (101, 102, 103). Here, the priorities may be determined by the user. For example, the priorities may be determined based on the frequency of use of each of the electronic devices (101, 102, 103). For example, the priorities may be determined based on the payment frequency of each of the electronic devices (101, 102, 103). For example, an electronic device with a higher payment frequency may be given a higher priority. However, the present invention is not limited thereto. For example, the priorities may be determined based on payment history. For example, an electronic device that has made a payment more recently may be given a higher priority.

[0136] In one embodiment, the payment application (241) may identify the payment terminal based on the priority of the running application of each of the electronic devices (101, 102, 103). Here, the priority of the application may be determined by the type of service provided by the application. For example, the priority of an electronic device running an application in the foreground may be lower than the priority of an electronic device running an application in the background. For example, the priority of an electronic device running an application in the background may be lower than the priority of an electronic device that does not run an application included in the application layer. However, this is not limited thereto. The priority of an application may be lower for a pre-defined application than for other applications. For example, the priority of an application may be lower for an electronic device providing a service requiring immediate interaction (e.g., phone calls, games, content viewing) that requires the user's concentration than for an electronic device providing other services (e.g., jogging route tracking).

[0137] In one embodiment, the payment application (241) can identify a payment terminal based on an error code. For example, the payment application (241) can identify a terminal that performed a payment when the same error code occurred as a payment terminal.

[0138] In one embodiment, the payment application (241) can identify a payment terminal based on the payment device (219). For example, if the payment device (219) supports either MST or NFC as a payment method, a terminal capable of outputting a payment signal of the supported payment method can be identified as a payment terminal.

[0139] In operation 620, the payment application (241) may request payment. The payment application (241) may request payment from the payment application (243). The payment application (241) may command the payment application (243) to request payment through a command (TossPay). Here, the parameters of the command (TossPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), a callback method (callback), or an error code. Here, the authentication result (secureObject) may be a value indicating whether user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method for generating and / or outputting a signal based on MST and / or NFC. The callback method (callback) may specify a method (or interface) for returning the result of the payment. The error code (failErrorCode) may be a value indicating the reason for payment failure. The error code may include error codes as in Table 1 and error codes as in Table 2. However, it is not limited to this.

[0140] In operation 630, the payment application (243) may command payment to start. The payment application (243) may command the payment framework (244) to start payment. The payment application (243) may transmit at least one of card information, a token ID, a token, a key, an authentication result, a payment setting, or a callback method to the payment framework (244) via a command (e.g., StartPay). Here, the parameter of the command (e.g., StartPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), or a callback method (callback). Here, the authentication result (secureObject) may be a value indicating whether user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method of generating and / or outputting a signal based on MST and / or NFC. For example, if the error code (failErrorCode) indicates P-16 (data encryption failure) or P-17 (data decryption failure), the payment configuration (payConfig) may indicate configuration values ​​for changing the encryption technique and / or decryption technique. The callback method (callback) may specify a method (or interface) for returning the result of the payment operation, but is not limited thereto.

[0141] In operation 640, the payment framework (244) may output a payment signal. The payment framework (244) may emit a payment signal based on MST. The payment framework (244) may transmit a payment signal based on NFC. The payment framework (244) may output a payment signal based on MST and / or NFC. For example, the framework (244) may simultaneously output a payment signal based on MST and a payment signal based on NFC. For example, the framework (244) may sequentially output a payment signal based on MST and a payment signal based on NFC. For example, the framework (244) may output only one signal selected from the payment signal based on MST or the payment signal based on NFC.

[0142] The payment framework (244) can generate a payment signal based on MST and / or NFC based on the payment configuration (payConfig). For example, when generating a payment signal based on MST, the payment framework (244) can change the output method of a sequence based on Track 1, Track 2, or Track 3 based on the payment configuration (payConfig). For example, when generating a payment signal based on MST, the payment framework (244) can adjust the idle interval between emission points of the payment signal based on the payment configuration (payConfig). However, the present invention is not limited thereto. For example, when a payment based on one communication protocol (e.g., MST) among MST and NFC fails, the payment framework (244) can perform a payment based on another communication protocol (e.g., NFC). Here, information about one communication protocol (e.g., MST) that failed can be included in the payment configuration (payConfig).

[0143] A payment application (243) that outputs a payment signal can be identified as operating in payment mode. Here, payment mode may refer to a situation in which a payment signal is output. Payment mode may refer to a situation in which a payment signal is output by a payment framework (244).

[0144] As described above, when payment through the payment device (219) by the first electronic device (101) fails, payment can be attempted without additional authentication through the user's other electronic devices (102, 103), thereby providing the user with the convenience of performing payment through multiple devices with one authentication.

[0145] FIG. 7 is a flowchart illustrating an operation of an electronic device according to one embodiment of the present invention to trigger another electronic device depending on whether a payment by the other electronic device is successful.

[0146] FIG. 7 may be described with reference to FIGS. 1, 2a, 2b, 3, 4, 5, and 6. Operation 640 of FIG. 7 may correspond to operation 640 of FIG. 6.

[0147] Referring to FIG. 7, in operation 640, the payment framework (244) of the second electronic device (102) may output a payment signal.

[0148] In operation 710, the payment framework (242) of the first electronic device (101) can identify whether the payment was successful. The payment framework (242) can receive data indicating whether the payment was successful from at least one of the payment server (211), the financial server (213), the token server (215), the payment network (217), or the payment device (219). The payment framework (242) can identify whether the payment was successful based on the received data.

[0149] In operation 720, the payment framework (242) may transmit whether the payment was successful. The payment framework (242) may transmit whether the payment was successful to the payment application (241). The payment framework (242) may transmit data indicating whether the payment was successful to the payment application (241). The payment framework (242) may transmit a response including data indicating whether the payment was successful to the payment application (241).

[0150] The payment application (241) that receives the payment success / failure information may be identified as operating in post-payment mode. Here, post-payment mode may refer to a situation after receiving the payment success / failure information based on the payment signal after outputting the payment signal.

[0151] In operation 730, the payment application (241) can determine whether the payment was successful. The payment application (241) can determine whether the payment was successful based on data indicating whether the payment was successful. For example, the payment application (241) can determine whether the payment was successful based on a code included in the response. For example, if the response includes RESULT_CODE_PAYMENT_SUCCESS, the payment application (241) can determine that the payment was successful. For example, if the response includes RESULT_CODE_PAYMENT_FAILURE, the payment application (241) can determine that the payment was failed. Here, RESULT_CODE_PAYMENT_FAILURE may include an error code (failErrorCode). RESULT_CODE_PAYMENT_FAILURE may include an error code such as Table 1 or Table 2.

[0152] The payment application (241) may perform operation 740 based on determining that the payment is successful.

[0153] In operation 740, the payment application (241) may return to a previous state. For example, the payment application (241) may return to a previous state based on information about the previous state. For example, the payment application (241) may display a previously displayed screen based on information about the previous state. Here, information about the previous state may be obtained through operation 441 of FIG. 4 .

[0154] In operation 751, the payment application (241) can command recovery. The payment application (241) can command recovery to the payment application (243). The payment application (241) can command recovery to the payment application (243) through the command (Restore).

[0155] The payment application (243) that received the recovery command may be identified as operating in post-payment mode. Here, post-payment mode may refer to a situation after outputting a payment signal and receiving a payment success / failure based on the payment signal.

[0156] In operation 753, the payment application (243) may command the payment to be stopped. The payment application (243) may command the payment framework (244) to stop the payment. The payment application (243) may command the payment framework (244) to stop the payment through the command (StopPay).

[0157] At operation 755, the payment application (243) may stop outputting the payment signal. The payment framework (244) may stop emitting the payment signal based on MST. The payment framework (244) may stop transmitting the payment signal based on NFC. The payment framework (244) may stop outputting the payment signal based on MST and / or NFC.

[0158] In operation 757, the payment application (243) may return to a previous state. For example, the payment application (243) may return to a previous state based on information about the previous state. For example, the payment application (243) may display a previously displayed screen on the display based on information about the previous state. Here, information about the previous state may be obtained through operation 443 of FIG. 4 .

[0159] In operation 761, the payment application (241) can command recovery. The payment application (241) can command recovery to the payment application (245). The payment application (241) can command recovery to the payment application (245) through the command (Restore).

[0160] The payment application (245) that received the recovery command can be identified as operating in post-payment mode. Here, post-payment mode can refer to a situation after receiving the success or failure of payment based on the payment signal after outputting the payment signal.

[0161] At operation 765, the payment application (243) may return to a previous state. For example, the payment application (245) may return to a previous state based on information about the previous state. For example, the payment application (245) may display a previously displayed screen on the display based on information about the previous state. Here, information about the previous state may be obtained through operation 445 of FIG. 4 .

[0162] FIG. 8 is a flowchart illustrating an operation of an electronic device according to one embodiment of the present invention to trigger another electronic device depending on whether a payment by the other electronic device is successful.

[0163] FIG. 8 may be described with reference to FIGS. 1, 2a, 2b, 3, 4, 5, 6, and 7. Operation 640 of FIG. 8 may correspond to operation 640 of FIG. 6 or 7. Operations 710, 720, and 730 of FIG. 8 may correspond to operations 710, 720, and 730 of FIG. 7.

[0164] Referring to FIG. 8, in operation 640, the payment framework (244) of the second electronic device (102) may output a payment signal.

[0165] In operation 710, the payment framework (242) of the first electronic device (101) can identify whether the payment was successful.

[0166] In operation 720, the payment framework (242) can convey whether the payment was successful.

[0167] In operation 730, the payment application (241) can determine whether the payment was successful.

[0168] The payment application (241) may perform operation 811 based on determining that the payment has failed.

[0169] In operation 811, the payment application (241) can command the payment to be stopped. The payment application (241) can command the payment application (243) to stop the payment. The payment application (241) can command the payment application (243) to stop the payment through the command (StopPay).

[0170] A payment application (243) that receives a payment suspension command may be identified as operating in post-payment mode. Here, post-payment mode may refer to a situation after outputting a payment signal and receiving a payment success / failure indication based on the payment signal.

[0171] In operation 813, the payment application (243) of the second electronic device (102) may command a payment stop. The payment application (243) may command the payment framework (244) to stop the payment. The payment application (243) may command the payment framework (244) to stop the payment through a command (StopPay).

[0172] In operation 815, the payment framework (244) may stop outputting the payment signal. The payment framework (244) may stop emitting the payment signal based on MST. The payment framework (244) may stop transmitting the payment signal based on NFC. The payment framework (244) may stop outputting the payment signal based on MST and / or NFC.

[0173] In operation 820, the payment application (241) may identify a payment terminal. In one embodiment, the payment application (241) may identify the payment terminal based on the priorities of the user's electronic devices (101, 102, 103). In one embodiment, the payment application (241) may identify the payment terminal based on the priorities of the applications currently running on each of the electronic devices (101, 102, 103). In one embodiment, the payment application (241) may identify the payment terminal based on an error code. In one embodiment, the payment application (241) may identify the payment terminal based on the payment device (219).

[0174] In operation 830, the payment application (241) may request payment. The payment application (241) may request payment from the payment application (245). The payment application (241) may command the payment application (245) to request payment through a command (TossPay). Here, the parameters of the command (TossPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), a callback method (callback), or an error code. Here, the authentication result (secureObject) may be a value indicating whether user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method of generating and / or outputting a signal based on MST and / or NFC. The callback method (callback) may specify a method (or interface) for returning the result of the payment. The error code (failErrorCode) may be a value indicating the reason for payment failure. The error code may include error codes as in Table 1 and error codes as in Table 2. However, it is not limited to this.

[0175] In operation 840, the payment application (245) of the third electronic device (103) may command payment to begin. The payment application (245) may command the payment framework (246) to begin payment. The payment application (245) may transmit at least one of card information, a token ID, a token, a key, an authentication result, a payment setting, or a callback method to the payment framework (246) via a command (e.g., StartPay). Here, the parameter of the command (e.g., StartPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), or a callback method (callback). Here, the authentication result (secureObject) may be a value indicating whether the user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method of generating and / or outputting a signal based on MST and / or NFC. The callback method (callback) may specify a method (or interface) for returning the result of the payment performance. However, the present invention is not limited thereto.

[0176] In operation 850, the payment framework (246) may output a payment signal. The payment framework (246) may emit a payment signal based on MST. The payment framework (246) may transmit a payment signal based on NFC. The payment framework (246) may output a payment signal based on MST and / or NFC. For example, the framework (246) may simultaneously output a payment signal based on MST and a payment signal based on NFC. For example, the framework (246) may sequentially output a payment signal based on MST and a payment signal based on NFC. For example, the framework (246) may output only one signal selected from the payment signal based on MST or the payment signal based on NFC.

[0177] The payment framework (246) can generate a payment signal based on MST and / or NFC based on payment settings (payConfig).

[0178] According to an embodiment, if payment fails based on a payment signal output by the payment framework (246), the payment application (241) may determine whether to retry the payment based on an error code (failErrorCode).

[0179] For example, the payment application (241) may perform processing related to the payment method if the error code (failErrorCode) indicates a failure related to the payment method (e.g., P-6, P-7, P-8, or P-10). For example, the payment application (241) may re-query information about the payment method or re-save (or update) information about the payment method if the error code (failErrorCode) indicates a failure related to the payment method.

[0180] For example, if the error code (failErrorCode) indicates a failure (e.g., P-14 or P-15) related to the user's consent, the payment application (241) may perform processing related to the payment user's consent. For example, if the error code (failErrorCode) indicates a failure related to the user's consent, the payment application (241) may display a UI requesting the user's consent.

[0181] For example, the payment application (241) may output a notification indicating that there is a server-related error if the error code (failErrorCode) indicates a server-related failure (e.g., P-18, P-19, P-20, P-21, P-22, or P-23). ​​For example, the payment application (241) may display a UI indicating that payment is difficult due to the server if the error code (failErrorCode) indicates a server-related failure.

[0182] A payment application (245) that outputs a payment signal can be identified as operating in payment mode. Here, payment mode may refer to a situation in which a payment signal is output. Payment mode may refer to a situation in which a payment signal is output by a payment framework (246).

[0183] FIG. 9 is a flowchart illustrating an operation of another electronic device triggering another electronic device depending on whether a payment is successful, according to one embodiment.

[0184] FIG. 9 may be described with reference to FIGS. 1, 2a, 2b, 3, 4, 5, 6, 7, and 8. Operation 640 of FIG. 9 may correspond to operation 640 of FIG. 6, FIG. 7, or FIG. 8.

[0185] Referring to FIG. 9, in operation 640, the payment framework (244) of the second electronic device (102) may output a payment signal.

[0186] In operation 910, the payment framework (244) can identify whether the payment was successful. The payment framework (242) can receive data indicating whether the payment was successful from at least one of the payment server (211), the financial server (213), the token server (215), the payment network (217), or the payment device (219). The payment framework (242) can identify whether the payment was successful based on the received data. For example, when the payment device (219) obtains the payment signal output through operation 470 of FIG. 4, the payment signal obtained by the payment device (219) can be transmitted to the payment network (217), the financial server (213), the payment server (211), or the token server (215). Based on the payment signal, at least one of the payment server (211), the financial server (213), the token server (215), the payment network (217), or the payment device (219) may directly and / or indirectly transmit data indicating whether the payment was successful to the payment framework (242). For example, if the payment device (219) does not receive the payment signal, the data indicating that the payment signal was not received may be directly transmitted to the payment framework (242). For example, if at least one of the payment network (217), the financial server (213), the payment server (211), or the token server (215) determines that the payment based on the payment signal is not successful, the data indicating that the payment signal was not received may be indirectly transmitted to the payment framework (242) via the payment server (211).

[0187] In operation 920, the payment framework (244) may transmit whether the payment was successful. The payment framework (242) may transmit whether the payment was successful to the payment application (241). The payment framework (242) may transmit data indicating whether the payment was successful to the payment application (241). The payment framework (242) may transmit a response including data indicating whether the payment was successful to the payment application (241). Here, the response may be RESULT_CODE_PAYMENT_SUCCESS or RESULT_CODE_PAYMENT_FAILURE.

[0188] The payment application (243) that receives the payment success / failure information may be identified as operating in post-payment mode. Here, post-payment mode may refer to a situation after receiving the payment success / failure information based on the payment signal after outputting the payment signal.

[0189] In operation 930, the payment application (243) can determine whether the payment was successful. The payment application (241) can determine whether the payment was successful based on data indicating whether the payment was successful. For example, the payment application (241) can determine whether the payment was successful based on a code included in the response. For example, if the response includes RESULT_CODE_PAYMENT_SUCCESS, the payment application (241) can determine that the payment was successful. For example, if the response includes RESULT_CODE_PAYMENT_FAILURE, the payment application (241) can determine that the payment was unsuccessful.

[0190] The payment application (241) may perform operation 941 based on determining that the payment is successful. The payment application (241) may perform operation 950 based on determining that the payment is successful. The order of performing operations 941 and 950 may be changed.

[0191] In operation 941, the payment application (243) may command a payment stop. The payment application (241) may command the payment framework (242) to stop the payment. The payment application (241) may command the payment framework (242) to stop the payment through the command (StopPay).

[0192] At operation 945, the payment application (243) may stop outputting payment signals. The payment framework (242) may stop transmitting payment signals based on MST. The payment framework (242) may stop transmitting payment signals based on NFC. The payment framework (242) may stop outputting payment signals based on MST and / or NFC.

[0193] At operation 950, the payment application (243) may return to a previous state. For example, the payment application (241) may return to a previous state based on information about the previous state. For example, the payment application (241) may display a previously displayed screen on the display based on information about the previous state. Here, information about the previous state may be obtained through operation 441 of FIG. 4 .

[0194] In operation 961, the payment application (243) may command recovery. The payment application (241) may command recovery to the payment application (243). The payment application (241) may command recovery to the payment application (243) via the command (Restore).

[0195] The payment application (241) that received the recovery command may be identified as operating in post-payment mode. Here, post-payment mode may refer to a situation after outputting a payment signal and receiving a payment success / failure based on the payment signal.

[0196] At operation 965, the payment application (241) may return to a previous state. For example, the payment application (243) may return to a previous state based on information about the previous state. For example, the payment application (243) may display a previously displayed screen on the display based on information about the previous state. Here, information about the previous state may be obtained through operation 443 of FIG. 4 .

[0197] In operation 971, the payment application (243) may command recovery. The payment application (241) may command recovery to the payment application (245). The payment application (241) may command recovery to the payment application (245) via the command (Restore).

[0198] The payment application (245) that received the recovery command may be identified as operating in post-payment mode. Here, post-payment mode may refer to a situation after outputting a payment signal and receiving a payment success / failure based on the payment signal.

[0199] In operation 965, the payment application (245) of the third electronic device (103) may return to a previous state. For example, the payment application (245) may return to a previous state based on information about the previous state. For example, the payment application (245) may display a previously displayed screen on the display based on information about the previous state. Here, information about the previous state may be obtained through operation 445 of FIG. 4 .

[0200] FIG. 10 is a flowchart illustrating an operation of another electronic device triggering another electronic device depending on whether a payment is successful, according to one embodiment.

[0201] FIG. 10 may be described with reference to FIGS. 1, 2a, 2b, 3, 4, 5, 6, 7, 8, and 9. Operation 640 of FIG. 10 may correspond to operation 640 of FIG. 6, FIG. 7, FIG. 8, or FIG. 9. Operations 910, 920, 930, 941, or 945 of FIG. 10 may correspond to operations 910, 920, 930, 941, or 945 of FIG. 9, respectively.

[0202] Referring to FIG. 10, in operation 640, the payment framework (244) of the second electronic device (102) may output a payment signal.

[0203] In operation 910, the payment framework (244) can identify whether the payment was successful.

[0204] In operation 920, the payment framework (244) can convey whether the payment was successful.

[0205] In operation 930, the payment application (243) can determine whether the payment was successful.

[0206] The payment application (241) may perform operation 1001 based on determining that the payment has failed. The payment application (241) may perform operation 1010 based on determining that the payment has failed. The order of performing operations 1001 and 1010 may be changed.

[0207] In operation 1001, the payment application (243) may command a payment stop. The payment application (241) may command the payment framework (242) to stop the payment. The payment application (241) may command the payment framework (242) to stop the payment through the command (StopPay).

[0208] In operation 1003, the payment application (243) may stop outputting payment signals. The payment framework (244) may stop transmitting payment signals based on MST. The payment framework (244) may stop transmitting payment signals based on NFC. The payment framework (244) may stop outputting payment signals based on MST and / or NFC.

[0209] In operation 1010, the payment application (243) can notify the payment status.

[0210] In operation 1020, the payment application (243) may identify a payment terminal. In one embodiment, the payment application (243) may identify the payment terminal based on the priorities of the user's electronic devices (101, 102, 103). In one embodiment, the payment application (243) may identify the payment terminal based on the priorities of the applications currently running on each of the electronic devices (101, 102, 103). In one embodiment, the payment application (243) may identify the payment terminal based on an error code. In one embodiment, the payment application (243) may identify the payment terminal based on the payment device (219).

[0211] In operation 1030, the payment application (243) may request payment. The payment application (243) may request payment from the payment application (245). The payment application (243) may command the payment application (245) to request payment through a command (TossPay). Here, the parameters of the command (TossPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), a callback method (callback), or an error code. Here, the authentication result (secureObject) may be a value indicating whether user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method of generating and / or outputting a signal based on MST and / or NFC. The callback method (callback) may specify a method (or interface) for returning the result of the payment. The error code (failErrorCode) may be a value indicating the reason for payment failure. The error code may include error codes as in Table 1 and Table 2. However, it is not limited to this.

[0212] In operation 1040, the payment application (245) of the third electronic device (103) may command payment to begin. The payment application (245) may command the payment framework (246) to begin payment. The payment application (245) may transmit at least one of card information, a token ID, a token, a key, an authentication result, a payment setting, or a callback method to the payment framework (246) via a command (e.g., StartPay). Here, the parameter of the command (e.g., StartPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), or a callback method (callback). Here, the authentication result (secureObject) may be a value indicating whether the user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method of generating and / or outputting a signal based on MST and / or NFC. The callback method (callback) may specify a method (or interface) for returning the result of the payment. However, the present invention is not limited thereto.

[0213] In operation 1050, the payment framework (246) may output a payment signal. The payment framework (246) may emit a payment signal based on MST. The payment framework (246) may transmit a payment signal based on NFC. The payment framework (246) may output a payment signal based on MST and / or NFC. For example, the framework (246) may simultaneously output a payment signal based on MST and a payment signal based on NFC. For example, the framework (244) may sequentially output a payment signal based on MST and a payment signal based on NFC. For example, the framework (246) may output only one signal selected from the payment signal based on MST or the payment signal based on NFC.

[0214] A payment application (245) that outputs a payment signal can be identified as operating in payment mode. Here, payment mode may refer to a situation in which a payment signal is output. Payment mode may refer to a situation in which a payment signal is output by a payment framework (246).

[0215] FIG. 11 is a flowchart illustrating an operation of another payment framework emitting a payment signal according to one embodiment.

[0216] Figure 11 can be explained with reference to Figures 1, 2a and 2b.

[0217] The payment processor (1103), payment network provider (1104), and MST pay task (1105) of FIG. 11 may be software included in the payment framework (1102).

[0218] Referring to FIG. 11, in operation 1110, a payment application (1101) may command a payment to start. The payment application (1101) may command a payment framework (1102) to start payment. The payment application (1101) may transmit at least one of card information, a token ID, a token, a key, an authentication result, a payment setting, or a callback method to the payment framework (1102) via a command (e.g., StartPay). Here, a parameter of the command (e.g., StartPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), or a callback method (callback). Here, the authentication result (secureObject) may be a value indicating whether user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method of generating and / or outputting a signal based on MST and / or NFC. The callback method (callback) may specify a method (or interface) for returning the result of the payment. However, the present invention is not limited thereto.

[0219] In operation 1121, the payment processor (1103) may command a payment to start. The payment processor (1103) may command the payment framework (1104) to start the payment. The payment processor (1103) may transmit at least one of card information, a token ID, a token, a key, an authentication result, a payment setting, or a callback method to the payment framework (1104) via a command (e.g., StartPay). Here, the parameters of the command (e.g., StartPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), or a callback method (callback). Here, the authentication result (secureObject) may be a value indicating whether the user authentication was successful. The payment setting (payConfig) may be a setting value for determining a method of generating and / or outputting a signal based on MST and / or NFC. The callback method (callback) may specify a method (or interface) for returning the result of the payment. However, the present invention is not limited thereto.

[0220] In operation 1125, the payment network provider (1104) may authenticate the transaction. The payment network provider (1104) may determine whether the authentication result (secureObject) is valid. If the authentication result (secureObject) is valid, the payment network provider (1104) may perform operation 1131.

[0221] In operation 1131, the payment network provider (1104) may issue a payment start command. Here, the command for starting the payment may be startMstPay. The command (startMstPay) may include baudRate and mstPayCfg as parameters. The baud rate may refer to the number of pulses per second or the number of symbols per second. The MST payment configuration may set the encoding method and / or output method of the MST signal.

[0222] In operation 1135, the MST pay task (1105) may emit a payment signal. The MST pay task (1105) may emit a payment signal generated based on baudRate and mstPayCfg.

[0223] FIG. 12 is a flowchart illustrating an operation of another payment framework transmitting a payment signal according to one embodiment.

[0224] FIG. 12 can be described with reference to FIGS. 1, 2A, and 2B. Operations 1110, 1121, 1125, and 1131 of FIG. 12 can correspond to operations 1110, 1121, 1125, and 1131 of FIG. 11, respectively.

[0225] The payment processor (1103), payment network provider (1104), and HCE (host card emulation) service (1106) of FIG. 12 may be software included in the payment framework (242).

[0226] Referring to FIG. 12, at step 1110, the payment application (1101) may initiate a payment. At step 1121, the payment processor (1103) may initiate a payment. At step 1125, the payment network provider (1104) may authenticate the transaction. At step 1131, the payment network provider (1104) may initiate a payment.

[0227] In operation 1201, the HCE service (1106) may be activated. For example, the payment framework (1102) may activate the HCE service (1106). Here, the activation of the HCE service (1106) may mean that it can receive an application protocol data unit (APDU) command from an external NFC reader (e.g., a payment device (219)).

[0228] In operation 1211, the payment device (219) may transmit an APDU command. The payment device (219) may transmit a command (processCommandApdu) to the HCE service (1106). Here, the command (processCommandApdu) may include data requesting a response. For example, the command (processCommandApdu) may refer to data to be included in a response APDU.

[0229] In operation 1213, the HCE service (1106) may request APDU processing. The HCE service (1106) may send a command (processApdu) to the payment processor (1103).

[0230] In operation 1215, the payment processor (1103) may request APDU processing. The payment processor (1103) may transmit a command (processApdu) to the payment network provider (1104).

[0231] In FIG. 12, through operations 1213 and 1215, a request for APDU processing of the HCE service (1106) is transmitted to the payment network provider (1104) via the payment processor (1103). However, this is not limited thereto. For example, the HCE service (1106) may directly request APDU processing from the payment network provider (1104).

[0232] In operation 1220, the payment network provider (1104) may generate a response APDU. The data requested by the command (processCommandApdu) may be generated. For example, the payment network provider (1104) may generate a response APDU that includes at least a token.

[0233] In operation 1225, the payment network provider (1104) may transmit a response APDU. The payment network provider (1104) may output the response APDU based on NFC. The payment network provider (1104) may output the NFC-based response APDU to the payment device (219).

[0234] In FIG. 12, through operation 1225, the payment network provider (1104) is illustrated as transmitting a response APDU. However, this is not limited thereto. For example, the payment network provider (1104) may request the HCE service (1106) to transmit a response APDU. The HCE service (1106) may output an NFC-based response APDU to the payment device (219).

[0235] FIG. 13 is a flowchart illustrating an operation in which another electronic device requests another electronic device to display a message depending on whether a payment is successful, according to one embodiment.

[0236] Figure 13 can be explained with reference to Figures 1, 2a and 2b.

[0237] Referring to FIG. 13, in operation 1310, the payment application (241) of the first electronic device (101) can identify whether the payment was successful. The payment application (241) can identify whether the payment was successful based on data indicating whether the payment was successful. For example, the payment application (241) can identify whether the payment was successful based on a code included in the response. For example, if the response includes RESULT_CODE_PAYMENT_SUCCESS, the payment application (241) can identify the payment as successful. For example, if the response includes RESULT_CODE_PAYMENT_FAILURE, the payment application (241) can identify the payment as failed.

[0238] In operation 1320, the payment application (241) may request the output of a notification. The payment application (241) may request the output of a notification corresponding to a response code. The payment application (241) may request the output of a notification corresponding to a response code from the payment application (243). However, this is not limited thereto. The payment application (241) may request the output of a notification corresponding to a response code from the payment application of at least one electronic device selected from among the electronic devices (102, 103) other than the first electronic device (101).

[0239] In operation 1330, the payment application (243) may output a notification. The payment application (243) may output a payment UI including the notification. Here, the payment UI may include a UI in a form that can interact with the user. For example, the payment UI may be based on at least one of a GUI, a NUI, an AUI, or a PUI. If the payment UI is based on the NUI, the payment application (243) may output a haptic based on a haptic module (not shown) based on receiving a notification corresponding to a response code. Here, the payment application (241) may change the pattern of a stimulus (e.g., a mechanical stimulus or an electrical stimulus) based on the response code. If the payment UI is based on the AUI, the payment application (243) may output a sound signal based on an audio output module (not shown) based on receiving a notification corresponding to a response code. Here, the payment application (243) may change the sound output based on the response code.

[0240] For example, if the response includes RESULT_CODE_PAYMENT_SUCCESS, the payment application (243) may output a notification indicating payment success. If the response includes RESULT_CODE_PAYMENT_SUCCESS, the payment application (243) may output a payment UI based on the notification indicating payment success.

[0241] For example, if the response includes RESULT_CODE_PAYMENT_FAILURE, the payment application (243) may output a notification indicating payment failure. For example, if the response includes RESULT_CODE_PAYMENT_FAILURE, the payment application (243) may output a notification including the reason for payment failure. If the response includes RESULT_CODE_PAYMENT_FAILURE, the payment application (243) may output a payment UI based on the notification indicating payment failure. If the response includes RESULT_CODE_PAYMENT_FAILURE, the payment application (243) may output a payment UI based on the notification including the reason for payment failure.

[0242] FIG. 14a illustrates an example of a screen displayed by electronic devices according to an embodiment. FIG. 14b illustrates an example of a screen displayed by electronic devices according to an embodiment.

[0243] FIG. 14A illustrates a situation in which a payment application (241) is executed through a first electronic device (101). Referring to FIG. 14A, electronic devices (102, 103) other than the first electronic device (101) may be executing applications other than the payment application (243, 245). Referring to FIG. 14A, the electronic devices (102, 103) may display screens for applications other than the payment application (243, 245) on their displays (1402, 1403).

[0244] In the situation of FIG. 14a, the first electronic device (101) can select a card through user input. The first electronic device (101) can authenticate the user through the user input. Based on the user's authentication, the first electronic device (101) can transmit a signal to the electronic devices (102, 103) causing the electronic devices (102, 103) to execute the payment application (243, 245).

[0245] FIG. 14B illustrates a situation in which electronic devices (102, 103) execute payment applications (243, 245) upon triggering a first electronic device (101). Referring to FIG. 14B, the electronic devices (102, 103) may display payment UIs (1412, 1413) via the payment application (243, 245). The electronic devices (102, 103) may display payment UIs (1412, 1413) including image objects for a selected payment card and signature. However, the present invention is not limited thereto. The electronic devices (101, 102, 103) may output vibration-based payment UIs (e.g., NUIs) (1411, 1414, 1415). Electronic devices (101, 102, 103) can output a payment UI (1411, 1414, 1415) including a vibration corresponding to the selected payment card.

[0246] In the situation of FIG. 14b, at least one of the electronic devices (101, 102, 103) may output a payment signal. For example, some of the electronic devices (101, 102, 103) that output a payment UI may not output a payment signal. For example, among the electronic devices (101, 102, 103) that output a payment UI, the first electronic device (101) may output a payment signal, and the electronic devices (102, 103) may not output a payment signal. However, the present invention is not limited thereto.

[0247] In the situation of FIG. 14b, payment can be successfully made by any of the electronic devices (101, 102, 103). Based on the successful payment, the first electronic device (101) can transmit a signal to the electronic devices (102, 103) to cause the electronic devices (102, 103) to return to their previous state.

[0248] Electronic devices (102, 103) can display the screen before the execution of the payment application (243, 245) on the display (1402, 1403).

[0249] FIG. 15A illustrates an example of a message displayed by electronic devices according to an embodiment. FIG. 15B illustrates an example of a message displayed by electronic devices according to an embodiment.

[0250] The first electronic device (101) can determine whether the payment was successful. The first electronic device (101) can determine whether the payment was successful based on the code included in the response. If the response includes RESULT_CODE_PAYMENT_SUCCESS, the first electronic device (101) can determine that the payment was successful. If the response includes RESULT_CODE_PAYMENT_FAILURE, the first electronic device (101) can determine that the payment was unsuccessful.

[0251] The first electronic device (101) can output a notification corresponding to the response code. If payment fails, the first electronic device (101) can output a notification corresponding to the response code. Additionally, the first electronic device (101) can request at least one of the other electronic devices (102, 103) to output a notification corresponding to the response code.

[0252] For example, if payment retry is possible, the first electronic device (101) may output a notification to guide the electronic devices (101, 102, 103) to retry the payment. Referring to FIG. 15A, the electronic devices (101, 102, 103) may output payment UIs (1501, 1502, 1503) including notifications guiding payment retry. Here, the payment UI (1501) may include a haptic. The payment UIs (1502, 1503) may be displayed through a display.

[0253] For example, if payment retry is not possible, the first electronic device (101) may output a notification to the electronic devices (101, 102, 103) informing them that payment is not possible. Referring to FIG. 15b, the electronic devices (101, 102, 103) may output payment UIs (1511, 1512, 1513) including a notification informing them that payment is not possible. Here, the payment UI (1511) may include a haptic. The payment UIs (1512, 1513) may be displayed through a display.

[0254] FIG. 16 is a flowchart illustrating an operation of an electronic device triggering entry into payment mode according to one embodiment.

[0255] Figure 16 can be explained with reference to Figures 1, 2a, 2b and 3.

[0256] Referring to FIG. 16, in operation 1601, the payment application (241) may identify a user input. Here, the user input may be an input used to authenticate the user. For example, the user input may include a gesture input. The gesture input may include a pattern input for authenticating the user. The user input may include an input for entering a password or a personal identification number (PIN) for authenticating the user. The user input may include an input of the user's biometric information (e.g., iris, fingerprint).

[0257] The payment application (241) can identify a card corresponding to a user input. The payment application (241) can identify a card corresponding to the user input among a plurality of cards. The payment application (241) can identify a card indicated by the user input among a plurality of cards registered in association with a user account. Here, the registration of a plurality of cards in association with a user account may mean that they are registered with the payment server (211). The registration of a plurality of cards in association with a user account may mean that the payment server (211) manages a plurality of cards in association with the user account.

[0258] In operation 1610, the payment application (241) may authenticate the user. The payment application (241) may authenticate the user based on a user input. For example, the payment application (241) may authenticate the user based on whether the user input is a registered user input. For example, the payment application (241) may authenticate the user based on whether the user input is a registered gesture. Here, the registration of the user input may mean that data representing the user input is registered in the memory of the first electronic device (101). The registration of the user input may mean that data representing the user input is registered in a server (not shown) that manages user authentication. For example, the user may be authenticated by comparing the user input with the registered data. However, the present invention is not limited thereto. The payment application (241) may authenticate the user based on the user's biometric information (e.g., iris, fingerprint). For example, the payment application (241) may authenticate the user based on whether the biometric information is registered biometric information. Here, the registration of biometric information may mean that data regarding the biometric information is registered in the memory of the first electronic device (101). The registration of biometric information may mean that data regarding the biometric information is registered in a server (not shown) that manages user authentication. For example, a user may be authenticated by comparing the biometric information with the registered data.

[0259] In operation 1621, the payment application (241) may request to enter payment preparation mode. The payment application (241) may request to enter payment preparation mode from the payment application (243). Here, the payment preparation mode may include a state in which the payment application (243) is running in the foreground. The payment preparation mode may include a state in which the running foreground application is changed to the payment application (243). The payment preparation mode may include a state in which the payment application (243) selects a card. The payment preparation mode may include a state in which the payment application (243) outputs a payment UI. Here, entering payment preparation mode may mean that the second electronic device (102) switches the running foreground application. Entering payment preparation mode may mean that the second electronic device (102) switches the running foreground application to the payment application (243).

[0260] In operation 1625, the payment application (241) may request to enter payment preparation mode. The payment application (241) may request the payment application (245) to enter payment preparation mode. Here, the payment preparation mode may include a state in which the payment application (245) is running in the foreground. The payment preparation mode may include a state in which the running foreground application is changed to the payment application (245). The payment preparation mode may include a state in which the payment application (245) selects a card. The payment preparation mode may include a state in which the payment application (245) outputs a payment UI.

[0261] In operation 1631, the payment application (241) may output a payment UI. The payment application (241) may output the payment UI through the display (260). Here, the payment UI may include a UI in a form that can interact with a user. For example, the payment UI may be based on at least one of a GUI, a NUI, an AUI, or a PUI. If the payment UI is based on the NUI, the payment application (241) may output a haptic based on the haptic module (179) based on receiving a card selection response. If the payment UI is based on the AUI, the payment application (241) may output a sound signal based on the sound output module (155) based on receiving a card selection response. Here, the sound output by the payment application (241) may change depending on the selected card.

[0262] In operation 1633, the payment application (243) may output a payment UI. The payment application (243) may output the payment UI through the display (261). Here, the payment UI may include a UI in a form that allows interaction with the user. For example, the payment UI may be based on at least one of a GUI, a NUI, an AUI, or a PUI.

[0263] In operation 1635, the payment application (245) may output a payment UI. The payment application (245) may output the payment UI through the display (263). Here, the payment UI may include a UI in a form that allows interaction with the user. For example, the payment UI may be based on at least one of a GUI, a NUI, an AUI, or a PUI.

[0264] In operation 1640, the payment application (241) may determine whether to perform a payment. The payment application (241) may identify a payment terminal. In one embodiment, the payment application (241) may identify a payment terminal based on the priorities of the user's electronic devices (101, 102, 103). In one embodiment, the payment application (241) may identify a payment terminal based on the priorities of the applications currently running on each of the electronic devices (101, 102, 103). In one embodiment, the payment application (241) may identify a payment terminal based on the payment device (219).

[0265] If the first electronic device (101) is identified as a payment terminal, the payment application (241) can determine that payment is being performed. If electronic devices (102, 103) other than the first electronic device (101) are identified as payment terminals, the payment application (241) can determine that payment is not being performed.

[0266] At operation 1640, based on the first electronic device (101) being identified as performing a payment, the payment application (241) may perform operation 1661. At operation 1640, based on the first electronic device (101) being identified as not performing a payment, the payment application (241) may perform operation 1650.

[0267] In operation 1650, the payment application (241) may identify a payment terminal. In one embodiment, the payment application (241) may identify the payment terminal based on the priorities of the user's electronic devices (102, 103). In one embodiment, the payment application (241) may identify the payment terminal based on the priorities of the applications currently running on each of the electronic devices (102, 103). In one embodiment, the payment application (241) may identify the payment terminal based on an error code. In one embodiment, the payment application (241) may identify the payment terminal based on the payment device (219).

[0268] If the second electronic device (102) is identified as a payment terminal, the payment application (241) can determine that the second electronic device (102) is performing the payment. If the third electronic device (103) is identified as a payment terminal, the payment application (241) can determine that the third electronic device (103) is performing the payment.

[0269] At operation 1650, based on the identification that the second electronic device (102) is performing the payment, the payment application (243) may perform operation 1663. At operation 1650, based on the identification that the third electronic device (103) is performing the payment, the payment application (245) may perform operation 1665.

[0270] In some embodiments, operations 1640 and 1650 may be replaced with a single operation. For example, in one embodiment, the payment application (241) may identify a payment terminal based on the priorities of the user's electronic devices (101, 102, 103). In one embodiment, the payment application (241) may identify a payment terminal based on the priorities of the applications currently running on each of the electronic devices (101, 102, 103). In one embodiment, the payment application (241) may identify a payment terminal based on an error code. In one embodiment, the payment application (241) may identify a payment terminal based on the payment device (219).

[0271] Based on the electronic device identified as performing the payment, at least one of operations 1661, 1663, or 1665 may be performed. For example, operations 1661, 1663, and 1665 may be performed concurrently and / or sequentially. For example, one of operations 1661, 1663, or 1665 may be performed. For example, two selected operations of operations 1661, 1663, or 1665 may be performed.

[0272] In operation 1661, the payment application (241) can perform a payment. The payment application (241) can output a payment signal through the payment framework (242). The payment application (241) can output the payment signal based on MST and / or NFC through the payment framework (242).

[0273] In operation 1663, the payment application (243) can perform a payment. The payment application (243) can output a payment signal through the payment framework (244). The payment application (243) can output the payment signal based on MST and / or NFC through the payment framework (244).

[0274] In operation 1665, the payment application (245) can perform a payment. The payment application (245) can output a payment signal through the payment framework (246). The payment application (245) can output the payment signal based on MST and / or NFC through the payment framework (246).

[0275] FIG. 17 is a flowchart illustrating an operation of an electronic device triggering payment of another electronic device according to one embodiment.

[0276] FIG. 17 may be described with reference to FIGS. 1, 2a, 2b, 3, and 16. Operation 1650 of FIG. 17 may correspond to operation 1650 of FIG. 16.

[0277] Referring to FIG. 17, in operation 1650, the payment application (241) can identify a payment performing terminal.

[0278] If the second electronic device (102) is identified as a payment terminal, the payment application (241) can determine that the second electronic device (102) is performing the payment. If the third electronic device (103) is identified as a payment terminal, the payment application (241) can determine that the third electronic device (103) is performing the payment.

[0279] At operation 1650, based on the identification that the first terminal is performing the payment, the payment application (241) may perform operation 1710. At operation 1650, based on the identification that a terminal other than the first terminal is performing the payment, the payment application (241) may perform operation 1720.

[0280] In operation 1721, the payment application (241) may request payment from the payment application (243). The payment application (241) may request payment from the payment application (243). The payment application (241) may instruct the payment application (243) to request payment via a command (TossPay). Here, the parameters of the command (TossPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), a callback method (callback), or an error code.

[0281] In operation 1720, the payment application (241) may request payment from the payment application (245). The payment application (241) may request payment from the payment application (245). The payment application (241) may instruct the payment application (245) to request payment via a command (TossPay). Here, the parameters of the command (TossPay) may include at least one of an authentication result (secureObject), a payment setting (payConfig), a callback method (callback), or an error code.

[0282] In operation 1731, the payment application (243) may determine whether a token exists. For example, the payment application (243) may determine whether a token exists for the selected card. For example, the payment application (243) may determine whether the token for the selected card is valid.

[0283] If a token for the card selected in operation 1731 does not exist, the payment application (243) may perform operation 1733. If a token for the card selected in operation 1731 exists but is invalid, the payment application (243) may perform operation 1733. If a token for the card selected in operation 1731 does not exist, the payment application (243) may perform operation 1733. If a token for the card selected in operation 1731 exists and is valid, the payment application (243) may perform operation 1735.

[0284] In operation 1733, the payment application (243) may obtain a token. The payment application (243) may obtain the token from the payment server (211). The payment application (243) may obtain the token by requesting the payment server (211) for a token corresponding to information (e.g., PAN, card expiration date, or CVV) about a payment method (e.g., credit card). Here, the information (e.g., PAN, card expiration date, or CVV) about the payment method (e.g., credit card) may be obtained from the payment application (243). For example, the information (e.g., PAN, card expiration date, or CVV) about the payment method (e.g., credit card) may be obtained by a request to enter payment preparation mode in operation 1621. For example, the information (e.g., PAN, card expiration date, or CVV) about the payment method (e.g., credit card) may be included in the payment request in operation 1710.

[0285] In operation 1735, the payment application (243) can perform a payment. The payment application (243) can output a payment signal through the payment framework (244). The payment application (243) can output the payment signal based on MST and / or NFC through the payment framework (244).

[0286] In operation 1741, the payment application (245) may determine whether a token exists. For example, the payment application (245) may determine whether a token exists for the selected card. For example, the payment application (245) may determine whether the token for the selected card is valid.

[0287] If a token does not exist for the card selected in operation 1741, the payment application (245) may perform operation 1743. If a token exists for the card selected in operation 1741 but is invalid, the payment application (245) may perform operation 1743. If a token does not exist for the card selected in operation 1741, the payment application (245) may perform operation 1743. If a token exists for the card selected in operation 1741 and is valid, the payment application (245) may perform operation 1745.

[0288] In operation 1743, the payment application (245) may obtain a token. The payment application (245) may obtain the token from the payment server (211). The payment application (245) may obtain the token by requesting the payment server (211) a token corresponding to information (e.g., PAN, card expiration date, or CVV) about a payment method (e.g., credit card). Here, the information (e.g., PAN, card expiration date, or CVV) about the payment method (e.g., credit card) may be obtained from the payment application (245). For example, the information (e.g., PAN, card expiration date, or CVV) about the payment method (e.g., credit card) may be obtained by a request to enter payment preparation mode in operation 1625. For example, the information (e.g., PAN, card expiration date, or CVV) about the payment method (e.g., credit card) may be included in the payment request in operation 1720.

[0289] In operation 1745, the payment application (245) can perform a payment. The payment application (245) can output a payment signal through the payment framework (246). The payment application (245) can output the payment signal based on MST and / or NFC through the payment framework (246).

[0290] FIG. 18 is a flowchart illustrating an operation of an electronic device triggering payment of another electronic device according to one embodiment.

[0291] FIG. 18 may be described with reference to FIGS. 1, 2A, 2B, 3, and 16. Operations 1650, 1710, or 1720 of FIG. 18 may correspond to operations 1650, 1710, or 1720 of FIG. 17, respectively. Operation 1650 of FIG. 18 may correspond to operation 1650 of FIG. 16 or FIG. 17.

[0292] Referring to FIG. 18, at operation 1650, the payment application (241) can identify a payment execution terminal. At operation 1710, the payment application (241) can request payment from the payment application (243). At operation 1720, the payment application (241) can request payment from the payment application (245).

[0293] In operation 1811, the payment application (243) can determine whether user authentication is required. The payment application (243) can determine whether user authentication related to the payment has been performed. The payment application (243) can determine whether the authentication result related to the payment is identified.

[0294] For example, the payment application (243) may determine that user authentication is required if the authentication result related to payment is not transmitted from the payment application (241). For example, the payment application (243) may determine that user authentication is required if the authentication result related to payment transmitted from the payment application (241) is invalid (e.g., authentication has expired). The application (243) may determine that user authentication is not required if the authentication result related to payment transmitted from the payment application (241) is valid.

[0295] If user authentication is required in operation 1811, the payment application (243) may perform operation 1813. If user authentication is not required in operation 1811, the payment application (243) may perform operation 1817.

[0296] In operation 1813, the payment application (243) may identify a user input. The user input may be input used to authenticate the user. For example, the user input may include a gesture input. The gesture input may include a pattern input for authenticating the user. The user input may include an input for entering a password or PIN for authenticating the user. The user input may include input of the user's biometric information (e.g., iris, fingerprint).

[0297] In operation 1815, the payment application (243) may authenticate the user. The payment application (243) may authenticate the user based on a user input. For example, the payment application (243) may authenticate the user based on whether the user input is a registered user input. For example, the payment application (243) may authenticate the user based on whether the user input is a registered gesture. Here, the registration of the user input may mean that data representing the user input is registered in the memory of the second electronic device (102). The registration of the user input may mean that data representing the user input is registered in a server (not shown) that manages user authentication. For example, the user may be authenticated by comparing the user input with the registered data. However, the present invention is not limited thereto. The payment application (243) may authenticate the user based on the user's biometric information (e.g., iris, fingerprint). For example, the payment application (243) may authenticate the user based on whether the biometric information is registered biometric information. Here, the registration of biometric information may mean that data regarding the biometric information is registered in the memory of the second electronic device (102). The registration of biometric information may mean that data regarding the biometric information is registered in a server (not shown) that manages user authentication. For example, a user may be authenticated by comparing the biometric information with the registered data.

[0298] In operation 1817, the payment application (243) can perform a payment. The payment application (243) can output a payment signal through the payment framework (244). The payment application (243) can output a payment signal based on MST and / or NFC through the payment framework (244).

[0299] In operation 1821, the payment application (245) can determine whether user authentication is required. The payment application (245) can determine whether user authentication related to the payment has been performed. The payment application (245) can determine whether the authentication result related to the payment is identified.

[0300] For example, the payment application (245) may determine that user authentication is required if the authentication result related to payment is not transmitted from the payment application (241). For example, the payment application (245) may determine that user authentication is required if the authentication result related to payment transmitted from the payment application (241) is invalid (e.g., authentication has expired). The application (245) may determine that user authentication is not required if the authentication result related to payment transmitted from the payment application (241) is valid.

[0301] If user authentication is required in operation 1821, the payment application (245) may perform operation 1823. If user authentication is not required in operation 1821, the payment application (245) may perform operation 1827.

[0302] In operation 1823, the payment application (245) may identify a user input. The user input may be input used to authenticate the user. For example, the user input may include a gesture input. The gesture input may include a pattern input for authenticating the user. The user input may include an input for entering a password or PIN for authenticating the user. The user input may include input of the user's biometric information (e.g., iris, fingerprint).

[0303] In operation 1825, the payment application (245) may authenticate the user. The payment application (245) may authenticate the user based on a user input. For example, the payment application (245) may authenticate the user based on whether the user input is a registered user input. For example, the payment application (245) may authenticate the user based on whether the user input is a registered gesture. Here, the registration of the user input may mean that data representing the user input is registered in the memory of the third electronic device (103). The registration of the user input may mean that data representing the user input is registered in a server (not shown) that manages user authentication. For example, the user may be authenticated by comparing the user input with the registered data. However, the present invention is not limited thereto. The payment application (245) may authenticate the user based on the user's biometric information (e.g., iris, fingerprint). For example, the payment application (245) may authenticate the user based on whether the biometric information is registered biometric information. Here, the registration of biometric information may mean that data about the biometric information is registered in the memory of the third electronic device (103). The registration of biometric information may mean that data about the biometric information is registered in a server (not shown) that manages user authentication. For example, a user may be authenticated by comparing the biometric information with the registered data.

[0304] In operation 1827, the payment application (245) can perform a payment. The payment application (245) can output a payment signal through the payment framework (246). The payment application (245) can output the payment signal based on MST and / or NFC through the payment framework (246).

[0305] FIG. 19 is a flowchart illustrating an operation of an electronic device triggering payment of another electronic device according to one embodiment.

[0306] FIG. 19 may be described with reference to FIGS. 1, 2A, 2B, 3, and 16. Operations 1650, 1710, or 1720 of FIG. 19 may correspond to operations 1650, 1710, or 1720 of FIG. 17 or FIG. 18, respectively. Operations 1811, 1813, 1815, 1821, 1823, or 1825 of FIG. 19 may correspond to operations 1811, 1813, 1815, 1821, 1823, or 1825 of FIG. 18, respectively. Operation 1650 of FIG. 18 may correspond to operation 1650 of FIG. 16, FIG. 17, or FIG. 18.

[0307] Referring to FIG. 19, at operation 1650, the payment application (241) can identify a payment execution terminal. At operation 1710, the payment application (241) can request payment from the payment application (243). At operation 1720, the payment application (241) can request payment from the payment application (245).

[0308] In operation 1811, the payment application (243) may determine whether user authentication is required. If user authentication is required in operation 1811, the payment application (243) may perform operation 1813. If user authentication is not required in operation 1811, the payment application (243) may perform operation 1911.

[0309] At operation 1813, the payment application (243) can identify the user input. At operation 1815, the payment application (243) can authenticate the user.

[0310] In operation 1911, the payment application (243) may determine whether a token exists. For example, the payment application (243) may determine whether a token exists for the selected card. For example, the payment application (243) may determine whether the token for the selected card is valid.

[0311] If a token does not exist for the card selected in operation 1911, the payment application (243) may perform operation 1913. If a token exists for the card selected in operation 1911 but is invalid, the payment application (243) may perform operation 1913. If a token does not exist for the card selected in operation 1911, the payment application (243) may perform operation 1913. If a token exists for the card selected in operation 1911 and is valid, the payment application (243) may perform operation 1915.

[0312] In operation 1913, the payment application (243) may obtain a token. The payment application (243) may obtain the token from the payment server (211). The payment application (243) may obtain the token by requesting the payment server (211) for a token corresponding to information (e.g., PAN, card expiration date, or CVV) regarding a payment method (e.g., credit card).

[0313] In operation 1915, the payment application (243) can perform a payment. The payment application (243) can output a payment signal through the payment framework (244). The payment application (243) can output the payment signal based on MST and / or NFC through the payment framework (244).

[0314] In operation 1821, the payment application (245) may determine whether user authentication is required. If user authentication is required in operation 1821, the payment application (245) may perform operation 1823. If user authentication is not required in operation 1821, the payment application (245) may perform operation 1827.

[0315] At operation 1823, the payment application (245) may identify the user input. At operation 1825, the payment application (245) may authenticate the user.

[0316] In operation 1921, the payment application (245) may determine whether a token exists. For example, the payment application (245) may determine whether a token exists for the selected card. For example, the payment application (245) may determine whether the token for the selected card is valid.

[0317] If a token does not exist for the card selected in operation 1921, the payment application (245) may perform operation 1923. If a token exists for the card selected in operation 1921 but is invalid, the payment application (245) may perform operation 1923. If a token does not exist for the card selected in operation 1921, the payment application (245) may perform operation 1923. If a token exists for the card selected in operation 1921 and is valid, the payment application (245) may perform operation 1925.

[0318] In operation 1923, the payment application (245) may obtain a token. The payment application (245) may obtain the token from the payment server (211). The payment application (245) may obtain the token by requesting the payment server (211) for a token corresponding to information (e.g., PAN, card expiration date, or CVV) regarding a payment method (e.g., credit card).

[0319] At operation 1925, the payment application (245) can perform the payment.

[0320] The payment application (245) can output a payment signal through the payment framework (246). The payment application (245) can output a payment signal based on MST and / or NFC through the payment framework (246).

[0321] As described above, the first electronic device (101) may include at least one communication circuit (290). The first electronic device (101) may include at least one processor (120). The first electronic device (101) may include at least one memory (130) storing instructions. The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to obtain payment information related to a payment request in response to an input requesting payment. The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to, in response to obtaining the payment information, transmit data including the payment information to the at least one external electronic device (102, 103) via the at least one communication circuit (290), causing the at least one external electronic device (102, 103) to display a screen including at least one piece of the payment information on a display (261, 263) of the at least one external electronic device (102, 103). The above instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to, in response to obtaining the payment information, emit a payment signal for the payment based on the data including the payment information to the outside through the at least one communication circuit (290).

[0322] The instructions, when executed by the at least one processor (120), are configured to cause the first electronic device (101) to, after radiating the signal for the payment to the outside, obtain a signal indicating that the payment has failed from a server (211, 213, 215, 217) related to the payment information through the at least one communication circuit (290), and the instructions, when executed by the at least one processor (120), are configured to cause the first electronic device (101) to, in response to obtaining the signal indicating that the payment has failed, transmit a request to the external electronic device (102, 103) through the at least one communication circuit (290), causing the at least one external electronic device (102, 103) to radiate another payment signal for the payment based on the data to the outside.

[0323] The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to select some of the at least one external electronic device (102, 103) based on priority information in response to obtaining the signal indicating that the payment has failed. The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to transmit the request to the selected some of the external electronic devices (102, 103) via the at least one communication circuit (290).

[0324] The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to obtain, through the at least one communication circuit (290), another signal indicating that the payment has failed from the selected some external electronic devices (102, 103). The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to select another some external electronic device (102, 103) from among the at least one external electronic device (102, 103) based on priority information, in response to obtaining the another signal indicating that the payment has failed from the selected some external electronic devices (102, 103). The above instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to transmit the request to the selected other external electronic device (102, 103) via the at least one communication circuit (290).

[0325] The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to obtain another signal from the selected external electronic devices (102, 103) indicating that the payment is successful. The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to, in response to obtaining the another signal indicating that the payment is successful, transmit a request to the at least one external electronic device (102, 103) via the at least one communication circuit (290), causing the at least one external electronic device (102, 103) to stop displaying the screen.

[0326] The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to transmit, through the at least one communication circuit (290), the request based on the signal indicating that the payment has failed to the at least one external electronic device (102, 103), such that another signal is generated in the at least one external electronic device (102, 103) based on payment failure type information of the signal indicating that the payment has failed.

[0327] The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to radiate the signal for the payment based on the first communication protocol to the outside through the at least one communication circuit (290). The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to, in response to obtaining the signal indicating that the payment has failed, select some external electronic device (102, 103) among the at least one external electronic device (102, 103) capable of generating the other signal for the payment based on a second communication protocol different from the first communication protocol. The above instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to transmit the request to the selected external electronic devices (102, 103) via the at least one communication circuit (290).

[0328] The instructions may be configured to cause the first electronic device (101) to, when executed by the at least one processor (120), obtain a signal indicating that the payment has failed from a server (211, 213, 215, 217) related to the payment information through the at least one communication circuit (290) after radiating the signal for the payment to the outside. The instructions may be configured to cause the first electronic device (101) to, when executed by the at least one processor (120), in response to obtaining the signal indicating that the payment has failed, transmit the signal indicating that the payment has failed to the at least one external electronic device (102, 103) through the at least one communication circuit (290), causing the at least one external electronic device (102, 103) to display another screen on a display (261, 263) based on payment failure type information included in the signal indicating that the payment has failed.

[0329] The instructions may be configured to cause the first electronic device (101) to, when executed by the at least one processor (120), obtain a signal indicating that the payment is successful from a server (211, 213, 215, 217) related to the payment information through the at least one communication circuit (290) after radiating the signal for the payment to the outside. The instructions may be configured to cause the first electronic device (101) to, when executed by the at least one processor (120), in response to obtaining the signal indicating that the payment is successful, transmit a request to the at least one external electronic device (102, 103) through the at least one communication circuit (290), causing the at least one external electronic device (102, 103) to stop displaying the screen.

[0330] The first electronic device (101) may further include at least one sensor. The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to obtain, through the at least one sensor, a user's gesture for payment based on at least one card among a plurality of cards. The instructions, when executed by the at least one processor (120), may be configured to cause the first electronic device (101) to obtain at least a portion of the payment information by authenticating the user based on the data representing the gesture.

[0331] The method may be performed by a first electronic device (101) including at least one communication circuit (290). The method may include, in response to an input requesting payment, obtaining payment information related to the payment request. The method may include, in response to obtaining the payment information, transmitting data including the payment information to at least one external electronic device (102, 103) through the at least one communication circuit (290), causing the at least one external electronic device (102, 103) other than the first electronic device (101) to display a screen including at least one piece of the payment information on a display (261, 263) of the at least one external electronic device (102, 103). The method may include, in response to obtaining the payment information, emitting a payment signal for the payment based on the data including the payment information to the outside through the at least one communication circuit (290).

[0332] As described above, a non-transitory computer-readable storage medium may include a program storing instructions. The instructions, when executed by at least one processor (120) of a first electronic device (101) including at least one communication circuit (290), may cause the first electronic device (101) to, in response to an input requesting payment, obtain payment information related to the payment request. The instructions, when executed by the at least one processor (120), may cause the first electronic device (101) to, in response to obtaining the payment information, transmit data including the payment information to the at least one external electronic device (102, 103) via the at least one communication circuit (290), which causes the at least one external electronic device (102, 103) to display a screen including at least one piece of the payment information on a display (261, 263) of the at least one external electronic device (102, 103). The above instructions, when executed by the at least one processor (120), may cause the first electronic device (101) to, in response to obtaining the payment information, emit a payment signal for the payment based on the data including the payment information to the outside through the at least one communication circuit (290).

[0333] As described above, the electronic device (102, 103) may include a display (261, 263). The electronic device (102, 103) may include at least one communication circuit (291, 293). The electronic device (102, 103) may include at least one processor (221, 223). The electronic device (102, 103) may include at least one memory (231, 233) for storing instructions. The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to receive data including payment information from an external first electronic device (101) connected to the electronic device (102, 103) based on short-range wireless communication via the at least one communication circuit (291, 293). The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to display, on the display (261, 263), a screen including at least one piece of payment information based on receiving the data. The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to receive a request from the external first electronic device (101) to externally emit a signal for payment based on the data while displaying the screen on the display (261, 263). The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to externally emit the signal for payment based on the data through the at least one communication circuit (291, 293) in response to receiving the request.

[0334] The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to identify a running application based on receiving the data. The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to stop displaying the screen in response to the running application being a designated application. The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to display the screen on the display (261, 263) in response to the running application being distinguished from the designated application.

[0335] The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to receive the request based on a signal indicating that the payment has failed. The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to externally emit the signal generated based on payment failure type information included in the result signal indicating that the payment has failed.

[0336] The above signal may be generated based on a communication protocol different from the communication protocol on which other signals generated by the external first electronic device (101) for the payment are based.

[0337] The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to receive, from the external first electronic device (101), a signal indicating that the payment has failed, via the at least one communication circuit (291, 293). The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to, in response to receiving the signal indicating that the payment has failed, display, via the display (261, 263), another screen based on payment failure type information included in the signal indicating that the payment has failed, on the display (261, 263).

[0338] The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to obtain a signal indicating that the payment is successful from the external first electronic device (101) via the at least one communication circuit (291, 293). The instructions, when executed by the at least one processor (221, 223), may be configured to cause the electronic device (102, 103) to stop displaying the screen in response to obtaining the signal indicating that the payment is successful.

[0339] The instructions may be configured such that, when executed by the at least one processor (221, 223), the electronic device (102, 103) transmits the signal for the payment to the outside, and then, through the at least one communication circuit (291, 293), obtains a signal indicating whether the payment was successful from a server related to the payment information. The instructions may be configured such that, when executed by the at least one processor (221, 223), the electronic device (102, 103) transmits, in response to obtaining the signal indicating whether the payment was successful, data based on the signal indicating whether the payment was successful to the external first electronic device (101) through the at least one communication circuit (291, 293).

[0340] The instructions may be configured to cause the electronic device (102, 103), when executed by the at least one processor (221, 223), to transmit to the outside the signal for the payment, and then, through the at least one communication circuit (291, 293), obtain a signal indicating that the payment has failed from a server associated with the payment information. The instructions may be configured to cause the electronic device (102, 103), when executed by the at least one processor (221, 223), to, in response to obtaining the signal indicating that the payment has failed, transmit, through the at least one communication circuit (291, 293), a request to transmit to the outside a signal for payment based on the data to the electronic device (102, 103) and to at least one other external first electronic device (101) associated with the external first electronic device (101).

[0341] As described above, the method can be performed by an electronic device (102, 103) including a display (261, 263) and at least one communication circuit (291, 293). The method can include an operation of receiving data including payment information from an external first electronic device (101) that is communicably connected to the electronic device (102, 103) based on short-range wireless communication via the at least one communication circuit (291, 293). The method can include an operation of displaying a screen including at least one piece of payment information on the display (261, 263) based on receiving the data including the payment information. The method can include an operation of receiving, from the external electronic device, a request to externally emit a signal for payment based on the data while displaying the screen on the display (261, 263). The method may include, in response to receiving the request, an operation of radiating the signal for payment based on the data to the outside through the at least one communication circuit (291, 293).

[0342] As described above, a non-transitory computer-readable storage medium may include a program storing instructions. The instructions, when executed by at least one processor (221, 223) of an electronic device (102, 103) including a display (261, 263) and at least one communication circuit (291, 293), may cause the electronic device (102, 103) to receive data including payment information from an external first electronic device (101) that is communicatively connected to the electronic device (102, 103) based on short-range wireless communication via the at least one communication circuit (291, 293). The instructions, when executed by the at least one processor (221, 223), may cause the electronic device (102, 103) to display a screen including at least one piece of payment information on the display (261, 263) based on receiving data including the payment information. The instructions, when executed by the at least one processor (221, 223), may cause the electronic device (102, 103) to receive a request from the external first electronic device (101) to externally emit a signal for payment based on the data while displaying the screen on the display (261, 263). The above instructions, when executed by the at least one processor (221, 223), may cause the electronic device (102, 103) to, in response to receiving the request, emit the signal for the payment based on the data to the outside through the at least one communication circuit (291, 293).

[0343] Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to the embodiments of this document are not limited to the aforementioned devices.

[0344] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another component (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0345] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0346] Various embodiments of the present document may be implemented as software (e.g., a program (140)) including one or more commands stored in a storage medium (e.g., an internal memory (136) or an external memory (138)) readable by a machine (e.g., a first electronic device (101)). For example, a processor (e.g., a processor (120)) of the machine (e.g., the first electronic device (101)) may call at least one command among the one or more commands stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one command called. The one or more commands may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0347] According to one embodiment, the method according to various embodiments disclosed in this document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., by download or upload) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0348] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In an electronic device (101), At least one communication circuitry (290), at least one processor (120), and Contains at least one memory (130) for storing instructions, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: In response to an input requesting payment, obtain payment information related to the payment request; In response to obtaining the payment information, transmitting data including the payment information to the at least one external electronic device (102, 103) via the at least one communication circuit (290), causing the electronic device (101) and at least one other external electronic device (102, 103) to display a screen including at least one piece of payment information on a display (261, 263) of the at least one external electronic device (102, 103), In response to obtaining the payment information, the payment signal for the payment based on the data including the payment information is configured to be emitted to the outside through the at least one communication circuit (290). Electronic devices.

2. In claim 1, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: After transmitting the payment signal to the outside, a result signal indicating that the payment has failed is obtained from a server (211, 213, 215, 217) related to the payment information through at least one communication circuit (290). In response to obtaining the result signal, a request is transmitted to the at least one external electronic device (102, 103) via the at least one communication circuit (290), causing the at least one external electronic device (102, 103) to externally emit another payment signal for the payment based on the data. Electronic devices.

3. In claim 1 or claim 2, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: In response to obtaining the above result signal, some of the external electronic devices (102, 103) are selected based on the priority information, configured to transmit the request to the selected external electronic devices (102, 103) via at least one communication circuit (290). Electronic devices.

4. In any one of claims 1 to 3, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: Through at least one communication circuit (290), another result signal indicating that the payment has failed is obtained from the selected external electronic device (102, 103), In response to obtaining the other result signal from the selected some external electronic devices (102, 103), based on the priority information, selecting another some external electronic devices (102, 103) among the at least one external electronic device (102, 103), configured to transmit the request to the selected other external electronic device (102, 103) via at least one communication circuit (290). Electronic devices.

5. In any one of claims 1 to 4, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: Obtaining another result signal indicating that the payment is successful from the selected external electronic devices (102, 103), In response to obtaining said other result signal, configured to transmit a request to said at least one external electronic device (102, 103) via said at least one communication circuit (290), causing said at least one external electronic device (102, 103) to stop displaying said screen. Electronic devices.

6. In any one of claims 1 to 5, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: Based on the payment failure type information included in the result signal, the other payment signal is configured to be generated in the at least one external electronic device (102, 103), and the request based on the result signal is transmitted to the at least one external electronic device (102, 103) through the at least one communication circuit (290). Electronic devices.

7. In any one of claims 1 to 6, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: The payment signal based on the first communication protocol is radiated to the outside through at least one communication circuit (290), In response to obtaining the above result signal, some external electronic devices (102, 103) are selected that can generate the other payment signal based on a second communication protocol different from the first communication protocol among the at least one external electronic device (102, 103), configured to transmit the request to the selected external electronic devices (102, 103) via at least one communication circuit (290). Electronic devices.

8. In any one of claims 1 to 7, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: After transmitting the payment signal to the outside, a result signal indicating that the payment has failed is obtained from a server (211, 213, 215, 217) related to the payment information through at least one communication circuit (290). In response to obtaining the result signal, a request based on the result signal is transmitted to the at least one external electronic device (102, 103) via the at least one communication circuit (290), causing the at least one external electronic device (102, 103) to display another screen based on payment failure type information included in the result signal on the display (261, 263). Electronic devices.

9. In any one of claims 1 to 8, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: After transmitting the payment signal to the outside, a result signal indicating that the payment is successful is obtained from a server (211, 213, 215, 217) related to the payment information through at least one communication circuit (290). In response to obtaining the result signal, configured to transmit a request to the at least one external electronic device (102, 103) via the at least one communication circuit (290), causing the at least one external electronic device (102, 103) to stop displaying the screen. Electronic devices.

10. In any one of claims 1 to 9, comprising at least one more sensor, The above instructions, when executed by the at least one processor (120), cause the electronic device (101) to: Obtaining a user's gesture for said payment based on at least one card among a plurality of cards through said at least one sensor, configured to obtain at least a portion of the payment information by authenticating the user based on the data representing the gesture; Electronic devices.

11. In electronic devices (102, 103), Display (261, 263), At least one communication circuitry (291, 293), At least one processor (221, 223), and Contains at least one memory (231, 233) for storing instructions, The above instructions, when executed by the at least one processor (221, 223), cause the electronic device (102, 103) to: Through at least one communication circuit (291, 293) above, data including payment information is received from an external electronic device (101) connected to the electronic device (102, 103) based on short-range wireless communication, Based on the above inbox, a screen including at least one piece of payment information is displayed on the display (261, 263), While displaying the above screen on the display (261, 263), a request is received from the external electronic device (101) to externally emit a payment signal for payment based on the above data, In response to receiving said request, configured to radiate said payment signal externally through said at least one communication circuit (291, 293), Electronic devices.

12. In claim 11, The above instructions, when executed by the at least one processor (221, 223), cause the electronic device (102, 103) to: Based on receiving the above data, identify the running application, In response to the above running application being the specified application, the display of the above screen is suspended, In response to the above running application being distinguished from the above designated application, the screen is configured to be displayed on the display (261, 263). Electronic devices.

13. In claim 11 or claim 12, The above instructions, when executed by the at least one processor (221, 223), cause the electronic device (102, 103) to: Receiving the above request based on a result signal indicating that the above payment has failed, configured to externally radiate the payment signal generated based on the payment failure type information included in the above result signal; Electronic devices.

14. In any one of claims 11 to 13, The above payment signal is generated based on a communication protocol different from the communication protocol on which other payment signals generated by the external electronic device (101) for the payment are based. Electronic devices.

15. A method performed by an electronic device (101) including at least one communication circuit (290), In response to an input requesting payment, an action to obtain payment information related to the payment request; In response to obtaining the payment information, an operation of transmitting data including the payment information to the at least one external electronic device (102, 103) via the at least one communication circuit (290), causing the electronic device (101) and at least one other external electronic device (102, 103) to display a screen including at least one piece of the payment information on a display (261, 263) of the at least one external electronic device (102, 103), and In response to obtaining the payment information, the method comprises emitting a payment signal for payment based on the data including the payment information to the outside through the at least one communication circuit (290). method.

Images