WO2016137300A1 - Electronic device providing electronic payment function and operation method thereof - Google Patents

Abstract

An electronic device, an electronic payment function, and an operation method are provided. The electronic device includes a display, a communication interface, and a processor, wherein the processor is configured to transmit a user identifier to a server through the communication interface, receive information of at least one card associated with the user identifier from the server through the communication interface and display the received information on a display, select one piece of card information from the displayed information of the at least one card, and request, through the communication interface, the server to issue a token for payment, using at least a part of the selected card information.

Description

ELECTRONIC DEVICE PROVIDING ELECTRONIC PAYMENT FUNCTION AND OPERATION METHOD THEREOF

The present disclosure relates to an electronic device and an operation method thereof. More particularly, the present disclosure relates to an electronic device for providing an electronic payment function, and an operation method thereof.

With the development of mobile communication technologies, an electronic device can perform various data communication functions as well as voice call functions. The electronic device, for example, a mobile device or a user device may provide various services through various applications. The electronic device may provide network-based communication services, such as multimedia services, for example, a music service, a dynamic image service, a digital broadcasting service, a call, wireless Internet, a short message service (SMS), a multimedia messaging service (MMS), and the like. Further, the electronic device has evolved from a simple communication medium to a device having various functions, such as a communication function, a circulation function, an Internet function, or a payment function, and may be used in the whole of the social, cultural, financial, or circulation industrial field.

The electronic device may provide, for example, a mobile payment scheme through the electronic device by the payment function. The electronic device may enable, for example, payment using the electronic device from a payment scheme using cash or a plastic card. The electronic device may provide, for example, a function of paying for, using the electronic device, a service or purchase of goods through on-line or off-line (in the case of proceeding payment after buying a product or food in an actual shop or restaurant) using a mobile payment service. Further, the electronic device may have, for example, a communication function for receiving or transmitting payment information.

When registering a new card in the electronic device as described above, a user should input all card information. Such an input of all card information by the user may cause inconvenience to the user.

Therefore, a need exists for an electronic device and an operation method thereof, which can improve the convenience in registering a new card.

The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present disclosure.

Aspects of the present disclosure are to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the present disclosure is to provide an electronic device and an operation method thereof, which can improve the convenience in registering a new card.

In accordance with an aspect of the present disclosure, a method of operating an electronic device is provided. The method includes transmitting a user identifier to a server, receiving information of at least one card associated with the user identifier from the server and displaying the received information on a display, selecting one piece of card information from the displayed information of the at least one card, and requesting the server to issue a token for payment, using at least a part of the selected card information.

In accordance with another aspect of the present disclosure, a method of operating a plurality of electronic devices is provided. The method includes performing management of or establishing a wired or wireless connection through a user identifier by the plurality of electronic devices, transmitting the user identifier to a server by a first electronic device among the plurality of electronic devices, receiving information of at least one card associated with the user identifier from the server by a second electronic device among the plurality of electronic devices, and requesting, by the second electronic device, the server to issue a token for payment, using at least a part of the received information of the at least one card.

In accordance with another aspect of the present disclosure, an electronic device is provided. The electronic device includes a display, a communication interface, and a processor, wherein the processor is configured to transmit a user identifier to a server through the communication interface, receive information of at least one card associated with the user identifier through the communication interface and display the received information on a display, select one piece of card information from the displayed information of the at least one card, and request, through the communication interface, the server to issue a token for payment, using at least a part of the selected card information.

Therefore, various embodiments may provide an electronic device and an operation method thereof, which can improve the convenience in registering a new card.

Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses various embodiments of the present disclosure.

The above and other aspects, features, and advantages of certain embodiments of the present disclosure will be more apparent from the following description taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram illustrating a network environment system according to various embodiments of the present disclosure;

FIG. 2 is a block diagram illustrating an electronic device according to various embodiments of the present disclosure;

FIG. 3 is a block diagram illustrating a programming module according to various embodiments of the present disclosure;

FIG. 4 is a block diagram illustrating a plurality of execution environments operated in an electronic device according to various embodiments of the present disclosure;

FIGS. 5A to 5C illustrate block diagrams of hardware structures of a trusted execution environment (TEE) according to various embodiments of the present disclosure;

FIG. 6 is a block diagram illustrating a payment system according to various embodiments of the present disclosure;

FIG. 7 is a block diagram illustrating a payment system for performing payment according to various embodiments of the present disclosure;

FIG. 8 is a block diagram illustrating a hardware structure of an electronic device according to various embodiments of the present disclosure;

FIG. 9 is a block diagram illustrating a program module to be executed in an execution environment of an electronic device according to various embodiments of the present disclosure;

FIG. 10 is a block diagram illustrating a payment system according to various embodiments of the present disclosure;

FIG. 11 is a block diagram illustrating a payment server according to various embodiments of the present disclosure;

FIG. 12 is a block diagram illustrating a method of generating a token cryptogram according to various embodiments of the present disclosure;

FIG. 13 is a signal flow diagram illustrating a communication method for payment between an electronic device and a point of sale (POS) device according to various embodiments of the present disclosure;

FIG. 14 is a block diagram illustrating a token payment flow in a payment system according to various embodiments of the present disclosure;

FIG. 15 is a block diagram illustrating a signal flow of an operation of a payment system according to various embodiments of the present disclosure;

FIGS. 16A to 16C illustrate screen configurations for registering a card associated with a user account in an electronic device according to various embodiments of the present disclosure;

FIG. 17 illustrates a screen configuration for transmitting card information in an electronic device according to various embodiments of the present disclosure;

FIGS. 18A to 18C illustrate screen configurations for registering a card associated with a user account in an electronic device according to various embodiments of the present disclosure;

FIG. 19 illustrates a signal flow diagram illustrating a token issuance operation in an electronic device according to various embodiments of the present disclosure;

FIG. 20 illustrates a signal flow diagram illustrating a process of registering a card relating to a user account in a payment system according to various embodiments of the present disclosure;

FIG. 21 is a flowchart illustrating a process of registering a card relating to a user account by an electronic device according to various embodiments of the present disclosure;

FIG. 22 is a flowchart illustrating a process of registering a card relating to a user account by a payment server according to various embodiments of the present disclosure;

FIG. 23 is a flowchart illustrating a process of registering a card relating to a user account by a token server according to various embodiments of the present disclosure;

FIGS. 24 to 26 are signal flow diagrams illustrating a process of registering a card in a payment system according to various embodiments of the present disclosure; and

FIGS. 27 and 28 are signal flow diagrams illustrating a process of registering a card relating to a user account in a payment system according to various embodiments of the present disclosure.

Throughout the drawings, like reference numerals will be understood to refer to like parts, components, and structures.

The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the present disclosure as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the present disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the present disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the present disclosure is provided for illustration purpose only and not for the purpose of limiting the present disclosure as defined by the appended claims and their equivalents.

It is to be understood that the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a component surface” includes reference to one or more of such surfaces.

By the term “substantially” it is meant that the recited characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including for example, tolerances, measurement error, measurement accuracy limitations and other factors known to those of skill in the art, may occur in amounts that do not preclude the effect the characteristic was intended to provide.

In an embodiment of the present disclosure, the expression “have”, “may have”, “include” or “may include” refers to existence of a corresponding feature (e.g., numerical value, function, operation, or components, such as elements), and does not exclude existence of additional features.

In an embodiment of the present disclosure, the expression “A or B,” “at least one of A or/and B,” or “one or more of A or/and B” may include all possible combinations of the items listed. For example, the expression “A or B,” “at least one of A and B,” or “at least one of A or B” refers to all of (1) including at least one A, (2) including at least one B, or (3) including all of at least one A and at least one B.

The expression “a first,” “a second,” “the first,” or “the second” used in various embodiments of the present disclosure may modify various components regardless of the order and/or the importance but does not limit the corresponding components. For example, a first electronic device and a second electronic device may indicate different user devices, regardless of order or importance thereof. For example, a first element may be interchangeably referred to as a second element, and similarly, a second element may be interchangeably referred to as a first element without departing from the scope of the present disclosure.

It should be understood that when an element (e.g., the first element) is referred to as being (operatively or communicatively) “connected” or “coupled” to another element (e.g., the second element), it may be directly connected or coupled directly to the other element. In such a situation, alternatively, any other element (e.g., a third element) may be interposed between them. In certain embodiments of the present disclosure, it may be understood that when an element (e.g., the first element) is referred to as being “directly connected,” or “directly coupled” to another element (e.g., the second element), there are no element (e.g., the third element) interposed between them (while there can be a connecting element, such as an adhesive or a connector between them).

The expression “configured to” used in embodiments of the present disclosure may be interchangeably used with, for example, “suitable for,” “having the capacity to,” “designed to,” “adapted to,” “made to,” or “capable of,” depending on the context. The term “configured to” may not necessarily imply “specifically designed to” in hardware. Alternatively, in some situations, the expression “device configured to” may mean that the device, together with other devices or components, “is able to.” For example, the phrase “processor adapted (or configured) to perform A, B, and C” may mean a dedicated processor (e.g., an embedded processor) only for performing the corresponding operations or a generic-purpose processor (e.g., a central processing unit (CPU) or an application processor (AP)) that can perform the corresponding operations by executing one or more software programs stored in a memory device.

Unless defined otherwise, all terms used herein, including technical and scientific terms, have the same meaning as those commonly understood by a person skilled in the art to which the present disclosure pertains. Such terms as those defined in a generally used dictionary may be interpreted to have the meanings equal to the contextual meanings in the relevant field of art, and are not to be interpreted to have ideal or excessively formal meanings unless clearly defined in embodiments of the present disclosure. In some cases, even the term defined in embodiments of the present disclosure should not be interpreted to exclude embodiments of the present disclosure.

An electronic device according to various embodiments of the present disclosure may include at least one of, for example, a smart phone, a tablet personal computer (PC), a mobile phone, a video phone, an electronic book reader (e-book reader), a desktop PC, a laptop PC, a netbook computer, a workstation, a server, a personal digital assistant (PDA), a portable multimedia player (PMP), a moving picture experts group phase 1 or phase 2 (MPEG-1 or MPEG-2) audio layer-3 (MP3) player, a mobile medical device, a camera, a wearable device, and the like. According to various embodiments of the present disclosure, the wearable device may include at least one of an accessory type (e.g., a watch, a ring, a bracelet, an anklet, a necklace, a glasses, a contact lens, or a head-mounted device (HMD)), a fabric or clothing integrated type (e.g., an electronic clothing), a body-mounted type (e.g., a skin pad, or tattoo), a bio-implantable type (e.g., an implantable circuit), and the like.

According to various embodiments of the present disclosure, the electronic device may be a home appliance. The home appliance may, for example, include at least one of a television, a digital versatile disc (DVD) player, an audio player, a refrigerator, an air conditioner, a cleaner, an oven, a microwave oven, a washing machine, an air purifier, a set-top box, a home automation control panel, a television (TV) box (e.g., HomeSync™ of Samsung, Apple TV™, or Google TV™), a game console (e.g., Xbox™, PalyStation™), an electronic dictionary, an electronic key, a camcorder, an electronic frame, and the like.

According to another embodiment of the present disclosure, the electronic device may include at least one of various medical devices (e.g., various portable medical measuring devices (e.g., a blood glucose measuring device, a heart rate measuring device, a blood pressure measuring device, a body temperature measuring device, and the like), a magnetic resonance angiography (MRA), a magnetic resonance imaging (MRI), a computed tomography (CT) machine, and an ultrasonic machine), a navigation device, a global navigation satellite system (GNSS) receiver, an event data recorder (EDR), a flight data recorder (FDR), a vehicle infotainment devices, an electronic devices for a ship (e.g., a navigation device for a ship, and a gyro-compass), avionics, security devices, an automotive head unit, a robot for home or industry, an automatic teller’s machine (ATM) in banks, a point of sale (POS) in a shop, or internet device of things (e.g., a light bulb, various sensors, electric or gas meter, a sprinkler device, a fire alarm, a thermostat, a streetlamp, a toaster, a sporting goods, a hot water tank, a heater, a boiler, and the like).

According to various embodiments of the present disclosure, the electronic device may include at least one of a part of furniture or a building/structure, an electronic board, an electronic signature-receiving device, a projector, and various kinds of measuring instruments (e.g., a water meter, an electric meter, a gas meter, and a radio wave meter). The electronic device according to various embodiments of the present disclosure may be a combination of one or more of the aforementioned various devices. The electronic device according to various embodiments of the present disclosure may be a flexible device. Further, the electronic device according to an embodiment of the present disclosure is not limited to the aforementioned devices, and may include a new electronic device according to the development of technology.

Hereinafter, an electronic device according to various embodiments will be described with reference to the accompanying drawings. As used herein, the term “user” may indicate a person who uses an electronic device or a device (e.g., an artificial intelligence electronic device) that uses an electronic device.

FIG. 1 is a block diagram illustrating a network environment according to various embodiments of the present disclosure.

Referring to FIG. 1, anelectronic device 101, a first externalelectronic device 102, or a second externalelectronic device 104 or aserver 106 may be connected to each other through anetwork 162 or a shortrange wireless communication 164. Theelectronic device 101 may include abus 110, aprocessor 120, amemory 130, an input/output interface 150, adisplay 160, and acommunication interface 170. In various embodiments of the present disclosure, theelectronic device 101 may omit at least one of the above elements or may further include other elements.

Thebus 110 may include, for example, a circuit for interconnecting theelements 110 to 170 and transferring communication (e.g., control messages and/or data) between the elements.

Theprocessor 120 may include one or more of a CPU, an AP, or a communication processor (CP). Theprocessor 120, for example, may carry out operations or data processing relating to control and/or communication of at least one other element of theelectronic device 101.

Thememory 130 may include a volatile memory and/or a non-volatile memory. Thememory 130 may store, for example, instructions or data relevant to at least one other element of theelectronic device 101. According to an embodiment of the present disclosure, thememory 130 may store software and/or aprogram 140. Theprogram 140 may include, for example, akernel 141,middleware 143, an application programming interface (API) 145, and/or application programs (or “applications”) 147. At least some of thekernel 141, themiddleware 143, and theAPI 145 may be referred to as an operating system (OS).

Thekernel 141 may control or manage system resources (e.g., thebus 110, theprocessor 120, or the memory 130) used for performing an operation or function implemented by the other programs (e.g., themiddleware 143, theAPI 145, or the application programs 147). Furthermore, thekernel 141 may provide an interface through which themiddleware 143, theAPI 145, or theapplication programs 147 may access the individual elements of theelectronic device 101 to control or manage the system resources.

Themiddleware 143, for example, may function as an intermediary for allowing theAPI 145 or theapplication programs 147 to communicate with thekernel 141 to exchange data.

In addition, themiddleware 143 may process one or more task requests received from theapplication programs 147 according to priorities thereof. For example, themiddleware 143 may assign priorities for using the system resources (e.g., thebus 110, theprocessor 120, thememory 130, and the like) of theelectronic device 101, to at least one of theapplication programs 147. For example, themiddleware 143 may perform scheduling or loading balancing on the one or more task requests by processing the one or more task requests according to the priorities assigned thereto.

TheAPI 145 is an interface through which theapplications 147 control functions provided from thekernel 141 or themiddleware 143, and may include, for example, at least one interface or function (e.g., an instruction) for file control, window control, image processing, or text control.

The input/output interface 150, for example, may function as an interface that may transfer instructions or data input from a user or another external device to the other element(s) of theelectronic device 101. In addition, the input/output interface 150 may output, to the user or another external device, commands or data received from the element(s) other than the input/output interface 150 within theelectronic device 101.

Examples of thedisplay 160 may include a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED(OLED) display, a microelectromechanical systems (MEMS) display, and an electronic paper display. Thedisplay 160, for example, may display various types of contents (e.g., a text, images, videos, icons, symbols, and the link) for the user. Thedisplay 160 may include a touch screen and receive, for example, a touch, gesture, proximity, or hovering input by using an electronic pen or the user's body part.

Thecommunication interface 170, for example, may set communication between theelectronic device 101 and an external device (e.g., the first externalelectronic device 102, the second externalelectronic device 104, or the server 106). For example, thecommunication interface 170 may be connected to anetwork 162 through wireless or wired communication to communicate with the external device (e.g., the second externalelectronic device 104 or the server 106).

The wireless communication may use at least one of, for example, long term evolution (LTE), LTE-advance (LTE-A), code division multiple access (CDMA), wideband CDMA (WCDMA), universal mobile telecommunications system (UMTS), wireless broadband (WiBro), and global system for mobile communications (GSM), as a cellular communication protocol. In addition, the wireless communication may include, for example,short range communication 164. The short-range communication 164 may include at least one of, for example, Wi-Fi, Bluetooth, Bluetooth low energy (BLE), near field communication (NFC), magnetic stripe transmission (MST), or Zigbee. The wireless communication may also utilize a global navigation satellite system (GNSS).

The MST may generate a pulse according to transmission data using an electromagnetic signal and the pulse may generate a magnetic field signal. Theelectronic device 101 may transmit the magnetic field signal to a POS device, and the POS device may detect the magnetic field signal using an MST reader and convert the detected magnetic field signal to an electric signal to restore the data.

The GNSS may include at least one of, for example, a GPS, a global navigation satellite system (Glonass), a Beidou navigation satellite system (hereinafter, referred to as “Beidou”), and European global satellite-based navigation system (Galileo). Hereinafter, in an embodiment of the present disclosure, the “GPS” may be interchangeably used with the “GNSS”. The wired communication may include, for example, at least one of a universal serial bus (USB), a high definition multimedia interface (HDMI), recommended standard 232 (RS-232), and a plain old telephone service (POTS). Thenetwork 162 may include at least one of a communication network, such as a computer network (e.g., a local area network (LAN) or a wide area network (WAN)), the internet, and a telephone network.

Each of the first externalelectronic device 102 and the second externalelectronic device 104 may be of a type identical to or different from that of theelectronic device 101. According to an embodiment of the present disclosure, theserver 106 may include a group of one or more servers. According to various embodiments of the present disclosure, all or some of the operations performed in theelectronic device 101 may be performed in another electronic device or a plurality of electronic devices (e.g., the first externalelectronic device 102 and the second externalelectronic device 104 or the server 106). According to an embodiment of the present disclosure, when theelectronic device 101 has to perform some functions or services automatically or in response to a request, theelectronic device 101 may make a request for performing at least some functions relating thereto to another device (e.g., the first externalelectronic device 102 or the second externalelectronic device 104 or the server 106) instead of performing the functions or services by itself or in addition. Another electronic device (e.g., the first externalelectronic device 102 or the second external electronic device 104) or theserver 106 may execute the requested functions or the additional functions, and may deliver a result of the execution to theelectronic device 101. Theelectronic device 101 may provide the received result as is or process it further, thereby performing the requested functions or services. To this end, for example, cloud computing, distributed computing, or client-server computing technology may be used.

FIG. 2 is a block diagram illustrating an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 2, for example, anelectronic device 201 may include the whole or part of theelectronic device 101 illustrated in FIG. 1.Theelectronic device 201 may include at least oneAP 210, acommunication module 220, a subscriber identification module (SIM)card 229, amemory 230, asensor module 240, aninput device 250, adisplay 260, aninterface 270, anaudio module 280, acamera module 291, apower management module 295, abattery 296, anindicator 297, and amotor 298.

Theprocessor 210 may control a plurality of hardware or software components connected to theprocessor 210 by driving an OS or an application program and perform processing of various pieces of data and calculations. Theprocessor 210 may be implemented by, for example, a system on chip (SoC). According to an embodiment of the present disclosure, theprocessor 210 may further include a graphics processing unit (GPU) and/or an image signal processor (ISP). Theprocessor 210 may include at least some (e.g., a cellular module 221) of the elements illustrated in FIG. 2. Theprocessor 210 may load, into a volatile memory, instructions or data received from at least one (e.g., a non-volatile memory) of the other elements and may process the loaded instructions or data, and may store various data in a non-volatile memory.

Thecommunication module 220 may have a configuration equal or similar to that of thecommunication interface 170 of FIG. 1. Thecommunication module 220 may include, for example, thecellular module 221, a Wi-Fi module 222, aBluetooth module 223, a GNSS module 224 (e.g., a GPS module, a Glonass module, a Beidou module, or a Galileo module), anNFC module 225, anMST module 226, and a radio frequency (RF)module 227.

Thecellular module 221 may provide a voice call, image call, a text message service, or an Internet service through, for example, a communication network. According to an embodiment of the present disclosure, thecellular module 221 may distinguish between and authenticateelectronic devices 201 within a communication network using a subscriber identification module (e.g., the SIM card 229). According to an embodiment of the present disclosure, thecellular module 221 may perform at least some of the functions that theprocessor 210 may provide. According to an embodiment of the present disclosure, thecellular module 221 may include a CP.

Each of the Wi-Fi module 222, theBT module 223, theGNSS module 224, theNFC module 225 and theMST module 226 may include, for example, a processor for processing data transmitted and received through the relevant module. According to various embodiments of the present disclosure, at least some (e.g., two or more) of thecellular module 221, the Wi-Fi module 222, theBT module 223, theGNSS module 224, theNFC module 225, and theMST module 226 may be included in one integrated chip (IC) or IC package.

TheRF module 227 may transmit/receive, for example, a communication signal (e.g., an RF signal). TheRF module 227 may include, for example, a transceiver, a power amp module (PAM), a frequency filter, a low noise amplifier (LNA), and/or an antenna. According to another embodiment of the present disclosure, at least one of thecellular module 221, the Wi-Fi module 222, theBluetooth module 223, theGNSS module 224, theNFC module 225, or theMST module 226 may transmit and receive RF signals through a separate RF module(s).

Thesubscriber identification module 229 may include, for example, a card including a subscriber identity module and/or an embedded SIM, and may contain unique identification information (e.g., an integrated circuit card identifier (ICCID)) or subscriber information (e.g., an international mobile subscriber identity (IMSI)).

The memory 230 (e.g., the memory 130) may include, for example, aninternal memory 232 or anexternal memory 234. Theinternal memory 232 may include at least one of, for example, a volatile memory (e.g., a dynamic random access memory (DRAM), a static RAM (SRAM), a synchronous dynamic RAM (SDRAM), and the like) and a non-volatile memory (e.g., a one time programmable read only memory (OTPROM), a programmable ROM (PROM), an erasable and programmable ROM (EPROM), an electrically erasable and programmable ROM (EEPROM), a flash memory (e.g., a NAND flash memory or a NOR flash memory), a hard driver, or a solid state drive (SSD).

Anexternal memory 234 may further include a flash drive, for example, a compact flash (CF), a secure digital (SD), a Micro-SD, a Mini-SD, an extreme digital (xD), a multi-media card (MMC), a memory stick, and the like. Theexternal memory 234 may be functionally and/or physically connected to theelectronic device 201 through various interfaces.

Thesecurity module 236 is a module including a storage space having a higher security level than that of thememory 230 and may be a circuit guaranteeing safe data storage and a protected execution environment. Thesecurity module 236 may be implemented by a separate circuit and may include a separate processor. Thesecurity module 236 may exist in, for example, a detachable smart chip or SD card, or may include an embedded secure elements (eSE) embedded in a fixed chip of theelectronic device 201. Further, thesecurity module 236 may be operated by an OS that is different from the OS of theelectronic device 201. For example, the security module may operate based on a java card open platform (JCOP) OS.

Thesensor module 240 may measure a physical quantity or detect an operation state of theelectronic device 201, and may convert the measured or detected information into an electrical signal. Thesensor module 240 may include, for example, at least one of agesture sensor 240A, agyro sensor 240B, anatmospheric pressure sensor 240C, amagnetic sensor 240D, anacceleration sensor 240E, agrip sensor 240F, aproximity sensor 240G, acolor sensor 240H (e.g., a red, green, blue (RGB) sensor), a biometric sensor 240I, a temperature/humidity sensor 240J, alight sensor 240K, and a ultraviolet (UV)sensor 240M. Additionally or alternatively, thesensor module 240 may include, for example, an E-nose sensor, an electromyography (EMG) sensor, an electroencephalogram (EEG) sensor, an electrocardiogram (ECG) sensor, an infrared (IR) sensor, an iris sensor, and/or a fingerprint sensor. Thesensor module 240 may further include a control circuit for controlling one or more sensors included therein. In various embodiments of the present disclosure, anelectronic device 201 may further include a processor configured to control thesensor module 240 as a part of or separately from theprocessor 210, and may control thesensor module 240 while theprocessor 210 is in a sleep state.

Theinput device 250 may include, for example, atouch panel 252, a (digital)pen sensor 254, a key 256, or anultrasonic input device 258. Thetouch panel 252 may use at least one of, for example, a capacitive scheme, a resistive scheme, an infrared scheme, and an ultrasonic scheme. In addition, thetouch panel 252 may further include a control circuit. Thetouch panel 252 may further include a tactile layer and provide a tactile reaction to the user.

The (digital)pen sensor 254 may include, for example, a recognition sheet which is a part of the touch panel or is separated from the touch panel. The key 256 may include, for example, a physical button, an optical key, a keypad, and the like. Theultrasonic input device 258 may detect ultrasonic wave generated by an input tool through a microphone (e.g., a microphone 288) and identify data corresponding to the detected ultrasonic waves.

The display 260 (e.g., the display 160) may include apanel 262, ahologram device 264, or aprojector 266. Thepanel 262 may include a configuration identical or similar to that of thedisplay 160 illustrated in FIG. 1. Thepanel 262 may be implemented to be, for example, flexible, transparent, or wearable. Thepanel 262 and thetouch panel 252 may be configured by one module. Thehologram device 264 may show a three dimensional image in the air by using an interference of light. Theprojector 266 may display an image by projecting light onto a screen. The screen may be located, for example, inside or outside theelectronic device 201. According to an embodiment of the present disclosure, thedisplay 260 may further include a control circuit for controlling thepanel 262, thehologram device 264, or theprojector 266.

Theinterface 270 may include, for example, anHDMI 272, aUSB 274, anoptical interface 276, or a D-subminiature (D-sub) 278. Theinterface 270 may be included in, for example, thecommunication interface 170 illustrated in FIG. 1. Additionally or alternatively, theinterface 270 may include, for example, a mobile high-definition link (MHL) interface, a SD card/ MMC interface, or an infrared data association (IrDA) standard interface.

Theaudio module 280 may bilaterally convert, for example, a sound and an electrical signal. At least some elements of theaudio module 280 may be included in, for example, the input/output interface 145 illustrated in FIG. 1. Theaudio module 280 may process sound information which is input or output through, for example, aspeaker 282, areceiver 284,earphones 286, themicrophone 288, and the like.

Thecamera module 291 is a device which may photograph a still image and a dynamic image. According to an embodiment of the present disclosure, thecamera module 291 may include one or more image sensors (e.g., a front sensor or a back sensor), a lens, an ISP or a flash (e.g., an LED or a xenon lamp).

Thepower management module 295 may manage, for example, power of theelectronic device 201. According to an embodiment of the present disclosure, thepower management module 295 may include a power management integrated circuit (PMIC), a charger integrated circuit (IC), or a battery or fuel gauge. The PMIC may use a wired and/or wireless charging method. Examples of the wireless charging method may include, for example, a magnetic resonance method, a magnetic induction method, an electromagnetic method, and the like, and may further include additional circuits (e.g., a coil loop, a resonance circuit, a rectifier, and the like) for wireless charging. The battery gauge may measure, for example, a residual quantity of thebattery 296, and a voltage, a current, or a temperature during the charging. Thebattery 296 may include, for example, a rechargeable battery or a solar battery.

Theindicator 297 may indicate a particular state (e.g., a booting state, a message state, a charging state, and the like) of theelectronic device 201 or a part (e.g., the processor 210) of theelectronic device 2201. Themotor 298 may convert an electrical signal into mechanical vibration, and may generate vibration, a haptic effect, and the like. Although not illustrated, theelectronic device 201 may include a processing unit (e.g., a GPU) for supporting a mobile TV. The processing unit for supporting mobile TV may, for example, process media data according to a certain standard, such as digital multimedia broadcasting (DMB), digital video broadcasting (DVB), or mediaFLO™.

Each of the components of the electronic device according to the present disclosure may be implemented by one or more components, and the name of the corresponding component may vary depending on the type of the electronic device. The electronic device according to various embodiments of the present disclosure may include at least one of the aforementioned elements. Some elements may be omitted or other additional elements may be further included in the electronic device. In addition, some of the hardware components according to various embodiments may be combined into one entity, which may perform functions identical to those of the relevant components before the combination.

FIG. 3 is a block diagram illustrating a program module according to various embodiments of the present disclosure.

Referring to FIG. 3, according to an embodiment of the present disclosure, a program module 310 (e.g., the program 140) may include an OS for controlling resources related to the electronic device (e.g., the electronic device 101) and/or various applications (e.g., the application programs 147) executed in the OS. The OS may be, for example, Android, iOS, Windows, Symbian, Tizen, Bada, and the like.

Theprogram module 310 may include akernel 320,middleware 330, anAPI 360, and/or anapplication 370. At least some of theprogram module 310 may be preloaded on the electronic device, or may be downloaded from an external electronic device (e.g., the first externalelectronic device 102 or the second externalelectronic device 104, or the server 106).

The kernel 320 (e.g., the kernel 141) may include, for example, asystem resource manager 321 and/or adevice driver 323. Thesystem resource manager 321 may perform the control, allocation, retrieval, and the like, of system resources. According to an embodiment of the present disclosure, thesystem resource manager 321 may include a process manager, a memory manager, a file system manager, and the like. Thedevice driver 323 may include, for example, a display driver, a camera driver, a Bluetooth driver, a shared memory driver, a USB driver, a keypad driver, a Wi-Fi driver, an audio driver, or an inter-process communication (IPC) driver.

Themiddleware 330 may provide a function required by theapplications 370 in common or provide various functions to theapplications 370 through theAPI 360 so that theapplications 370 can efficiently use limited system resources within the electronic device. According to an embodiment of the present disclosure, the middleware 330 (e.g., the middleware 143) may include, for example, at least one of aruntime library 335, anapplication manager 341, awindow manager 342, amultimedia manager 343, aresource manager 344, apower manager 345, adatabase manager 346, apackage manager 347, aconnectivity manager 348, anotification manager 349, alocation manager 350, agraphic manager 351, and asecurity manager 352, apayment manager 354.

Theruntime library 335 may include a library module which a compiler uses in order to add a new function through a programming language while theapplications 370 are being executed. Theruntime library 335 may perform input/output management, memory management, the functionality for an arithmetic function, and the like.

Theapplication manager 341 may manage, for example, a life cycle of at least one of theapplications 370. Thewindow manager 342 may manage graphical user interface (GUI) resources used for the screen. Themultimedia manager 343 may determine a format required to reproduce various media files, and may encode or decode a media file by using a coder/decoder (codec) appropriate for the corresponding format. Theresource manager 344 may manage resources, such as a source code, a memory, a storage space, and the like, of at least one of theapplications 370.

Thepower manager 345 may operate together with a basic input/output system (BIOS) to manage a battery or power, and may provide power information required for the operation of the electronic device. Thedatabase manager 346 may generate, search for, and/or change a database to be used by at least one of theapplications 370. Thepackage manager 347 may manage the installation or update of an application distributed in the form of a package file.

Theconnectivity manager 348 may manage a wireless connection, such as, for example, Wi-Fi or Bluetooth. Thenotification manager 349 may display or notify of an event, such as an arrival message, an appointment, a proximity notification, and the like, in such a manner as not to disturb the user. Thelocation manager 350 may manage location information of the electronic device. Thegraphic manager 351 may manage a graphic effect, which is to be provided to the user, or a user interface (UI) related to the graphic effect. Thesecurity manager 352 may provide various security functions required for system security, user authentication, and the like. According to an embodiment of the present disclosure, when the electronic device (e.g., the electronic device 101) has a telephone call function, themiddleware 330 may further include a telephony manager for managing a voice call function or a video call function of the electronic device. Thepayment manager 354 may relay information for payment from theapplication 370 to theapplication 370 orkernel 320. Further, the payment manager may store information related to the payment, which has been received from an external device, in the electronic device 200 or transfer the internally stored information to an external device.

Themiddleware 330 may include a middleware module that forms a combination of various functions of the above-described elements. Themiddleware 330 may provide a module specialized for each type of OS in order to provide a differentiated function. In addition, themiddleware 330 may dynamically delete some of the existing elements, or may add new elements.

The API 360 (e.g., the API 145) is, for example, a set of API programming functions, and may be provided with a different configuration according to an OS. For example, in the case of Android or iOS, one API set may be provided for each platform. In the case of Tizen, two or more API sets may be provided for each platform.

The applications 370 (e.g., the application programs 147) may include, for example, one or more applications which can provide functions, such as ahome application 371, adialer application 372, a short message service (SMS)/ multimedia messaging service (MMS)application 373, an instant message (IM)application 374, abrowser application 375, acamera application 376, analarm application 377,contacts application 378, avoice dialer application 379, anemail application 380, acalendar application 381, amedia player application 382, analbum application 383, aclock application 384, apayment application 385, a health care application (e.g., measure exercise quantity or blood sugar), or environment information (e.g., atmospheric pressure, humidity, or temperature information).

According to an embodiment of the present disclosure, theapplications 370 may include an application (hereinafter, referred to as an “information exchange application” for convenience of description) supporting information exchange between the electronic device (e.g., the electronic device 101) and an external electronic device (e.g., the first externalelectronic device 102 or the second external electronic device 104). The information exchange application may include, for example, a notification relay application for transferring specific information to an external electronic device or a device management application for managing an external electronic device.

For example, the notification relay application may include a function of transferring, to the external electronic device (e.g., the first externalelectronic device 102 or the second external electronic device 104), notification information generated from other applications of the electronic device 101 (e.g., an SMS/MMS application, an e-mail application, a health management application, or an environmental information application). Further, the notification relay application may receive notification information from, for example, an external electronic device and provide the received notification information to a user.

For example, the device management application may manage (e.g., install, delete, or update) at least one function of an external electronic device (e.g., the second external electronic device 104) communicating with the electronic device (e.g., a function of turning on/off the external electronic device itself (or some components) or a function of adjusting luminance (or a resolution) of the display), applications operating in the external electronic device, or services provided by the external electronic device (e.g., a call service and a message service).

According to an embodiment of the present disclosure, theapplications 370 may include applications (e.g., a health care application of a mobile medical appliance, and the like) designated according to attributes of the first externalelectronic device 102 or the second externalelectronic device 104. According to an embodiment of the present disclosure, theapplication 370 may include an application received from the external electronic device (e.g., theserver 106, or the first externalelectronic device 102 or the second external electronic device 104). According to an embodiment of the present disclosure, theapplication 370 may include a preloaded application or a third party application which can be downloaded from the server. Names of the elements of theprogram module 310, according to the above-described embodiments of the present disclosure, may change depending on the type of OS.

According to various embodiments of the present disclosure, at least some of theprogram module 310 may be implemented in software, firmware, hardware, or a combination of two or more thereof. At least some of theprogram module 310 may be implemented (e.g., executed) by, for example, the processor (e.g., the processor 210). At least some of theprogram module 310 may include, for example, a module, a program, a routine, a set of instructions, and/or a process for performing one or more functions.

FIG. 4 is a block diagram illustrating a plurality of execution environments operated in an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 4, theelectronic device 101 may operate a plurality ofexecution environments 400 having security levels in order to reinforce the security. The plurality of execution environments may include, for example, a rich execution environment (REE) 410 and a trusted execution environment (TEE) 420.

TheREE 410 may be, for example, a first execution environment having a first security level. TheTEE 420 may be, for example, a second execution environment having a second security level different from (e.g., higher than) the first security level. According to an embodiment of the present disclosure, theelectronic device 101 may include another execution environment (e.g., a third execution environment) having a third security level, without being limited thereto.

TheREE 410 may include, for example, aclient application 411, a sharedmemory 412, a TEEfunctional API 413, aTEE client API 414, arich OS component 415, apublic device driver 416, or anREE communication agent 417. The client application 411 (e.g., theapplication 370 or application program 147) may include at least one application capable of performing functions, including a phone call, messaging, payment, alarm, browser, or camera. Theclient application 411 may include the sharedmemory 412 and may access a sharedmemory view 452 of theTEE 420 using the sharedmemory 412. The sharedmemory 412 may be a memory accessible by applications of theREE 410 and theTEE 420.

The TEEfunctional API 413 and/or theTEE client API 414 are APIs allowed to access theTEE 420 and can perform functions similar to those of theAPI 145 or theAPI 360. The TEEfunctional API 413 may be an application interface designed to access some services of theTEE 420. TheTEE client API 414 may be an interface designed to allow exchange of data between applications of theREE 410 and theTEE 420. Therich OS component 415 may include, for example, apublic device driver 416 or anREE communication agent 417. Thepublic device driver 416 may be a system driver for driving a publicperipheral device 471 in theREE 410. TheREE communication agent 417 may perform a role of processing a message communication between theclient application 411 and atrusted application 451. Theclient application 411 may transfer amessage 472 from theREE communication agent 417 to aTEE communication agent 455 of theTEE 420, using the TEEfunctional API 413 and/or theTEE client API 414. Themessage 472 may be, for example, implemented to be transferred to only theTEE 420 in view of hardware. TheREE communication agent 417 may, for example, receive a result of processing associated with themessage 472 from theTEE communication agent 455 and transfer the result to theclient application 411.

TheTEE 420 may store data requiring a relatively high security level and perform related operations in a safe environment. TheTEE 420 may operate on an AP of theelectronic device 101 and operate based on a reliable hardware structure determined in the process of manufacturing theelectronic device 101. TheTEE 420 may divide the AP or memory into a general area and a security area and operate in the security area. TheTEE 420 may configure software or hardware requiring security, to operate in only the security area. Theelectronic device 101 may operate theTEE 420 through a physical change of hardware or a logical change of software. TheTEE 420 may be separated from theREE 410 through hardware restrictions, or may be separated in view of software while operating in the same hardware.

TheTEE 420 may include a trustedapplication 451, a sharedmemory view 452, a TEEinternal API 453, a secure OS component 454, aTEE communication agent 455, a trustedcore framework 456, atrusted function 457, or a trusted kernel 458. The trustedapplication 451 may include at least one application capable of performing functions of digital right management (DRM), security, payment, or biometric information. The sharedmemory view 452 may be a memory space capable of accessing the sharedmemory 412 of theREE 410.

The trustedapplication 451 may receive, for example, amessage 472 from theREE communication agent 417 through theTEE communication agent 455, using the TEEinternal API 453. TheTEE client API 453 may be an interface provided to enable basic software of theTEE 420 to operate. TheTEE communication agent 455 may receive themessage 472 and transfer the message to the trustedapplication 451. The trustedapplication 451 may perform an operation associated with themessage 472 and transfer a result of processing of the operation to theREE communication agent 417 through theTEE communication agent 455. The secure OS component 454 may include aTEE communication agent 455, a trustedcore framework 456, atrusted function 457, and/or a trusted kernel 458.

TheTEE communication agent 455 is one kind of framework API and may perform a role of processing a safe message communication between theclient application 411 and the trustedapplication 451. The trustedcore framework 456 may provide OS functions, such as scheduling, communication, and memory management, to be performed by the trustedapplication 451. The trustedfunction 457 may provide a function of trust including a password. The trusted kernel 458 may be a kernel for driving theTEE 420. Theplatform hardware 470 is a hardware element which transfers, for example, themessage 472 from theREE communication agent 417 to theTEE communication agent 455. Theplatform hardware 470 may include a publicperipheral device 471 and/or a trusted peripheral device 473. The publicperipheral device 471 may communicate with thepublic device driver 416 of theREE 410. The trusted peripheral device 473 may communicate with the trusted kernel 458 of theTEE 420. The publicperipheral device 471, which is a general peripheral device provided in an electronic device, may be, for example, a Gyro sensor or a GPS device. The trusted peripheral device 473 is a security (or password)-related peripheral device connected with theTEE 420 and may be, for example, a fingerprint sensor, an iris sensor, or a security display.

“More privileged” and “less privileged” relate to an authority capable of accessing the system, and “more privileged” may refer to a high system access authority and “less privileged” may refer to a low system access authority. For example, a low system authority may have a limited authority for access to the system (e.g., file writing, reading, and the like). The system access authority may have a concept equal or similar to the access authority in a general OS.

FIGS. 5A to 5C illustrate block diagrams of hardware structures of a TEE according to various embodiments of the present disclosure.

FIG. 5A illustrates an example (e.g., a trustzone (TZ) of ARM) of using one processor (e.g., the processor 120) and one memory (e.g., the memory 130) in a manner of dividing them into theREE 410 and theTEE 420 in view of hardware.

Referring to FIG. 5A, the hardware structure of theTEE 420 may include an on-system on chip (On-SoC) 510 and anexternal memory 520. The On-SoC 510 may include, for example, amicro-processing core 501, aRAM 502, aROM 503, aperipheral device 504, a crypto-accelerator 505, or anOTP field 506. In order to operate two or more execution environments, the trust zone may temporally divide the processors to separately use theREE 410 and theTEE 420. Further, the trust zone may divide one memory into an area accessible in theREE 410 and an area accessible in theTEE 420 and separately use the areas. Therefore, themicro-processing core 501, theRAM 502, theROM 503, theperipheral device 504, the crypto-accelerator 505, and theOTP field 506 may be divided, in use, into an REE area and a TEE area.

FIG. 5B illustrates a case where a processor (e.g., the processor 120) for theTEE 420 is implemented together with a processor for operating theREE 410 in the form of on-chip but is implemented in a separate processing core set. The processor for theTEE 420 according to various embodiments may have a configuration equal or similar to that of the above processor (e.g., the processor 120) due to an on-chip security sub-system 507 added thereto. Therefore, the following description omits description on the same elements as those of the above processor (e.g., the processor 120).

Referring to FIG. 5B, the On-SoC 510 may include an on-chip security sub-system 507 including at least one processor, in addition to amicro-processing core 501, aRAM 502, aROM 503, aperipheral device 504, a crypto-accelerator 505, and anOTP field 506. In this case, the On-SoC 510 may be configured to operate theREE 410 while the on-chip security sub-system 507 is configured to operate theTEE 420. As in FIG. 5A, one memory may be divided in use into an area accessible in theREE 410 and an area accessible in theTEE 420 in the structure of FIG. 5B.

FIG. 5C illustrates an example in which a processor for theTEE 420 is implemented as a separate chip in view of hardware and is thus separated from a chip in which a processor for operating theREE 410 is implemented. The processor for theTEE 410 according to various embodiments may have a configuration equal or similar to that of the above processor (e.g., the processor 120) due to anexternal security co-processor 530 added thereto. Therefore, the following description omits description on the same elements as those of the above processor (e.g., the processor 120).

Referring to FIG. 5C, the On-SoC 510 may be configured to operate theREE 410 and one or moreexternal security co-processors 530 disposed outside of the On-SoC 510 may be configured to operate theTEE 420.

FIG. 6 is a block diagram illustrating a payment system according to various embodiments of the present disclosure.

Referring to FIG. 6, apayment system 600 may include an electronic device 610 (e.g., the electronic device 101) and/or server. For example, the server may include apayment server 620, a token server (e.g., a token service provider (TSP)) 630, or a financial server (issuer) 640. Theelectronic device 610 may include, for example, a payment application (e.g., a wallet application) 612 and/or apayment manager 614. Thepayment server 620 may include, for example, apayment service server 622 and/or atoken requester server 624.

According to various embodiments of the present disclosure, thepayment application 612 may include a payment application 612 (e.g., a Samsung Pay™ application). Thepayment application 612 may provide, for example, a UI or user experience (UX) related to payment. The UI related to payment may include a wallet UI/UX. For example, thepayment application 612 may provide, for example, a UI related to card registration, payment, or transaction. Thepayment application 612 may provide, for example, an interface related to card registration through an external input (e.g., a user input) or a text reader (e.g., optical character reader/recognition (OCR)). Further, thepayment application 612 may provide, for example, an interface related to user Identification through identification and verification (ID&V).

According to various embodiments of the present disclosure, thepayment application 612 may perform payment transaction. For example, thepayment application 612 may provide a user with a payment function through execution of Simple Pay, Quick Pay, or a designated application. Using thepayment application 612, a user may perform a payment function and receive information associated with the payment function.

According to various embodiments of the present disclosure, thepayment manager 614 may include information associated with a card company. For example, thepayment manager 614 may include a card company software development kit (SDK).

According to various embodiments of the present disclosure, thepayment server 620 may include a management server for electronic payment or mobile payment. Thepayment server 620 may, for example, receive information related to payment from theelectronic device 610 and transmit the information to the outside or process the information in itself.

According to various embodiments of the present disclosure, thepayment server 620 may transmit or receive information between theelectronic device 610 and thetoken server 630, using thepayment service server 622 and/or thetoken requester server 624. Thepayment service server 622 may include, for example, a payment server (e.g., a Samsung payment server) 620. Thepayment service server 622 may manage, for example, card information linked to a service account (e.g., a Samsung account) or user account. Further, thepayment service server 622 may include an API server related to thepayment application 612. Further, thepayment service server 622 may provide, for example, an account management module (e.g., account integration or Samsung account integration).

According to various embodiments of the present disclosure, thetoken requester server 624 may provide an interface for processing information relating to payment. For example, thetoken requester server 624 may perform issuance, deletion, or activation of information (e.g., token) related to payment. In addition, the token requester server may be functionally connected to thepayment manager 614 to control the information required for the payment.

According to various embodiments of the present disclosure, thepayment application 612 included in theelectronic device 610 and thepayment service server 622 included in thepayment server 620 may be functionally connected with each other. For example, thepayment application 612 may transmit or receive information relating to payment to or from thepayment server 620.

According to various embodiments of the present disclosure, thepayment manager 614 included in theelectronic device 610 and thetoken requester server 624 included in thepayment server 620 may be functionally connected with each other. For example, thepayment manager 614 may transmit or receive information relating to payment to or from thetoken requester server 624.

According to various embodiments of the present disclosure, thetoken server 630 may issue or manage information (e.g., token) relating to payment. For example, thetoken server 630 may control the operation cycle (like cycle) of a token and the operation cycle may include a generation, revision, or deletion function. Further, thetoken server 630 may include, for example, a token management server and perform token provisioning, ID&V, replenishment, or life cycle management. Further, the token server may integrate information relating to the financial server.

According to various embodiments of the present disclosure, thepayment server 620 and/or thetoken server 630 may be located in an identical area, similar areas, or separated areas. For example, thepayment server 620 may be included in a first server while thetoken server 630 is included in a second server. Further, for example, thepayment server 620 and/or thetoken server 630 may be distinguishably implemented in one server (e.g., the first server or second server).

According to various embodiments of the present disclosure, thefinancial server 640 may perform issuance of a card. For example, thefinancial server 640 may include a card issuing bank. Further, thefinancial server 640 may generate information required for the payment provided to the user. The user may store, in theelectronic device 610, the information required for the payment generated in thefinancial server 640, using thepayment application 612. In addition, thefinancial server 640 may be functionally connected to thetoken server 630 to transmit or receive the information required for the payment.

FIG. 7 is a block diagram illustrating a payment system for performing payment according to various embodiments of the present disclosure.

Referring to FIG. 7, apayment system 700 may include an electronic device 710 (e.g., the electronic device 101), a payment server 720 (e.g., the server 106), a TSP 730 (e.g., theserver 106 or another server (not shown)), and a POS device 740 (e.g., the first external electronic device 102). According to an embodiment of the present disclosure, thepayment system 700 may include one or more additionalelectronic device 750 or 760. The one or more additionalelectronic device 750 or 760 may include a wearable device 750 (e.g., a smart watch) or an accessory device 760 (e.g., a fob type device of the LoopPay™ company), which can be functionally connected with theelectronic device 710. According to an embodiment of the present disclosure, the fob type device of the LoopPay™ company may include an external payment module connected to theelectronic device 710 through a microphone.

According to an embodiment of the present disclosure, theelectronic device 710 may perform a payment function. Theelectronic device 710 may register a card (e.g., a credit card, such as a master card, a visa card, and the like) in theelectronic device 710 or thepayment server 720 in order to perform the payment function. Thepayment server 720 may manage information on a plurality of registered cards including a card registered through another electronic device (e.g., the electronic device 750) of the user corresponding to theelectronic device 710 or another card registered through an electronic device of another user as well as a card registered through theelectronic device 710.

According to an embodiment of the present disclosure, thepayment server 720 may acquire token information corresponding to registered card information from theTSP 730 and transfer the acquired information to theelectronic device 710. Thepayment server 720 may include, for example, a payment service server or token requester server. The payment service server may manage card information of the user. The payment server may provide a service related to payment based on an account. The token requester server may request theTSP 730 to provide token information necessary for the payment operation and acquire the token information.

TheTSP 730 may issue a token used in a payment process. According to an embodiment of the present disclosure, the token may have a value replacing a primary account number (PAN), which is information of a card. According to an embodiment of the present disclosure, a token may be generated using a bank identification number (BIN). Further, the generated token may be encrypted by theTSP 730, or may be encrypted by thepayment server 720 after being transmitted to thepayment server 720 without being encrypted. The encrypted token information may be transferred to theelectronic device 710 through thepayment server 720 and decrypted by theelectronic device 710. According to an embodiment of the present disclosure, the token may be generated and encrypted in theTSP 730 and may be transferred to theelectronic device 710 without passing through thepayment server 720. According to another embodiment of the present disclosure, thepayment server 720 may include a token generation function. In this instance, the payment system may omit aseparate TSP 730.

Theelectronic device 710 may perform payment using, for example, at least one electronic device among one or more otherelectronic devices 750 or 760 functionally connected thereto based on a short range communication (e.g., Bluetooth or Wi-Fi). According to an embodiment of the present disclosure, the at least oneelectronic device 750 may be a wearable device (e.g., a smart watch) and, in this instance, theelectronic device 710 may transmit the token received from theTSP 730 to the wearable device. According to an embodiment of the present disclosure, the at least oneelectronic device 760 may be an accessory device (e.g., a fob type device of the LoopPay™ company) and, in this instance, theelectronic device 710 may be functionally connected with the accessory device (e.g., a fob type device of the LoopPay™ company) through its input/output interface 150 (e.g., the earphone 286).

FIG. 8 is a block diagram illustrating a hardware structure of an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 8, anelectronic device 800 may include, for example, acamera module 801, anacceleration sensor 803, agyro sensor 805, abiometric sensor 807, anMST module 810, anNFC module 820, anMST control module 830, anNFC control module 840, aprocessor 850, and amemory 860.

Thecamera module 801 may photograph a card required for payment to acquire card information. Thecamera module 801 may recognize, through an OCR function, card information (e.g., card company, card number, card expiration date, or card owner) recorded in the card. Otherwise, a user may input necessary card information to theelectronic device 800, using an input device (e.g., a touch panel, a pen sensor, a key, an ultrasonic input device, or a microphone input device) included in theelectronic device 800.

Theacceleration sensor 803 orgyro sensor 805 may acquire location state of theelectronic device 800 at the time of payment. The acquired location state of theelectronic device 800 may be transferred to theprocessor 850. Theprocessor 850 may adjust the intensity (current intensity) of a magnetic field transmitted to thePOS device 740 from one of theMST module 810 or theNFC module 820 based on the acquired location state of theelectronic device 800 or select a coil antenna to be used when there are a plurality of coil antennas.

Thebiometric sensor 807 may acquire biometric information. The acquired biometric information may be transferred to theprocessor 850. Theprocessor 850 may authenticate a user by comparing the acquired biometric information and pre-stored biometric information of the user.

At least one of theMST control module 830 and theNFC control module 840 may transmit payment information. TheMST control module 830 may transmit payment information to aPOS device 740 through theMST module 810. TheNST control module 840 may transmit payment information to thePOS device 740 through theNST module 820.

According to an embodiment of the present disclosure, theMST control module 830 may include adata reception module 831 and anoutput conversion module 833. Thedata reception module 831 may receive a pulse signal in the form of logical low/high, which includes payment information transmitted from theprocessor 850 or the security module 236 (e.g., an eSE). Theoutput conversion module 833 may include a circuit for converting data recognized by thedata reception module 831 into necessary types in order to transfer the data to theMST module 810. The circuit may include an H-Bridge for controlling the direction of the voltage supplied to opposite ends of theMST module 810. The H-Bridge may include a circuit structure connected in a shape like H using four switch structures.

According to an embodiment of the present disclosure, based on the card information input through thecamera module 801 or an input device (e.g., a touch panel or a pen sensor), theelectronic device 800 may receive the payment information (e.g., track 1/2/3 or token information) included in the magnetic stripe of a magnetic card from a card company/bank server through a communication module (not shown) and store the received information in a necessary form in a separate security module 236 (e.g., an eSE).

According to an embodiment of the present disclosure, theelectronic device 800 may transmit the payment information to thePOS device 740 using at least one of theMST module 810 and theNFC module 820. For example, theelectronic device 800 may transmit the payment information to thePOS device 740 using all of theMST module 810 and theNFC module 820 to elevate recognition rate. Another example, theelectronic device 800 may transmit the payment information using theMST module 810, and transmit the payment information using theNFC module 820 when the payment is failed. A method for recognizing a failure of the payment may include that theelectronic device 800 may receive a notification from thePOS device 740 or a 3rd party (e.g., a financial institution), or a defined time is exceeded.

FIG. 9 is a block diagram illustrating a program module to be executed in an execution environment of an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 9, aprogram module 900 may include, for example, anREE 910 and aTEE 920.

According to an embodiment of the present disclosure, theREE 910 may include, for example, a payment application 930 (e.g., the payment application 385), a payment manager 940 (e.g., thepayment manager 354 or 614), and a kernel 950 (e.g., the kernel 320).

According to an embodiment of the present disclosure, thepayment application 930 may include, for example, apayment management module 931, aserver inter-working module 933, anauthentication module 935, and a peripheraldevice management module 937.

According to an embodiment of the present disclosure, thepayment management module 931 may perform operations for card registration, card authentication, card de-registration, and payment. Thepayment management module 931 may register a user’s card. Theelectronic device 800 may receive a card registration request from a user. Theelectronic device 800 may acquire a card image, using thecamera module 801. Thepayment management module 931 may acquire a card image through an OCR module. Thepayment management module 931 may receive a user’s input of information (e.g., a secret code, a home address, an e-mail address, a phone number, an account ID, and the like) associated with the card information or acquire the information from thepayment server 720.

According to an embodiment of the present disclosure, thepayment management module 931 may display a registered card to the user through thedisplay 160. The user may revise at least a part of the information (e.g., a card name, a home address, a phone number, the number of times of payment trials, or information on whether payment notification information has been received or not) of the registered card. Thepayment management module 931 may display transaction details of each card. Thepayment management module 931 may display the registered card information in a wearable device (e.g., a smart watch) functionally connected to the electronic device.

According to an embodiment of the present disclosure, thepayment management module 931 may perform a payment operation using a registered card. The user may select one card among a plurality of registered card. The user may take theelectronic device 800 to thePOS device 740. Thepayment management module 931 may display product information (e.g., price) received from thePOS device 740 through thedisplay 160. Thepayment management module 931 may perform user authentication (e.g., fingerprint authentication) through theauthentication module 935 for payment. When the authentication has been completed, thepayment management module 931 may display notification information reporting completion of payment through thedisplay 160.

According to an embodiment of the present disclosure, theelectronic device 800 may transmit payment information to thePOS device 740, using at least one module among theMST module 810 and theNFC module 820. In order to raise the recognition rate, theelectronic device 800 may transmit the payment information to thePOS device 740, simultaneously using theMST module 810 and theNFC module 820. Otherwise, the electronic 800 may use theMST module 810 in transmission and may use theNFC module 820 in the transmission when the payment has failed. A method of recognizing a case wherein the payment has failed may include reception, by theelectronic device 800, of a notification from thePOS device 740 or a 3rd party (e.g., financial institution) or lapse of a certain time. Various embodiments are not limited to the sequence described above and allows an opposite sequence.

According to an embodiment of the present disclosure, anelectronic device 800 may receive a request for removal of at least one card among already registered cards from a user. Thepayment management module 931 may delete information corresponding to the at least one card from thememory 860. Thepayment management module 931 may request thepayment server 720 to delete the information corresponding to the at least one card.

According to an embodiment of the present disclosure, thepayment management module 931 may determine whether the owner of the card is identical to the user performing the card registration. Thepayment management module 931 may include, for example, an ID&V module. Thepayment management module 931 perform user authentication through text messages, e-mail, ARS, or phone call. Further, the authentication may be performed through an application issued by a card company or bank. The card registered through thepayment management module 931 may be used after being authenticated.

According to an embodiment of the present disclosure, thepayment management module 931 may include an OCR module. The OCR module may acquire, through a scanner, an image of a letter written by a human or printed by a machine and convert the image to a machine-readable letter. Theelectronic device 800 may acquire an image of a card possessed by a user, through acamera module 801. The OCR module may convert an image, a letter, or a number written in a card, obtained from a card image, to a machine-readable letter. The OCR module may acquire card information (e.g., card number, user name, or valid period) of the user from converted letters. Theelectronic device 800 may acquire the card information of the user through the OCR module and perform a card registration process.

According to an embodiment of the present disclosure, thepayment management module 931 may display a bar code generated for payment through thedisplay 160. For example, thepayment management module 931 may receive a command indicating generation of a bar code for payment through a bar code reader. Thepayment management module 931 may generate a bar code based on the command.

According to an embodiment of the present disclosure, theserver interworking module 933 may receive a payment-related message, a device-related message, or a service-related message from thepayment server 720 or theTSP 730. Theserver interworking 933 may transfer the message to thepayment management module 931.

According to an embodiment of the present disclosure, theserver interworking module 933 may include, for example, a push management module and an account management module. For example, a message received from thepayment server 720 may be processed by the push management module when the message is in the form of a push notification associated with a token, and may be processed by the account management module when the message relates to account-related information (e.g., Samsung account).

According to an embodiment of the present disclosure, the push management module may calculate or handle the push notification or push message information received from thepayment server 720. The push message may be transferred to theserver interworking module 933 within thepayment application 930 through apayment relay module 941 within thepayment manager 940 or 354 or directly transferred to thepayment application 930. At least some messages among transferred push messages may be transferred to thepayment management module 931 to update card-related information and be synchronized with thepayment server 720.

According to an embodiment of the present disclosure, thepayment server 720 may include an account server for managing account-related information or a token requester server for providing payment-related information. The account server and the token requester server may be implemented as a separate device (e.g., the server 106) and may be included in a single device.

According to an embodiment of the present disclosure, the message information received by the push management module may include token and payment related information, such authority configuration (e.g., token provisioning), suspension (e.g., token suspension), disposal (e.g., token disposal), state change (e.g., token status change), additional issuance (e.g., token replenishment), and payment identification (e.g., transaction notification), as shown in Table 1 below.

The messages transmitted/received by the account management module may include at least a part of electronic device-related information, a lost electronic device identification function (e.g., lost device, find my mobile), remote blocking (e.g., remote lock/unlock), membership management (e.g., loyalty/membership cards), a web-linked function (e.g., website portal-on-line).

According to an embodiment of the present disclosure, when token provisioning ID&V information acquired by thepayment management module 931 is successfully transferred through thepayment server 720 to an external server and the transferred token-related information is valid, theserver interworking module 933 may receive, for example, a “push token {id} status changed” message and transfer the received message to thepayment management module 931.

According to an embodiment of the present disclosure, in regard to card information temporal suspension information (e.g., token suspension) acquired by thepayment management module 931 of theelectronic device 800, a use stop command of thepayment server 720 may be transferred to thepayment application 930 to switch the card configuration state for mobile payment from the active state to the inactive state.

According to an embodiment of the present disclosure, when theelectronic device 800 is lost, thepayment server 720 may delete or temporarily stop all token information stored in thepayment server 720. In order to synchronize this with thepayment application 930, thepayment server 720 may transmit a push message. Thepayment server 720 may transfer the push message to thepayment application 930 through thepayment relay module 931 or the server interworking module (e.g., a Push management module or an account management module) 933.

Referring to Table 2, showing contents of push APIs supported by theelectronic device 800 and thepayment relay module 931, the APIs may be distinguishably and separately implemented according to thepayment relay module 931.

According to an embodiment of the present disclosure, the account management module may manage, in the payment application, information including a user-specific identifier (e.g., a Samsung account ID or a device ID), card, or membership which the module exchanges with thepayment server 720. The user identifier may include an account, which a user has joined in order to manage cards (e.g., a VISA™ card or a MASTER card™) of various business providers, a portal account associated with an electronic device, or a unique identifier (e.g., a model name, a MAC address, an international mobile equipment identity (IMEI), a serial number, a universally unique ID (UUID), an ID, and the like) of an electronic device. In addition, the unique identifier may have a value which has been generated by and transferred from thepayment server 720 through the account.

The account management module may manage registration, addition, deletion, repeated registration, use suspension, or use restart of a card, using the account of the user or the identifier of theelectronic device 800. Moreover, in the case of transmitting (importing/exporting) card information between theelectronic device 800 and a wearable device also, registration, addition, deletion, repeated registration, use suspension, or use restart of a card may be managed based on the generated account or an identifier of theelectronic device 800. Here, a management method based on an account may manage a plurality ofelectronic devices 800 or a plurality of users sharing one account to use a unique account (e.g., a Samsung account) for eachelectronic device 800 or synthetically manage a plurality ofelectronic devices 800 by one account.

According to an embodiment of the present disclosure, information of a first card (e.g., a VISA™ card) and a second card (e.g., MASTER™ card) generated through an OCR module of thepayment management module 931 may be used to register the cards based on an account (e.g., registration02@samsung.com) generated at the time of joining the Samsung account. The registered information may be synchronized with thepayment server 720 based on the generated account.

According to an embodiment of the present disclosure, membership information generated through a bar code interface may be used to register the first card (e.g., a Samsung point card) and the second card (e.g., CJ membership point card) based on an account (e.g., registration01@samsung.com) generated at the time of joining the Samsung account. The registered information may be synchronized with thepayment server 720 based on the generated account. Further, a user may determine the active/inactive states of a card based on an account after logging-in through the payment application and transfer the determination to thepayment server 720 using the account management module, and on the contrary, may change the management of the card state based on an account in a server management web page (e.g., server portal). Further, the account management module manage, while interworking with the server, the card information (e.g., a VISA™ card ID&V) and membership information (e.g., membership points, registraion001@Cj.com) associated with a service account (e.g., registration01@samsung.com). The membership information may be automatically linked, at the time of card payment, to payment processing information (e.g., payment amount) and membership accumulation information (e.g., points or mileage) to automatically accumulate or subtract the points or mileage.

When an application including an account management module is installed, the configuration state of a part or all of an existing registered card may be continuously linked and used by only one time of an account login (or sign-in) process of a user even in any device. Further, even membership information having a relatively low authentication security level may be registered and linked based on an account of the user to reduce additional authentication processes.

According to an embodiment of the present disclosure, theauthentication module 935 may display a UI for authentication of a user or a card for payment through thedisplay 160. Theauthentication module 935 may include, for example, a biometric information module.

According to an embodiment of the present disclosure, the biometric information module may acquire biometric information of a user. The biometric information of a user may include, for example, information of, a fingerprint, an iris, a face image, voice, cardiac impulse, or blood pressure. Theelectronic device 800 may acquire biometric information of a user through a sensor module. For example, the electronic device may acquire fingerprint information of a user through a fingerprint sensor. Meanwhile, theelectronic device 800 may acquire information of an iris of a user through thecamera module 801. The biometric information module may display a UI for acquiring biometric information of a user through thedisplay 160.

According to an embodiment of the present disclosure, when a user tries payment using card information registered in theelectronic device 800, the biometric information module may perform an authentication in order to acquire security data (e.g., token) from a security memory (e.g., eSE or memory accessible in a secure environment) functionally connected to theelectronic device 800. Theelectronic device 800 may acquire biometric information (e.g., fingerprint or iris) of the user through the biometric information module for user authentication. The acquired biometric information may be transferred to a biometricinformation management module 943 of thepayment manager 940. According to an embodiment of the present disclosure, the security memory may be a memory including data stored by encryption key.

According to an embodiment of the present disclosure, the biometric information module may proceed with payment, using card information and biometric information registered in theelectronic device 800, when the user proceeds with electronic payment on an Internet web page. In order to acquire security data (e.g., token) from a memory or security module (e.g., an eSE or a memory accessible in a secure environment) functionally connected to theelectronic device 800, the user may perform an authentication. When user authentication has successfully progressed in theelectronic device 800, the electronic device is linked to an external server to enable fast automatic authentication (e.g., fast identity online (FIDO)) without electronic payment on a separate Internet web page. For example, instead of an authentication process required at the time of on-line payment, a fast authentication may be performed by liking to the biometric information module.

According to an embodiment of the present disclosure, theelectronic device 800 may previously appoint a fingerprint of a user and a card to be used for payment. For example, when the user performs authentication using a fingerprint in the payment application, the user may appoint his or her right hand thumb to VISA™ card and his or her right hand index finger to MASTER™ card, so that payment through a corresponding card can be achieved as soon as the user performs authentication using a corresponding finger.

According to an embodiment of the present disclosure, the peripheraldevice management module 937 may manage an external device functionally connected to theelectronic device 800. The peripheraldevice management application 937 may include, for example, an MST peripheral device module and a wearable device module.

According to an embodiment of the present disclosure, the MST peripheral device module may output information on whether an MST accessory (e.g., fob type device of LoopPay™) and theelectronic device 800 are connected or not wirelessly or wiredly, and may provide a UI proper for the user on the basis thereof. The UI may progress and output card registration or deletion, or payment in a state where the MST accessory has been connected thereto. The MST peripheral device module may store various card information necessary for payment in theelectronic device 800 or a separate memory within the MST accessory, in a state where it is connected to the MST accessory. As a result, theelectronic device 800 or MST accessory can independently progress the payment in a state where the MST accessory is not connected.

The wearable device module may output information on whether a wearable device (e.g., watch, headset, glasses, or ring) and theelectronic device 800 are connected or not wirelessly or wiredly, and may provide a UI proper for the user on the basis thereof. The wired or wireless connection may include various interfaces, such as BT, BLE, Wi-Fi, Zigbee, or Z-wave, and may be implemented by applying a particular accessory protocol (Samsung accessory protocol (SAP)). The UI may progress and output card registration or deletion, or payment in a state where the wearable device has been connected thereto. In the process of card registration, deletion, or payment, the wearable device module may output information on whether to generate a secure session with the wearable device, and transmit or receive and display a user input value on theelectronic device 800 or wearable device. The input of the user may include various card information required for payment and other additional authentication information (e.g., PIN, user-specific pattern-related data, fingerprint recognition-related data, a touch input value of thedisplay 160 or wearable device bezel unit).

According to an embodiment of the present disclosure, theelectronic device 800 may share one piece of payment information with the wearable device or accessory. For example, information on one VISA™ card may be stored in both the wearable device and theelectronic device 800. According to an embodiment of the present disclosure, theelectronic device 800 may store different pieces of card information generated from one piece of card information in the wearable device and the accessory, respectively. For example, among different tokens issued from one piece of VISA™ card information, one token may be stored in the electronic device while the other token is stored in the accessory or wearable device. According to an embodiment of the present disclosure, when a different token issued from one piece of card information is stored in the electronic device while the other token is stored in the accessory or wearable device, if a payment module of one device is activated, a payment module of the other device may be deactivated. For example, among different tokens issued from one piece of VISA™ card information, if one token is stored in theelectronic device 800 while the other token is stored in the accessory or wearable device, payment of theelectronic device 800 may be deactivated when the payment is performed by the wearable device. In addition, when the payment is performed by theelectronic device 800, payment by the wearable device may be deactivated.

According to an embodiment of the present disclosure, thepayment manager 940 may include, for example, apayment relay module 941, a biometricinformation management module 943, and a securityenvironment relay module 946. According to an embodiment of the present disclosure, thepayment relay module 941 may relay a card or information (e.g., token) corresponding to the card to thepayment application 930, thekernel 950, or thepayment server 720. Thepayment relay module 941 may perform off-line payment through a communication module (e.g., NFC module or MST module). A payment method using theNFC module 820 can be operated through thePOS device 740, and a payment method using theMST module 810 can be operated by a user input. Further, thepayment relay module 941 may perform on-line payment through a communication module (e.g., cellular module, RF module, or Wi-Fi module).

According to an embodiment of the present disclosure, thepayment relay module 941 may perform state management (e.g., card/token life cycle management) of a card or information (e.g., token) corresponding to the card. Thepayment relay module 941 may provide at least one API associated with payment to thepayment application 930.

According to an embodiment of the present disclosure, thepayment relay module 941 may further include at least one interface provided by system services associated with payment, and system service interfaces, which provide security UIs for a payment service for access to apayment module 921, trustzone-based integrity measurement architecture (TIMA) for kernel integrity authentication, fingerprint recognition result inquiry (e.g., supporting both the security and non-security mode), and PIN or PAN input. Thepayment relay module 941 may include an encryption library in order to transfer a message or command to theTEE 920. Thepayment relay module 941 may transmit or receive a message or command with theTEE 920 through the encryption library.

According to an embodiment of the present disclosure, thepayment relay module 941 may include a card management function which provides addition, deletion, or update of a card, as a general card management function. Thepayment relay module 941 may include a first payment SDK or a second payment SDK. The first payment SDK (e.g., a Samsung SDK) may be embedded in theelectronic device 800. The second payment SDK may be provided by a card company or bank and may be installed in theelectronic device 800. From the first payment SDK or second payment SDK, thepayment relay module 941 may select a payment SDK corresponding to card information. Further, thepayment relay module 941 may set a basic card or select another card other than the basic card.

According to an embodiment of the present disclosure, thepayment relay module 941 may transmit messages, such as token provisioning, token replenishment, token suspension, token resume, and token disposal, as a general token and key management function, to thepayment server 720.

According to an embodiment of the present disclosure, thepayment module 921 may acquire a token and a token cryptogram from theelectronic device 800 or another external electronic device. A key (e.g., limited used key (LUK) or single used key) capable of generating the token or token cryptogram may be stored in theREE 910 orTEE 920. Moreover, when the token and the key are stored in theREE 910, thepayment module 921 of theTEE 920 may encrypt and store the token and key, using the key (e.g., device root key (DRK)) of theTEE 920. When theelectronic device 800 performs payment, thepayment relay module 941 may acquire the encrypted token in a decrypted state through the payment module. When the token or key capable of generating the token cryptogram is stored in theTEE 920, theelectronic device 800 may store the token or key in an encrypted form, using the key of theTEE 920.

According to an embodiment of the present disclosure, thepayment relay module 941 may receive a push message from theTSP 730 and transfer the push message to the payment application.

According to an embodiment of the present disclosure, when the first payment SDK (provided by a card company or bank) provides a self-token management function, thepayment relay module 941 may further include a function of relaying a token management function request to the second payment SDK when receiving the request. For example, thepayment relay module 941 having acquired a token or key, using an SDK of VISA™ card, may transfer the token or key to thepayment module 921 within theTEE 920, using a Samsung™ SDK. According to an embodiment of the present disclosure, thepayment relay module 941 may further include, on a payment framework, a host card emulation (HCE) function which enables a virtual card to be used in theelectronic device 800 by only software without a separate hardware device (e.g., a security module or a secure element (SE)) at the time of payment. The HCE function may transfer a token and a token cryptogram through a communication module (e.g., an NFC), using a message standard (e.g., application protocol data unit (APDU)) associated with thePOS 740.

According to an embodiment of the present disclosure, thepayment relay module 941 may include a function of processing a message received from thePOS device 740. The POS-related message processing function may include a function of managing payment data to be transmitted to thePOS device 740 as a response. The POS-related message analysis function may include a function of, when the first payment SDK provides a self POS-related message processing function, relaying the POS-related message to the first payment SDK. According to an embodiment of the present disclosure, thepayment relay module 941 may include at least one database for storing the card data, token data, or transaction data.

According to an embodiment of the present disclosure, thepayment relay module 941 may select at least one method among a method using NFC and a method using MST. For example, the methods may include a method of first performing payment using NFC and performing payment using MST, a method of first performing payment using MST and performing payment using NFC, and a method of performing payment simultaneously using NFC and MST. According to an embodiment of the present disclosure, in the case of first performing payment through one communication module and performing payment through another communication module, thepayment relay module 941 may perform payment through the another communication module when there is no response to a result of payment performance from the communication module having first performed the payment or after passage of a certain time.

According to an embodiment of the present disclosure, in the case of having both token information and PAN information for one card, thepayment relay module 941 may use at least one of them for payment. Thepayment relay module 941 may determine whether thePOS device 740 can perform payment using PAN or using a token. For example, theelectronic device 800 may receive payable information through a back light unit (BLE), and thepayment relay module 941 may identify the information. Based on the identified information, thepayment relay module 941 may perform the payment using a toke when the token is available for the payment and using PAN when the PAN is available for the payment.

According to an embodiment of the present disclosure, thepayment relay module 941 may further include an SDK provided by a payment network. The SDK may further include token management, POS-related message processing, or token/card databases.

According to an embodiment of the present disclosure, the securityenvironment relay module 946 may further include a function enabling a payment application to access a biometricinformation driver module 951 or a securityenvironment driver module 953 in order to use functions provided by thepayment module 921 or abiometric information module 925. Thepayment relay module 941 may include an encryption library in order to transfer a message or command to the securityenvironment relay module 946. Thepayment relay module 941 may transmit or receive a message or command with the securityenvironment relay module 946 through the encryption library.

Various embodiments of the present disclosure may further include a securityenvironment relay module 946 connected to enable thepayment application 930 to use functions of a securityidentifier processing module 923 of theTEE 920, in thepayment manager 940. According to an embodiment of the present disclosure, thepayment relay module 941 may include a function of relaying an authentication request through a PIN input by thepayment application 930 to the securityidentifier processing module 923 of theTEE 920. When there is a request for fingerprint recognition, a general application may acquire information on whether the recognition is success or failure. The security payment application (payment trusted app) may acquire a security biometric result (secure fingerprint result). The security biometric result may have a form encrypted by combining a disposable random number and information of success/failure. The disposable random number may be encrypted through a hardware key (e.g., DRK) of theTEE 920.

According to an embodiment of the present disclosure, thepayment relay module 941 may transfer a message requiring execution of payment to thepayment module 921 through the securityenvironment driver module 953 in order to perform payment. Thepayment module 921 may notify thepayment relay module 941, through the securityenvironment driver module 953, that an authentication operation is necessary. Thepayment relay module 941 may issue a command requiring thebiometric sensor 807 to acquire biometric information through the biometricinformation management module 943 and the biometricinformation driver module 951. In addition, thepayment relay module 941 may transfer an authentication identification message to thebiometric information module 925 of theTEE 920 through the biometricinformation management module 943 and the securityenvironment driver module 953. Thebiometric sensor 807 may be included in thebiometric information module 925 of theTEE 920. Thebiometric information module 925 may identify a user’s identity by comparing pre-stored biometric information of the user and information acquired by the biometric sensor. Based on the identified information, thebiometric information module 925 may transfer success or failure of authentication to the biometricinformation management module 943 through the securityenvironment driver module 953, and the biometricinformation management module 943 may transfer the received information to thepayment relay module 941. Thepayment relay module 941 and the biometricinformation management module 943 may be configured to be integrated in a single construction or configured as separate modules.

According to an embodiment of the present disclosure, thepayment relay module 941 may perform an authentication through an external device. For example, theelectronic device 800 may request the payment server (e.g., a Samsung account server or token requester server) 720 to authenticate biometric information (e.g., fingerprint or iris). Thepayment server 720 may perform authentication of biometric information of a user and transfer a result of the authentication to theelectronic device 800. When the authentication has been completed, thepayment relay module 941 may perform a token provisioning process by transferring data including information that the authentication has been completed to the TSP. Further, according to a result of the authentication, theelectronic device 800 may perform payment when the authentication is successfully completed, or may not perform payment when the authentication fails or is not completed.

According to an embodiment of the present disclosure, thekernel 950 may include, for example, the biometricinformation driver module 951 and the securityenvironment driver module 953. The biometricinformation driver module 951 may transfer a message transferred from the biometricinformation management module 943 of thepayment manager 940 to thebiometric sensor 807. The biometric information obtained by thebiometric sensor 807 may be transferred to thebiometric information module 925 within theTEE 920 instead of being transferred to a module within theREE 910 through the biometricinformation driver module 951.

According to an embodiment of the present disclosure, the securityenvironment driver module 953 may perform as an interface for transfer from a module in theREE 910 to a module in theTEE 920. For example, in the case of the trust zone of ARM corresponding to an embodiment of theTEE 920, the AP time-divisionally performs operations of theREE 910 and theTEE 920. Here, a separate data path for transferring a message from theREE 910 to theTEE 920 may implemented by hardware. In this event, a driver module for accessing the hardware may be the securityenvironment driver module 953. The securityenvironment driver module 953 may transfer a message relating to an operation of a module in theTEE 920 to a module in theREE 910.

According to an embodiment of the present disclosure, theTEE 920 may include, for example, thepayment module 921, the securityidentifier processing module 923, thebiometric information module 925, and apayment driver module 927. Theelectronic device 800 may store data requiring a relatively high security and perform related operations in a safe environment through theTEE 920. TheTEE 920 may operate on an AP of theelectronic device 800, and areliable TEE 920 determined in the operation of manufacturing anelectronic device 800 may refer to a security area within theelectronic device 800. Theelectronic device 800 may store data requiring a relatively high security and perform related operations based on a safe hardware structure through theTEE 920. TheTEE 920 may enable the AP and the memory area to operate in a state of being divided into a general area and a security area. Further, theTEE 920 may configure software or hardware requiring security, to operate in only the security area. When theREE 910 of an electronic device is required to perform an operation related to sensitive information, the electronic device may be allowed to access theTEE 920 only through an API and a driver capable of accessing theTEE 920. TheTEE 920 may hand over limited data on related information to theREE 910. TheTEE 920 may encrypt internally stored data through a hardware key (e.g., DRK). Without a separate decryption process, theREE 910 may unable to interpret data within theTEE 920.

An application (e.g., a security application or payment module) within theTEE 920 may transfer a message to another electronic device (e.g., the TSP 730) outside of theelectronic device 800.

According to an embodiment of the present disclosure, theTEE 920 may include a trusted OS and a security application. In addition, theTEE 920 may include an encryption module related to the security, a driver capable of collecting data in hardware requiring security, and the like. The security application may include thepayment module 921. In addition, theTEE 920 may transfer payment information to the outside through a communication module. For example, the TEE may transmit payment information to thePOS device 740 by transferring the payment information to theMST module 810 through theMST control module 830 or transferring the payment information to theNFC module 820 through theNFC control module 840.

According to an embodiment of the present disclosure, the trusted application may determine whether theREE 910 has an integrity. Theelectronic device 800 may store, in theTEE 920, information on whether theREE 910 has an integrity. Booting of theREE 910 supporting theTEE 920 may follow a sequence in which a boot loader is first executed, theTEE 920 is booted, and theREE 910 is booted. When theTEE 920 has been booted, integrity information of theREE 910 is identified in theTEE 920, and the identified information may be notified to a user after the booting. According to an embodiment of the present disclosure, when the image of theREE 910 has been damaged due to hacking or rooting, it may be determined that the integrity of theREE 910 is problematic. When the integrity is problematic, the REE may be prohibited to access theTEE 920. For example, when thepayment relay module 941 tries to transfer a message or command to theTEE 920 through the securityenvironment driver module 953, thekernel 950 of theTEE 920 may disregard the message or command or deny to receive the message.

According to an embodiment of the present disclosure, thepayment module 921 may be an application installed by a bank or card company (e.g., a VISA™ card or a MASTER™ card). There may be at least onepayment module 921. When a user accesses, in theelectronic device 800, the payment server (e.g., mobile application platform, payment gateway, token requester, TSP, trusted service manager, or bank server) 720 or thetoken provider 730, using thepayment management module 931, and approves to install thepayment module 921, theTSP 730 may perform operations associated with the installation. For example, thepayment management module 931 may acquire a card number and valid term information of a plastic card through OCR, and perform a card registration operation for installing thepayment module 921 in thepayment server 720. The payment management module may connect to theTSP 730 in the network through thepayment relay module 941 having connection information of theTSP 730 according to each card/bank company to receive an installation file, and thepayment relay module 941 may transfer the information to theTEE 920 to install thepayment module 921. The process described above may be called a provisioning process or card registration process. There may be a plurality ofpayment modules 921 of theTEE 920. Eachpayment module 921 is unable to exchange data within theTEE 920 and may be configured in an isolated form.

According to an embodiment of the present disclosure, thepayment module 921 may be an application to be used for data communication with thepayment server 720. Thepayment module 921 may include information of a credit card, a debit card, a membership card, and the like. Thepayment module 921 may communicate with another external electronic device through encryption. The encryption process may be different according to the card manufacturing company having transferred thepayment module 921. Thepayment server 720 may control the state of thepayment module 921. For example, thepayment server 720 may activate, temporarily suspend, resume, or delete (dispose) thepayment module 921.

According to an embodiment of the present disclosure, thepayment module 921 may store information related to the card information. For example, the stored information may include at least one among a token, a token reference ID, a part of a PAN, a PAN product ID, a token requester ID, a token assurance level, token assurance data, a valid term of a token, an encryption key, and a value (e.g., one time password (OTP)) provided by theTSP 730, which correspond to the card information (e.g., PAN). The token may be controlled by the state of theTSP 730. For example, the token may be activated, temporarily suspended, resumed, or deleted (disposed). The token may be static information basically corresponding to the card information (e.g., PAN).

According to an embodiment of the present disclosure, thepayment module 921 may determine a card to be used for payment. For example, apayment module 921 corresponding to a card selected by the user in at least onepayment management module 931 may be determined according to a user’s selection. Thepayment management module 931 may transfer the determined card to thepayment relay module 941. Thepayment relay module 941 may transfer the determined card information to thepayment module 921 through the securityenvironment driver module 953. Thepayment module 921 may manage a list of cards actually used in the payment among possessed cards. Thepayment module 921 may change the list of cards actually used in the payment, based on the determined card information. The changing may include a method of raising the priority of the determined card information in the card list or a method of deleting the other card information except for the determined card information.

According to an embodiment of the present disclosure, thepayment module 921 may generate information used for the payment based on the information associated with the card information when the payment is executed. Referring to Table 3, the information used for the payment may include a token, a token reference ID, a part of a PAN, a PAN product ID, a token requester ID, a token assurance level, token assurance data, a valid term of a token, a token cryptogram, a POS entry mode, a token requester indicator, and the like.

According to an embodiment of the present disclosure, thepayment module 921 may receive a key (e.g., LUK or single used key), by which a token cryptogram can be generated, through theTSP 730 or the payment server 720 (e.g., a payment service server or a token requester server). The key may be transferred and received through a data network or an SMS. The key may be exchanged using a security channel between theelectronic device 800 and theTSP 730. The security channel may be a logical channel for encrypting data, which is exchanged by a separate key (e.g., a method using a public key or private key) different from the key described above. Moreover, thepayment module 921 may include a module for generating a key capable of generating a token cryptogram. Theelectronic device 800 may receive the module for generating the key, through theTSP 730 or thepayment server 720. Otherwise, the key may be included in theelectronic device 800 in the stage of manufacturing theelectronic device 800.

According to an embodiment of the present disclosure, thepayment module 921 may generate a token cryptogram, using a key (e.g., a limited used key or a single used key) capable of generating the token cryptogram. Thepayment module 921 may use different keys according to a certain rule, for example, in each transaction, in a certain number of times of transaction, or a transaction within a particular time. TheTSP 730 may possess a key paired with the above-described key. TheTSP 730 may decrypt the encrypted token cryptogram through the paired key.

According to an embodiment of the present disclosure, thepayment module 921 may generate a token cryptogram, using a key capable of generating the token cryptogram.

According to an embodiment of the present disclosure, when the payment is performed, theelectronic device 800 may transfer a message reporting that the payment application will perform the payment, to thepayment relay module 941. Thepayment relay module 941 may determine whether to use MST or NFC for the payment. In the case of using MST for the payment, the payment relay module may acquire information (e.g., token, token cryptogram, a part of PAN information, token valid period, and the like) necessary for payment from thepayment module 921 of theTEE 920 and transfer the information to thepayment driver module 927 in theTEE 920. Thepayment driver module 927 may transfer the information to the payment controller. TheMST module 810 may transmit the information in order to perform payment.

According to an embodiment of the present disclosure, when using the NFC for the payment, theelectronic device 800 may transfer the information necessary for the payment to thepayment driver module 927 of theTEE 920. Thepayment driver module 927 may transfer information required for performing the payment to theNFC module 820. TheNFC module 820 may perform the payment based on the information.

According to an embodiment of the present disclosure, in the case of using the NFC for the payment, theelectronic device 800 may perform the payment when receiving a certain message from thePOS device 740. For example, when theNFC module 820 detects a certain message transferred from thePOS device 740, theNFC module 820 may transfer the message to thepayment driver module 927. Thepayment driver module 927 may transfer information that the message has been received from thePOS device 740, to thepayment relay module 941 of theREE 910. Thepayment relay module 941 may generate a token cryptogram in order to perform payment. The token cryptogram may be generated in thepayment module 921 of theTEE 920, using a key (e.g., a limited used key or a single used key) capable of generating the token cryptogram. The generated token cryptogram may be transferred to theREE 910. Thepayment relay module 941 may transfer payment-related information including the token and token cryptogram through a network module (e.g., an NFC-related host card emulation module). The network module may transfer the payment-related information to thePOS device 740 through theNFC module 820.

According to an embodiment of the present disclosure, thepayment module 921 may transfer information including the token, token valid period, token requester ID, and token cryptogram to an external electronic device. For example, thepayment module 921 may transfer the payment information to thePOS device 740 through the MST communication module. Further, thepayment module 921 may transfer the payment information to thePOS device 740 through theNFC communication module 820.

According to an embodiment of the present disclosure, thepayment module 921 may transmit or receive certain information to or from thePOS device 740 in the payment operation. In the case of NFC, thePOS device 740 may first receive the information to perform the payment. In the case of MST, payment-related information including the token and token cryptogram may be transmitted, based on an explicit input from a user or an internal algorithm of theelectronic device 800, to thePOS device 740.

According to an embodiment of the present disclosure, thebiometric information module 925 may store biometric information of a user of theelectronic device 800 and compare the biometric information with information obtained by the biometric sensor to authenticate the user. Thebiometric information module 925 may include a fingerprint information module or an iris information module. The biometric information module may collect information from thebiometric sensor 807. When thepayment application 930 shows, through thedisplay 160, contents requiring authentication of the biometric information of the user, the user may transfer the biometric information through thebiometric sensor 807. Theauthentication module 935 of thepayment application 930 may transfer, through the biometricinformation management module 943, a message requiring collection of biometric information to the biometricinformation driver module 951. The biometricinformation driver module 951 may transfer the message to thebiometric sensor 807. Thebiometric sensor 807 may collect biometric information and transfer the collected information to theTEE 920. Thebiometric information module 925 of theTEE 920 may compare the collected biometric information with the stored biometric information of the user to determine whether to authenticate the biometric information, and may transfer a result of the determination to theauthentication module 935 of thepayment application 930 through the securityenvironment driver module 953 and the biometricinformation management module 943 of theREE 910. Thepayment application 930 may show, to thedisplay 160, whether to authenticate. The biometric information of the user may be stored in theTEE 920, stored in theREE 910 in an encrypted state, or stored in the security module (e.g., an eSE) 236.

According to an embodiment of the present disclosure, the securityidentifier processing module 923 may acquire, through a user input, an input value, which is necessary for theelectronic device 800 or is associated with payment or authentication. For example, the input value may be a personal identification number (PIN) during payment. In addition, the input value may include information related to the card. For example, the information may include a PAN, a card valid term (expiration date), or card verification value (CVV). In addition, the information may include a Chip PIN or automated teller machine (ATM) PIN. The securityidentifier processing module 923 may be indicated in the form of an application. A graphic library necessary for illustration of the application of the securityidentifier processing module 923 on a screen may be stored in theTEE 920. The graphic library stored in theTEE 920 may be different from a graphic library in theREE 910. The securityidentifier processing module 923 may perform user authentication by an input value, such as a PIN, and may transfer a result of the authentication to thepayment management module 931 through thepayment relay module 941.

According to an embodiment of the present disclosure, the securityidentifier processing module 923 may receive an encrypted disposable random number (e.g., nonce) transferred through the securityenvironment driver module 953 by the securityenvironment relay module 946. The securityidentifier processing module 923 may encrypt the disposable random number and the input value acquired through the user input, using an encryption key (e.g., device root key) in theTEE 920, and transfer them to the securityenvironment relay module 946. The securityenvironment relay module 946 may transfer the encrypted input value and disposable random number to thepayment module 921 through the securityenvironment driver module 953. Thepayment module 921 may decrypt the input value and disposable random number, using a hardware key in theTEE 920. Thepayment module 921 may identify that the input value transferred through theREE 910 has an integrity, based on the point that the generated value and the received value of the disposable random number are the same. Thepayment module 921 may perform user authentication through the input value, based on the point that the input value has an integrity. Thepayment module 921 may perform payment through user authentication.

According to an embodiment of the present disclosure, a factory reset refers to an operation of returning a software image of theelectronic device 800 to the original state at the time when the electronic device is shipped from a factory. This operation may be performed as an explicit operation of a user through an application. Moreover, a module for determining and monitoring a hacking by a certain condition (e.g., when it is determined that the system has been hacked) may perform a factory reset. When the operation is performed, data stored in theelectronic device 800 is reset and the payment-related information of the user also may be thus reset. The payment-related information may be stored in thepayment server 720. When the user accesses thepayment server 720 based on an account, the user may be allowed to perform operations of registering a card and installing apayment module 921 again based on the payment-related information. When the data is reset, the payment-related module stored in theelectronic device 800 may notify theTSP 730 of the resetting through thepayment server 720 to deactivate the TSP. When a network of theelectronic device 800 has been deactivated, it may be impossible to perform the operation of notification. In this event, theelectronic device 800 may perform the factory reset and access the account of thepayment server 720 based on an account. Theelectronic device 800 may identify a list of pre-registered cards through thepayment server 720, and may deactivate a card module or token of theelectronic device 800 pre-registered in theTSP 730 through thepayment server 720. In addition, based on the card list of thepayment server 720, theelectronic device 800 may perform card registration again and receive apayment module 921, token, and the like.

According to an embodiment of the present disclosure, an electronic device includes a display, a communication interface, and a processor, wherein the processor is configured to transmit a user identifier to a server through the communication interface, receive information of at least one card associated with the user identifier from the server through the communication interface and display the received information on a display, select one piece of card information from the displayed information of the at least one card, and request, through the communication interface, the server to issue a token for payment, using at least a part of the selected card information.

According to an embodiment of the present disclosure, an electronic device includes a communication interface, and a processor, wherein the processor is configured to connect to another electronic device through the communication interface, using a user identifier, receive information of at least one card associated with the user identifier from the server through the communication interface as a response to a card information request from the electronic device through another electronic device, and request the server to issue a token for payment, using at least a part of the received information of the at least one card.

According to an embodiment of the present disclosure, an electronic device includes a communication interface, and a processor, wherein the processor is configured to connect to another electronic device through the communication interface, using a user identifier, receive information of at least one card associated with the user identifier from the another electronic device through the communication interface as a response to a card information request from the electronic device through the another electronic device, and request the server to issue a token for payment, using at least a part of the received information of the at least one card.

According to an embodiment of the present disclosure, the server may include a communication interface, and a processor, wherein the processor is configured to receive a user identifier from an electronic device through the communication interface, identify a card identifier associated with the user identifier, request, through the communication interface, an external device to provide information of at least one card associated with the card identifier, receive the information of the at least one card from the external device through the communication interface, and transmit the information of the at least one card to the electronic device through the communication interface.

According to an embodiment of the present disclosure, the external device may be a token server.

According to an embodiment of the present disclosure, the server may be a payment server.

FIG. 10 is a block diagram illustrating a payment system according to various embodiments of the present disclosure.

Referring to FIG. 10, apayment system 1000 may include anelectronic device 1010 and/or an external device 1020 (e.g., server). Theelectronic device 1010 may include, for example, aTEE 1030 and/or aREE 1040. Theexternal device 1020 may include, for example, a server, and the server may include, for example, apayment server 1050 and/or atoken server 1060. Thepayment server 1050 may include, for example, apayment service server 1052 ortoken requester server 1054.

According to various embodiments of the present disclosure, theTEE 1030 may include a security system related to theelectronic device 1010. For example, theelectronic device 1010 may protect information included or stored in theTEE 1030 from a control related to a request, a revision, or an input from the outside, using theTEE 1030.

According to an embodiment of the present disclosure, theTEE 1030 may include, for example, a program mode, the security of which has been reinforced. For example, using theTEE 1030, a normal area (world) and a security area (world) may be distinguished. The normal world may be referred to as theREE 1040. Further, theTEE 1030 may, for example, execute a reliable application or manage encrypted information. For example, the encrypted information may include token or key information.

According to an embodiment of the present disclosure, theTEE 1030 may protect the encrypted information from the outside. The token or key information may be used to encrypt the card information. For example, in relation to the token or key information, when the card information is provided to a device for payment, the card information may be at least partly changed rather than being directly provided to the device for payment. In changing the card information, the token or key information may be used. The key may be acquired from, for example, a service provider who provides a payment service. Further, the key may be managed by theelectronic device 1010 or the server. According to an embodiment of the present disclosure, theTEE 1030 may include, for example, a security application (trusted application) 1032. TheTEE 1030 may provide, for example, an environment in which thesecurity application 1032 can be executed.

According to various embodiments of the present disclosure, thesecurity application 1032 may include, for example, information related to a card company included in theTEE 1030. The information related to the card company may include, for example, an application related to the card company, and the application may be provided in a packaged form. The packaged form may be provided by a SDK.

According to various embodiments of the present disclosure, thesecurity application 1032 may include, for example, an application or applet which should be executed in a mode, the security of which has been reinforced, likewise in theTEE 1030. Further, thesecurity application 1032 may include, for example, an encryption-related function. For example, thesecurity application 1032 may perform functions of generating, revising, or deleting a cryptogram related to the payment.

According to various embodiments of the present disclosure, theREE 1040 may include an application layer. For example, theREE 1040 may include an application and/or framework. TheREE 1040 may allow access thereto from the outside or control thereof, differently from theTEE 1030. TheREE 1040 may include, for example, a payment application (wallet application) 1042 and/or apayment manager 1044. Thepayment application 1042 may perform, for example, functions of identification, OCR, or interfacing for payment by thepayment application 1042. For example, thepayment application 1042 may perform, for example, functions related to card registration or payment.

According to various embodiments of the present disclosure, thepayment manager 1044 may include, for example, information related to a card company included in theREE 1040. The information related to the card company may include, for example, an application related to the card company, and the application may be provided in a packaged form. The packaged form may be provided by an SDK. Thepayment manager 1044 may include, for example, an encryption-related function. For example, thepayment manager 1044 may perform functions of token ID management or card company channel establishment. Further, thepayment manager 1044 may perform, for example, interfacing with the external device (e.g., a server) 1020. For example, thepayment manager 1044 may provide an interface with a server (e.g., the payment server 1050) for a tokenization service.

According to various embodiments of the present disclosure, thepayment manager 1044 may be functionally connected with and share information with thesecurity application 1032. For example, thepayment manager 1044 may perform interfacing with thesecurity application 1032 for using (e.g., storing) the token or the key. Further, thesecurity application 1032 may include information associated with a network service provider.

According to various embodiments of the present disclosure, thepayment application 1042 and thepayment manager 1044 may be functionally connected with each other, and thesecurity application 1032 and thepayment manager 1044 may be functionally connected with each other. For example, thepayment manager 1044 may transfer information received from the outside to thepayment application 1042 or thesecurity application 1032 or transfer information received from thepayment application 1042 or thesecurity application 1032 to the outside. According to an embodiment of the present disclosure, thepayment manager 1044 may share information related to payment with thesecurity application 1032 or thepayment application 1042.

According to various embodiments of the present disclosure, theelectronic device 1010 may include an additional configuration or module, as well as theTEE 1030, thesecurity application 1032, theREE 1040, thepayment application 1042, and thepayment manager 1044.

According to various embodiments of the present disclosure, thepayment server 1050 is a management server for electronic payment or mobile payment and may transmit or receive information (e.g., token or key) related to payment to or from theelectronic device 1010. Further, thepayment service server 1052 and thetoken requester server 1054 included in thepayment server 1050 are functionally connected with each other to share information relating to payment.

According to various embodiments of the present disclosure, thetoken server 1060 may be functionally connected to thetoken requester server 1054 to transmit or receive the information related to payment. For example, thetoken requester server 1054 and thetoken server 1060 may provide an interface for transfer of the token or the key.

FIG. 11 is a block diagram illustrating a payment server according to various embodiments of the present disclosure.

Referring to FIG. 11, according to various embodiments of the present disclosure, a management server for payment, for example, apayment server 1110, may include a security service (e.g. a trusted service)management server 1120, apayment service server 1130, or atoken requester server 1140. Thepayment service server 1130 may include, for example, at least one of a payment service module, a card management module, or an account management module. The account management module may include, for example, a Samsung account integration. According to an embodiment of the present disclosure, thetoken requester server 1140 may include at least one module among a payment service interface, a message gateway, or a data management module. The payment service interface may include, for example, a token service interface, and the message gateway may include, for example, a push gateway module. Further, the data management module may include, for example, a data management module.

According to various embodiments of the present disclosure, the securityservice management server 1120 may manage information relating to payment. For example, the securityservice management server 1120 may manage the information relating to the payment according to the kind (e.g., a security area or a non-security area) and/or configuration (e.g., a logical configuration or physical configuration) of the area in which the information related to the payment is stored. For example, when the area in which the information related to payment, for example, a token, is stored is a security module (e.g., an eSE) or an embedded subscriber identity module (eSIM), the securityservice management server 1120 may perform management of the token stored in the security module or eSIM. For example, the security module or eSIM may be included in theelectronic device 800 or an external device (e.g., the first externalelectronic device 102, the second externalelectronic device 104, or theserver 106 of FIG. 1).

According to various embodiments of the present disclosure, the securityservice management server 1120 may perform functions of thepayment service server 1130 and/or thetoken requester server 1140. Further, the securityservice management server 1120 may be implemented separately from thepayment service server 1130 and/or thetoken requester server 1140. For example, thepayment service server 1130 and/or thetoken requester server 1140 may be included in a first server, while the securityservice management server 1120 may be included in a second server.

According to various embodiments of the present disclosure, the securityservice management server 1120 may control a storage area (e.g., memory) for storing the information (e.g., token or key) relating to payment in order to manage the information relating to payment. The storage area for storing the information relating to payment may include a key management module.

According to various embodiments of the present disclosure, the securityservice management server 1120 may manage, using the key management module, the token stored in the security module or eSIM. The storage area included in the security module or eSIM may include, for example, a supplementary secure domain (SSD). The SSD may be included in, for example, theelectronic device 800 and may be generated using a key management module agent or client. The key management module agent or client may be functionally connected with the key managing module to perform a payment function.

According to various embodiments of the present disclosure, theelectronic device 800 may include a certain key when theelectronic device 800 is produced or processed. For example, theelectronic device 800 may generate a master key in a certain area (e.g., security module or eSIM), using the certain key.

According to various embodiments of the present disclosure, theelectronic device 800 may generate the SSD in the certain area, using the master key, in response to a request from the securityservice management server 1120. According to an embodiment of the present disclosure, the SSD may include a profile or an application (e.g., SDK) required for each bank or financial company to perform a payment function. The profile or application may be installed in the SSD through, for example, the securityservice management server 1120.

According to various embodiments of the present disclosure, the payment service module may be functionally connected to the payment application included in theelectronic device 800 to provide an API for transmitting or receiving information related to payment. Further, the payment service module may record, for example, flows of information (e.g., data) related to payment. For example, the flows related to the payment may include payment result storage, transmission of payment details to the electronic device, or inquiry to payment history.

According to various embodiments of the present disclosure, the card management module may generate information on a card received from the payment application. For example, the card management module may generate resource ID related to the card information received from the payment application. The resource ID may be recorded as “resour.ID”. The card information from the payment application may be received by thepayment service server 1130, for example, in response to a command (e.g., registration request) indicating a card for payment from a user. The resource ID may include, for example, a token ID or token reference. Further, the resource ID may include, for example, a plurality of token IDs or token references, and the plurality of token IDs or token references may include information corresponding to information of each card.

According to various embodiments of the present disclosure, the card management module may transfer the token ID or token reference to thetoken requester server 1140 included in thepayment server 1110. For example, the card management module may transfer a request for registration of the card information to a token service interface included in thetoken requester server 1140.

According to various embodiments of the present disclosure, the card management module may manage an operation cycle (life cycle) of a card corresponding to the token ID or token reference. For example, the operation cycle of the card may include at least one of card registration, token issuance, token activation, or token removal.

According to various embodiments of the present disclosure, the account management module may manage an account corresponding to a registered card, using the card management module. For example, the account management module may provide a payment service by linking a card registered in thepayment server 1110 with a service account (e.g., a Samsung account). Further, the account management module may perform, for example, functions of account registration, login, authentication, or generation of a security area. Further, the account management module may manage, for example, at least one policy among policies according to countries, devices, or card companies.

According to various embodiments of the present disclosure, thetoken requester server 1140 may be functionally connected to the token server to perform at least one of issuance, removal, or activation of a token, and may interwork with the securityservice management server 1120 to store a token in the security area (e.g., TEE) of theelectronic device 800. Further, thetoken requester server 1140 may manage, for example, a security channel with the token server, and perform data collection, ingestion, or service function of the information related to payment.

According to various embodiments of the present disclosure, the token service interface may transfer a request associated with the token received from the electronic device to the token server, and transfer a response to the request, received from the token server, to the electronic device. Further, the token service interface may manage, for example, the security of a channel functionally connected to the token server.

According to various embodiments of the present disclosure, the push gateway module may perform a path function for transferring a message associated with the token from the token server to theelectronic device 800.

According to various embodiments of the present disclosure, the data management module may manage data (e.g., card information or user information) used in thetoken requester server 1140. Further, the data management module may provide, for example, a mapping table including card information (e.g., PAN), payment application information, a user, or anelectronic device 800. For example, the data management module may store, in the form of a table, at least one of a PAN, payment application information, user information, device information, and token information.

According to various embodiments of the present disclosure, thetoken requester server 1140 may identify the mapping table related to the token, using the data management module. In addition, thepayment service server 1130 may include information related to anelectronic device 800 or account. For example, the payment system may perform user authentication, using the mapping table and the information related to anelectronic device 800 or account.

FIG. 12 is a block diagram illustrating a method of generating a token cryptogram according to various embodiments of the present disclosure.

Referring to FIG. 12, thepayment module 921 may store atoken 1210, a tokenvalid period 1220, atoken requester ID 1230, and atoken cryptogram 1240 from theelectronic device 800 or another external electronic device. Thepayment module 921 may generate thetoken cryptogram 1240, using a key 1260 anddata 1270. For example, anencryption engine 1250 may encrypt thetoken cryptogram 1240, based on the key 1260 and thedata 1270. Thepayment module 921 may usedifferent keys 1260 according to a certain rule, for example, in each transaction, in a certain number of times of transaction, or a transaction within a particular time. Thedata 1270 and theencryption engine 1250 may change into a wide variety of types according to the encryption method (e.g., AES, TKIP, and the like).

TheTSP 730 may possess a key paired with the above-describedkey 1260. TheTSP 730 may decrypt the encryptedtoken cryptogram 1240 through the paired key.

FIG. 13 is a signal flow diagram illustrating a communication method for payment between an electronic device and a POS device according to various embodiments of the present disclosure. For example, the electronic device may be anelectronic device 800 of FIG. 8.

Referring to FIG. 13, thepayment module 921 may transmit or receive certain information to or from thePOS device 740 in the payment operation. In the case of NFC, thePOS device 740 may first receive the information to perform the payment. In the case of MST, payment-related information including the token 1210 andtoken cryptogram 1240 may be transmitted, based on an explicit input from a user or an internal algorithm of theelectronic device 800, to thePOS device 740.

According to an embodiment of the present disclosure, in the case of using the NFC for the payment, theelectronic device 800 may transmit or receive at least one message.

Inoperation 1311, theelectronic device 800 may receive a message determined by thePOS device 740.

Inoperation 1313, theelectronic device 800 may transmit information (e.g., card type and priority information) associated with thepayment module 921 to thePOS device 740 based on the certain message.

Inoperation 1315, thePOS device 740 may determine apayment module 921 to perform the payment, based on information associated with thepayment module 921. ThePOS device 740 may transfer the information associated with thedetermined payment module 921 to theelectronic device 800.

Inoperation 1317, theelectronic device 800 may transfer the information enabling access to thedetermined payment module 921 to thePOS device 740.

Inoperation 1319, thePOS device 740 may establish a security channel between theelectronic device 800 and thePOS device 740 based on the information enabling the access. To this end, theelectronic device 800 and thePOS device 740 may exchange at least one key 1260 capable of establishing a security channel. The above process may be a process of exchanging at least one message.

Inoperation 1321, theelectronic device 800 may transmit information (e.g., token 1210,token cryptogram 1240, a part of PAN information, or token valid period 1220) necessary for payment to thePOS device 740 through the security channel.

FIG. 14 is a block diagram illustrating a token payment flow in a payment system according to various embodiments of the present disclosure.

Referring to FIG. 14, the payment system may include anelectronic device 1410, apayment server 1470, atoken server 1450, aPOS device 1420, afinancial server 1460, a purchase server (acquirer) 1430, or apayment network 1440. Theelectronic device 1410 may include, for example, a payment application, a payment manager, or a security area (e.g., a security module or a TEE). ThePOS device 1420 may include, for example, a sales time point information management system. ThePOS device 1420 may be, for example, a combination of functions of a cash register and a computer electronic device, and a user can perform a payment function using thePOS device 1420. Thefinancial server 1460 may include, for example, a bank or financial company for issuing a card, and may perform identification of the card. Further, the financial server may proceed approval of the card at the time of payment. Thepurchase server 1430 may include, for example, a bank or financial company which purchases a transaction sheet for the card transaction paid in a shop (e.g., the POS device 1420). Thepayment network 1440 may include, for example, a card network.

According to various embodiments of the present disclosure, inoperation 1401, theelectronic device 1410 may transfer a token and/or encryption information (e.g., cryptogram) to a payment terminal (e.g., the POS terminal 1420). For example, the token may be stored in theelectronic device 1410. Further, the token may be stored in an encrypted area of theelectronic device 1410. For example, theelectronic device 1410 may encrypt and store the token in the security module or theTEE 920. For example, theelectronic device 1410 may generate encryption information, using a key received from the outside or a key generated by theelectronic device 1410. The security information may include a cryptogram. Further, theelectronic device 1410 may transfer the cryptogram and/or the token to thepayment terminal 1420.

According to various embodiments of the present disclosure, theelectronic device 1410 may use various communication connections in order to transfer the token and/or cryptogram to thepayment terminal 1420. The communication connections may include, for example, NFC, MST, barcode, or quick response (QR) code.

According to various embodiments of the present disclosure, inoperation 1402, thepayment terminal 1420 may transfer at least one among the token, the encryption information, and the payment information to thepurchase server 1430. For example, thepayment terminal 1420 may transfer the token and/or the cryptogram received from theelectronic device 1410 and the payment information (e.g., payment location, payment date, or payment amount) acquired from thepayment terminal 1420 to thepurchase server 1430. Further, the payment information may be, for example, acquired from thepayment terminal 1420 or received from an external device, and may include payment details relating to a payment function requested by the user. Further, the payment information may include, for example, payment history performed using thepayment system 700.

According to various embodiments of the present disclosure, inoperation 1403, thepurchase device 1430 may transfer, for example, at least one among the token, the encryption information, and the payment information to thepayment network 1440. Thepurchase server 1430 may receive at least one among the token, the password information, and the payment information, and transfer at least one among the received token, password information, and payment information to thepayment network 1440.

According to various embodiments of the present disclosure, inoperation 1404, thepayment network 1440 may transmit, for example, at least one among the token, the encryption information, and the payment information to thetoken server 1450. Thepayment network 1440 may include a network associated with a card company, for example, VISA™, Master Card™, or Amex™.

According to an embodiment of the present disclosure, thepayment network 1440 may include or operate thetoken server 1450.

According to various embodiments of the present disclosure, thetoken server 1450 may receive at least one of the token, the encryption information, and the payment information from thepayment network 1440. Thetoken server 1450 may identify information on the received token. For example, thetoken server 1450 may use the token to identify card information (e.g., card number (PAN), expiration date) corresponding to the token. For example, thetoken server 1450 may identify a PAN corresponding to thefinancial server 1460, using information (e.g., Data) included in the token. Thetoken server 1450 may, for example, identify a PAN corresponding to thefinancial server 1460 and use the PAN to get payment authentication from thefinancial server 1460.

According to various embodiments of the present disclosure, thetoken server 1450 may identify the PAN, using the received cryptogram.

According to various embodiments of the present disclosure, inoperation 1405, thetoken server 1450 may transfer the PAN to thepayment network 1440.

According to an embodiment of the present disclosure, thepayment network 1440 may receive the PAN from, for example, thetoken server 1450.

Inoperation 1406, thepayment network 1440 may transfer the PAN and/or the payment information to thefinancial server 1460. According to various embodiments of the present disclosure, thefinancial server 1460 may receive the PAN and/or the payment information from thepayment network 1440.

For example, thefinancial server 1460 may determine whether to approve the payment, using the PAN and/or the payment information. For example, thefinancial server 1460 may use the PAN and/or the payment information to determine whether it coincides (e.g., valid PAN) with information included in thefinancial server 1460. Thefinancial server 1460 may determine whether a database storing the PAN includes a PAN coinciding with the received PAN, and may identify payment restriction information (e.g., payment limit or foreign approval-or-not) associated with the coinciding PAN.

For example, thefinancial server 1460 may determine whether to approve the payment, by determining whether the payment information satisfies the identified payment restriction information. Thefinancial server 1460 may approve the payment when the PAN and/or the payment information coincides with the information included in thefinancial server 1460. Meanwhile, thefinancial server 1460 may reject the payment when the PAN and/or the payment information does not coincide with the information included in thefinancial server 1460. The rejection of the payment may refer to unapproval of the payment (e.g., unapproval or rejection).

According to various embodiments of the present disclosure, inoperation 1407, thefinancial server 1460 may transfer a result of the approval determination (e.g., approval or rejection) to thepayment network 1440.

According to various embodiments of the present disclosure, inoperation 1408, thepayment network 1440 may transfer the approval result to thepurchase server 1430. Further, thepayment network 1440 may transfer the payment information to thetoken server 1450, when the approval result corresponds to approval.

According to various embodiments of the present disclosure, inoperation 1409, thepurchase server 1430 may transfer the approval result received from thepayment network 1440 to thepayment terminal 1420. Inoperation 1411, thetoken server 1450 may transfer, for example, the payment information to thepayment server 1470.

According to various embodiments of the present disclosure, inoperation 1412, thepayment server 1470 may transfer, for example, the payment information to theelectronic device 1410. For example, thepayment server 1470 may transfer the payment information to theelectronic device 1410, using a certain command (e.g., a push message). The payment information may include payment location, payment date, payment amount, and total payment amount.

Although thepurchase server 1430, the token server1450, thefinancial server 1460, and thepayment server 1470 are separately illustrated and described in the above description, thepurchase server 1430, the token server1450, thefinancial server 1460, and thepayment server 1470 may be configured in one unit according to embodiments of the present disclosure.

According to various embodiments of the present disclosure, theelectronic device 1410 may display the payment information on thedisplay 160. For example, theelectronic device 1410 may display the payment information, using the payment application included in theelectronic device 1410, or display the payment information through an interface associated with a payment function. The interface associated with the payment function may include a notification bar.

According to various embodiments of the present disclosure, theelectronic device 1410 may display the payment information or information (e.g., payment state, payment history, or accumulated amount) associated with the payment through adisplay 160 functionally connected to theelectronic device 1410. For example, theelectronic device 1410 may use a notification module (e.g., thenotification manager 349 of FIG. 3) of theelectronic device 1410 to display payment information or the information associated with the payment. Further, in theelectronic device 1410, the payment information or the information associated with the payment may be displayed using at least one among, for example, a notification, an indicator, a status bar, a task bar, an icon, a floating icon, a tile, and a widget, and may be displayed in a partial area of at least one among a home screen, a lock screen, and a curved display.

According to various embodiments of the present disclosure, theelectronic device 1410 may output a sound notifying of the payment information or the information associated with the payment through an audio module (e.g., theaudio module 280 of FIG. 2 and/or a motor (e.g., themotor 298 of FIG. 2, a tactile feedback device (not shown), a friction display (not shown)) functionally connected to theelectronic device 1410, or generate vibration or haptic effect notifying of the information.

According to various embodiments of the present disclosure, a payment card industry (PCI) for a protocol for a payment card exists, and thepayment terminal 1420 should satisfy the requirements by a PIN transaction security (PTS) for payment transaction. For example, thepayment terminal 1420 should follow a contingency mechanism, which can monitor physically sensitive data (e.g., card information and signature information) in order to physically protect the physically sensitive data and, when an intrusion is deleted, can delete the data to preclude the possibility of restoration of the sensitive data. Further, thepayment terminal 1420 should discriminate between applications in executing each application, and follow requirements that it should be impossible to monitor, collide with, or revise another application or OS. Further, as firmware is authenticated when the firmware is updated, thepayment terminal 1420 should identify cryptological authentication of firmware in installing all applications in a corresponding terminal.

Further, an OS of thepayment terminal 1420 may include only software necessary for an intended function. An OS of thepayment terminal 1420 should be safely configured and be executed by least authority. An OS of thepayment terminal 1420 should not allow an unauthenticated or unnecessary function for a security policy performed by a device. An OS of thepayment terminal 1420 should disable or, if possible, delete an unrequired API or commands for supporting a special function.

Therefore, in order to use theelectronic device 1410 as thepayment terminal 1420, the requirements described above should be satisfied.

According to various embodiments of the present disclosure, theelectronic device 1410 may implement an input of PIN, and the like, as a trusted input to safely read a physical signature or the PIN input, entering through a touch screen and a trust zone, and directly bring it into the trust zone. Meanwhile, at the time of processing the payment mode, theelectronic device 1410 may configure a tone or screen displayed on adisplay 160 differently from a general mode, to enable a user to recognize the tone or screen. Hereinafter, an operation method for using theelectronic device 1410 as thepayment terminal 1420 will be described below. Hereinafter, an operation method for using theelectronic device 1410 as apayment terminal 1420 will be described below.

FIG. 15 is a block diagram illustrating a signal flow of an operation of a payment system according to various embodiments of the present disclosure.

Referring to FIG. 15, the payment system may include anelectronic device 1510, apayment server 1520, and/or apayment network 1530. Theelectronic device 1510 may include, for example, apayment manager 1512. Thepayment server 1520 may include, for example, apayment service server 1522 or atoken requester server 1524. Thepayment network 1530 may include, for example, atoken server 1532. The payment system may use, for example, the token for the functions performed by each of theelectronic device 1510, thepayment server 1520, and/or thepayment network 1530.

According to various embodiments of the present disclosure, theelectronic device 1510 may provide a tokenization service associated with the token, using thepayment manager 1512 included in theelectronic device 1510 and thetoken requester server 1524 included in thepayment server 1520.

According to various embodiments of the present disclosure, thepayment management server 1522 may provide an operation cycle (e.g., token life management) associated with a token, using thetoken requester server 1524 included in thepayment server 1520.

According to various embodiments of the present disclosure, thetoken server 1532 may provide a notification service associated with the token, using thetoken requester server 1524.

According to various embodiments of the present disclosure, thetoken requester server 1524 may provide a payment method to theelectronic device 1510, using a payment network solution. For example, thetoken requester server 1524 may determine a payment method proper for the user, using the tokenization service, an operating cycle associated with the token, and/or a notification service associated with the token.

FIGS. 16A to 16C illustrate screen configurations for registering a card associated with a user account in an electronic device according to various embodiments of the present disclosure. For example, the electronic device may be theelectronic device 710 illustrated in FIG. 7.

According to an embodiment of the present disclosure, when a user attempts to initially register a card in theelectronic device 710, theelectronic device 710 may transmit an input user account to thepayment server 720. For example, the attempt of the initial card registration may refer to an attempt of registration of a card in theelectronic device 710 in a state where no card has been stored therein.

Referring to FIG. 16A, for example, when there is no card registered in a payment application (e.g., Samsung Pay™), theelectronic device 710 may display animage 1603 as shown inscreen 1601 of FIG. 16A. For example, theimage 1603 may include amessage 1603 reading “No card has been registered in the payment application yet. Please tap theimage 1603 in order to register a new card”. When theimage 1603 is tapped by the user, theelectronic device 710 may determine that the user is attempting to register a new card, and may transmit an input user account to thepayment server 720.

According to an embodiment of the present disclosure, theelectronic device 710 may receive and display at least one piece of card information from thepayment server 720.

Referring to FIG. 16A, for example, theelectronic device 710 may display a plurality of overlappingcard images 1607 included in multiple pieces of card information as shown in thescreen 1605 of FIG. 16A. For example, in order to express that a plurality of cards have not been registered yet, theelectronic device 710 may display a plurality ofcard images 1607 in a particular color (e.g., gray color) or display the images to have at least one of a different color, a different transparency, a different size, and a different text from those of a registered card.

Referring to FIG. 16B, for example, when onecard image 1609 is selected from a plurality ofcard images 1607 by a user, theelectronic device 710 may display card information associated with the selected card image. For example, as shown in thescreen 1611 of FIG. 16B, theelectronic device 710 may display related card information on the selectedcard image 1613. As another example, as shown in thescreen 1621 of FIG. 16C, theelectronic device 710 may display aparticular window 1625 including related card information, separately from the selectedcard image 1623.

According to an embodiment of the present disclosure, when the user selects a card to be registered, theelectronic device 710 may proceed with a card registration procedure, based on card information associated with the selected card.

Referring to FIG. 16B, for example, as shown in thescreen 1611 of FIG. 16B, when thecard image 1613 has been tapped by the user, theelectronic device 710 may determine a card corresponding to thecard image 1613 as the card to be registered, and may perform a card registration process based on card information corresponding to thecard image 1613.

Referring to FIG. 16C, as another example, as shown in thescreen 1621 of FIG. 16C, when thecard registration menu 1627 has been tapped by the user, theelectronic device 710 may determine a card corresponding to thecard image 1623 as the card to be registered, and may perform a card registration process based on card information corresponding to thecard image 1623.

According to an embodiment of the present disclosure, when the card registration has been completed, theelectronic device 710 may display an image of the registered card. For example, in order to express that a card has been registered in theelectronic device 710, theelectronic device 710 may display an image of the registered card in a particular color (e.g., a color different from that of unregistered cards) or display the image to have at least one of a different transparency, a different size, and a different text from those of the unregistered card.

Referring to FIG. 16C, for example, when the card registration has been completed, theelectronic device 710 may display theimage 1617 or 1631 of the registered card in the same color as that of the real card as shown in thescreen 1615 of FIG. 16B or thescreen 1629 of FIG. 16C.

FIG. 17 illustrates a screen configuration for transmitting card information in an electronic device according to various embodiments of the present disclosure. For example, the electronic device may be theelectronic device 710 illustrated in FIG. 7.

Referring to FIG. 17, according to an embodiment of the present disclosure, the user may use a plurality of electronic devices (e.g., the electronic device 710) andwearable devices 750. The plurality of electronic devices may be managed and used by a user through an identical user ID. The plurality of electronic devices may have been paired or connected with each other wiredly or wirelessly through BT, BLE, Wi-Fi, ZIGBEE, USB, IEE1394, and the like.

According to an embodiment of the present disclosure, theelectronic device 710 may directly or indirectly transmit card information to another device according to a user’s request. For example, the electronic device may receive, from a user, a determination on whether to transmit the card information or may automatically transmit the card information to another device without the user’s determination.

For example, when card information is received from the payment server (e.g., the payment server 720), theelectronic device 710 may display amessage 1703 inquiring whether to transmit the received card information to the wearable device 750 (e.g., a watch device), as in ascreen 1701 of FIG. 17.

For example, when adenial 1707 of the transmission of the card information is received from the user, theelectronic device 710 may not transmit the card information to thewearable device 750.

For example, when anapproval 1705 of the transmission of the card information is received from the user, theelectronic device 710 may directly transmit the received card information to thewearable device 750. In this event, theelectronic device 710 may directly transmit the card information through a communication network (e.g., 2G, 3G, 4G, or LTE) or a short-range wireless communication (e.g., BT, BLE, Wi-Fi, ZIGBEE, or Li-Fi).

As another example, when theapproval 1705 of the transmission of the card information is received, theelectronic device 710 may request, through thepayment server 720, the card information from thetoken server 730. Thereafter, thetoken server 730 may directly or indirectly transmit the card information to thewearable device 750. For example, thetoken server 730 may transmit the card information to thewearable device 750 through thepayment server 720. As another example, thetoken server 730 may directly transmit the card information to thewearable device 750. In this event, thetoken server 730 may directly transmit the card information through a communication network (e.g., 2G, 3G, 4G, or LTE).

According to an embodiment of the present disclosure, thewearable device 750 may receive and store the card information.

According to an embodiment of the present disclosure, after the card issuance in theelectronic device 710 is completed, thetoken server 730 may directly or indirectly transmit the card information to thewearable device 750.

FIGS. 18A to 18C illustrate screen configurations for registering a card associated with a user account in an electronic device according to various embodiments. For example, the electronic device may be thewearable device 750 illustrated in FIG. 7.

According to an embodiment of the present disclosure, when a payment application is executed, thewearable device 750 may display card information. For example, as soon as the reception and storage of the card information is completed, thewearable device 750 may automatically execute the payment application and display the card information. As another example, when there is a first request for execution of the payment application by the user after thewearable device 750 stores the card information, thewearable device 750 may execute the payment application and display the card information.

Referring to FIG. 18A, for example, thewearable device 750 may display a plurality of overlappingcard images 1803 included in multiple pieces of card information as shown in ascreen 1801 of FIG. 18A. For example, in order to express that a plurality of cards have not been registered yet, thewearable device 750 may display a plurality ofcard images 1803 in a particular color (e.g., gray color) or display the images to have at least one of a different color, a different transparency, a different size, and a different text from those of a registered card.

Referring to FIG. 18B, for example, when onecard image 1805 is selected from a plurality ofcard images 1803 by a user, thewearable device 750 may display card information associated with the selected card image. For example, as shown in ascreen 1807 of FIG. 18B, thewearable device 750 may display related card information on a selectedcard image 1809.

Referring to FIG. 18C, as another example, as shown in ascreen 1815 of FIG. 18C, thewearable device 750 may display aparticular window 1819 including related card information, separately from a selectedcard image 1817.

Referring to FIG. 18B, according to an embodiment of the present disclosure, when the user selects a card to be registered, thewearable device 750 may proceed with a card registration procedure, based on card information associated with the selected card. For example, as shown in thescreen 1807 of FIG. 18B, when thecard image 1809 has been tapped by the user, thewearable device 750 may determine a card corresponding to thecard image 1809 as the card to be registered, and may perform a card registration process based on card information corresponding to thecard image 1809.

Referring to FIG. 18C, as another example, as shown in thescreen 1815 of FIG. 18C, when acard registration menu 1821 has been tapped by the user, thewearable device 750 may determine a card corresponding to thecard image 1817 as the card to be registered, and may perform a card registration process based on card information corresponding to thecard image 1817.

According to an embodiment of the present disclosure, when the card registration has been completed, thewearable device 750 may display an image of the registered card. For example, in order to express that a card has been registered in thewearable device 750, thewearable device 750 may display an image of the registered card in a particular color (e.g., a color different from that of unregistered cards) or display the image to have at least one of a different transparency, a different size, and a different text from those of the unregistered card.

For example, when the card registration has been completed, thewearable device 750 may display animage 1813 or 1825 of the registered card in the same color as that of the real card, as shown in ascreen 1811 of FIG. 18B or ascreen 1823 of FIG. 18C.

FIG. 19 illustrates a signal flow diagram illustrating a token issuance operation in an electronic device 1902 (e.g., the electronic device 101) according to various embodiments of the present disclosure.

According to an embodiment of the present disclosure, the token issuance operation may be changed according to the country. For example, the token issuance operation may be changed based on the United States of America, Europe, or Republic of Korea.

Referring to FIG. 19, the payment system may include anelectronic device 1902, apayment server 1904, or atoken server 1906. Theelectronic device 1902 may include, for example, at least one of a payment application, a payment manager, a security module, and a TEE.

According to an embodiment of the present disclosure, theelectronic device 1902 may acquire card-related information through a sensor functionally connected to theelectronic device 1902. The card-related information may be used in, for example, a card registration operation. The sensor may include, for example, an OCR function. The card-related information may include, for example, at least one among PAN, valid period, name, and CVV. The sensor may be operated using, for example, theelectronic device 1902 or the payment application included in theelectronic device 1902.

According to various embodiments of the present disclosure, the payment application included in theelectronic device 1902 may transfer the card-related information to thepayment server 1904. Thepayment server 1904 may include, for example, a payment service server or token requester server, and the card-related information may be transferred between the payment service server and the token requester server.

According to an embodiment of the present disclosure, the payment server (e.g., the token requester server) 1904 may transfer the card-related information and/or information (e.g., device information or user information) related to theelectronic device 1902 to thetoken server 1906. The information related to theelectronic device 1902 may include, for example, information of a device having requested the token issuance operation.

According to an embodiment of the present disclosure, thetoken server 1906 may transfer a token based on the information received from thepayment server 1904. Thetoken server 1906 may transfer the token to, for example, the token requester server included in thepayment server 1904.

According to an embodiment of the present disclosure, thepayment server 1904 may transfer the token to theelectronic device 1902. Thepayment server 1904 may transfer a token through, for example, the token requester server included in thepayment server 1904, to theelectronic device 1902.

According to an embodiment of the present disclosure, theelectronic device 1902 may store, in the security module or the TEE, the token received from thepayment server 1904. For example, theelectronic device 1902 may store the token in the security module or the TEE, which is a security area, to control access from the outside.

According to an embodiment of the present disclosure, theelectronic device 1902 may store, in the general memory (e.g., memory included in the REE), the token received from thepayment server 1904.

According to an embodiment of the present disclosure, the token may be issued (generated) based on a payment method (e.g., OTP or call center) performed by theelectronic device 1902.

According to an embodiment of the present disclosure, the token may be issued (generated) corresponding to theelectronic device 1902. For example, a first token may be included in the first electronic device while a second token is included in the second electronic device, and the first and second tokens may be different from each other.

According to an embodiment of the present disclosure, the token may be activated based on an authentication operation (e.g., ID&V). For example, the token may be stored in theelectronic device 1902 and activated based on the authentication operation. The authentication operation may include, for example, an identification. The identification may be conducted by, for example, a financial server and through various methods.

According to an embodiment of the present disclosure, thepayment server 1904 may transfer the card-related information to the security service management server included in thepayment server 1904. The security service management server may be included and internally operate in, for example, thepayment server 1904 or may operate separately from thepayment server 1904. For example, the security service management server may be included in another device (e.g., an external device) different from thepayment server 1904, and may be functionally connected to thepayment server 1904 to transmit or receive the card-related information.

According to an embodiment of the present disclosure, the security service management server may transfer the card-related information and/or information (e.g., device information or user information) related to theelectronic device 1902 to thetoken server 1906. According to an embodiment of the present disclosure, thetoken server 1906 may perform an authentication operation based on the information received from thepayment server 1904. Thetoken server 1906 may perform an authentication operation, for example, based on the card-related information and/or the information related to theelectronic device 1902.

According to an embodiment of the present disclosure, thetoken server 1906 may transfer a result (e.g., success or failure) of the authentication operation to the security service management server included in thepayment server 1904.

According to an embodiment of the present disclosure, the security service management server may issue (generate) a token based on the card-related information and/or the information related to theelectronic device 1902.

According to an embodiment of the present disclosure, the security service management server may store the token in a security area (e.g., a security module) included in theelectronic device 1902. For example, the security service management server may have an authority (e.g., security module access authority) for access to the security area of theelectronic device 1902. Further, the security service management server may store the token in the security area of theelectronic device 1902, using the access authority. Further, the token may be transferred from the security service managing server to theelectronic device 1902.

According to an embodiment of the present disclosure, theelectronic device 1902 may perform an authentication operation (e.g., ID&V). The authentication operation, for example, an identification, may be performed using the payment application.

According to an embodiment of the present disclosure, theelectronic device 1902 may perform the card registration and/or the identification when performing the payment function. For example, theelectronic device 1902 may perform the card registration and/or the identification in order to perform the payment function. For example, the card registration and the identification may refer to a standby (preparation) state for the payment function.

According to an embodiment of the present disclosure, theelectronic device 1902, thepayment server 1904, and thetoken server 1906 may share information associated with the card registration and the identification. For example, theelectronic device 1902, thepayment server 1904, and thetoken server 1906 may share at least one type of information among PAN, valid term, CVV, device information, and user information.

According to an embodiment of the present disclosure, a token associated with the token issuance operation may be issued (generated) when payment is performed using the payment function.

According to an embodiment of the present disclosure, the payment application included in theelectronic device 1902 may perform user authentication in order to perform the payment function. For example, the user authentication may include secret code authentication, pattern authentication, or biometric information (e.g., fingerprint or iris) authentication.

According to an embodiment of the present disclosure, when the user authentication is successful (e.g., authentication completion), the payment application may perform the token issuance operation with respect to thepayment server 1904. The token issuance operation may include, for example, a token request.

According to an embodiment of the present disclosure, based on the token request, thepayment server 1904 may transfer card information (e.g., card Identifier) and/or user information to thetoken server 1906. The information related to theelectronic device 1902 may include, for example, information on a device having requested the token issuance operation.

According to an embodiment of the present disclosure, thetoken server 1906 may issue (generate) a token based on the information received from thepayment server 1904.

According to an embodiment of the present disclosure, theelectronic device 1902 may store, in the general memory (e.g., memory included in the REE), the token received from thepayment server 1904.

According to an embodiment of the present disclosure, theelectronic device 1902 may not store, in the storage area (e.g., memory) included in theelectronic device 1902, the token received from thepayment server 1904. For example, theelectronic device 1902 may use the token in the payment function instead of storing the token in the storage area.

According to an embodiment of the present disclosure, the storage area of the token may be changed based on a payment method (e.g., OTP or call center) performed by theelectronic device 1902. For example, the token may be stored in the security module or the TEE when the payment method is OTP, and may not be stored in theelectronic device 1902 when the payment method is call center.

According to an embodiment of the present disclosure, the token may include use time or valid time. For example, use of the token may be restricted when a certain time (e.g., three hours or one day) has passed from the issuance (generation) of the token.

According to an embodiment of the present disclosure, the token may include card information. For example, the token may include disposable card information (OTC, one time card).

FIG. 20 illustrates a signal flow diagram illustrating a process of registering a card relating to a user account in a payment system according to various embodiments of the present disclosure.

Referring to FIG. 20, the payment system may include an electronic device (e.g., the electronic device 710), a payment server (e.g., the payment server 720), or a token server (e.g., the token server 730). Theelectronic device 710 may include, for example, a payment application and/or a payment manager.

Inoperation 2001, theelectronic device 710 may receive a user account (e.g., a user identifier) through a payment application and transmit the received user account to thepayment server 720. For example, the user identifier may include an ID and password previously stored in thepayment server 720. As another example, the user identifier may include at least one of the user’s fingerprint and iris.

According to an embodiment of the present disclosure, when a user attempts to initially register a card in theelectronic device 710, theelectronic device 710 may transmit an input user account to thepayment server 720. For example, the attempt of the initial card registration may refer to an attempt of registration of a card in theelectronic device 710 in a state where no card has been stored therein. For example, when there is no card registered in a payment application (e.g., Samsung Pay™), theelectronic device 710 may display animage 1603 as shown inscreen 1601 of FIG. 16A. For example, theimage 1603 may include amessage 1603 reading “No card has been registered in the payment application yet. Please tap theimage 1603 in order to register a new card”. When theimage 1603 is tapped by the user, theelectronic device 710 may determine that the user is attempting to register a new card, and may transmit an input user account to thepayment server 720.

Inoperation 2003, thepayment server 720 may identify at least one card identifier (e.g., card reference ID) associated with the user account. For example, the card identifier may be an identifier of a card previously registered in thepayment server 720 by the user, using another electronic device.

According to an embodiment of the present disclosure, thepayment server 720 may receive a user account from theelectronic device 710 and identity all card identifiers corresponding to the received user account in a database. For example, the database may store a list of one or more card identifiers for each user account.

Inoperation 2005, thepayment server 720 may request thetoken server 730 to provide information of at least one card corresponding to at least one identified card identifier. For example, the card information may include at least one among a card issuance company, a card name, a PAN, a card expiration date, a CVV, an actual card image, and a card reference ID.

According to an embodiment of the present disclosure, thepayment server 720 may generate a card information request message including at least one identified card identifier and transmit the generated card information request message to thetoken server 730.

Inoperation 2007, thetoken server 730 may transmit information of at least one card associated with at least one card identifier to thepayment server 720, as a response to the card information request. According to an embodiment of the present disclosure, thetoken server 730 may receive the card information request message, and identify, in the database, information of at least one card corresponding to at least one card identifier included in the received card information request message. Thetoken server 730 may generate a card information response message including the identified information of the at least one card and transmit the generated card information response message to thepayment server 720.

Inoperation 2009, thepayment server 720 may transmit information of at least one card associated with the user account to theelectronic device 710. According to an embodiment of the present disclosure, thepayment server 720 may receive the card information response message from thetoken server 730 and transmit the received card information response message to theelectronic device 710.

Inoperation 2011, theelectronic device 710 may display information of at least one card associated with the user account.

According to an embodiment of the present disclosure, theelectronic device 710 may receive and store the card information response message from thepayment server 720, and display information of at least one card included in the stored card information response message through the payment application.

For example, theelectronic device 710 may display a plurality of overlappingcard images 1607 included in multiple pieces of card information as shown in thescreen 1605 of FIG. 16A. For example, in order to express that a plurality of cards have not been registered yet, theelectronic device 710 may display a plurality of card images in a particular color (e.g., gray color).

For example, when onecard image 1609 is selected from a plurality ofcard images 1607 by a user, theelectronic device 710 may display card information associated with the selected card image. For example, as shown in thescreen 1611 of FIG. 16B, theelectronic device 710 may display related card information on the selectedcard image 1613. As another example, as shown in thescreen 1621 of FIG. 16C, theelectronic device 710 may display aparticular window 1625 including related card information, separately from the selectedcard image 1623.

Inoperation 2013, theelectronic device 710 may perform a card registration process, using the displayed card information.

According to an embodiment of the present disclosure, when the user selects a card to be registered, theelectronic device 710 may proceed with a card registration procedure, based on card information associated with the selected card. For example, when the card information does not include all information required for card registration, theelectronic device 710 may perform a card registration process after manually receiving corresponding information from a user through the payment application. As another example, when the card information includes all information required for card registration, theelectronic device 710 may automatically perform a card registration process based on the card information.

For example, as shown in thescreen 1611 of FIG. 16B, when thecard image 1613 has been tapped by the user, theelectronic device 710 may determine a card corresponding to thecard image 1613 as the card to be registered, and may perform a card registration process based on card information corresponding to thecard image 1613. As another example, as shown in thescreen 1621 of FIG. 16C, when thecard registration menu 1627 has been tapped by the user, theelectronic device 710 may determine a card corresponding to thecard image 1623 as the card to be registered, and may perform a card registration process based on card information corresponding to thecard image 1623.

The card registration process inoperation 2013 will be described below with reference to FIGS. 23 to 25.

According to an embodiment of the present disclosure, thepayment server 720 may store card information at the time of initial card registration. In this event, without requesting the card information from thetoken server 730, thepayment server 720 may identify information of at least one card associated with the user account in the stored card information and transmit the identified information to theelectronic device 710.

According to an embodiment of the present disclosure, a plurality of card identifiers may be associated with a plurality of different token servers. In this instance, thepayment server 720 may request card information from each token server and may receive card information from the plurality of token servers. Thepayment server 720 may integrate the received card information and transmit the integrated information to theelectronic device 710.

According to an embodiment of the present disclosure, thetoken server 730 may directly transmit information of at least one card to theelectronic device 710 without passing through thepayment server 720.

According to an embodiment of the present disclosure, thetoken server 730 may temporarily store the information of the at least one card in thepayment server 720, and thepayment server 720 may delete the temporarily stored information of the at least one card after transmitting the information.

Through the operation described above, theelectronic device 710 can simplify the card registration process of the user by displaying card information corresponding to a card already registered in another electronic device. Thepayment server 720 may acquire card information corresponding to the card registered in another electronic device from thetoken server 730 and transmit the acquired information to theelectronic device 710, which can simplify the card registration process of the user.

FIG. 21 is a flowchart illustrating a process of registering a card relating to a user account by an electronic device according to various embodiments of the present disclosure. For example, the electronic device may be theelectronic device 710 illustrated in FIG. 7.

Referring to FIG. 21, inoperation 2101, the electronic device 710 (e.g., processor 210) may receive an input of a user account (e.g., a user identifier). For example, theelectronic device 710 may receive a user account input through a payment application (e.g., Samsung Pay™).

Inoperation 2103, theprocessor 210 may transmit the input user account to the payment server (e.g., the payment server 720).

According to an embodiment of the present disclosure, when a user attempts to initially register a card in theelectronic device 710, theelectronic device 710 may transmit an input user account to thepayment server 720 in order to receive card information corresponding to a card previously registered in another electronic device. For example, the card information may include at least one among a card issuance company, a card name, a PAN, a card expiration date, a CVV, an actual card image, and a card reference ID.

Inoperation 2105, theprocessor 210 may determine whether information of at least one card associated with the user account is received from thepayment server 720. For example, the information of at least one card associated with the user account may be information of at least one card corresponding to at least one card identifier associated with the user account.

As a result of the determination, when the card information is received, theprocessor 210 proceeds tooperation 2107. Otherwise, theprocessor 210 may repeatedly performoperation 2105.

Inoperation 2107, theprocessor 210 may display the card information. According to an embodiment of the present disclosure theprocessor 210 may store card information of at least one card and display at least one card image included in the stored card information of the at least one card on a display (e.g., display 160). When one card image is selected from the at least one displayed card images by a user, theprocessor 210 may display card information corresponding to the selected card image.

For example, theprocessor 210 may display card information on a card image. For example, theprocessor 210 may display card information in a window separate from the card image.

Inoperation 2109, theprocessor 210 may determine whether a card to be registered is selected. For example, when a card image including card information is touched (e.g., tapping) by a user, theprocessor 210 may determine that a card corresponding to the card information has been selected as the card to be registered. As another example, when a card registration menu displayed together with the displayed card information is touched (e.g., tapping) by a user, theprocessor 210 may determine that a card corresponding to the displayed card information has been selected as the card to be registered.

As a result of the determination, when a card to be registered is selected, theprocessor 210 proceeds tooperation 2111. Otherwise, theprocessor 210 may repeatedly performoperation 2109.

Inoperation 2111, theprocessor 210 may perform a card registration process, based on card information corresponding to the selected card. According to an embodiment of the present disclosure, when the user selects a card to be registered, theprocessor 210 may proceed with a card registration procedure, based on card information associated with the selected card.

For example, when the card information does not include all information required for card registration, theprocessor 210 may perform a card registration process after manually receiving corresponding information from a user through the payment application. As another example, when the card information includes all information required for card registration, theprocessor 210 may automatically perform a card registration process based on the card information.

Inoperation 2113, theprocessor 210 may determine whether a card to be registered is additionally selected. According to an embodiment of the present disclosure, when registration of the selected card is completed, theprocessor 210 may display at least one card image corresponding to at least one card to be registered excluding the already-registered cards. According to an embodiment of the present disclosure, when one card image is selected from at least one displayed card images by a user, theprocessor 210 may display card information corresponding to the selected card image.

According to an embodiment of the present disclosure, when a card image including card information is touched (e.g., tapping) by a user, theprocessor 210 may determine that a card corresponding to the card information has been additionally selected as the card to be registered.

According to an embodiment of the present disclosure, when a card registration menu displayed together with the displayed card information is touched (e.g., tapping) by a user, theprocessor 210 may determine that a card corresponding to the displayed card information has been additionally selected as the card to be registered.

As a result of the determination, when a card to be registered is additionally selected, theprocessor 210 proceeds tooperation 2115. Otherwise, theprocessor 210 may terminate the card registration process.

Inoperation 2115, theprocessor 210 may perform a card registration process, based on card information corresponding to the additionally selected card.

According to an embodiment of the present disclosure, when the user additionally selects a card to be registered, theprocessor 210 may additionally perform a card registration process based on card information associated with the additionally selected card.

According to an embodiment of the present disclosure, when the additional card registration process has been completed, theprocessor 210 may proceed tooperation 2113 and determine whether a card to be registered is additionally selected.

FIG. 22 is a flowchart illustrating a process of registering a card relating to a user account by a payment server according to various embodiments of the present disclosure. For example, the payment server may be thepayment server 720 illustrated in FIG. 7.

Referring to FIG. 22, inoperation 2201, thepayment server 720 may determine whether a user account (e.g., a user identifier) is received from an electronic device (e.g., the electronic device 710). As a result of the determination, when a user account is received, thepayment server 720 proceeds tooperation 2203. Otherwise, the payment server may repeatedly performoperation 2201.

Inoperation 2203, thepayment server 720 may identify at least one card identifier (e.g., a card reference ID) associated with the user account.

According to an embodiment of the present disclosure, thepayment server 720 may detect at least one card identifier corresponding to the user account in a database.

Inoperation 2205, thepayment server 720 may request a token server (e.g., the token server 730) to provide information of at least one card corresponding to at least one identified card identifier. According to an embodiment of the present disclosure, thepayment server 720 may generate a card information request message including at least one identified card identifier and transmit the generated card information request message to thetoken server 730.

Inoperation 2207, thepayment server 720 may determine whether information of at least one card corresponding to at least one identifier is received from thetoken server 730. According to an embodiment of the present disclosure, thepayment server 720 may receive a card information response message including information of at least one card from thetoken server 730.

As a result of the determination, when information of at least one card is received, thepayment server 720 proceeds tooperation 2209. Otherwise, the payment server may repeatedly performoperation 2207.

Inoperation 2209, thepayment server 720 may transmit the received information of at least one card to theelectronic device 710.

According to an embodiment of the present disclosure, thepayment server 720 may transmit a card information response message including information of at least one card to theelectronic device 710.

Inoperation 2211, thepayment server 720 may determine whether there is a request for card registration from theelectronic device 710. For example, when receiving a card registration request message (e.g., POST/tokens) from theelectronic device 710, thepayment server 720 may determine that the card registration has been requested. For example, the card registration request message may include at least a part of card information.

As a result of the determination, when there is a request for card registration, thepayment server 720 proceeds tooperation 2213. Otherwise, thepayment server 720 may repeatedly performoperation 2211.

Inoperation 2213, thepayment server 720 may perform a card registration process, based on information included in the card registration request message. For example, thepayment server 720 may perform a card registration process in cooperation with theelectronic device 710 and thetoken server 730.

Inoperation 2215, thepayment server 720 may determine whether there is a request for additional card registration from theelectronic device 710. For example, when additionally receiving a card registration request message (e.g., POST/tokens) from theelectronic device 710, thepayment server 720 may determine that the card registration has been additionally requested.

As a result of the determination, when card registration is additionally requested, thepayment server 720 proceeds tooperation 2217. Otherwise, the payment server may terminate the card registration process.

Inoperation 2217, thepayment server 720 may additionally perform a card registration process, based on information included in the card registration request message.

FIG. 23 is a flowchart illustrating a process of registering a card relating to a user account by a token server according to various embodiments of the present disclosure. For example, the token server may be thetoken server 730 illustrated in FIG. 7.

Referring to FIG. 23, inoperation 2301, thetoken server 730 may determine whether a card information request is received from a payment server (e.g., the payment server 720).

According to an embodiment of the present disclosure, thetoken server 730 may receive a card information request message including at least one card identifier.

As a result of the determination, when a card information request is received, thetoken server 730 proceeds tooperation 2303. Otherwise, the token server may repeatedly performoperation 2301.

Inoperation 2303, thetoken server 730 may identify information of at least one card corresponding to at least one card identifier.

According to an embodiment of the present disclosure, thetoken server 730 may detect, in the database, information of at least one card corresponding to at least one card identifier included in the card information request message.

Inoperation 2305, thetoken server 730 may transmit the detected information of at least one card to thepayment server 720.

According to an embodiment of the present disclosure, thetoken server 730 may generate a card information response message including the identified information of the at least one card and transmit the generated card information response message to thepayment server 720.

FIGS. 24 to 26 are signal flow diagrams illustrating a process of registering a card in a payment system according to various embodiments of the present disclosure.

The signal flow diagram of FIG. 24 illustrates a process of registering a card without an identification process of an electronic device (e.g., the electronic device 710).

Referring to FIG. 24, the solid line indicates a request (e.g., request or call) command and the dotted line indicates a response (e.g., response or return) command.

According to an embodiment of the present disclosure, the payment system may include theelectronic device 710, thepayment server 720, and thetoken server 730. Theelectronic device 710 may include, for example, a payment application and/or a payment manager.

Inoperation 2401, the payment application of theelectronic device 710 may transmit a command requesting a token for card registration to the payment manager of theelectronic device 710.

Inoperation 2403, the payment manager may transfer information corresponding to the command requesting a token to the payment server. The information may include, for example, a certain command (e.g., POST/tokens). The information corresponding to the command requesting a token may be information associated with the time point at which the command request input is received.

For example, the POST/tokens may be used when a token is requested after a user’s approval (e.g., accept) of the card registration in the operation of performing card registration to thepayment server 720 by the payment manager. The parameters of POST/ tokens may include, for example, at least one among a card reference ID, contract condition approval (e.g., T&C acceptance), and timestamp. The timestamp may include, for example, a time point at which a command approving the card registration is received from the user.

Inoperation 2405, thepayment server 720 may transmit a command allowing card registration to thetoken server 730. For example, thepayment server 720 may transmit information (e.g., T&C acceptance and/or timestamp) associated with payment to thetoken server 730. As another example, thepayment server 720 may transmit information relating to payment to thetoken server 730 and request thetoken server 730 to configure a token.

Inoperation 2407, thetoken server 730 may transmit the information associated with a token to be generated, to thepayment server 720. For example, the information associated with the token may include a random value (e.g., token reference) generated by thetoken server 730 in order to distinguish the token. As another example, the information relating to the token may include a token ID. According to an embodiment of the present disclosure, the token reference and the token ID may be distinguished from each other.

Inoperation 2409, based on the token reference received from thetoken server 730, thepayment server 720 may allocate a logical or physical space for the token reference in thepayment server 720. For example, thepayment server 720 may generate an ID (e.g., resource ID) identifying the logical or physical space. The resource ID may include an identifier of the registered (enrolled) resource, which may be configured in the form of uniform resource locator (URL). Further, the resource ID may include, for example, reference information including information related to a token ID and may include an address at which the token ID is stored in thepayment server 720.

Further, as a response to a request (e.g., POST/tokens) from the payment manager, thepayment server 720 may transmit a token response to the payment manager. For example, the token response may include at least one among a resource ID, a token status, and a token ID. For example, the token status may include, for example, a state (e.g., active, suspended, resume, or dispose) of the token.

Inoperation 2411, the payment manager may transmit at least a part of the information received from thepayment server 720 to the payment application. For example, the information transmitted to the payment application may include a token ID.

Inoperation 2413, thetoken server 730 may transfer a notification message (e.g., POST/notification) requiring progress of issuance of a token to thepayment server 720. For example, the notification message may include at least one among a token reference, a token ID, a token value, and a key for generation of a cryptogram. Further, the notification message may include an indication (e.g., op:Provision) which implies that the message is a message for issuance of a token.

Inoperation 2415, thepayment server 720 may transmit at least a part of information included in the notification message received from thetoken server 730 to the payment manager. For example, the message transmitted to the payment manager may include at least one among a token ID, a resource ID, and an indication for issuance of a token.

Inoperation 2417, after receiving the message from thepayment server 720, the payment manager may transmit a token value request message (e.g., GET/token/{id}) requesting a token value to thepayment server 720. For example, the token value request message may include a resource ID.

Inoperation 2419, as a response to the token value request message (e.g., GET/token/{id}), thepayment server 720 may transmit a token value response message to the payment manager. For example, the token value response message may include at least one among a token ID, a token state, a token value, and a key.

According to an embodiment of the present disclosure, at least one among the token ID, the token state, the token value, and the key may be encrypted.

Inoperation 2421, the payment manager may store a token value response message received from thepayment server 720 in a trust zone. The trust zone may be included in, for example, the TEE. The payment manager may store, for example, at least one of the token ID, the token state, the token value, and the key in a security application included in theelectronic device 710.

Inoperation 2423, the payment manager may transmit a result of storage of the token value response message (e.g., token ID, token value, and key) received from thepayment server 720 in the trust zone, to the payment application. For example, the payment manager may transmit a command (e.g., active) associated with token activation to the payment application. For example, the payment manager may transmit, to the payment application, information reporting that the state of the card related to the payment function is an active state.

Inoperation 2425, the payment application may change the state of the PAN recognized by theelectronic device 710. For example, the payment application may change (e.g., enable) the state of the PAN to enable payment using the PAN.

Inoperation 2427, the payment application may transmit the changed state of the PAN to the payment manager. For example, the payment application may transmit information (e.g., PAN enrolled) indicating registration of the PAN to the payment manager.

Inoperation 2429, the payment manager may transmit the changed state of the PAN to thepayment server 720. For example, the payment manager may transfer, to thepayment server 720, information that the PAN is in a payable state (e.g., enable), using a certain command (e.g., POST/reports). The payment manager may perform, for example, state synchronization with thepayment server 720.

Inoperation 2431, thepayment server 720 may transmit the changed state of the PAN to thetoken server 730. For example, thepayment server 720 may transmit a response message (e.g., an acknowledgement or an ack PAN enrolled (PAN registration ACK)) to thetoken server 730.

According to an embodiment of the present disclosure, the payment communication system may omit at least a part ofoperations 2401 to 2431. For example, inoperation 2407, when information associated with the token is received from thetoken server 730, thepayment server 720 may directly performoperation 2419 without performingoperations 2409 to 2417, which can reduce a time required for registration of a new card.

The signal flow diagrams of FIGS. 25 and 26 illustrate a process of registering a card including an identification process of an electronic device (e.g., the electronic device 710).

Referring to FIGS. 25 and 26, the solid line may indicate a request (e.g., request or call) command and the dotted line may indicate a response (e.g., response or return) command.

According to an embodiment of the present disclosure, the payment system may include theelectronic device 710, thepayment server 720, and thetoken server 730. Theelectronic device 710 may include, for example, a payment application and/or a payment manager.

The signal flow diagram of FIG. 25 illustrates a signal flow of a token issuance operation using OTP in an identification process of an electronic device.

Inoperation 2501, the payment application of theelectronic device 710 may transmit a command requesting a token for card registration to the payment manager of theelectronic device 710.

Inoperation 2503, the payment manager may transfer information corresponding to the command requesting a token to the payment server. The information may include, for example, a certain command (e.g., POST/tokens). The information corresponding to the command requesting a token may be information associated with the time point at which the command request input is received.

For example, the POST/tokens may be used when a token is requested after user’s approval (e.g., accept) of the card registration in the operation of performing card registration to thepayment server 720 by the payment manager. The parameters of POST/ tokens may include, for example, at least one among a card reference ID, contract condition approval (e.g., T&C acceptance), timestamp, and billing address. The timestamp may include, for example, a time point at which a command approving the card registration is received from the user.

Inoperation 2505, thepayment server 720 may transmit a command allowing card registration to thetoken server 730. For example, thepayment server 720 may transmit information (e.g., T&C acceptance and/or timestamp) associated with payment to thetoken server 730. As another example, thepayment server 720 may transmit information relating to payment to thetoken server 730 and request thetoken server 730 to configure a token.

Inoperation 2507, thetoken server 730 may transfer the information associated with a token to be generated, to the payment server. For example, the information relating to a token may include a random value (e.g., token reference) generated by the token server in order to distinguish the token. As another example, the information relating to the token may include a token ID. For example, the token reference and the token ID may be distinguished from each other. As another example, the information relating to the token may include information relating to an identification item (e.g., option).

For example, the token ID may include index information related to a token. For example, the identification item may include at least one method among call, SMS, OTP, and App-to-App method. The identification item may be determined by, for example, thetoken server 730, and the token server may determine at least one identification item. The determining of at least one identification item may include, for example, at least two methods related to authentication. As another example, the determining of at least one identification item may be performed based on a policy.

At least two identification items or methods may be used according to an embodiment of the present disclosure. For example, an additional identification item or method may be used as well as the OTP method described above as an identification item or method. A plurality of identification items or methods may be used, for example, simultaneously or sequentially in the payment system.

When using at least two identification items or methods according to an embodiment of the present disclosure, a user may optionally select at least one item or method among the at least two identification items or methods. For example, when thetoken server 730 does not limit the identification item, the user may use at least one among the identification items available in theelectronic device 710.

Inoperation 2509, based on the token reference received from thetoken server 730, thepayment server 720 may allocate a logical or physical space for the token reference in thepayment server 720. For example, thepayment server 720 may generate an ID (e.g., resource ID) identifying the logical or physical space. The resource ID may include an identifier of the registered (enrollment) resource, which may be configured in the form of URL. Further, the resource ID may include, for example, reference information including information related to a token ID and may include an address at which the token ID is stored in thepayment server 720.

According to an embodiment of the present disclosure, based on the information received from thetoken server 730, thepayment server 720 may transfer at least one among a token ID, a resource ID, a token state, and an identification item to the payment manager. For example, in response to the request (e.g., POST/tokens) from the payment manager, thepayment server 720 may transfer at least one of the token ID, the resource ID, the token state, and the identification item. The at least one of the token ID, the resource ID, the token state, and the identification item may be, for example, transmitted after being encrypted. Thepayment server 720 may include a status or identification method in the transmitted at least one of the token ID, the resource ID, the token state, and the identification item. The status may include, for example, a state (e.g., active, suspended, resume, or dispose) of the token. The identification method may include, for example, an activation method for the token, and the type of the identification method may include, for example, at least one among CODE, CALL, APP, and LINK.

Inoperation 2511, the payment manager may transmit the information (e.g., the token ID, the resource ID, the token state, or the identification item) received from thepayment server 720 to the payment application. For example, the payment manager may transmit a command (e.g., pending) associated with token to the payment application. For example, the payment manager may transfer, to the payment application, information reporting that the state of the card related to the payment function is a standby (pending) state.

According to an embodiment of the present disclosure, the payment manager may transfer the identification item received from the token requester server to the payment application to provide an interface so that a user can select the identification item. The payment manager may provide, for example, an interface to enable the token requester server included in thepayment server 720 to use at least one item or method as the identification item. Theelectronic device 710 may perform the identification using, for example, a plurality of identification items or methods.

Inoperation 2513, the payment application may use an OTP method as the identification item or method. For example, the payment application may receive the OTP method as the identification item or method and may transmit the received OTP method to the payment manager.

In operation 2515, the payment manager may transmit the received or acquired identification item or method to thepayment server 720. For example, the payment manager may transmit the identification item or method to thepayment server 720, using a certain command (e.g., POST/tokens or POST/tokens, OTP). Further, the payment manager may transmit, for example, a card reference ID and the identification method to thepayment server 720. For example, the identification method may include the OTP method received from the user.

Inoperation 2517, thepayment server 720 may transmit the received or acquired identification item or method to thetoken server 730. For example, thepayment server 720 may transfer the OTP method, which is an identification item or method received or acquired from the user, to thetoken server 730.

Inoperation 2519, thetoken server 730 may generate an OTP corresponding to the OTP method received from thepayment server 720. For example, thetoken server 730 may generate the OTP based on a pre-configured rule or algorithm. The OTP may include, for example, numbers, letters, or certain information (e.g., pattern or picture).

According to an embodiment of the present disclosure, thetoken server 730 may transmit information (e.g., OTP option) on the OTP to thepayment server 720.

Inoperation 2521, thepayment server 720 may transmit information (e.g., OTP option) on the OTP to the payment manager. The information on the OTP may include, for example, the length of the OTP. The length of the OTP may include, for example, digits used in the OTP method. The digits may include, for example, four digits or six digits.

Inoperation 2523, the payment manager may transmit the information (e.g., OTP option) on the OTP to the payment application. The information on the OTP may include, for example, format information of the OTP.

Inoperation 2525, thetoken server 730 may transmit the numerical value or value of the OTP to the payment application. For example, thetoken server 730 may transmit an OTP numerical value or value through a communication channel. The communication channel may include, for example, an SMS or e-mail.

Inoperation 2527, the payment application may provide an interface displaying information relating to the OTP value or numerical value. For example, the payment application may provide the OTP value or numerical value, unit numbers, letters, or certain information (e.g., pattern or picture).

According to an embodiment of the present disclosure, the payment application may acquire data, from the user, using an interface displaying information relating to the OTP value or numerical value. For example, the payment application may acquire the OTP value or numerical value through an external device functionally connected to the payment application or a user input (e.g., touch). The payment application may change the interface displaying the information relating to the OTP value or numerical value, based on the digits received from thepayment server 720.

Inoperation 2529, the payment application may transmit the OTP value or numerical value acquired through a user input or from an external device to the payment manager. For example, the OTP value or numerical value acquired through a user input or from an external device may be used in a user authentication operation.

In operation 2531, the payment application may transmit the OTP value or numerical value acquired through a user input or from an external device to thepayment server 720. The payment manager may transfer the OTP value or numerical value acquired from external device or a user input to thepayment server 720, using a certain command (e.g., POST/tokens{OTP:value=data).

Inoperation 2533, thepayment server 720 may transmit the OTP value or numerical value acquired through a user input or from an external device to thetoken server 730.

Inoperation 2535, thetoken server 730 may determine the validity of the OTP value or numerical value received from thepayment server 720. For example, thetoken server 730 may determine the validity of the identification item (method) acquired from the user and information (data) associated with the identification item. For example, thetoken server 730 may determine whether the identification items and data generated by thetoken server 730 are identical or similar to information (e.g., OTP method and the OTP value or numerical value) received from thepayment server 720. For example, when the identification items and data generated by thetoken server 730 are identical or similar to information received from thepayment server 720, thetoken server 730 may determine that the identification items and data generated by the token server are valid.

According to an embodiment of the present disclosure, when it is determined that the identification items and data are valid, thetoken server 730 may change the token suspension (token pending) indicating the state of the token. For example, thetoken server 730 may change the state of the token suspension to an activation state.

According to an embodiment of the present disclosure, thetoken server 730 may transmit an authentication result including a result of the determination to thepayment server 720.

In operation 2537, when receiving the authentication result, thepayment server 720 may transmit information associated with the authentication result to the payment manager. For example, the information associated with the authentication result may include at least one among a resource ID, status, and a token ID.

Inoperation 2539, the payment manager may transmit a token ID to the payment application.

Inoperation 2541, thetoken server 730 may transfer a notification message (e.g., POST/notification) requiring progress of issuance of a token to thepayment server 720. For example, the notification message may include at least one among a token reference, a token ID, a token value, and a key for generation of a cryptogram. Further, the notification message may include an indication (e.g., op:Provision) which implies that the message is a message for issuance of a token.

Inoperation 2543, thepayment server 720 may transmit at least a part of information included in the notification message received from thetoken server 730 to the payment manager. For example, the message transmitted to the payment manager may include at least one among a token ID, a resource ID, and an indication for issuance of a token.

Inoperation 2545, after receiving the message from thepayment server 720, the payment manager may transmit a token value request message (e.g., GET/token/{id}) requesting a token value to thepayment server 720. For example, the token value request message may include a resource ID.

Inoperation 2547, as a response to the token value request message (e.g., GET/token/{id}), thepayment server 720 may transmit a token value response message to the payment manager. For example, the token value response message may include at least one among a token ID, a token state, a token value, and a key. The at least one of the token ID, the token state, the token value, and the key may be, for example, encrypted.

Inoperation 2549, the payment manager may store a token value response message received from thepayment server 720 in a trust zone. The trust zone may be included in, for example, the TEE. The payment manager may store, for example, at least one of the token ID, the token state, the token value, and the key in a security application included in theelectronic device 710.

Inoperation 2551, the payment manager may transmit a result of storage of the token value response message (e.g., token ID, token value, and key) received from thepayment server 720 in the trust zone, to the payment application. For example, the payment manager may transmit a command (e.g., active) associated with token activation to the payment application. For example, the payment manager may transmit, to the payment application, information reporting that the state of the card related to the payment function is an active state.

Inoperation 2553, the payment application may change the state of the PAN recognized by theelectronic device 710. For example, the payment application may change (e.g., enable) the state of the PAN to enable payment using the PAN.

Inoperation 2555, the payment application may transmit the changed state of the PAN to the payment manager. For example, the payment application may transmit information (e.g., PAN enrolled) indicating registration of the PAN to the payment manager.

Inoperation 2557, the payment manager may transmit the changed state of the PAN to thepayment server 720. For example, the payment manager may transfer, to thepayment server 720, information that the PAN is in a payable state (e.g., enable), using a certain command (e.g., POST/reports). The payment manager may perform, for example, state synchronization with thepayment server 720.

Inoperation 2559, thepayment server 720 may transmit the changed state of the PAN to thetoken server 730. For example, thepayment server 720 may transmit a response messages (e.g., an acknowledgement or an ack PAN enrolled (PAN registration ACK)) to thetoken server 730.

The signal flow diagram of FIG. 26 illustrates a signal flow of a token issuance operation using a call center in an identification process of theelectronic device 710.

Inoperation 2601, the payment application of theelectronic device 710 may transmit a command requesting a token for card registration to the payment manager of theelectronic device 710.

Inoperation 2603, the payment manager may transfer information corresponding to the command requesting a token to the payment server. The information may include, for example, a certain command (e.g., POST/tokens). For example, the information corresponding to the command requesting a token may be information associated with the time point at which the command request input is received.

For example, the POST/tokens may be used when a token is requested after a user’s approval (e.g., accept) of the card registration in the operation of performing card registration to thepayment server 720 by the payment manager. The parameters of POST/ tokens may include, for example, at least one among a card reference ID, contract condition approval (e.g., T&C acceptance), timestamp, and billing address. The timestamp may include, for example, a time point at which a command approving the card registration is received from the user.

Inoperation 2605, thepayment server 720 may transmit a command allowing card registration to thetoken server 730. For example, thepayment server 720 may transmit information (e.g., T&C acceptance and/or timestamp) associated with payment to thetoken server 730. As another example, thepayment server 720 may transmit information relating to payment to thetoken server 730 and request thetoken server 730 to configure a token.

Inoperation 2607, thetoken server 730 may transfer the information associated with a token to be generated, to the payment server. For example, the information relating to a token may include a random value (e.g., token reference) generated by the token server in order to distinguish the token. As another example, the information relating to the token may include a token ID. For example, the token reference and the token ID may be distinguished from each other. As another example, the information relating to the token may include information relating to an identification item (e.g., option).

For example, the token ID may include index information related to a token. For example, the identification item may include at least one method among call, SMS, OTP, and App-to-App method. The identification item may be determined by, for example, thetoken server 730, and the token server may determine at least one identification item. The determining of at least one identification item may include, for example, at least two methods related to authentication. As another example, the determining of at least one identification item may be performed based on the policy.

At least two identification items or methods may be used according to an embodiment of the present disclosure. For example, an additional identification item or method may be used as well as the OTP method described above as an identification item or method. A plurality of identification items or methods may be used, for example, simultaneously or sequentially in the payment system.

When using at least two identification items or methods according to an embodiment of the present disclosure, a user may optionally select at least one item or method among the at least two identification items or methods. For example, when thetoken server 730 does not limit the identification item, the user may use at least one among the identification items available in theelectronic device 710.

Inoperation 2609, based on the token reference received from thetoken server 730, thepayment server 720 may allocate a logical or physical space for the token reference in thepayment server 720. For example, thepayment server 720 may generate an ID (e.g., resource ID) identifying the logical or physical space. The resource ID may include an identifier of the registered (enrollment) resource, which may be configured in the form of URL. Further, the resource ID may include, for example, reference information including information related to a token ID and may include an address at which the token ID is stored in thepayment server 720.

According to an embodiment of the present disclosure, based on the information received from thetoken server 730, thepayment server 720 may transfer at least one among a token ID, a resource ID, a token state, and an identification item to the payment manager. For example, in response to the request (e.g., POST/tokens) from the payment manager, thepayment server 720 may transfer at least one of the token ID, the resource ID, the token state, and the identification item. The at least one of the token ID, the resource ID, the token state, and the identification item may be, for example, transmitted after being encrypted. Thepayment server 720 may include a status or identification method in the transmitted at least one of the token ID, the resource ID, the token state, and the identification item. The status may include, for example, a state (e.g., active, suspended, resume, or dispose) of the token. The identification method may include, for example, an activation method for the token, and the type of the identification method may include, for example, at least one among CODE, CALL, APP, and LINK.

Inoperation 2611, the payment manager may transmit the information (e.g., the token ID, the resource ID, the token state, or the identification item) received from thepayment server 720 to the payment application. For example, the payment manager may transmit a command (e.g., pending) associated with token to the payment application. For example, the payment manager may transfer, to the payment application, information reporting that the state of the card related to the payment function is a standby (pending) state.

According to an embodiment of the present disclosure, the payment manager may transfer the identification item received from the token requester server to the payment application to provide an interface so that a user can select the identification item. The payment manager may provide, for example, an interface to enable the token requester server included in thepayment server 720 to use at least one item or method as the identification item. Theelectronic device 710 may perform the identification using, for example, a plurality of identification items or methods.

Inoperation 2613, the payment application may use a call center method as the identification item or method. For example, the payment application may receive, from the user, the call center method as the identification item or method and may transmit the received call center method to the payment manager.

Inoperation 2615, the payment manager may transmit the received or acquired identification item or method to thepayment server 720. For example, the payment manager may transmit the identification item or method to thepayment server 720, using a certain command (e.g., POST/tokens or tokens, Call). Further, the payment manager may transfer, for example, a card reference ID and the identification method to thepayment server 720. For example, the identification method may include the call center method (e.g., POST/tokens, CALL) received from the user.

Inoperation 2617, thepayment server 720 may transmit the received or acquired identification item or method to thetoken server 730. For example, thepayment server 720 may transmit the call center method, which is an identification item or method received or acquired from the user, to thetoken server 730.

Inoperation 2619, thetoken server 730 may prepare a call connection (counselling call) corresponding to the call center method received from thepayment server 720. For example, thetoken server 730 may use anelectronic device 710 associated with the call center method received from the user and a number (e.g., a phone number) of theelectronic device 710. Thetoken server 730 may receive, for example, theelectronic device 710 or the number of theelectronic device 710 through at least one among the payment application, the payment manager, and thepayment server 720, or may receive it using a payment network.

According to an embodiment of the present disclosure, thetoken server 730 may transmit information associated with the call center method to thepayment server 720. The notification associated with the call center method may include, for example, theelectronic device 710 or the number of theelectronic device 710.

Inoperation 2621, thepayment server 720 may transmit a notification associated with the call center method to the payment manager. The notification associated with the call center method may include, for example, theelectronic device 710 or the number of theelectronic device 710.

Inoperation 2623, the payment manager may transmit a notification associated with the call center method to the payment application. The notification associated with the call center method may include, for example, theelectronic device 710 or the number of theelectronic device 710.

Inoperation 2625, the payment application may provide an interface displaying information relating to the call center method. For example, the payment application may use an application (e.g., a phone application) included in theelectronic device 710 in order to perform the communication connection.

According to an embodiment of the present disclosure, the payment application may perform an authentication operation, using an interface displaying information relating to the call center method from the user. For example, the payment application may perform the authentication operation, using an external device functionally connected to the payment application or a user input (e.g., a touch). Further, the payment application may perform the authentication operation, based on the communication connection. For example, the payment application may transfer, through the communication connection, information that the authentication operation (e.g., ID&V operation) has succeeded or has been completed. The result (e.g., success or completion of authentication) of the authentication operation may be shared through synchronization with, for example, the token server.

Inoperations 2627 to 2631, the payment application may perform a communication connection (e.g., phone connection) associated with the call center method, with at least one of thetoken server 730 or thepayment server 720. For example, at least one among thetoken server 730 and thepayment server 720 may use a communication network (e.g., 2G, 3G, 4G, or LTE communication networks) in order to perform the communication connection.

Inoperation 2627, the payment application may transmit a value acquired through a user input or from an external device during call to the payment manager. In operation 2629, the payment manager may transmit a value acquired through a user input or from an external device during call to thepayment server 720. The payment manager may transfer the value acquired from the external device or through the user input during call to thepayment server 720, using a certain command (e.g., POST/tokens{OTP:value=data}). As another example, the payment manager may transfer a command identifying a result of authentication performed during a call to thepayment server 720, using a certain command (e.g., POST/tokens{Call}).

Inoperation 2631, thepayment server 720 may transmit a message for identification of a result of authentication performed during the call to thetoken server 730. For example, thepayment manager 720 may transmit a value acquired through a user input or from an external device during call to thetoken server 730.

Inoperation 2633, thetoken server 730 may identify the authentication operation for the call center method performed in the payment application. For example, thetoken server 730 may identify the result of the authentication (e.g., the identification operation) through the communication connection with theelectronic device 710.

According to an embodiment of the present disclosure, thetoken server 730 may change the state of the token when the result of the authentication operation is success or authentication completion. For example, thetoken server 730 may change the state of the token to an activation state.

According to an embodiment of the present disclosure, thetoken server 730 may determine the validity of a user input received from thepayment server 720 or a value acquired from an external device. For example, thetoken server 730 may determine the validity of the identification item (method) acquired from the user and information (data) associated with the identification item. For example, thetoken server 730 may determine whether the identification items and data generated by thetoken server 730 are identical or similar to information (e.g., call method and input value) received from thepayment server 720.

According to an embodiment of the present disclosure, thetoken server 730 may identify the result of authentication performed in the call center. For example, thetoken server 730 may determine the validity of the identification item (method) and information (data) associated with the identification item, which have been received from thepayment server 720 based on a result through the call center performed with the user. For example, thetoken server 730 may determine, based on the information received from the call center, whether to transmit data from thetoken server 730 to theelectronic device 710.

According to an embodiment of the present disclosure, when the identification items and data generated by thetoken server 730 are identical or similar to information received from thepayment server 720, thetoken server 730 may determine that the identification items and data generated by the token server are valid. According to various embodiments of the present disclosure, when receiving, from the call center, a result reporting that the identification items and data are valid, thetoken server 730 may determine the identification items and data as valid.

According to an embodiment of the present disclosure, when it is determined that the identification items and data are valid, thetoken server 730 may change the token suspension (token pending) indicating the state of the token. For example, thetoken server 730 may change the state of the token suspension to an activation state.

Inoperation 2639, thetoken server 730 may transfer a notification message (e.g., POST/notification) requiring progress of issuance of a token to thepayment server 720. For example, the notification message may include at least one among a token reference, a token ID, a token value, and a key for generation of a cryptogram. Further, the notification message may include an indication (e.g., op:Provision) which implies that the message is a message for issuance of a token.

Inoperation 2641, thepayment server 720 may transmit at least a part of information included in the notification message received from thetoken server 730 to the payment manager. For example, the message transmitted to the payment manager may include at least one among a token ID, a resource ID, and an indication for issuance of a token.

Inoperation 2643, after receiving the message from thepayment server 720, the payment manager may transmit a token value request message (e.g., GET/token/{id}) requesting a token value to thepayment server 720. For example, the token value request message may include a resource ID.

Inoperation 2645, as a response to the token value request message (e.g., GET/token/{id}), thepayment server 720 may transmit a token value response message to the payment manager. For example, the token value response message may include at least one among a token ID, a token state, a token value, and a key. The at least one of the token ID, the token state, the token value, and the key may be, for example, encrypted.

Inoperation 2647, the payment manager may store a token value response message received from thepayment server 720 in a trust zone. The trust zone may be included in, for example, the TEE. The payment manager may store, for example, at least one of the token ID, the token state, the token value, and the key in a security application included in theelectronic device 710.

Inoperation 2649, the payment manager may transmit a result of storage of the token value response message (e.g., token ID, token value, and key) received from thepayment server 720 in the trust zone, to the payment application. For example, the payment manager may transmit a command (e.g., active) associated with token activation to the payment application. For example, the payment manager may transmit, to the payment application, information reporting that the state of the card related to the payment function is an active state.

Inoperation 2651, the payment application may change the state of the PAN recognized by theelectronic device 710. For example, the payment application may change (e.g., enable) the state of the PAN to enable payment using the PAN.

Inoperation 2653, the payment application may transmit the changed state of the PAN to the payment manager. For example, the payment application may transmit information (e.g., PAN enrolled) indicating registration of the PAN to the payment manager.

Inoperation 2655, the payment manager may transmit the changed state of the PAN to thepayment server 720. For example, the payment manager may transfer, to thepayment server 720, information that the PAN is in a payable state (e.g., enable), using a certain command (e.g., POST/reports). The payment manager may perform, for example, state synchronization with thepayment server 720.

Inoperation 2657, thepayment server 720 may transmit the changed state of the PAN to thetoken server 730. For example, thepayment server 720 may transmit a response messages (e.g., acknowledgement or ack PAN enrolled (PAN registration ACK)) to thetoken server 730.

FIGS. 27 and 28 are signal flow diagrams illustrating a process of registering a card relating to a user account in a payment system according to various embodiments of the present disclosure.

Referring to FIGS. 27 and 28, the payment system may include a first electronic device (e.g., the electronic device 710), a payment server (e.g., the payment server 720), a token server (e.g., the token server 730), and a second electronic device (e.g., the electronic device 750). The firstelectronic device 710 may include, for example, a payment application and/or a payment manager. The secondelectronic device 750 may include, for example, a payment application and/or a payment manager.

According to an embodiment of the present disclosure, the user may use a plurality of electronic devices (e.g., the firstelectronic device 710 and second electronic devices 750). The plurality of electronic devices may be managed and used by a user through an identical user ID. The plurality of electronic devices may have been paired or connected with each other wiredly or wirelessly through BT, BLE, Wi-Fi, ZIGBEE, USB, IEE1394, and the like.

Referring to FIG. 27,operations 2701 to 2711 of FIG. 27 correspond tooperations 2001 to 2011 of FIG. 20, so a detailed description thereof is omitted here, and operations thereafter will be described hereinafter.

Inoperation 2713, the payment application of the firstelectronic device 710 may request thepayment server 720 to provide card information for the secondelectronic device 750. At this time, the firstelectronic device 710 may be connected through communication with or paired wiredly or wirelessly with the secondelectronic device 750. When storing a payment application and a payment manager, the firstelectronic device 710 may request card information for the secondelectronic device 750.

As another embodiment of the present disclosure, inoperation 2713, the secondelectronic device 750 other than the firstelectronic device 710 may directly or indirectly request card information from thepayment server 720.

According to an embodiment of the present disclosure, thecard information request 2713 may be progressed before thecard information display 2711.

In operation 2715, thepayment server 720 may request thetoken server 730 to provide card information for the secondelectronic device 750.

Inoperation 2717, thetoken server 730 may transmit the card information to the payment application of the secondelectronic device 750. For example, thetoken server 730 may indirectly transmit the card information to the secondelectronic device 750 through the firstelectronic device 710. For example, the firstelectronic device 710 may encrypt the card information and transmit the information to the secondelectronic device 750.

As another example, thetoken server 730 may transmit the card information to thepayment server 720 and thepayment server 720 may transmit the received card information to the secondelectronic device 750. As another example, thetoken server 730 may directly transmit the card information to the secondelectronic device 750. For example, thetoken server 730 may directly transmit the card information through a communication network (e.g., 2G, 3G, 4G, or LTE).

Inoperation 2719, the firstelectronic device 710 may perform a card registration process, using the displayed card information.

According to an embodiment of the present disclosure, when the user selects a card to be registered, the firstelectronic device 710 may proceed with a card registration procedure, based on card information associated with the selected card.

Referring to FIG. 28,operations 2801 to 2809 of FIG. 28 correspond tooperations 2001 to 2009 of FIG. 20, so a detailed description thereof is omitted here, and operations thereafter will be described hereinafter.

Inoperation 2811, the firstelectronic device 710 may transmit the card information received from thepayment server 720 to the secondelectronic device 750. For example, the firstelectronic device 710 may transmit the card information to the payment application of the secondelectronic device 750. For example, the firstelectronic device 710 may encrypt the card information and transmit the information to the secondelectronic device 750. For example, the firstelectronic device 710 may directly transmit the card information to the secondelectronic device 750 through a short-range communication (e.g., BT, BLE, Wi-Fi, or ZIGBEE).

According to an embodiment of the present disclosure, the firstelectronic device 710 may transmit the card information according to a user’s request or a request from the secondelectronic device 750. For example, when the card information is received, the firstelectronic device 710 may display a message inquiring whether to transmit the received card information to the secondelectronic device 750. For example, when approval of the transmission of the card information is received from the user through a message, the firstelectronic device 710 may directly transmit the received card information to the secondelectronic device 750.

As another example, when denial of the transmission of the card information is received from the user through a message, the firstelectronic device 710 may perform a following operation (display of card information) without transmitting the received card information to the secondelectronic device 750.

Inoperation 2813, the firstelectronic device 710 may display information of at least one card associated with the user account. Inoperation 2813, the firstelectronic device 710 may display information of at least one card that can be registered.

Inoperation 2815, the firstelectronic device 710 may perform a card registration process, using the displayed card information.

According to an embodiment of the present disclosure, when the user selects a card to be registered, the firstelectronic device 710 may proceed with a card registration procedure, based on card information associated with the selected card.

According to another embodiment of the present disclosure,operation 2811 may be performed afteroperation 2813. For example, the firstelectronic device 710 may transmit card information of at least one card to the secondelectronic device 750 after displaying the card information.

According to an embodiment of the present disclosure, when a plurality of electronic devices are communicating with each other, a card is not inevitably required to be registered in only one electronic device but can be simultaneously registered in a plurality of electronic devices. When card information is input through a payment application in one electronic device, user’s identification or automatic determination of the payment application allows transmission of card information to a payment application of another electronic device.

Therefore, without needing to newly input the card information, the same process of card registration (e.g., token provisioning) can be progressed through thepayment server 720 and thetoken server 730.

According to an embodiment of the present disclosure, in a token provisioning process, a plurality of electronic devices are managed by one user, are paired with each other, or connected with each other through communication. Therefore, authentication through biometric information, such as recognition of user’s fingerprint, is allowed to be progressed in only one device or be partially omitted.

According to an embodiment of the present disclosure, after a card is normally issued through a token provisioning process, a server may transmit a notification for the card registration to an electronic device. For example, after normal card registration of the firstelectronic device 710, thetoken server 730 may progress card registration with the secondelectronic device 750 after transmitting a card registration notification to the secondelectronic device 750.

According to an embodiment of the present disclosure, when the wired or wireless connection between the firstelectronic device 710 and the secondelectronic device 750 is interrupted, the firstelectronic device 710 or the secondelectronic device 750 may cancel or suspend the transmission or reception of the card information and issuance of the token. When the wired or wireless connection is re-established, the transmission or reception of the card information and issuance of the token may be restarted.

According to an embodiment of the present disclosure, the secondelectronic device 750 may receive card information from the firstelectronic device 710 or thetoken server 730 after completion of the card issuance (or registration) of the firstelectronic device 710.

According to an embodiment of the present disclosure, a method of operating an electronic device includes transmitting a user identifier to a server, receiving information of at least one card associated with the user identifier from the server and displaying the received information on a display, selecting one piece of card information from the displayed information of the at least one card, and requesting the server to issue a token for payment, using at least a part of the selected card information.

According to an embodiment of the present disclosure, the method may further include starting to register a card corresponding to the selected card information.

According to an embodiment of the present disclosure, the card information may include at least one among a card issuance company, a card name, a PAN, a card expiration date, a CVV, an actual card image, and a card reference ID.

According to an embodiment of the present disclosure, the receiving of the information of at least one card associated with the user identifier and displaying of the received information on the display may include displaying the information of the at least one card through one or more card images.

According to an embodiment of the present disclosure, the displaying of the information of the at least one card through the one or more card images may include displaying the one or more card images to have at least one among a different color, a different transparency, a different size, and a different text from those of a registered card image.

According to an embodiment of the present disclosure, the transmitting of the user identifier to the server may include transmitting the user identifier to the server when there is an attempt to register the card in a state where there is no card registered in the electronic device.

According to an embodiment of the present disclosure, a method of operating a plurality of electronic devices may include, performing management or establishing a wired or wireless connection through a user identifier by the plurality of electronic devices, transmitting the user identifier to a server by a first electronic device among the plurality of electronic devices, receiving information of at least one card associated with the user identifier from the server by a second electronic device among the plurality of electronic devices, and requesting, by the second electronic device, the server to issue a token for payment, using at least a part of the received information of the at least one card.

According to an embodiment of the present disclosure, the method may further include starting to register a card corresponding to the at least a part of the received information of the at least one card.

According to an embodiment of the present disclosure, the requesting to issue the token may include omitting a user authentication process for the second electronic device.

According to an embodiment of the present disclosure, the method may include, when the wired or wireless connection is interrupted, canceling or suspending transmission or reception of the card information and issuance of the token.

According to an embodiment of the present disclosure, the receiving of the information of the at least one card from the server may be performed after card registration by the first electronic device is completed.

According to an embodiment of the present disclosure, the requesting, by the second electronic device, the server to issue the token for payment, using the at least a part of the received information of the at least one card, includes displaying the received information of the at least one card on a display, selecting one piece of card information from the displayed information of the at least one card, and requesting the server to issue the token for payment, using at least a part of the selected card information.

According to an embodiment of the present disclosure, the method may further include starting to register a card corresponding to the selected card information.

According to an embodiment of the present disclosure, a method of operating a plurality of electronic devices includes performing management or establishing a wired or wireless connection through a user identifier by the plurality of electronic devices, receiving information of at least one card from a first electronic device among the plurality of electronic devices by a second electronic device among the plurality of electronic devices, and requesting, by the second electronic device, a server to issue a token for payment, using at least a part of the received information of the at least one card.

According to an embodiment of the present disclosure, the method may further include starting to register a card corresponding to the at least a part of the received information of the at least one card.

According to an embodiment of the present disclosure, the receiving of the information of the at least one card from the first electronic device may be performed after card registration by the first electronic device is completed.

According to an embodiment of the present disclosure, an electronic device may include at least one non-transitory computer-readable recording medium having a program for executing operations recorded therein, the operations including transmitting a user identifier to a server, receiving information of at least one card associated with the user identifier from the server and displaying the received information on a display, selecting one piece of card information from the displayed information of the at least one card, and requesting the server to issue a token for payment, using at least a part of the selected card information.

The term “module” as used herein may, for example, mean a unit including one of hardware, software, and firmware or a combination of two or more of them. The “module” may be interchangeably used with, for example, the term “unit”, “logic”, “logical block”, “component”, or “circuit”. The "module" may be a minimum unit of an integrated component element or a part thereof. The “module” may be a minimum unit for performing one or more functions or a part thereof. The “module” may be mechanically or electronically implemented. For example, the “module” according to the present disclosure may include at least one of an application-specific integrated circuit (ASIC) chip, a field-programmable gate arrays (FPGAs), and a programmable-logic device for performing operations which has been known or are to be developed hereinafter.

At least some of the devices (e.g., modules or functions thereof) or the method (e.g., operations) according to various embodiments may be implemented by, for example, a command stored in a computer-readable storage medium in a programming module form. The instruction, when executed by a processor (e.g., the processor 120), may cause the one or more processors to execute the function corresponding to the instruction. The computer-readable storage medium may be, for example, thememory 130.

Certain aspects of the present disclosure can also be embodied as computer readable code on a non-transitory computer readable recording medium. A non-transitory computer readable recording medium is any data storage device that can store data which can be thereafter read by a computer system. Examples of the non-transitory computer readable recording medium include a Read-Only Memory (ROM), a Random-Access Memory (RAM), Compact Disc-ROMs (CD-ROMs), magnetic tapes, floppy disks, and optical data storage devices. The non-transitory computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. In addition, functional programs, code, and code segments for accomplishing the present disclosure can be easily construed by programmers skilled in the art to which the present disclosure pertains.

At this point it should be noted that the various embodiments of the present disclosure as described above typically involve the processing of input data and the generation of output data to some extent. This input data processing and output data generation may be implemented in hardware or software in combination with hardware. For example, specific electronic components may be employed in a mobile device or similar or related circuitry for implementing the functions associated with the various embodiments of the present disclosure as described above. Alternatively, one or more processors operating in accordance with stored instructions may implement the functions associated with the various embodiments of the present disclosure as described above. If such is the case, it is within the scope of the present disclosure that such instructions may be stored on one or more non-transitory processor readable mediums. Examples of the processor readable mediums include a ROM, a RAM, CD-ROMs, magnetic tapes, floppy disks, and optical data storage devices. The processor readable mediums can also be distributed over network coupled computer systems so that the instructions are stored and executed in a distributed fashion. In addition, functional computer programs, instructions, and instruction segments for accomplishing the present disclosure can be easily construed by programmers skilled in the art to which the present disclosure pertains.

While the present disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the appended claims and their equivalents.

Claims (20)

1. A method of operating an electronic device, the method comprising:

   transmitting a user identifier to a server;

   receiving information of at least one card associated with the user identifier from the server and displaying the received information on a display;

   selecting one piece of card information from the displayed information of the at least one card; and

   requesting the server to issue a token for payment, using at least a part of the selected card information.
2. The method of claim 1, further comprising starting to register a card corresponding to the selected card information.
3. The method of claim 1, wherein the card information comprises at least one among a card issuance company, a card name, a primary account number (PAN), a card expiration date, a card verification value (CVV), an actual card image, and a card reference identifier (ID).
4. The method of claim 1, wherein the receiving of the information of at least one card associated with the user identifier from the server and displaying of the received information on the display comprise displaying the information of the at least one card through one or more card images.
5. The method of claim 4, wherein the displaying of the information of the at least one card through the one or more card images comprises displaying the one or more card images to have at least one among a different color, a different transparency, a different size, and a different text from those of a registered card image.
6. The method of claim 1, wherein the transmitting of the user identifier to the server comprises transmitting the user identifier to the server when there is an attempt to register a card in a state where there is no card registered in the electronic device.
7. A method of operating a plurality of electronic devices, the method comprising:

   establishing a wireless connection through a user identifier by the plurality of electronic devices;

   transmitting the user identifier to a server by a first electronic device among the plurality of electronic devices;

   receiving information of at least one card associated with the user identifier from the server by a second electronic device among the plurality of electronic devices; and

   requesting, by the second electronic device, the server to issue a token for payment, using at least a part of the received information of the at least one card.
8. The method of claim 7, further comprising starting to register a card corresponding to the at least a part of the received information of the at least one card.
9. The method of claim 7, wherein the requesting to issue the token comprises omitting a user authentication process for the second electronic device.
10. The method of claim 7, further comprising, when the wireless connection is interrupted, canceling or suspending transmission or reception of the card information and issuance of the token.
11. The method of claim 7, wherein the receiving of the information of the at least one card from the server is performed after card registration by the first electronic device is completed.
12. The method of claim 7, wherein the requesting, by the second electronic device, the server to issue the token for payment, using the at least a part of the received information of the at least one card, comprises:

    displaying the received information of the at least one card on a display;

    selecting one piece of card information from the displayed information of the at least one card; and

    requesting the server to issue the token for payment, using at least a part of the selected card information.
13. The method of claim 12, further comprising starting to register a card corresponding to the selected card information.
14. The method of claim 7, wherein the server comprises a payment server.
15. An electronic device comprising:

    a display;

    a communication interface; and

    a processor,

    wherein the processor is configured to:

    transmit a user identifier to a server through the communication interface,

    receive information of at least one card associated with the user identifier from the server through the communication interface and display the received information on a display,

    select one piece of card information from the displayed information of the at least one card, and

    request, through the communication interface, the server to issue a token for payment, using at least a part of the selected card information.
16. The electronic device of claim 15, wherein the processor is further configured to start to register a card corresponding to the selected card information.
17. The electronic device of claim 15, wherein the card information comprises at least one among a card issuance company, a card name, a primary account number (PAN), a card expiration date, a card verification value (CVV), an actual card image, and a card reference identifier (ID).
18. The electronic device of claim 15, wherein the processor is further configured to display the information of at least one card through one or more card images.
19. The electronic device of claim 18, wherein the processor is further configured to display the one or more card images to have at least one among a different color, a different transparency, a different size, and a different text from those of a registered card image.
20. The electronic device of claim 15, wherein the processor is further configured to transmit the user identifier to the server when there is an attempt to register a card in a state where there is no card registered in the electronic device.

Images