KR102458145B1 - Appratus and method for payment - Google Patents

Abstract

The electronic device includes a security module operable to store at least one token; a first communication module; a second communication module; and at least one processor operatively connected to the security module, the first communication module, and the second communication module, wherein the at least one processor is used for payment among the first communication module or the second communication module It may be configured to determine at least one communication module to be used, and to transmit payment information including a token related to the at least one communication module among the at least one token to the external electronic device.

Description

Method and device for payment

Various embodiments relate to an electronic device, for example, to an electronic device including a control unit capable of making a payment using the electronic device.

Various embodiments relate to electronic devices, for example, to devices and methods for electronic payment systems.

With the development of mobile communication technology, the electronic device may perform various data communication functions as well as a voice call function. An electronic device, for example, a mobile device or a user device, may provide various services through various applications. The electronic device includes a multimedia service, for example, a music service, a video service, or a digital broadcast service, or a call, wireless Internet, a short message service (SMS), a multimedia messaging service (MMS), and the like. of network-based communication services, etc. can be provided. In addition, the electronic device can be used throughout the social, cultural, financial, or distribution industries as it evolves from a simple communication medium to a device capable of various functions such as communication, distribution, the Internet, or payment. The electronic device may provide, for example, a mobile payment method through the electronic device in a payment function. The electronic device may, for example, make a payment using the electronic device in a payment method that has been transferred from cash to a plastic card. The electronic device uses, for example, a mobile payment service, a payment function to purchase services and goods made online or offline (when payment is made by purchasing a product at an actual store or restaurant) can provide In addition, the electronic device may have, for example, a communication function for receiving or transmitting payment information.

Various embodiments relate to a method of transmitting authentication information using at least one communication module for a mobile payment service, and an electronic device thereof.

Various embodiments relate to a method of generating and transmitting highly secure payment information using time information for a mobile payment service, and an electronic device thereof.

An electronic device according to various embodiments may include a security module operable to store at least one token; a first communication module; a second communication module; and at least one processor operatively connected to the security module, the first communication module, and the second communication module, wherein the at least one processor is used for payment among the first communication module or the second communication module It may be configured to determine at least one communication module to be used, and to transmit payment information including a token related to the at least one communication module among the at least one token to the external electronic device.

In the method for securing payment information of an electronic device including a first security area, a second security area, and at least one payment signal module, the method according to various embodiments includes the at least one payment signal module in the first security area, respectively. storing the corresponding at least one token; generating a timestamp in at least one of the first security area and the second security area; generating a payment signal in the second security area based on at least one of a token corresponding to one of the at least one payment signal module among the at least one token and the timestamp; and transmitting the payment signal to an external electronic device.

In an electronic device including a security area and at least one payment signal module, a computer-readable recording medium recording a program according to various embodiments includes at least one token corresponding to each of the at least one payment signal module in the security area. save action; generating a timestamp in the secure region; generating a payment signal in the secure area based at least in part on a token corresponding to one of the at least one payment signal module among the at least one token and the timestamp; and transmitting the payment signal to an external electronic device.

It is possible to provide a mobile payment service based on various communication methods. In addition, various embodiments may provide a more secure wireless payment environment by using a high security area.

1 is a block diagram illustrating a network environment according to various embodiments.
2 is a block diagram of an electronic device according to various embodiments of the present disclosure;
3 is a block diagram of a program module according to various embodiments.
4 illustrates a plurality of execution environments operated in an electronic device according to various embodiments of the present disclosure;
5A to 5C illustrate a hardware structure of a trusted execution environment (TEE) according to various embodiments.
6 illustrates a payment system according to various embodiments.
7 illustrates a payment system for performing payment according to various embodiments of the present disclosure.
8 illustrates a hardware structure of an electronic device according to various embodiments.
9 illustrates a payment system for managing tokens according to various embodiments.
10 illustrates an electronic device supporting a payment method using near field communication (NFC) according to various embodiments of the present disclosure.
11 illustrates a method for performing a payment transaction using a token according to various embodiments.
12 is a block diagram of an electronic device according to various embodiments of the present disclosure;
13 is a flowchart illustrating a method of operating an electronic device according to various embodiments of the present disclosure.
14 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure;
15 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
16 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure;
17 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
18 illustrates program modules to be executed in an execution environment of an electronic device according to various embodiments of the present disclosure;
19 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure;
20 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
21 is a flowchart for another operating method of an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
22 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure;
23 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
24 is a flowchart for another operating method of an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
25 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure.
26 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
27 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure;
28 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
29 is a flowchart illustrating another operation method of an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
30 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure.
31 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile payment service according to various embodiments of the present disclosure.
32 illustrates an interface between internal components of an electronic device for generating information for payment according to various embodiments of the present disclosure;
33 illustrates an interface between internal components of an electronic device for generating information for payment according to various embodiments of the present disclosure;
34 illustrates an interface between internal components of an electronic device for generating information for payment according to various embodiments of the present disclosure;
35 illustrates an interface between internal components of an electronic device for generating information for payment according to various embodiments of the present disclosure;
36 is a diagram illustrating an effective time of payment information according to various embodiments of the present disclosure;
37 to 39 are diagrams illustrating an example of the structure of a payment method (eg, a card) according to various embodiments of the present disclosure;
40 illustrates a structure of payment information according to various embodiments.
41 illustrates a structure of transaction data according to various embodiments.
42 illustrates a structure of payment authentication data according to various embodiments.
43 illustrates a function in which the payment relay module relays an authentication request through input of a personal identification number (PIN) of a payment application to the security identifier processing module of the TEE according to various embodiments of the present disclosure;
44 to 45 are diagrams illustrating a method in which a payment relay module performs a payment using a result of performing authentication using biometric information according to various embodiments of the present disclosure.
46 illustrates a method for generating a token cryptogram according to various embodiments of the present invention.
47 is a flowchart illustrating a payment process using payment information generated based on timestamp information according to various embodiments of the present disclosure;
48 is a flowchart illustrating a payment process using payment information generated based on timestamp information according to various embodiments of the present disclosure;
49 illustrates a method for performing a payment transaction using a token according to various embodiments.

Hereinafter, various embodiments of the present document will be described with reference to the accompanying drawings. However, it is not intended to limit the technology described in this document to specific embodiments, and it should be understood to include various modifications, equivalents, and/or alternatives of the embodiments of this document. . In connection with the description of the drawings, like reference numerals may be used for like components.

In this document, expressions such as "has," "may have," "includes," or "may include" refer to the presence of a corresponding characteristic (eg, a numerical value, function, operation, or component such as a part). and does not exclude the presence of additional features.

In this document, expressions such as "A or B," "at least one of A and/and B," or "one or more of A or/and B" may include all possible combinations of the items listed together. . For example, "A or B," "at least one of A and B," or "at least one of A or B" means (1) includes at least one A, (2) includes at least one B; Or (3) it may refer to all cases including both at least one A and at least one B.

As used herein, expressions such as "first," "second," "first," or "second," may modify various elements, regardless of order and/or importance, and refer to one element. It is used only to distinguish it from other components, and does not limit the components. For example, the first electronic device and the second electronic device may represent different electronic devices regardless of order or importance. For example, without departing from the scope of the rights described in this document, a first component may be referred to as a second component, and similarly, the second component may also be renamed as a first component.

A component (eg, a first component) is "coupled with/to (operatively or communicatively)" to another component (eg, a second component) When referring to "connected to", it will be understood that the certain element may be directly connected to the other element or may be connected through another element (eg, a third element). On the other hand, when it is said that a component (eg, a first component) is "directly connected" or "directly connected" to another component (eg, a second component), the component and the It may be understood that other components (eg, a third component) do not exist between other components.

As used herein, the expression "configured to (or configured to)" depends on the context, for example, "suitable for," "having the capacity to ," "designed to," "adapted to," "made to," or "capable of." The term “configured (or configured to)” may not necessarily mean only “specifically designed to” in hardware. Instead, in some circumstances, the expression “a device configured to” may mean that the device is “capable of” with other devices or parts. For example, the phrase “a processor configured (or configured to perform) A, B, and C” refers to a dedicated processor (eg, an embedded processor) for performing the operations, or by executing one or more software programs stored in a memory device. , may mean a generic-purpose processor (eg, a CPU or an application processor) capable of performing corresponding operations.

Terms used in this document are only used to describe specific embodiments, and may not be intended to limit the scope of other embodiments. The singular expression may include the plural expression unless the context clearly dictates otherwise. Terms used herein, including technical or scientific terms, may have the same meanings as commonly understood by one of ordinary skill in the art described in this document. Among the terms used in this document, terms defined in a general dictionary may be interpreted with the same or similar meaning to the meaning in the context of the related art, and unless explicitly defined in this document, ideal or excessively formal meanings is not interpreted as In some cases, even terms defined in this document cannot be construed to exclude embodiments of the present document.

The electronic device according to various embodiments of the present document may include, for example, a smartphone, a tablet personal computer, a mobile phone, a video phone, and an e-book reader. , desktop personal computer, laptop personal computer, netbook computer, workstation, server, personal digital assistant (PDA), portable multimedia player (PMP), MP3 player, mobile It may include at least one of a medical device, a camera, and a wearable device. According to various embodiments, the wearable device may be an accessory type (eg, a watch, ring, bracelet, anklet, necklace, eyeglass, contact lens, or head-mounted-device (HMD)), a fabric or an integral piece of clothing ( It may include at least one of, for example, electronic clothing), a body attachable type (eg, a skin pad or tattoo), or a bioimplantable type (eg, an implantable circuit).

In some embodiments, the electronic device may be a home appliance. Home appliances are, for example, televisions, digital video disk (DVD) players, audio systems, refrigerators, air conditioners, vacuum cleaners, ovens, microwave ovens, washing machines, air purifiers, set-top boxes, home automation controls. panel (home automation control panel), security control panel (security control panel), TV box (eg Samsung HomeSync ^TM , Apple TV ^TM , or Google TV ^TM ), game console (eg Xbox ^TM , PlayStation ^TM ), electronic dictionary , an electronic key, a camcorder, or an electronic picture frame.

In another embodiment, the electronic device may include various medical devices (eg, various portable medical measuring devices (eg, a blood glucose meter, a heart rate monitor, a blood pressure monitor, or a body temperature monitor), magnetic resonance angiography (MRA), magnetic resonance imaging (MRI), Computed tomography (CT), imagers, or ultrasound machines, etc.), navigation devices, satellite navigation systems (global navigation satellite system (GNSS)), event data recorder (EDR), flight data recorder (FDR), automotive infotainment ) devices, ship electronic equipment (e.g. ship navigation systems, gyro compasses, etc.), avionics, security devices, vehicle head units, industrial or domestic robots, and automatic teller's machines (ATMs) in financial institutions. , point of sales (POS) in stores, or internet of things (e.g. light bulbs, sensors, electricity or gas meters, sprinkler devices, smoke alarms, thermostats, street lights, toasters) , exercise equipment, hot water tank, heater, boiler, etc.) may include at least one.

According to some embodiments, the electronic device is a piece of furniture or part of a building/structure, an electronic board, an electronic signature receiving device, a projector, or various measuring instruments (eg, water, electricity, gas, or a radio wave measuring device). In various embodiments, the electronic device may be a combination of one or more of the various devices described above. The electronic device according to an embodiment may be a flexible electronic device. In addition, the electronic device according to the embodiment of the present document is not limited to the above-described devices, and may include a new electronic device according to technological development.

Hereinafter, an electronic device according to various embodiments will be described with reference to the accompanying drawings. In this document, the term user may refer to a person who uses an electronic device or a device (eg, an artificial intelligence electronic device) using the electronic device.

1 is a block diagram 100 illustrating a network environment, in accordance with various embodiments. Referring to FIG. 1 , an electronic device 101 , 102 , or 104 or a server 106 may be connected to each other through a network 162 or short-range communication 164 . The electronic device 101 may include a bus 110 , a processor 120 , a memory 130 , an input/output interface 150 , a display 160 , and a communication interface 170 . In some embodiments, the electronic device 101 may omit at least one of the components or may additionally include other components.

The bus 110 may include, for example, a circuit that connects the components 110 - 170 to each other and transmits communication (eg, a control message and/or data) between the components.

The processor 120 may include one or more of a central processing unit (CPU), an application processor (AP), and a communication processor (CP). The processor 120 may, for example, execute an operation or data processing related to control and/or communication of at least one other component of the electronic device 101 .

The memory 130 may include volatile and/or non-volatile memory. The memory 130 may store, for example, commands or data related to at least one other component of the electronic device 101 . According to one embodiment, the memory 130 may store software and/or a program 140 . Program 140 may include, for example, kernel 141 , middleware 143 , application programming interface (API) 145 , and/or application programs (or “applications”) 147 , etc. may include At least a portion of the kernel 141 , the middleware 143 , or the API 145 may be referred to as an operating system (OS).

The kernel 141 is, for example, system resources (eg, middleware 143, API 145, or application program 147) used to execute an operation or function implemented in other programs (eg, middleware 143, API 145, or the application program 147). : The bus 110, the processor 120, the memory 130, etc.) can be controlled or managed. In addition, the kernel 141 may provide an interface capable of controlling or managing system resources by accessing individual components of the electronic device 101 from the middleware 143 , the API 145 , or the application program 147 . can

The middleware 143 may, for example, play an intermediary role so that the API 145 or the application program 147 communicates with the kernel 141 to send and receive data.

Also, the middleware 143 may process one or more work requests received from the application program 147 according to priority. For example, the middleware 143 may use a system resource (eg, the bus 110 , the processor 120 , or the memory 130 ) of the electronic device 101 for at least one of the application programs 147 . You can give priority. For example, the middleware 143 may process the one or more work requests according to the priority given to the at least one, thereby performing scheduling or load balancing for the one or more work requests.

The API 145 is, for example, an interface for the application 147 to control functions provided by the kernel 141 or the middleware 143, for example, file control, window control, image processing, or text. It may include at least one interface or function (eg, a command) for control and the like.

The input/output interface 150 may serve as an interface capable of transmitting, for example, a command or data input from a user or other external device to other component(s) of the electronic device 101 . Also, the input/output interface 150 may output a command or data received from other component(s) of the electronic device 101 to a user or other external device.

Display 160 may be, for example, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic light-emitting diode (OLED) display, or microelectromechanical systems (MEMS) displays, or electronic paper displays. The display 160 may, for example, display various contents (eg, text, image, video, icon, or symbol) to the user. The display 160 may include a touch screen, and may receive, for example, a touch, gesture, proximity, or hovering input using an electronic pen or a part of the user's body.

The communication interface 170, for example, sets up communication between the electronic device 101 and an external device (eg, the first external electronic device 102, the second external electronic device 104, or the server 106). can For example, the communication interface 170 may be connected to the network 162 through wireless communication or wired communication to communicate with an external device (eg, the second external electronic device 104 or the server 106 ).

Wireless communication is, for example, a cellular communication protocol, for example, long-term evolution (LTE), LTE Advance (LTE-A), code division multiple access (CDMA), wideband CDMA (WCDMA), universal (UMTS). At least one of mobile telecommunications system), Wireless Broadband (WiBro), and Global System for Mobile Communications (GSM) may be used. Also, wireless communication may include, for example, short-range communication 164 . The short-range communication 164 includes, for example, at least one of wireless fidelity (WiFi), Bluetooth (Bluetooth), near field communication (NFC), magnetic stripe transmission (MST), or global navigation satellite system (GNSS), etc. can do.

The MST may generate a pulse according to transmitted data using an electromagnetic signal, and the pulse may generate a magnetic field signal. The electronic device 101 transmits the magnetic field signal to a point of sales (POS), the POS detects the magnetic field signal using an MST reader, and converts the detected magnetic field signal into an electric signal to convert the data can be restored.

GNSS is, depending on the region or bandwidth used, for example, global positioning system (GPS), global navigation satellite system (Glonass), Beidou navigation satellite system (hereinafter “Beidou”) or Galileo, the European global satellite-based navigation system. It may include at least one. Hereinafter, in this document, "GPS" may be used interchangeably with "GNSS". Wired communication may include, for example, at least one of universal serial bus (USB), high definition multimedia interface (HDMI), recommended standard232 (RS-232), or plain old telephone service (POTS). The network 162 may include at least one of a telecommunications network, for example, a computer network (eg, LAN or WAN), the Internet, or a telephone network.

Each of the first and second external electronic devices 102 and 104 may be the same as or different from the electronic device 101 . According to one embodiment, server 106 may include a group of one or more servers. According to various embodiments, all or part of the operations executed by the electronic device 101 may be executed by one or a plurality of other electronic devices (eg, the electronic devices 102 and 104 , or the server 106 ). Accordingly, when the electronic device 101 is to perform a function or service automatically or upon request, the electronic device 101 performs at least some functions related thereto instead of or in addition to executing the function or service itself. may request from another device (eg, electronic device 102, 104, or server 106) The other electronic device (eg, electronic device 102, 104, or server 106) may request the requested function or The additional function may be executed and the result may be transmitted to the electronic device 101. The electronic device 101 may provide the requested function or service by processing the received result as it is or additionally. For example, cloud computing, distributed computing, or client-server computing technology may be used.

2 is a block diagram 200 illustrating an electronic device 201, according to various embodiments. The electronic device 201 may include, for example, all or a part of the electronic device 101 illustrated in FIG. 1 . The electronic device 201 includes one or more processors (eg, an application processor (AP)) 210 , a communication module 220 , (a subscriber identification module 224 , a memory 230 , a sensor module 240 , an input device ( 250 ), a display 260 , an interface 270 , an audio module 280 , a camera module 291 , a power management module 295 , a battery 296 , an indicator 297 , and a motor 298 . can

The processor 210 may control a plurality of hardware or software components connected to the processor 210 by, for example, driving an operating system or an application program, and may perform various data processing and operations. The processor 210 may be implemented as, for example, a system on chip (SoC). According to an embodiment, the processor 210 may further include a graphic processing unit (GPU) and/or an image signal processor. The processor 210 may include at least some of the components shown in FIG. 2 (eg, the cellular module 221 ). The processor 210 may load and process commands or data received from at least one of other components (eg, non-volatile memory) into a volatile memory, and store various data in the non-volatile memory. have.

The communication module 220 may have the same or similar configuration to the communication interface 170 of FIG. 1 . The communication module 220 is, for example, a cellular module 221 , a WiFi module 222 , a Bluetooth module 223 , a GNSS module 224 (eg, a GPS module, a Glonass module, a Beidou module, or a Galileo module). , an NFC module 225 , an MST module 226 , and a radio frequency (RF) module 227 .

The cellular module 221 may provide, for example, a voice call, a video call, a text service, or an Internet service through a communication network. According to an embodiment, the cellular module 221 may use a subscriber identification module (eg, a SIM card) 229 to identify and authenticate the electronic device 201 within a communication network. According to an embodiment, the cellular module 221 may perform at least some of the functions that the processor 210 may provide. According to an embodiment, the cellular module 221 may include a communication processor (CP).

Each of the WiFi module 222, the Bluetooth module 223, the GNSS module 224, the NFC module 225, or the MST module 226 includes, for example, a processor for processing data transmitted and received through the corresponding module. may include According to some embodiments, at least some (eg, two or more) of the cellular module 221 , the WiFi module 222 , the Bluetooth module 223 , the GNSS module 224 , the NFC module 225 , or the MST module 226 . ) may be included in one integrated chip (IC) or IC package.

The RF module 227 may transmit and receive, for example, a communication signal (eg, an RF signal). The RF module 227 may include, for example, a transceiver, a power amp module (PAM), a frequency filter, a low noise amplifier (LNA), or an antenna. According to another embodiment, at least one of the cellular module 221, the WiFi module 222, the Bluetooth module 223, the GNSS module 224, the NFC module 225, or the MST module 226 is a separate RF module. RF signals can be transmitted and received through

Subscriber identification module 229 may include, for example, a card including a subscriber identification module and/or an embedded SIM (SIM), and may include unique identification information (eg, integrated circuit card identifier (ICCID)) or Subscriber information (eg, international mobile subscriber identity (IMSI)) may be included.

The memory 230 (eg, the memory 130 ) may include, for example, an internal memory 232 or an external memory 234 . The built-in memory 232 may include, for example, a volatile memory (eg, dynamic RAM (DRAM), static RAM (SRAM), or synchronous dynamic RAM (SDRAM)), a non-volatile memory (eg, a non-volatile memory). One time programmable ROM (OTPROM), programmable ROM (PROM), erasable and programmable ROM (EPROM), electrically erasable and programmable ROM (EEPROM), mask ROM, flash ROM, flash memory (such as NAND flash or NOR flash); It may include at least one of a hard drive and a solid state drive (SSD).

The external memory 234 is a flash drive, for example, compact flash (CF), secure digital (SD), micro secure digital (Micro-SD), mini secure digital (Mini-SD), extreme xD (xD). digital), a multi-media card (MMC), or a memory stick may be further included. The external memory 234 may be functionally and/or physically connected to the electronic device 201 through various interfaces.

The security module 236 is a module including a storage space having a relatively higher security level than the memory 230 , and may be a circuit that ensures safe data storage and a protected execution environment. For example, the electronic device may encrypt data requiring high security (eg, biometric information, personal information, card information) and store the key used for encryption in the security module 236 . The security module 236 may be implemented as a separate circuit, and may include a separate processor. The secure module 236 may include, for example, an embedded secure element residing within a removable smart chip, a secure digital (SD) card, or embedded within a fixed chip of the electronic device 201 . eSE)) may be included. Also, the security module 236 may be driven by an operating system different from the operating system (OS) of the electronic device 201 . For example, it may operate based on a Java card open platform (JCOP) operating system.

The sensor module 240 may, for example, measure a physical quantity or sense an operating state of the electronic device 201 , and convert the measured or sensed information into an electrical signal. The sensor module 240 is, for example, a gesture sensor 240A, a gyro sensor 240B, a barometric pressure sensor 240C, a magnetic sensor 240D, an acceleration sensor 240E, a grip sensor 240F, a proximity sensor ( 240G), color sensor (240H) (e.g. RGB (red, green, blue) sensor), biometric sensor (240I), temperature/humidity sensor (240J), illuminance sensor (240K), or UV (ultra violet) sensor ) may include at least one of the sensors 240M. Additionally or alternatively, the sensor module 240 may include, for example, an olfactory sensor (E-nose sensor), an electromyography sensor (EMG sensor), an electroencephalogram sensor (EEG sensor), an electrocardiogram sensor (ECG sensor) , an infrared (IR) sensor, an iris sensor, and/or a fingerprint sensor. The sensor module 240 may further include a control circuit for controlling at least one or more sensors included therein. In some embodiments, the electronic device 201 further comprises a processor configured to control the sensor module 240 , either as part of the processor 210 or separately, while the processor 210 is in a sleep state; The sensor module 240 may be controlled.

The input device 250 may include, for example, a touch panel 252 , a (digital) pen sensor 254 , a key 256 , or an ultrasonic input device ( 258) may be included. The touch panel 252 may use, for example, at least one of a capacitive type, a pressure sensitive type, an infrared type, and an ultrasonic type. Also, the touch panel 252 may further include a control circuit. The touch panel 252 may further include a tactile layer to provide a tactile response to the user.

The (digital) pen sensor 254 may be, for example, a part of a touch panel or may include a separate recognition sheet. Key 256 may include, for example, a physical button, an optical key, or a keypad. The ultrasonic input device 258 may detect an ultrasonic wave generated by an input tool through a microphone (eg, the microphone 288 ), and check data corresponding to the sensed ultrasonic wave.

The display 260 (eg, the display 160 ) may include a panel 262 , a hologram device 264 , or a projector 266 . The panel 262 may have the same or similar configuration to the display 160 of FIG. 1 . The panel 262 may be implemented to be flexible, transparent, or wearable, for example. The panel 262 may be composed of the touch panel 252 and one module. The hologram device 264 may display a stereoscopic image in the air by using light interference. The projector 266 may display an image by projecting light onto the screen. The screen may be located inside or outside the electronic device 201 , for example. According to one embodiment, the display 260 may further include a control circuit for controlling the panel 262 , the hologram device 264 , or the projector 266 .

The interface 270 is, for example, a high-definition multimedia interface (HDMI) 272 , a universal serial bus (USB) 274 , an optical interface 276 , or a D-subminiature (D-sub). ) (278). The interface 270 may be included in, for example, the communication interface 170 shown in FIG. 1 . Additionally or alternatively, the interface 270 may be, for example, a mobile high-definition link (MHL) interface, a secure digital (SD) card/multi-media card (MMC) interface, or an infrared (IrDA) interface. data association) standard interface.

The audio module 280 may interactively convert a sound and an electrical signal, for example. At least some components of the audio module 280 may be included in, for example, the input/output interface 145 illustrated in FIG. 1 . The audio module 280 may process sound information input or output through, for example, the speaker 282 , the receiver 284 , the earphone 286 , or the microphone 288 .

The camera module 291 is, for example, a device capable of capturing still images and moving images, and according to an embodiment, one or more image sensors (eg, a front sensor or a rear sensor), a lens, and an image signal processor (ISP). , or a flash (eg, an LED or xenon lamp, etc.).

The power management module 295 may manage power of the electronic device 201 , for example. According to an embodiment, the power 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 have a wired and/or wireless charging method. The wireless charging method includes, for example, a magnetic resonance method, a magnetic induction method, or an electromagnetic wave method, and may further include an additional circuit for wireless charging, for example, a coil loop, a resonance circuit, or a rectifier. have. The battery gauge may measure, for example, the remaining amount of the battery 296 , voltage, current, or temperature during charging. The battery 296 may include, for example, a rechargeable battery and/or a solar battery.

The indicator 297 may display a specific state of the electronic device 201 or a part thereof (eg, the processor 210 ), for example, a booting state, a message state, or a charging state. The motor 298 may convert an electrical signal into mechanical vibration, and may generate vibration or a haptic effect. Although not shown, the electronic device 201 may include a processing unit (eg, GPU) for supporting mobile TV. The processing device for supporting mobile TV may process media data according to standards such as digital multimedia broadcasting (DMB), digital video broadcasting (DVB), or mediaFloTM, for example.

Each of the components described in this document may be composed of one or more components, and the name of the component may vary depending on the type of the electronic device. In various embodiments, the electronic device may be configured to include at least one of the components described in this document, and some components may be omitted or may further include additional other components. In addition, since some of the components of the electronic device according to various embodiments are combined to form a single entity, the functions of the components prior to being combined may be identically performed.

3 is a block diagram 300 illustrating a program module 310, according to various embodiments. According to an embodiment, the program module 310 (eg, the program 140 ) is an operating system (OS) and/or an operating system that controls resources related to the electronic device (eg, the electronic device 101 ). It may include various applications (eg, the application program 147) running on the system. The operating system may be, for example, Android ^TM , iOS ^TM , Windows ^TM , Symbian ^TM , Tizen ^TM , or bada ^TM .

The program module 310 may include a kernel 320 , middleware 330 , an application programming interface (API) 360 , and/or an application 370 . At least a portion of the program module 310 may be preloaded on the electronic device or downloaded from an external electronic device (eg, the electronic devices 102 and 104 , the server 106 , etc.).

The kernel 320 (eg, the kernel 141 ) may include, for example, a system resource manager 321 and/or a device driver 323 . The system resource manager 321 may control, allocate, or recover system resources. According to an embodiment, the system resource manager 321 may include a process manager, a memory manager, or a file system manager. The device 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 WiFi driver, an audio driver, or an inter-process communication (IPC) driver. .

The middleware 330 provides, for example, functions commonly required by the applications 370 or provides various functions through the API 360 so that the applications 370 can efficiently use limited system resources inside the electronic device. Functions may be provided to the application 370 . According to an embodiment, the middleware 330 (eg, middleware 143 ) includes a runtime library 335 , an application manager 341 , a window manager 342 , and a multimedia manager. ) (343), resource manager (344), power manager (345), database manager (346), package manager (347), connectivity manager ) 348 , notification manager 349 , location manager 350 , graphic manager 351 , security manager 352 , or payment manager 354 . ) may include at least one of.

The runtime library 335 may include, for example, a library module used by the compiler to add a new function through a programming language while the application 370 is being executed. The runtime library 335 may perform input/output management, memory management, or a function for an arithmetic function.

The application manager 341 may manage, for example, a life cycle of at least one application among the applications 370 . The window manager 342 may manage GUI resources used in the screen. The multimedia manager 343 may identify a format required for reproduction of various media files, and may encode or decode the media file using a codec suitable for the format. The resource manager 344 may manage resources such as source code, memory, or storage space of at least one of the applications 370 .

The power manager 345 may, for example, operate in conjunction with a basic input/output system (BIOS), etc. to manage a battery or power, and provide power information required for the operation of the electronic device. The database manager 346 may create, search, or change a database to be used by at least one of the applications 370 . The package manager 347 may manage installation or update of applications distributed in the form of package files.

The connection manager 348 may manage a wireless connection such as WiFi or Bluetooth, for example. The notification manager 349 may display or notify the user of events such as arrival messages, appointments, and proximity notifications in an unobtrusive manner. The location manager 350 may manage location information of the electronic device. The graphic manager 351 may manage graphic effects to be provided to the user or a user interface related thereto. The security manager 352 may provide various security functions necessary for system security or user authentication. According to an embodiment, when the electronic device (eg, the electronic device 101) includes a phone function, the middleware 330 further includes a telephony manager for managing the voice or video call function of the electronic device. can do. The payment manager 354 may relay information for payment from the application 370 to the application 370 or the kernel 320 . Also, payment related information received from an external device may be stored inside the electronic device 200 or information stored therein may be transmitted to the external device.

The middleware 330 may include a middleware module that forms a combination of various functions of the aforementioned components. The middleware 330 may provide a specialized module for each type of operating system in order to provide a differentiated function. Also, the middleware 330 may dynamically delete some existing components or add new components.

The API 360 (eg, the API 145 ) is, for example, a set of API programming functions, and may be provided in a different configuration according to an operating system. For example, in the case of Android ^TM or iOS ^TM , one API set may be provided for each platform, and in the case of tizen ^TM , two or more API sets may be provided for each platform.

The application 370 (eg, the application program 147 ) may include, for example, a home 371 , a dialer 372 , an SMS/MMS 373 , an instant message (IM) 374 , a browser 375 , Camera 376, Alarm 377, Contacts 378, Voice Dial 379, Email 380, Calendar 381, Media Player 382, Album 383, Clock 384, Payment 385 ), health care (e.g., measuring exercise volume or blood sugar), or providing environmental information (e.g., providing information about air pressure, humidity, or temperature), etc. can do.

According to an embodiment, the application 370 is an application that supports information exchange between an electronic device (eg, the electronic device 101) and an external electronic device (eg, the electronic devices 102 and 104) (hereinafter, described below). For convenience, "information exchange application") may be included. The information exchange application may include, for example, a notification relay application for transmitting specific information to an external electronic device or a device management application for managing the external electronic device.

For example, the notification delivery application transmits notification information generated by another application of the electronic device (eg, an SMS/MMS application, an email application, a health management application, or an environment information application) to an external electronic device (eg, the electronic device 102 ). , 104)). Also, the notification delivery application may receive notification information from, for example, an external electronic device and provide the notification information to the user.

The device management application is, for example, the turn-of at least one function (eg, the external electronic device itself (or some component) of the external electronic device (eg, the electronic device 102, 104) that communicates with the electronic device) Manage (eg, install, delete, etc.) applications running on/off or display brightness (or resolution) adjustments), applications running on external electronic devices, or services provided by external electronic devices (eg, call services or message services, etc.) , or update).

According to an embodiment, the application 370 may include an application (eg, a health management application of a mobile medical device, etc.) designated according to a property (eg, the electronic device 102 or 104 ) of the external electronic device (eg, the electronic device 102 or 104 ). According to an embodiment, the application 370 may include an application received from an external electronic device (eg, the server 106 or the electronic devices 102 and 104). may include a preloaded application or a third party application downloadable from a server The names of components of the program module 310 according to the illustrated embodiment depend on the type of the operating system. Therefore, it may vary.

According to various embodiments, at least a portion of the program module 310 may be implemented in software, firmware, hardware, or a combination of at least two or more thereof. At least a portion of the program module 310 may be implemented (eg, executed) by, for example, a processor (eg, the processor 210 ). At least a portion of the program module 310 may include, for example, a module, a program, a routine, sets of instructions, or a process for performing one or more functions.

As used herein, the term “module” may refer to, for example, a unit including one or a combination of two or more of hardware, software, or firmware. The term “module” may be used interchangeably with terms such as, for example, unit, logic, logical block, component, or circuit. A “module” may be a minimum unit or a part of an integrally configured component. A “module” may be a minimum unit or a part of performing one or more functions. A “module” may be implemented mechanically or electronically. For example, a “module” may be one of an application-specific integrated circuit (ASIC) chip, field-programmable gate arrays (FPGAs) or programmable-logic device, known or to be developed, that performs certain operations. It may include at least one.

At least a portion of an apparatus (eg, modules or functions thereof) or a method (eg, operations) according to various embodiments is, for example, a computer-readable storage medium in the form of a program module It can be implemented as a command stored in . When the instruction is executed by a processor (eg, the processor 120), the one or more processors may perform a function corresponding to the instruction. The computer-readable storage medium may be, for example, the memory 130 .

Computer-readable recording media include hard disks, floppy disks, magnetic media (eg, magnetic tape), optical media (eg, compact disc read only memory (CD-ROM), DVD ( digital versatile disc), magneto-optical media (such as floppy disk), hardware devices (such as read only memory (ROM), random access memory (RAM), or flash memory, etc.) ), etc. In addition, the program instructions may include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc. The above-described hardware devices include various It may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

A module or program module according to various embodiments may include at least one or more of the above-described components, some may be omitted, or may further include additional other components. Operations performed by a module, a program module, or other components according to various embodiments may be executed sequentially, in parallel, iteratively, or in a heuristic manner. Also, some operations may be executed in a different order, omitted, or other operations may be added. In addition, the embodiments disclosed in this document are presented for explanation and understanding of the disclosed and technical content, and do not limit the scope of the technology described in this document. Accordingly, the scope of this document should be construed to include all modifications or various other embodiments based on the technical spirit of this document.

4 is a block diagram 400 illustrating a rich execution environment (REE) 410 and a trusted execution environment (TEE) 420 operated in an electronic device (eg, the electronic device 101 ), according to various embodiments of the present disclosure. )to be. According to various embodiments, the electronic device may operate an execution environment having a plurality of security levels to enhance security. The plurality of execution environments may include, for example, an REE 410 and a TEE 420 . The REE may be, for example, a first execution environment having a first security level. The TEE may be, for example, a second execution environment having a second security level that is different (eg, higher) than the first security level. According to an embodiment, the electronic device 101 may include an additional additional writing environment (eg, a third execution environment) having a third security level, but is not limited thereto.

The TEE can store data requiring a relatively high security level in a secure environment and perform related operations. The TEE may operate on an application processor of the electronic device and may operate based on a reliable hardware structure determined during a manufacturing process of the electronic device. The TEE divides the application processor or memory into a normal area and a security area to operate in the security area. TEE can be configured to operate software or hardware requiring security only in a secure area. The electronic device may operate the TEE through a physical change of hardware or a logical change of software.

TEE can be separated from each other through REE and hardware restrictions, and can be operated separately in software on the same hardware. At least one application (eg, payment, contact, e-mail, or browser) operating in the REE may use an API (eg, TEE functional API or TEE client API) that is allowed to access the TEE. The at least one application may transmit a message from a communication agent of the REE to a communication agent of the TEE (TEE communication agent) using the API. The message may be implemented to be delivered only to the TEE in hardware. The communication agent of the TEE may receive the message and transmit it to a trusted application (TA) (eg, digital rights management (DRM), a secure payment module, or a secure biometric information module, etc.) related to the message. The security application may perform an operation related to the message, and may transmit a result of the operation to the communication agent of the REE through the communication agent of the TEE. The communication agent of the REE may transmit the result to at least one application operating in the REE.

5(a) to 5(c) are block diagrams 500 illustrating a hardware structure of a TEE, according to various embodiments. FIG. 5(a) shows a case in which one processor and one memory are divided into REE and TEE in terms of hardware (eg, trust zone (TZ) of ARM). According to an embodiment, the hardware structure of the TEE may include an On-SoC 510 and external memories 520 . The On-SoC 510 may include a microprocessing core 501 , RAM 502 , ROM 503 , peripheral 504 , crypto accelerator 505 or OTP fields 506 . In order to operate two or more execution environments, the trust zone can time-separate processors and use REE and TEE separately. In addition, the trust zone can use one memory by dividing it into an area accessible from the REE and an area accessible from the TEE.

FIG. 5(b) shows a case in which a processor for TEE is implemented in an on-chip form like a processor for operating REE, but is implemented as a separate processing core set. According to one embodiment, the On-SoC 510 may further include an on-chip security subsystem 507 including one or more processors in addition to the microprocessing core 501 . In this case, the On-SoC 510 may be configured to operate the REE, and the On-chip security subsystem 507 may be configured to operate the TEE. In the case of FIG. 5B , as in FIG. 5A , one memory may be divided into an area accessible from the REE and an area accessible from the TEE to be used.

FIG. 5( c ) shows a case in which a processor for TEE is implemented as a separate chip in hardware, and the processor for operating REE is separated from the implemented chip. Referring to FIG. 5( c ), the On-Soc 510 operates the REE, and one or more external security co-processors 530 provided outside the On-Soc 510 are set to operate the TEE. can

6 , a payment system 600 is illustrated, in accordance with various embodiments.

According to various embodiments, the payment system 600 may include an electronic device 610 and/or a server. Also, for example, the server may include a payment server 620 , a token server (token service provider) 630 , or a financial server (issuer) 640 . The electronic device 610 may include, for example, a payment application (wallet application) 612 and/or a payment manager 614 . The payment server 620 may include, for example, payment service servers 622 and 622 and/or a token requester server (token requester server) 624 .

According to various embodiments, the payment application 612 may include a payment application 612 (eg, a Samsung Pay ^TM application). The payment application 612 may include, for example, payment A user interface (eg, a user interface (UI) or user experience (UX)) related to the payment may be provided. The user interface related to the payment may include a wallet UI/UX. For example, The payment application 612 may provide a user interface related to card registration, payment, or transaction, The payment application 612 may include, for example, a text reader (eg, OCR). (optical character reader/recognition)) or an interface related to card registration through an external input (eg, user input) In addition, the payment application 612 may provide, for example, identification (ID&V, identification) and verification) can provide an interface related to user authentication.

According to various embodiments, the payment application 612 may perform a payment transaction using the payment application 612 . For example, the payment application 612 may provide a payment function to the user through Simple Pay, Quick Pay, or a specified application execution. The user may perform a payment function using the payment application 612 and receive information related to the payment function.

According to various embodiments, the payment manager 614 may include information related to a card company. For example, the payment manager 614 may include a card company software development kit (SDK).

According to various embodiments, the payment server 620 may include a management server for electronic payment or mobile payment. The payment server 620 may receive payment-related information from the electronic device 610 and transmit it to the outside or process the payment server 620 .

According to various embodiments, the payment server 620 uses the payment service server 622 and/or the token requestor server 624 to provide information between the electronic device 610 and the token server 630 . can send and receive The payment service server 622 may include, for example, a payment server (eg, Samsung payment server) 620 . The payment service server 622 may manage card information linked to a service account (eg, Samsung account) or a user account, for example. In addition, the payment service server 622 may include an API (application program interface) server related to the payment application 612 . Also, the payment service server 622 may provide, for example, the account management module (eg, account integration or Samsung account integration).

According to various embodiments, the token requestor server 624 may provide an interface for processing payment related information. For example, the token requestor server 624 may issue, delete, or activate payment-related information (eg, a token). Alternatively, it may be functionally connected to the payment manager 614 to control information required for the payment.

According to various embodiments, the payment application 612 included in the electronic device 610 and the payment service server 622 included in the payment server 620 may be functionally connected. For example, the payment application 612 may transmit/receive information related to payment to the payment server 620 . According to an embodiment, the payment manager 614 included in the electronic device 610 and the token requestor server 624 included in the payment server 620 may be functionally connected. For example, the payment manager 614 may transmit and receive payment-related information to the token requestor server 624 .

According to various embodiments, the token server 630 may issue payment-related information (eg, a token) or manage payment-related information. For example, the token server 630 may control an operation cycle (like cycle) of a token, and the operation cycle may include a creation, modification, or deletion function. Also, the token server 630 may include, for example, a token management server, and performs token provisioning, identification and verification (ID&V, identification and verification), renewal, or life cycle management. can do. In addition, it is possible to perform integration (integration) of information related to the financial server.

According to various embodiments, the payment server 620 and/or the token server 630 may be located in the same or similar area or may be located in separate areas. For example, the payment server 620 may be included in a first server, and the token server 630 may be included in a second server. Also, for example, the payment server 620 and/or the token server 630 may be separately implemented in one server (eg, a first server or a second server).

According to various embodiments, the financial server 640 may perform card issuance. For example, the financial server 640 may include a card issuing bank. In addition, information required for payment provided to the user may be generated. The user may store the information necessary for the payment generated by the financial server 640 in the electronic device 610 using the payment application 612 . In addition, the financial server 640 may be functionally connected to the token server 630 to transmit/receive information necessary for the payment.

7 is a block diagram 700 illustrating a payment system for performing a payment, according to various embodiments. Referring to FIG. 7 , the payment system includes an electronic device 710 (eg, electronic device 101), a payment server 720 (eg, server 106), and a token service provider (TSP). 730 (eg, the server 106 or another server (not shown)) and a point of sales (POS) 740 (eg, the electronic device 102). According to an embodiment, the payment system may include one or more additional electronic devices 750 or 760 . The one or more additional electronic devices include a wearable device 750 (eg, a smart watch) or an accessory 760 (eg, a fob type device of LoopPay ^TM ) that can be functionally (eg, communicate) with the electronic device 710 . may include According to an embodiment, the fob type device of LoopPay ^TM may include an external payment module connected to the electronic device 710 through a microphone.

According to an embodiment, the electronic device 710 may operate a payment function. The electronic device 710 may register a card (eg, a credit card such as MasterCard or Visa) in the electronic device 710 or the payment server 720 to perform a payment function. In addition to the card registered through the electronic device 710 , the payment server 720 may include a card registered through another electronic device (eg, the electronic device 750 ) of the user corresponding to the electronic device 710 or the electronic device of another user. Information on a plurality of registered cards including other registered cards may be managed through the device.

According to an embodiment, the payment server 720 may obtain token information corresponding to registered card information from the token service provider 730 and transmit it to the electronic device 710 . The payment server 720 may include, for example, a payment service server or a token requestor server. The payment service server may manage the user's card information. It is possible to provide services related to payment based on the account. The token requestor server may obtain token information by requesting token information required for a payment operation from the token service provider 730 .

The token service provider 730 may issue a token used in the payment process. According to one embodiment, the token may be a value replacing the primary account number (PAN), which is information of the card. According to an embodiment, the token may be generated using a bank identification number (BIN) or the like. In addition, the generated token may be encrypted by the token service provider 730 or transmitted to the payment server 720 in an unencrypted state, and then encrypted by the payment server 720 . After the encrypted token information is transmitted to the electronic device 710 through the payment server 720 , the encrypted token information may be decrypted in the electronic device 710 . According to an embodiment, the token may be generated and encrypted by the token service provider 730 and delivered to the electronic device 710 without going through the payment server 720 . According to another embodiment, the payment server 720 may include a token generation function, and in this case, a separate token service provider 730 may not be used in the payment system.

The electronic device 710 may perform payment using at least one of one or more other electronic devices 750 or 760 that are functionally connected based on, for example, short-range communication (eg, Bluetooth or WiFi). According to an embodiment, the other electronic device 750 may be a wearable device (eg, a smart watch). In this case, the electronic device 710 transmits the token delivered from the token service provider 730 to the wearable device. can According to an embodiment, the other electronic device 760 may be an accessory (eg, a fob type device manufactured by LoopPay ^TM ). )) through the accessory (eg, LoopPay ^TM 's fob type device) can be functionally connected.

8 is a block diagram 800 illustrating a hardware structure of an electronic device (eg, the electronic device 101) capable of performing a payment function, according to various embodiments of the present disclosure. According to an embodiment, the electronic device includes, for example, a camera module 801 , an acceleration sensor 803 , a gyro sensor 805 , a biometric sensor 807 , an MST module 810 , an NFC module 820 , It may include an MST control module 830 , an NFC control module 840 , a processor 850 , and a memory 860 . The camera module 801 may acquire card information by photographing a card required for payment. The camera module 801 may recognize card information (eg, card company, card number, card expiration date, card owner, etc.) marked on the card through an optical character reader (OCR) function. Alternatively, the user may input necessary card information into the electronic device using an input device (eg, a touch panel, a pen sensor, a key, an ultrasonic input device, or a microphone input device) included in the electronic device.

According to an embodiment, the acceleration sensor 803 or the gyro sensor 805 may acquire the position state of the electronic device during payment. The obtained location information of the electronic device (eg, the electronic device 101) is transmitted to the processor 850, and the processor is the strength of the magnetic field transmitted from the MST module 810 to the POS based on the obtained location state of the electronic device. (Intensity of current) may be adjusted or, if there are a plurality of coil antennas, a coil antenna to be used may be selected. According to an embodiment, the MST control module 830 may include a data reception module 831 and an output conversion module 833 . The data receiving module 831 may receive a logical low/high type pulse signal including payment information transmitted by the processor 850 or a security module (eg, eSE). According to an embodiment, the data received by the data receiving module 831 may have the form of track data of a magnetic stripe of a magnetic card. For example, the received data may be in the form of inserting a token and payment verification data into at least one format among the formats of tack 1, 2, and 3 of the magnetic stripe.

The output conversion module 833 may include a circuit that converts the data recognized by the data reception module 831 into a necessary form in order to transmit the data to the MST module 810 . The circuit may include, for example, an H-Bridge for controlling the direction of the voltage supplied to both ends of the MST module 810 . The H-Bridge may include a circuit structure connected in an H shape using a four switch structure.

According to one embodiment, based on the card information input through the camera module 801 or an input device (eg, a touch panel, a pen sensor, etc.), the electronic device is a card company through a communication module (not shown). / Receive payment information (eg, track1/2/3 or token information) included in the magnetic stripe of the magnetic card from the bank server and use it in the memory 860 or a separate security module 236 (eg, eSE) can be saved in the form.

According to an embodiment, the tokens delivered to the POS through the MST module 810 and the NFC module 820 may be different from each other even if the underlying card is the same. For example, if the last four digits of a token (eg, digital card number) delivered to an external device (eg, POS) through the MST module 810 are 1111, an external device (eg, POS) through the NFC module 820 ), the last four digits of the token (eg digital card number) may be 2222.

9 illustrates a payment system 900 , in accordance with various embodiments.

According to various embodiments, the payment system 900 may include an electronic device 910 and/or a plurality of servers. For example, the plurality of servers may be a payment server 920 , a first token server (token service provider) 934 , a second token server (token server, token service provider) 944 , or a first It may include a financial server (issuer or card network) 932 , a second financial server (issuer or card network) 942 , and a trusted service manager (TSM) 936 . The electronic device 910 may include, for example, a payment application (wallet application) 912 , a payment manager 914 , and/or a secure storage 916 . The payment server 920 may include, for example, a payment service server 922 and/or a token requester server (token requester, token requester server) 924 . A combination of the components of the first financial server 932 , the first token server 934 , and the TSM 936 may be implemented as one server (eg, the first management server). For example, the first management server 930 is (first financial server and first token server) or (first financial server and TSM) or (first token server and TSM) or (first financial server and TSM) , (the first financial server and the first token server and the TSM) may be configured as a combination. The second financial server 942 and the second token server 944 may be implemented as one server (eg, the second management server 940).

According to various embodiments, the payment application 912 (eg, payment application 612 ) may include, for example, a Samsung ^Pay application. The payment application 912 may provide, for example, a payment-related user interface (eg, a user interface (UI) or a user experience (UX)). The payment-related user interface may include a wallet UI. /UX) For example, the payment application 912 may provide a user interface related to card registration, payment, or transaction. ), for example, may provide an interface related to card registration through a character reader (eg, optical character reader/recognition (OCR)) or external input (eg, user input). ) may provide an interface related to user authentication through, for example, identification and verification (ID&V).

According to various embodiments, the payment application 912 may perform a payment transaction using the payment application 912 . For example, the payment application 912 may provide a payment function to the user through Simple Pay, Quick Pay, or a specified application execution. The user may perform a payment function using the payment application 912 and receive information related to the payment function.

According to various embodiments, the payment manager 914 may include information related to a card company. For example, the payment manager 914 may include a card company software development kit (SDK).

According to various embodiments, the secure storage 916 may include a secure module 236 and a secure area (eg, a trusted execution environment (TEE)). A payment related program (eg, applet, trusted application) issued by the first financial server or the second financial server may be installed. According to one embodiment, the payment-related program may generate payment information (eg, token, token cryptogram, time authentication code, number of payments) to be transmitted to the MST according to the track data format of the magnetic card. For example, the time authentication code is a value for checking the validity of payment information, and a specific time value may be used to generate the time authentication code. According to an embodiment, Coordinated Universal Time (UTC) information may be used as the specific time value. For example, the electronic device may acquire UTC information through network identity and time zone (NITZ) or network time protocol (NTP), and when an external server (eg, the first management server) also acquires UTC information, the electronic device and the external server can authenticate the time authentication code by synchronizing time. An external server may also acquire a specific time value using the same method as the electronic device (eg, NITZ or NTP).

The secure storage 916 may store payment information (eg, a token or a key for generating a token cryptogram).

The TSM 936 may communicate with the payment-related program installed in the secure storage 916 to store and manage payment information (eg, delete or update information).

According to various embodiments, the payment server 920 may include a management server for electronic payment or mobile payment. The payment server 920 may receive, for example, payment-related information from the electronic device 910 and transmit it to the outside or may process the information in the payment server 920 .

According to various embodiments, the payment server 920 is configured between the electronic device 910 and the first financial server 932 using the payment service server 922 and/or the token requestor server 924 . can send and receive information (eg, token issuance request). The payment service server 922 may include, for example, a payment server (eg, Samsung payment server) 920 . The payment service server 922 may manage card information linked to a service account (eg, Samsung account) or a user account, for example. In addition, the payment service server 922 may include an API (application program interface) server related to the payment application 912 . Also, the payment service server 922 may provide, for example, the account management module (eg, account integration or Samsung account integration).

According to various embodiments, the token requestor server 924 may provide an interface for processing payment related information. For example, the token requestor server 924 may issue, delete, or activate payment-related information (eg, a token). Alternatively, it may be functionally connected to the payment manager 914 to control information required for the payment.

According to various embodiments, the payment application 912 included in the electronic device 910 and the payment service server 922 included in the payment server 920 may be functionally connected. For example, the payment application 912 may transmit/receive information related to payment to the payment server 920 . According to an embodiment, the payment manager 914 included in the electronic device 910 and the token requestor server 924 included in the payment server 920 may be functionally connected. For example, the payment manager 914 may transmit and receive payment related information to the token requestor server 924 .

According to various embodiments, the first financial server 932 and the second financial server 942 may manage data for issuing payment related information (eg, a token). For example, the first financial server 932 may request the first token server to issue another second payment information related to the first payment information issued by the second token server. In addition, the first financial server 932 stores and manages information (eg, token ID) that can confirm that the first token and the second token are related tokens when a token issuance is requested to the first token server 934 . can do.

According to one embodiment, the first payment information (eg digital card number, token or/and key for generating token cryptogram) and second payment information (eg digital card number, token or/and token cryptogram) ) may be tokens each issued according to a transmission method (eg, MST, NFC) used for payment by the electronic device 910 . For example, the first payment information may be used when making a payment using MST, and the second payment information may be used when making a payment using NFC. However, the opposite case is also possible, and there may be a case where the first payment information and the second payment information are the same. The token may mean a digital card number replacing the PAN. At least a portion of the first payment information or at least a portion of the second payment information is transmitted from the electronic device 910 to the outside through the POS device or network of the store, and the financial server may check the token to determine whether to approve the payment .

According to various embodiments, the first token server 934 and the second token server 944 may issue payment-related information (eg, a token) or manage payment-related information. For example, the first token server 934 may control an operation cycle (life cycle) of a token, and the operation cycle may include a creation, modification, or deletion function. Also, the first token server 934 may include, for example, a token management server, token provisioning, identification and verification (ID&V, identification and verification), renewal, or life cycle management. can be performed. In addition, it is possible to perform integration (integration) of information related to the financial server.

According to various embodiments, the TSM 936 may install the first token and/or the second token issued by the first token server 934 and the second token server 944 in the secure storage 916 . . In addition, a payment-related program for creating and managing payment information including the corresponding token may be installed.

10 illustrates an electronic device supporting a payment method using near field communication (NFC) according to various embodiments of the present disclosure.

Referring to FIG. 10 , the electronic device 1000 may be configured to include, for example, a processor 1001 , an NFC controller 1003 , an NFC RF module 1005 , and a secure element 1007 . can

The processor 1001 may control the overall operation of the electronic device. The processor 1001 may be a processor that does not support the TEE or a processor that supports the TEE.

In the case of an NFC module built into an electronic device (eg, a smartphone), it is connected to a rich OS such as Android (Android ^TM ), and the chipset and security of the low-security OS (or Rich OS, OS operating in the normal area) It may be a structure used as an interface for connecting regions, but is not limited thereto.

The NFC controller 1003 may process data based on the NFC communication method. For example, it can operate in three communication modes: card emulation, reader/writer, and peer to peer (P2P). The card emulation mode is a method of transmitting authentication information stored in the security module 1007 to an external reader, and can be applied to a payment function, a transportation card function, a user authentication function such as an ID card, and the like. The reader mode may be a method of reading external tag information. P2P is a mode that supports data exchange between devices, and data exchange such as electronic business cards, contact information, digital photos, and URLs can be performed.

The NFC RF module 1005 demodulates a signal received from the antenna based on the corresponding demodulation method and provides a demodulated signal to the NFC controller 1003, or modulates data from the NFC controller 103 based on the corresponding modulation method. It can transmit through an antenna.

The secure element module 1007 may store information related to a transaction or authentication. For example, information related to a transaction or authentication may include information requiring security, such as a primary account number (PAN), a token, and an encryption key. The PAN includes credit card information and means a card unique number, and the credit card unique number may be unencrypted information. The token may be used as information replacing the unique number of the credit card. The PAN or token may be information used for electronic payment, and the encryption key may be used to generate encryption data for payment authentication. The token and the PAN may be transmitted together with the generated encrypted data.

The security module 1007 may be accessible only by the NFC controller 1003 , and the processor 1001 may not have an authority to access the security module 1007 .

In various embodiments, since the NFC module of the electronic device is connected to the OS of the normal area, the NFC module may perform an interface connecting the chipset of the OS of the normal area and the security area. Access to the secure area with a high security level may be possible only through the controller inside the NFC module.

The NFC controller 1003 , the NFC RF module 1005 , and the security module 1007 may be implemented as a single chip or package. Hereinafter, one package including the NFC controller 1003 , the NFC RF module 1005 , and the security module 1007 may be an NFC module.

11 illustrates a payment transaction using a token, according to various embodiments. Components described in FIG. 11 may be identical to components of the payment system described above. According to an embodiment, the electronic device 910 may perform a payment transaction using NFC and/or MST. The following operation describes a payment transaction using NFC and/or MST as an example, but various embodiments of the present invention are not limited thereto.

Operation 1111 describes a method of transmitting payment information (eg, token, token cryptogram) from the electronic device 910 to the POS 1101 using NFC. For example, when a payment transaction is started, the electronic device 910 may be waiting to detect an external NFC signal. At this time, upon receiving an active signal from the POS 1101, the electronic device 910 may generate an NFC signal to transmit the first payment information.

Operation 1113 describes a method of transmitting payment information (eg, token, token cryptogram) from the electronic device 910 to the POS 1101 using the MST. For example, when a payment transaction is started, the electronic device 910 may transmit the MST signal to the magnetic signal reader of the POS 1101 by including the second payment information in the track data format. According to an embodiment, the Track data format may include an authentication code generated using a specific time. For example, the electronic device 910 generates an authentication code using UTC obtained from NITZ or NTP, and puts the second payment information and the authentication code in the Track data format to transmit the MST signal to the magnetic signal reader of the POS 1101. can be sent to

In operation 1115 , the POS 1101 may transmit the first payment information (operation 1111 ) or the second payment information (operation 1113 ) received from the electronic device 910 to the first financial server 932 . According to an embodiment, the first financial server 932 may authenticate the first payment information (operation 1111 ) or the second payment information (operation 1113 ) received in operation 1115 . For example, the first financial server 932 checks the authentication code made using time information or time information included in or transmitted together with the second payment information (operation 1113 ), and the second payment received over a set time period The information (operation 1113 ) may be transmitted to an external device (eg, POS, second financial server) as a result of failure in payment authentication. The authentication method described above may be similarly performed in the second financial server.

Operation 1117 may describe a method in which the first token server 934 changes the second payment information to the first payment information when the information received by the first financial server is the second payment information. For example, when the information received by the first financial server is the second payment information, the first financial server may transmit the second payment information to the first token server. The first financial server may match the first payment information with the second payment information when issuing the second payment information (refer to FIG. 9 ). In the payment transaction, first payment information matching the second payment information may be checked using the matched information, and related first payment information may be checked.

In operation 1119 , the first financial server 932 may request the second financial server 842 to authenticate the first payment information.

In operation 1121 , the second financial server 942 may transmit the authentication for the received first payment information to the POS 1101 . According to the authentication result, the POS 1101 may output a receipt of transaction completion or may display a transaction failure message.

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

12, the electronic device includes a processor 1200, a UICC 1202, a memory 1204, an input device 1206, a display module 1208, a baseband module 1214, an RF module 1216, It may include a first communication module 1210 and a second communication module 1212 .

The processor 1200 may control the overall operation of the electronic device. For example, processing and control for voice calls and data communication may be performed, and payment service functions may be processed by executing payment applications in various embodiments in addition to normal functions. In addition, the processor 1200 may operate in a rich execution environment (REE)/trusted execution environment (TEE). The TEE can store, execute and protect sensitive data such as authentication information in a secure environment. The REE may process data in an environment in which security is weaker than that of the TEE.

For example, the processor 1200 may detect a request for transmission of information related to payment or authentication when there is a user input for transmitting authentication information or when the electronic device approaches or contacts a reader of a point of sales (PoS) device. have. That is, the processor 1200 may receive a command to transmit authentication information through a user input (or user interface) or may receive a request for authentication information from the PoS device. In addition, the processor 1200 may determine a communication method for transmitting the requested authentication information. For example, when the requested authentication information is related to the payment method based on the first communication module 1210, the processor 1200 selects the first communication module 1210, and the requested information is transmitted to the second communication module When related to the payment method based on 1212 , the second communication module 1212 may be selected.

According to an embodiment, the processor 1200 may acquire authentication information corresponding to the authentication information transmission request from a security module that collects authentication information corresponding to each communication method. For example, the security module may store the first authentication information used for the payment method based on the first communication module 1210 and the second authentication information used for the payment method based on the second communication module 1212 .

In addition, the processor 1200 may transmit the obtained authentication information (eg, first authentication information or second authentication information) through the first communication module 1210 or the second communication module 1212 .

According to an embodiment, the security module may be implemented in various forms. For example, the security module may be included in a part or the entire area of the internal memory 1204 or the Universal IC Card (UICC) 1202 of the electronic device. Alternatively, it may be implemented inside the first communication module 1210 or the second communication module 1212 .

In various embodiments, the security module may be implemented as an embedded secure element as a separate chip, or may be implemented by mounting on a small removable flash memory card (micro SD).

According to one embodiment, the security module may be implemented in the form of one package by being combined with another component inside the processor 1200 .

The processor 1200 may access the secure area in the TEE environment and may not access the secure area in the REE environment. Alternatively, only specific modules (eg, the second communication module 1212 and the first communication module 1210) may access the security area even if the TEE environment is not present.

Examples of obtaining at least one piece of authentication information from at least one security module in response to a request for transmission of information related to the transaction or authentication will be described with reference to FIGS. 14 to 31 below.

According to an embodiment, the processor 1200 may process the at least one piece of authentication information and transmit it through at least one communication module (eg, the first communication module 1210, the second communication module 1212). have. For example, the electronic device generates encrypted data by using the encryption key among information related to a transaction or authentication such as a PAN, a token, and an encryption key, and uses the token of information related to the transaction or authentication and the generated encrypted data together. The transmission may be performed through at least one of the first communication module 1210 and the second communication module 1212 .

In the following description, a description of the processing and control of the typical processor 1200 will be omitted.

Memory 1204 may include program memory, data memory, nonvolatile memory, and the like. The program memory may store a program for controlling the overall operation of the electronic device. The program memory may use a flash memory. The data memory may perform a function of temporarily storing data generated during operation of the electronic device. The data memory may use a random access memory (RAM). The nonvolatile memory may store system parameters and other storage data (phone number, SMS message, image data, etc.). The nonvolatile memory may use an EEPROM. According to the present invention, the memory 1204 may be used as a security area. In various embodiments, the memory 1204 may operate according to REE/TEE. For example, as shown in FIGS. 5A to 5C , the memory in the REE environment and the memory in the TEE environment may be configured as separate hardware chips. In addition, the memory of the REE environment and the memory of the TEE environment may be used with different addresses in one hardware chip. In various embodiments, the authentication information may be stored in the memory 1204 . For example, when the authentication information is transmitted through the NFC communication module, the authentication information may be acquired from the memory 1204 in the Host Card Emulation mode. In addition, the authentication information can be obtained from the memory 1204 even in the case of near field magnetic stripe data transmission. The authentication information may be stored in at least one of a memory of an REE environment or a TEE environment.

The input device 1206 includes numeric keys 0 to 9, a menu key (menu), a cancel key (delete), a confirmation key, a call key (TALK), an end key (END), an Internet access key, and navigation keys (up/ It has a plurality of function keys such as down/left/right) and may provide key input data corresponding to a key pressed by the user to the processor 1200 . The display module 1208 may display status information generated during operation of the electronic device, various moving images and still images, and the like. The display module 1208 may use a color liquid crystal display (LCD). In various embodiments, the display module 1208 may receive an authentication result from the processor 1200 and display the result.

The RF module (Radio Frequency module) 1216 lowers the frequency of the radio frequency (RF) signal received through the antenna 1218 based on the corresponding communication method and provides it to the baseband module 1214, and the baseband module ( The baseband signal from 1214 may be increased in frequency and transmitted through the antenna 1218 . The baseband module 1214 may process a baseband signal transmitted/received between the RF module 1216 and the processor 1200 . For example, the corresponding communication method is long term evolution (LTE), long term evolution-advanced (LTE-A), code division multiple access (CDMA), wideband code division multiple access (WCDMA), and universal mobile telephone system (UMTS). ), GSM (global system for mobile communications), and may be at least one of 5G communication method.

The first communication module 1210 may perform, for example, one-way (eg, transmission) communication. As an example of the unidirectional communication, a near field magnetic stripe data transmission communication method may be used. Also, the first communication module 1210 may process the first authentication information and transmit it to the PoS device.

The second communication module 1212 may perform, for example, bidirectional communication (eg, transmitting and receiving). As an example of the two-way communication, the second communication module 1212 may use an NFC communication method. Also, the second communication module 1212 may process the second authentication information and transmit it to the PoS device.

In various embodiments, when a payment method based on a two-way communication method (eg, an NFC communication module) is used, for example, when the electronic device approaches or contacts a reader of a PoS device, the second communication module 1212 performs a PoS By directly receiving the authentication information through a request from the device, the second communication module 1212 may transmit the second authentication information corresponding to the payment method based on the second communication module 1212 to the PoS device. When a payment method based on a one-way communication method (eg, near field magnetic stripe data transmission) is used, the first communication module 1210 cannot receive data from the PoS device and can only transmit data to the PoS device. Therefore, according to a transmission command of the authentication information from the processor 1200, the first authentication information corresponding to the payment method based on the first communication module 1210 may be transmitted to the PoS device. The UICC (Universal IC Card) 1202 may be a card including a subscriber identification module, and may be inserted into a slot formed at a specific location of the electronic device. The UICC 1202 may include unique identification information (eg, integrated circuit card identifier (ICCID)) or subscriber information (eg, international mobile subscriber identity (IMSI)).

Depending on the implementation, the first communication module 1210 or the second communication module 1212 is separated from the electronic device and a connector (eg, an audio jack (not shown)) or a USB connector of the electronic device. ) can be connected via

In various embodiments, the first communication module 1210 is not limited to a near field magnetic stripe data transmission method, and may be replaced with a module that outputs a barcode, a QR code, or audio data. For example, instead of the first communication module 1210, the display module 1208 for displaying a barcode or QR code may be used as a one-way communication module. Alternatively, a speaker outputting audio data may be used as a one-way communication module.

Similarly, the second communication module 1212 may use various other two-way communication methods instead of the NFC communication method.

13 is a flowchart for a method of operating an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 13 , the electronic device (eg, the processor 1200 of FIG. 12 ) may select a communication module for transmitting at least one piece of authentication information in operation 1300 . For example, when there is a user input for transmitting authentication information or when the electronic device approaches or contacts a reader of a point of sales (PoS) device, the electronic device may select a communication module for transmitting the authentication information.

For example, when there is a user input (eg, fingerprint authentication) for transmitting authentication information, the electronic device selects the first communication module 1210 and the electronic device is connected to a reader of a point of sales (PoS) device. Upon proximity or contact, the electronic device may select the second communication module 1212 .

According to the implementation, when a transaction for transmitting authentication information occurs (that is, when the PoS device supports the NFC communication method and the near field magnetic stripe data transmission method), the electronic device transmits the first communication module 1210 and the second communication module 1212 may all be selected.

In operation 1302 , the electronic device (eg, the processor 1200 of FIG. 12 ) acquires at least one authentication information from at least one of at least one security module or memory in response to a request for transmission of information related to the transaction or authentication can do. The authentication information may consist of at least one of a PAN, a token, and a key. For example, the token is digital data used in place of a user's credit card, and may be received from a server of the credit card company when the corresponding credit card is registered. The key may be periodically received from the credit card company or a server of the authentication center that distributes the key, or may be requested when necessary and stored in at least one of a security module or a memory. In addition, the key may be used to generate encrypted data for authentication for product payment.

Examples of obtaining at least one piece of authentication information from at least one security area will be described with reference to FIGS. 14 to 31 below.

The electronic device (eg, the processor 1200 of FIG. 12 ) processes the at least one piece of authentication information in operation 1304 to process at least one communication module (eg, the first communication module 1210 or the second communication module of FIG. 12 ) (1212)). For example, the electronic device may generate encrypted data through the key of the authentication information, and transmit it together with the token of the authentication information and the generated encrypted data. For example, the encrypted data generated by the token and the key may be transmitted in the form of a message. And the token may be dynamic data. The key may be dynamic data.

Meanwhile, a token and/or a key of authentication information may be classified according to an authentication type. For example, when the first authentication method is used, the first token and the first key may be used, and when the second authentication method is used, the second token and the second key may be used. According to various embodiments, the first authentication method may be a payment method using the near field magnetic stripe data transmission communication, and the second authentication method may be a payment method using NFC communication.

14 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 14 , an application processor (AP) 1401 corresponds to the processor 1200 of FIG. 12 , and a first communication module 1403 corresponds to the first communication module 1210 of FIG. 12 , and , and the second communication module 1405 may correspond to the second communication module 1212 of FIG. 12 . The first communication module 1403 and the second communication module 1405 may be electrically connected to the AP 1401 , and the security module 1407 may be electrically connected to the second communication module 1405 . Also, the first communication module 1403 and the second communication module 1405 may be functionally connected.

In various embodiments, the first communication module 1403 may be an MST module (eg, the MST module 810 ), and the second communication module 1405 may be an NFC module (eg, the NFC module 820 ). . The security module 1407 may be an embedded secure element (eSE).

The AP 1401 may detect a first authentication service transaction and transmit a first authentication service transaction command to the first communication module 1403 . According to various embodiments, the first authentication service transaction command may be a command to perform an authentication procedure based on the first communication module 1403 . For example, the input may be generated by a user.

Also, the AP 1401 may receive an authentication result corresponding to the second authentication information 1407 - 2 from the second communication module 1405 and control it to be displayed on the display module 1208 .

When receiving an authentication service transaction command from the AP 1401, the first communication module 1403 requests the first authentication information 1407-1 from the second communication module 1405 to the second communication module (1405). In addition, the first communication module 1403 processes the first authentication information 1407-1 (eg, generates encrypted data using a key and generates a token and the generated encrypted data in the form of a message) ) to the POS device.

The second communication module 1405 detects a second authentication service transaction when the electronic device approaches or is connected to the POS device, and acquires the second authentication information 1407-2 from the security module 1407 and the second authentication information 1407-2 may be processed and transmitted to the POS device. In addition, the second communication module 1405 may receive information on the authentication result as feedback and provide the result to the AP 1401 .

The security module 1407 can be accessed only by the second communication module 1405 and may be a storage space that the AP 1401 or the first communication module 1403 cannot access. In an embodiment, the security module 1407 may include the first authentication information 1407-1 and the second authentication information 1407-2.

In various embodiments, at least one piece of authentication information (eg, the first authentication information 1409 - 1) stored in the security module 1407 may be stored in a general memory 1409 electrically connected to the AP 1401. Here, the general memory 1409 may be accessed by the AP 1401 in the normal area.

15 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile short-distance payment service according to various embodiments of the present disclosure.

Referring to FIG. 15 , when the transaction of the first authentication service occurs in operation 1500 , the AP 701 proceeds to operation 1502 and transmits the transaction command of the first authentication service to the first communication module 1403 . have.

The first communication module 1403 may request the first authentication information for payment to the second communication module 1405 in operation 1504 .

The second communication module 1405 may obtain the first authentication information for payment from the security area 1507 in the second communication module 1405 in operation 1506 .

The second communication module 1405 may transmit the acquired authentication information for payment to the first communication module 1403 in operation 1508 .

In operation 1510 , the first communication module 1403 may process the authentication information and transmit it through the first communication module 1210 .

In various embodiments, after operation 1502 , the first communication module 1403 may acquire the authentication information from the memory 1409 in operation 1516 . The obtained authentication information may be transmitted in operation 1510 .

On the other hand, when the transaction of the second authentication service occurs in operation 1500 , the second communication module 1405 may proceed to operation 1512 to obtain second authentication information for payment settlement from the security module 1407 .

The second communication module 1407 may transmit the authentication information through the second communication module 1212 after processing the authentication information in operation 1514 .

16 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 16 , the AP 1601 corresponds to the processor 1200 of FIG. 12 , the first communication module 1603 corresponds to the first communication module 1210 of FIG. 12 , and the second communication The module 1605 may correspond to the second communication module 1212 of FIG. 12 . The first communication module 1603 and the second communication module 1605 may be electrically connected to the AP 1601 , and the first security module 1607 may be electrically connected to the first communication module 1603 . In addition, the second security module 1609 may be electrically connected to the second communication module 1609 .

In various embodiments, the first communication module 1603 may be at least one of an MST module (eg, the MST module 810 ) or an NFC module (eg, the NFC module 820 ). The second communication module 1605 may be at least one of an MST module (eg, MST module 810) or an NFC module (eg, NFC module 820). The first security module 1607 may be a first embedded secure element (eSE). The second security module 1609 may be a second embedded secure element (eSE).

The AP 1601 may detect a first authentication service transaction and transmit a first authentication service transaction command to the first communication module 1603 . Also, the AP 1601 may receive an authentication result corresponding to the second authentication information from the second communication module 1605 and control it to be displayed on the display module 1208 .

When receiving an authentication service transaction command from the AP 1601 , the first communication module 1603 obtains the first authentication information 1607-1 from the first security module 1607, and The authentication information 1607-1 may be processed and transmitted to the POS device.

The second communication module 1605 detects an authentication service transaction when the electronic device approaches or is connected to the POS device, and obtains the second authentication information 1609-2 from the second security module 1609. and process the second authentication information 1609-2 and transmit it to the POS device. In addition, the second communication module 1605 may receive information on the authentication result as feedback and provide the result to the AP 1601 .

The first security module 1607 is accessible only by the first communication module 1603, the second security module 1609 is accessible only by the second communication module 1605, and the AP 1601 ) or the first communication module 1603 cannot access the second security module 1609, and the AP 1601 or the second communication module 1605 accesses the first security module 1607 It may not be possible, it may be a storage space.

In various embodiments, the first authentication information 1607 - 1 may be stored in a general memory 1611 electrically connected to the AP 1601 . Here, the general memory 1611 may be accessed by the AP 1201 in a normal area.

17 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile short-distance payment service according to various embodiments of the present disclosure.

Referring to FIG. 17 , when the transaction of the first authentication service occurs in operation 1700 , the AP 1601 proceeds to operation 1702 and transmits the transaction command of the first authentication service to the first communication module 1603 . have.

The first communication module 1603 may obtain authentication information (eg, first authentication information) for payment settlement from at least one of the first security module 1607 and the memory 1711 in operation 1704 .

In operation 1706 , the second communication module 1605 may process the authentication information and transmit it through the first communication module 1603 .

On the other hand, when the transaction of the second authentication service occurs in operation 1700 , the second communication module 1605 may proceed to operation 1708 to obtain authentication information for payment from the second security module 1609 .

The second communication module 1605 may process the authentication information in operation 1710 and transmit it through the second communication module 1605 .

18 is a block diagram 1800 illustrating program modules to be executed in an execution environment 1801 of an electronic device (eg, the electronic device 101) capable of performing a payment function, according to various embodiments of the present disclosure. Referring to FIG. 18 , the execution environment 1801 may include, for example, an REE 1810 and a TEE 1820 .

According to one embodiment, the REE is for payment, for example, a payment application 1830 (eg, payment (application) 385), a payment manager 1840 (eg, payment manager 354), and a kernel 1850. ) (eg, the kernel 320). According to an embodiment, the payment application 1830 may include, for example, a payment management module 1831 , a server interworking module 1833 , an authentication module 1835 , and a peripheral device management module 1837 . In addition, the payment application of FIGS. 32 to 36 may be included.

According to an embodiment, the payment management module 1831 may perform operations for card registration, card authentication, card deletion, and payment. The payment management module may register the user's card. The electronic device (eg, the electronic device 101) may receive a card registration request from the user. The electronic device may acquire a card image by using the camera module. The payment management module may acquire the card image through the OCR module. The payment management module may receive information related to card information (eg, password, home address, email address, phone number, or account ID) from a user or obtain it from the payment server 720 .

According to an embodiment, the payment management module 1831 may display the registered card to the user through the display 160 . The user may modify at least some information of the registered cards (eg, card name, home address, phone number, number of payment attempts, or whether payment notification information is received, etc.). The payment management module 1831 may display transaction details for each card. The payment management module 1831 may display card information registered in a wearable device (eg, a smart watch) functionally connected to the electronic device.

According to an embodiment, the payment management module 1831 may perform a payment operation using a registered card. The user may select one of a plurality of cards registered for payment. The user may bring the electronic device to a point of sales (POS) 740 . The payment management module 1831 may display product information (eg, price) received from the POS 740 through the display 160 . The payment management module 1831 may perform user authentication (eg, fingerprint authentication) through the authentication module 1835 for payment. When authentication is completed, the payment management module 1831 may display notification information indicating that the payment is completed through the display 160 .

According to an embodiment, the electronic device (the electronic device 101 or the electronic device 710) may transmit payment information to the POS using at least one of the MST module and the NFC module. To increase the recognition rate, payment information can be transmitted to the POS by using the MST module and the NFC module at the same time. Alternatively, the transmission may be performed using the MST module, and if the payment fails, the transmission may be performed using the NFC module. A method of recognizing a case in which payment has failed may include receiving a notification from a POS or a 3rd party (eg, a financial institution) or exceeding a specified time. Various embodiments are not limited to the order, and vice versa.

According to an embodiment, the electronic device may receive a request for the user to delete at least one card among previously registered cards. The payment management module 1831 may delete information corresponding to the corresponding card from the memory 130 . The payment management module 1831 may request the payment server 720 to delete information corresponding to the at least one card.

According to an embodiment, the payment management module 1831 may check whether the card owner and the card registration user match. The payment management module 1831 may include, for example, an identification & verification (ID&V) module. The payment management module 1831 may perform user authentication through text, email, ARS, or phone call. In addition, authentication may be performed through an application issued by a card company or a bank. The card registered through the payment management module 1831 may be used after authentication.

According to an embodiment, the payment management module 1831 may include an OCR module. The OCR module can acquire images of human-written or machine-printed characters with a scanner and convert them into machine-readable characters. The electronic device may acquire an image of the card held by the user through the camera module. The OCR module can convert the image, letter, or number written on the card from the card image into machine-readable characters. The OCR module may acquire the user's card information (eg, card number, user name, or expiration date) through the converted character. The electronic device may obtain card information of the user through the OCR module and perform a card registration process.

According to an embodiment, the payment management module 1831 may display a barcode generated for payment through the display 160 . For example, the payment management module 1831 may receive a command for generating a barcode through which payment can be performed through a barcode reader from the POS 740 . The payment management module 1831 may generate a barcode based on the command.

According to an embodiment, the server interworking module 1833 may receive a payment-related message, a device-related message, or a service-related message from the payment server 720 or the token service provider 730 . The server interworking module 1833 may transmit the message to the payment management module 1831 .

According to an embodiment, the server interworking module 1833 may include, for example, a push management module and an account management module. For example, if the message received from the payment server 720 is in the form of a push notification associated with a token, the push management module processes the received message, and the received message is account-related information (eg, Samsung). account), you can process messages received from the account management module.

According to an embodiment, the push management module may calculate and handle information about a push notification or a push message received from the payment server 720 . The push message may be delivered to the server interworking module 1833 inside the payment application 1830 through the payment relay module 1841 inside the payment manager 1840 or 354, and directly to the payment application 1830 can be transmitted as At least some of the transmitted push messages may be transmitted to the payment management module 1831 to update card-related information and to be synchronized with the payment server 720 .

According to one embodiment, the payment service 720 may include an account server that manages account-related information or a token requestor server that provides payment-related information. The account server and the token requestor server may be implemented as separate devices (eg, server 106), or may be included in one device.

According to an embodiment, the message information received from the push management module includes permission setting (eg, token provisioning), suspension (eg, token suspension), disposal (eg, token disposal), and state transition (eg: token provisioning) as shown in Table 1 below. Token status change), additional issuance (eg token replenishment), and payment confirmation (eg transaction notification) may include token and payment-related information.

Messages sent/received from the account management module include lost electronic device verification function (eg lost device, find my mobile), remote block (eg remote lock/unlock), membership management (eg loyalty/membership cards), and web linkage. It may include at least a part of information related to the electronic device, such as a function (eg, website portal-online).

push management use case details Token Token provisioning withID & V From an external server to the push management module in the electronic device, the card information for the purpose of identification and verification is sent down for token installation and authentication Token suspension Passed from an external server to the push management module in the electronic device to stop using the token Token resume Delivered to resume use of token from external server to push management module in electronic device Token disposal Delivered for token revocation from external server to push management module in electronic device Token status change Delivered for card status change from external server to push management module in electronic device Token Replenishment Delivered for additional token issuance from the external server to the push management module in the electronic device Transaction Notification Delivery of token payment details from the external server (payment server) to the push management module in the electronic device Device Lost Device (Find my mobile) Delivery of loss history information between the external server (service server) and the account management module in the electronic device Remote lock /unlock Transmission of remote device blocking command between the external server (service server) and the account management module in the electronic device Loyalty/Membership cards Transfer of membership information between the external server (service server) and the account management module in the electronic device Website (online) Supports web interworking function between an external server (service server) and the account management module in the electronic device

According to one embodiment, if the token provisioning ID & V information obtained from the payment management module is successfully transferred to the external server through the payment server 720 and the delivered token-related information is validated, an example For example, the “push token {id} status changed” message may be received from the server interworking module 1833 and delivered to the payment management module 1831 .

According to an embodiment, the card information suspension (eg, token suspension) information obtained from the payment management module 1831 of the electronic device transmits a stop command of the payment server 720 to the payment application 1830 to make a mobile payment It is possible to switch the card setting state for , from an active state to an inactive state.

According to an embodiment, when the electronic device is lost, the payment server 720 may delete or temporarily suspend all token information stored in the payment server 720 . A push message may be transmitted to synchronize this with the payment application 1830 . The payment server 720 may be transmitted to the payment application 1831 through the payment relay module 1831 or the server interworking module 1833 (eg, a push management module, an account management module).

Referring to Table 2, the contents of the push API supported by the electronic device and the payment relay module 1831 may be divided according to the payment relay module 1831 and implemented separately.

API Description type validation device.push Contains push platform Json required device.push.spp.id Samsung Push ID. String required device.push.gcm.id Google Push Id. String optional

According to an embodiment, the account management module manages information such as a user's unique identifier (eg, Samsung account id or device id), card, or membership exchanged with the payment server 720 in the payment application can do. The user identifier is a unique identifier (eg, model name, MAC address, IMEI, unique identifier of an account or electronic device related to an account subscribed by a user or an electronic device to manage cards (eg, Visa or Master Card) of multiple operators) number (serial number), UUID, or ID (ID, etc.). In addition, the unique identifier may be a value generated and transmitted by the payment server 720 through the account.

The account management module may manage registration, addition, deletion, duplicate registration, suspension of use, or resumption of use of a card using the user's account or electronic device identifier. In addition to this, even when card information is exported (imported/exported) between an electronic device and a wearable device, registration, addition, deletion, duplicate registration check, suspension of use, Or you can manage resumption of use, etc.

In this case, in the account-based management method, a plurality of electronic devices or multiple users sharing one account are managed to use a unique account (eg, a Samsung account) for each electronic device, or to manage a plurality of electronic devices with one account. can be

According to an embodiment, the first card (eg, Visa card) and the second card (eg, master card) information generated through the optical character recognition module (eg, OCR module) of the payment management module 1831 is a Samsung account The card can be registered based on the account created during registration (eg, registration02@samsung.com). In this case, the registered information may be synchronized with the payment server 720 based on the created account.

According to an embodiment, the membership information generated through the barcode interface is the first card (eg, Samsung point card) based on the account (eg, registration01@samsung.com) created when signing up for a Samsung account. (Samsung points card) and a second card (eg, CJ membership points card) can be registered. The registered information may be synchronized with the payment server 720 based on the created account.

In addition, the user can determine the active / inactive state of the card based on the account after logging in in the payment application and transmit it to the payment server 710 using the account management module 1831. Conversely, the server management web page ( Account-based card status can be managed toggle (eg server portal). In addition, the account management module transmits card information (eg Visa card ID & V) and membership information (eg CJ membership points, registraion001@Cj.com) associated with the service account (eg registration01@samsung.com) with the server. It can be managed in conjunction. The membership information may be automatically accumulated or deducted by linking payment processing information (eg, payment amount) and membership accumulation information (eg, point scores, mileage, etc.) when paying by card.

As such, when a payment application including an account management module is installed, the user's account login (log in or sign in) process can be used in any device to continuously link and use the setting status of some or all of the existing registered cards. In addition, membership information, which has a relatively low authentication security level, is registered and linked to the user's account, thereby reducing the additional authentication process.

According to an embodiment, the authentication module 1835 may display a card for payment or a user interface (UI) for performing user authentication through the display 160 . The authentication module may include, for example, a biometric information module.

According to an embodiment, the biometric information module may acquire the user's biometric information. The user's biometric information may include, for example, fingerprint, iris, face image, voice, heart rate, or blood pressure information. The electronic device may acquire the user's biometric information through the sensor module. For example, the user's fingerprint information may be acquired through a fingerprint sensor. Alternatively, the electronic device may acquire the user's iris information through the camera module. The biometric information module may display a user interface (UI) for obtaining the user's biometric information through the display 160 .

According to one embodiment, the biometric information module accesses a secure memory (eg, a built-in secure element (eSE)) or a secure environment functionally connected to the electronic device when a user attempts to make a payment using card information registered in the electronic device. Authentication can be performed to obtain secure data (eg tokens) from available memory). The electronic device may acquire the user's biometric information (eg, fingerprint or iris) through the biometric information module for user authentication. The obtained biometric information may be transmitted to the biometric information management module 1843 of the payment manager 1840 . According to an embodiment, the secure memory may be a memory including data stored with an encrypted key.

According to an embodiment, the biometric information module 1843 may perform payment using card information and biometric information registered in the electronic device when a user performs an electronic payment on an Internet web page. A user may perform authentication to obtain security data (eg, a token) from a memory or security module functionally connected to the electronic device (eg, a memory accessible in an eSE or secure environment). When user authentication is successfully performed in the electronic device, it can be linked with an external server to perform fast automatic authentication (eg, FIDO: fast identity online) without an electronic payment process on a separate Internet web page. That is, it is possible to perform fast authentication by linking the authentication process required for online payment with the biometric information module.

According to an embodiment, the electronic device may designate a user's fingerprint and a payment card. For example, when the user performs authentication using a fingerprint in a payment application, the right thumb may be designated as a Visa card, the right index finger as a Master Card, or the like, so that the user can make payment with the corresponding card at the moment of authentication.

According to an embodiment, the peripheral device management module 1837 may manage an external device functionally connected to the electronic device. The peripheral device management module 1837 may include, for example, an MST peripheral device module and a wearable device module.

According to an embodiment, the MST peripheral device module may output whether a wired/wireless connection between an MST accessory (eg, a fob-type device manufactured by LoopPay ^TM ) and an electronic device is connected, and provide a user interface (UI) suitable for the user based on this. The UI can process and print card registration, deletion, or payment while the MST accessory is connected. The MST peripheral device module may store various card information required for payment in an electronic device or a separate memory within the MST accessory while connected to the MST accessory. This may enable payment to be performed independently of the electronic device or the MST accessory even when the MST accessory is not connected.

The wearable device module may output a wired/wireless connection between the wearable device (eg, a watch, a headset, glasses, or a ring) and an electronic device, and provide a user interface (UI) suitable for the user based thereon. The wired/wireless connection may include various interfaces such as BT, BLE, WiFi, Zigbee, or Z-wave, and may be implemented by applying a specific accessory protocol (samsung accessory protocol (SAP)). The UI may perform card registration, deletion, and payment execution processes while the wearable device is connected and output the same. In the card registration, deletion, and payment execution process, the wearable device module may output whether a secure session based on a short distance with the wearable device is generated, transmit/receive a user input value on the electronic device or the wearable device, and display it. The user's input includes various card information required for payment and other additional authentication information (eg, PIN, user-specific pattern-related data, fingerprint recognition-related data, wearable device bezel unit or touch input value of the display 160, etc.) can do.

According to an embodiment, the electronic device may share one piece of payment information with a wearable device or an accessory. For example, information on one Visa card may be stored in both the wearable device and the electronic device. According to an embodiment, the electronic device may store other card information generated from one card information in the wearable device or the accessory, respectively. For example, one token issued from one piece of Visa card information may be stored in an electronic device and the other token may be stored in an accessory or wearable device. According to an embodiment, when one token issued from one card information is stored in an electronic device and the other is stored in an accessory or wearable device, when a payment module of one device is activated, a payment module of another device can be disabled. For example, when one token issued from one Visa card information is stored in an electronic device and the other is stored in an accessory or a wearable device, payment by the electronic device may be deactivated when paying with the wearable device. In addition, when payment is performed by the electronic device, payment of the wearable device may be deactivated.

According to an embodiment, the payment manager 1840 may include, for example, a payment relay module 1841 , a biometric information management module 1843 , and a secure environment relay module 1846 . According to an embodiment, the payment relay module 1841 may relay a card or information (eg, a token) corresponding to the card to the payment application, the kernel, or the payment server 710 . The payment relay module 1841 may make an offline payment through a communication module (eg, an NFC module, an MST module). A payment method using NFC can be driven through POS, and a payment method using MST can be driven by a user input. Also, the payment relay module 1841 may make an online payment through a communication module (eg, a cellular module, an RF module, a WIFI module, etc.).

According to an embodiment, the payment relay module 1841 may manage the status of a card or information (eg, token) corresponding to the card (eg, card/token lifecycle management). The payment relay module 1841 may provide at least one application programming interface (API) related to payment to the payment application 1830 .

According to one embodiment, the payment relay module 1841 is an interface provided by at least one payment-related system services, a payment service for accessing the payment module, and a trustzone-based (TIMA) for kernel integrity authentication. Integrity measurement architecture), fingerprint recognition result inquiry (eg, both secure/non-secure mode are supported), and may further include system service interfaces that provide a secure UI for inputting a PIN or a primary account number (PAN). The payment relay module 1841 may include an encryption library to transmit a message or a command to the TEE 1820 . The payment relay module 1841 may exchange messages or commands with the TEE 1820 through the encryption library.

According to an embodiment, the payment relay module 1841 may include a card management function that provides functions such as card addition, deletion, and update as a general card management function. The payment relay module 1841 may include a first payment software development kit (SDK) or a second payment SDK. The first payment SDK (eg, Samsung SDK) may be embedded in the electronic device. The second payment SDK may be provided by a card company or a bank, and may be installed in the electronic device. The payment relay module 1841 may select a corresponding payment SDK according to card information using the first payment SDK or the second payment SDK. You can also set a default card or choose a card other than the default card.

According to one embodiment, the payment relay module 1841 is a general token and key management function, such as initial permission setting (token provisioning), additional issuance (token replenishment), suspension (token suspension), resume (token resume), and revocation (token). disposal) and the like may be transmitted to the payment server 710 .

According to an embodiment, the payment module 1821 may obtain a token and a token cryptogram from an electronic device or another external electronic device. According to one embodiment, the token cryptogram may be used in the same meaning as cipher information, cipher, cryptogram, cipher, and cipher method. According to an embodiment, the token cryptogram may include data for checking the validity of a payment transaction. According to one embodiment, the payment module 1821 may include the security application of FIGS. 32 to 35 . For example, the received time information may be delivered to a security module (eg, eSE). According to another embodiment, the TA may receive track 2 format data from a security module (eg, eSE), generate payment verification data, and insert the data into track 2 format data. The token and a key (eg, a limited used key (LUK) or a single used key) capable of generating a token cryptogram may be stored in the REE 1810 or the TEE 1820 . In addition, when storing the token and the key in the REE 1810, the payment module of the TEE may encrypt and store the TEE 1820 using the key (eg, device root key (DRK)). . When the electronic device performs payment, the payment relay module 1841 may obtain the encrypted token in a decrypted state through the payment module. When the key or token for generating the token cryptogram is stored in the TEE, the electronic device may store it in an encrypted form using the key of the TEE.

According to an embodiment, the payment relay module 1841 may receive a push message from a token service provider (TSP) 730 and deliver it to the payment application.

According to one embodiment, when the first payment SDK (provided by a card company or bank) provides its own token management function, the payment relay module 1841 further adds a function of relaying a token management function request to the second payment SDK when receiving a request for a token management function. may include For example, a payment relay module that has obtained a token or key through the SDK of the Visa card may transmit it to the payment module in the TEE 1820 using the Samsung SDK. According to one embodiment, the payment relay module 1841 is a host card emulation (HCE) capable of enabling a virtual card to be used in an electronic device only with software without a separate hardware device (eg, a security module or secure element (SE)) during payment. ) function can be further included in the payment framework. The HCE function may transmit a token and a token cryptogram using a POS-related message standard (eg, application protocol data unit (APDU)) through a communication module (eg, NFC).

According to one embodiment, the payment relay module 1841 may include a function of processing a message received from the POS. The POS-related message processing function may include a function of managing payment data to respond to the POS. The POS-related message interpretation function may further include a function of relaying the POS-related message to the first payment SDK when the first payment SDK provides its own POS-related message processing function. According to an embodiment, the payment relay module 1841 may include at least one database for storing the card data, token data, or transaction data.

According to an embodiment, the payment relay module 1841 may select at least one of a payment method using NFC and a method of payment using MST. For example, the method may include a method of first performing a payment with NFC and then paying MST, a method of first performing a payment with MST and then performing a payment with NFC, and a method of performing both NFC and MST payment. According to one embodiment, when payment is made with one communication module and then payment is performed with another communication module, the payment relay module does not respond to the result of performing payment with the communication module that performed the payment first, or the specified time After that, payment can be performed with another communication module.

According to an embodiment, when the payment relay module 1841 has both the token and the PAN information for one card, the payment may be performed using at least one. The payment relay module can check whether the POS can be paid with the PAN or the token can be paid. For example, the electronic device may receive payment possible information through BLE, and the payment relay module may check the information. Based on the verified information, the payment relay module may perform payment with a token if payment is possible with a token, and may perform payment with the PAN if payment with PAN is possible.

According to an embodiment, the payment relay module 1841 may further include an SDK provided by a payment network. The SDK may include token management, POS-related message processing, or a token/card database.

According to one embodiment, the secure environment relay module 1846 is a biometric information driver module 1851 or a secure environment driver module 1853 to use a function provided by the payment module 1821 or the biometric information module 1825. ) may further include a function of relaying so that the payment application can access. The payment relay module 1841 may include an encryption library in order to transmit a message or a command to the secure environment relay module 1846 . The payment relay module 1841 may exchange messages or commands with the secure environment relay module 1846 through the encryption library.

Various embodiments of the present invention may further include a secure environment relay module 1846 connected to the payment manager 1840 to use the function of the TEE security identifier processing module in a payment application.

According to an embodiment, the payment relay module 1841 may include a function of relaying an authentication request through PIN input of the payment application 1830 to the security identifier processing module 1823 of the TEE 1820 . A specific relay function will be described later with reference to FIG. 22 .

A general application may obtain success or failure when requesting fingerprint recognition. A payment trusted app may obtain a secure fingerprint result. The secure biometric result may be in an encrypted form by combining a one-time random number and success/failure. The one-time random number may be encrypted through a hardware key (eg, device root key (DRK)) of the TEE 1820 .

According to an embodiment, the payment relay module 1841 may transmit a message to the payment module 1821 to perform payment through the secure environment driver module 1853 to perform payment. The payment module 1821 may notify the payment relay module 1841 through the secure environment driver module 1853 that an authentication operation is required. The payment relay module 1841 may instruct the biometric sensor 240I to acquire biometric information through the biometric information management module 1843 and the biometric information driver module 1851 for an authentication operation. In addition, the payment relay module 1841 may transmit an authentication confirmation message to the biometric information module 1825 of the TEE 1820 through the biometric information management module 1843 and the secure environment driver module 1853 . The biometric sensor 240I may be acquired from the biometric information module 1825 of the TEE 1820 . The biometric information module 1825 may determine whether the user is the same user by comparing pre-stored biometric information of the user with information obtained from the biometric sensor. Based on the verified information, the biometric information module 1825 transmits whether or not authentication is performed to the biometric information management module 1843 through the secure environment driver module 1853, and the biometric information management module 1843 sends the payment relay module 1841 ) can be passed to The payment relay module 1841 and the biometric information management module 1843 may be configured as one or as separate modules.

According to an embodiment, the payment relay module 1841 may perform authentication through an external device. For example, the electronic device may request authentication for biometric information (eg, fingerprint or iris, etc.) from the payment server 720 (eg, a Samsung account server or a token requestor server). The payment server 720 may authenticate the user's biometric information and transmit a corresponding result to the electronic device. When authentication is completed, the payment relay module 1841 may perform a token provisioning process by delivering data including information indicating that authentication is complete to a token service provider. In addition, the electronic device may perform payment when authentication is completed according to the authentication result, and may not perform payment when authentication is not completed or is not authenticated.

According to an embodiment, the kernel 1850 may include, for example, a biometric information driver module 1851 and a secure environment driver module 1853 . The biometric information driver module 1851 may transmit a message transmitted from the biometric information management module 1843 of the payment manager 1840 to the biometric sensor 240I. The biometric information obtained from the biometric sensor may not be transferred to the module in the REE 1810 through the biometric information driver module, but may be transferred to the biometric information module 1825 in the TEE 1820 .

According to one embodiment, the secure environment driver module 1853 may serve as an interface for passing from a module in the REE 1810 to a module in the TEE 1820 . For example, in the case of Trustzone of ARM, which is an embodiment of TEE, the application processor performs REE and TEE operations in time division, and a separate data path for transferring messages from REE to TEE is implemented in hardware. can In this case, the driver module for accessing this hardware may be the secure environment driver module 1853 . The secure environment driver module may transmit a message about the operation of the module in the TEE to the module in the REE.

According to an embodiment, the TEE may include a payment module 1821 , a security identifier processing module 1823 , a biometric information module 1825 , and an MST driver module 1827 . The electronic device 701 may store data requiring relatively high security through the TEE 1820 in a safe environment and perform a related operation. The TEE 1820 operates on an application processor of the electronic device, and the trusted TEE determined in the manufacturing operation of the electronic device may mean a security area within the electronic device. The electronic device may operate data requiring relatively high security through the TEE based on a secure hardware structure. The TEE may operate by dividing the application processor and the memory area into a normal area and a security area. In addition, software or hardware requiring security can be operated only in a secure area. When the electronic device REE 1810 needs to perform an operation related to sensitive information, access to the TEE 1820 may be possible only through an API and a driver that can access the TEE 1820 . The TEE 1820 may pass limited data on related information to the REE. TEE may encrypt internally stored data through a hardware key (eg, device root key (DRK)). Data inside the TEE may not be interpreted by the REE unless there is a separate decoding process.

The TEE 1820 may transmit a message to an application inside the TEE (eg, a trusted application or a payment module) to another electronic device (eg, the token service provider 730 ) outside the electronic device.

According to an embodiment, the TEE may include a trusted OS and a trusted application. In addition, it may include an encryption module related to security, a driver capable of collecting data from hardware requiring security, and the like. A trusted application may include a payment module. In addition, payment information may be transmitted to the outside through a communication module. For example, payment information may be transmitted to the MST controller (MST control module 830) through the MST driver, or to the NFC controller (NFC control module 840) through the NFC driver and transmitted to the POS.

According to one embodiment, it is possible to check whether the integrity of the REE (1810). The electronic device may store the integrity of the image of the REE in the TEE 1820 . In the case of REE booting supporting TEE, the booting sequence is when the boot loader is executed, the TEE is booted, and the REE can be booted. When the TEE is booted, the integrity information of the REE inside the TEE can be checked and displayed to the user after the REE is booted. According to one embodiment, when the REE image is damaged by hacking or routing, it may be determined that there is a problem in integrity. In the event of an integrity problem, the TEE can be made inaccessible. For example, when the payment relay module 1841 tries to transmit a message or command to the TEE through the secure environment driver module 1853 , the kernel of the TEE may ignore the message or command or reject the message reception.

According to one embodiment, the payment module 1821 may be an application installed by a bank, a credit card company (eg, a Visa card or a Master card, etc.). The payment module may be at least one. In the electronic device, the user uses the payment management module 1831 to the payment server 720 (eg, mobile application platform, payment gateway, token requestor, token service provider, trusted service manager, or bank server) or token service provider When accessing 730 through the Internet and approval to install the payment module 1821, the token service provider 730 may perform an installation related operation. For example, the payment management module 1831 may obtain the card number and expiration date information of the plastic card through OCR and perform a card registration operation for installing the payment module 1821 in the server. Depending on the card/banking company, it connects to the token service provider 730 in the network through the payment relay module 1841 having connection information of each token service provider 730 to receive the installation file and receive the payment relay module 1841 may transmit the information to the TEE to install the payment module 1821 . This process can be called a provisioning process or a card registration process. The payment module 1821 of the TEE may have several modules. Each payment module cannot send and receive data within the TEE, and can be configured in an isolated form.

According to one embodiment, the payment module 1821 may be an application used for data communication with the payment server 720 . The payment module may include information such as a credit card, a debit card, and a membership card. The payment module may transmit and receive communication with the external electronic device through encryption. The encryption process may vary depending on the card manufacturer that has delivered the payment module. The server may control the state of the payment module. For example, the payment module may be activated, temporarily suspended, reactivated, or disposed of.

According to an embodiment, the payment module 1821 may store information related to card information. For example, a token (token) corresponding to the card information (eg, primary account number (PAN)), token reference ID, part of PAN, PAN product ID, token requestor ID, token assurance level, token assurance data , the validity period of a token, an encryption key, and a value (eg, one time password (OPT)) provided by the token service provider 730. The token is the token service provider It may be controlled by the state of 730. For example, a token may be activated, temporarily suspended, resumed, or disposed of. A token may be basically static information corresponding to card information (eg, PAN).

According to an embodiment, the payment module 1821 may determine a payment card when performing payment. For example, a payment module corresponding to a card selected by the user in at least one payment management module 1831 may be determined according to the user's selection. The payment management module may transmit the determined card to the payment relay module 1841 . The payment relay module may transmit the determined card information to the payment module 1821 through the secure environment driver module 1853 . The payment module may manage a list of cards used for actual payment from among the card information held. The card list used for the actual payment may be changed based on the determined card information. The change may be a method of increasing the priority of the determined card information in the card list or deleting card information other than the determined card information.

According to an embodiment, when performing payment, the payment module may create information used for payment based on information related to card information. Referring to Table 3, information used for payment includes token, token reference ID, part of PAN, PAN product ID, token requestor ID, token assurance level, token assurance data, validity period of token, token cryptogram, POS entry mode, It may be a token requestor indicator or the like.

Field Name Comment Payment Token The Payment Token number refers to a surrogate value for a PAN that is a 13 to 19-digit numeric value that passes basic validation rules of an account number, including the Luhn check digit. Payment Tokens are generated within a BIN range or Card range that has been designated as a Token BIN Range and flagged accordingly in all appropriate BIN tables. Payment Tokens are generated such that they will not have the same value as or conflict with a real PAN.
Transaction messages
The Payment Token number will be passed through the authorization, capture, clearing, and exception messages in lieu of the PAN.
The Payment Token number may optionally be passed from the Token Service Provider to the Card Issuer as part of the authorization request. Token Expiry Date The expiration date of the Payment Token that is generated by and maintained in the Token Vault. The Token Expiry Date field carries a 4-digit numeric value that is consistent with the ISO 8583 format.
Transaction messages
The Token Expiry Date is passed in lieu of PAN Expiry Date.
The value is replaced by the Token Service Provider with the PAN Expiry Date which is then passed to the Card Issuer as part of the authorization request. Last 4 Digits of PAN The last four digits of the PAN to be provided optionally through the Acquirer to the Merchant for customer service usage such as being printed on the consumer receipt. PAN Product ID The last four digits of the PAN to be provided optionally through the Acquirer to the Merchant for customer service usage such as being printed on the consumer receipt. PAN Product ID The PAN Product ID is an optional identifier used for determining the type of Card product that was tokenized. It may be included in cases where transparency of this information is necessary.
Transaction messages
The PAN Product ID may optionally be passed from the Token Service Provider to the Acquirer as part of the authorization response. POS Entry Mode This specification uses the POS Entry Mode field to indicate the mode through which the Payment Token is presented for payment. Each Payment Network will define and publish any new POS Entry Mode values as part of its existing message specifications and customer notification procedures.
Transaction messages
POS Entry Mode is an existing field that will be passed through the authorization, capture, clearing, and exception messages. Token Requestor ID This value uniquely identifies the pairing of Token Requestor with the Token Domain. Thus, if a given Token Requestor needs Tokens for multiple domains, it will have multiple Token Requestor IDs, one for each domain. It is an 11-digit numeric value assigned by the Token Service Provider and is unique within the Token Vault:
Positions 1-3: Token Service Provider Code, unique to each Token Service Provider
Positions 4-11: Assigned by the Token Service Provider for each requesting entity and Token Domain
Transaction messages
Token Requestor ID can be optionally passed through the authorization, capture, clearing, and exception messages. Token Assurance Level Token Assurance Level is a value that allows the Token Service Provider to indicate the confidence level of the Payment Token to PAN / Cardholder binding. It is determined as a result of the type of ID&V performed and the entity that performed it.
The Token Assurance Level is set when issuing a Payment Token and may be updated if additional ID&V is performed. It is a two-digit value ranging from 00 which indicates the Payment Token has no ID&V that has been performed to a value of 99 indicating the highest possible assurance. The specific method to produce the value is defined by the Token Service Provider.
Transaction messages
Token Assurance Level will be provided by the Token Service Provider.
The value may be optionally passed to the Card Issuer as part of the authorization request.
The value may optionally be passed to the Acquirer / Merchant in the authorization response, capture, clearing, and exception processing messages. Token Assurance Data This data provided by the Token Service Provider contains supporting information for the Token Assurance Level.
Transaction messages
This data may be optionally passed to the Card Issuer as part of the authorization request. Token Cryptogram This cryptogram is uniquely generated by the Token Requestor to validate authorized use of the Token. The cryptogram will be carried in different fields in the transaction message based on the type of transaction and associated use case:
NFC contactless transactions will carry the Token Cryptogram in existing chip data fields.
Other transactions, such as those originating from a digital wallet, may carry the Token Cryptogram in an existing field.
Transaction messages
The Token Cryptogram will be passed in the authorization request and validated by the Token Service Provider and / or the Card Issuer. Token Request Indicator An indicator used to indicate that the message is intended to authenticate the Cardholder during a Payment Token Request.

According to one embodiment, the payment module 1821 may generate a token cryptogram through a token service provider 730 or a payment server 720 (eg, a payment service server or a token requestor server). A key (eg, a limited used key (LUK) or a single used key) may be delivered. The key may be delivered through a data network or SMS.

The key may be exchanged between the electronic device and the token service provider 730 using a secure channel. The secure channel may be a logical channel for encrypting data exchanged by a key different from the key (eg, a method using a public key or a private key). In addition, a module for generating a key capable of generating a token cryptogram may be included in the payment module. The electronic device may receive the module for generating the key through the token service provider 730 or the payment server 720 . Alternatively, it may be included in the manufacturing operation of the electronic device. electronic device

According to an embodiment, the payment module may generate a token cryptogram using a key (eg, a limited used key or a single used key) capable of generating the token cryptogram. The payment module can use a different key according to a set rule, such as every transaction, a specific number of transactions, or a transaction within a specific time. The token service provider 730 may own a key paired with the key. The token service provider 730 may decrypt the encrypted token cryptogram through the paired key.

According to an embodiment, the payment module 1821 may generate a token cryptogram using a key capable of generating a token cryptogram. Details will be described later with reference to FIG. 46 .

According to an embodiment, when performing payment, the electronic device may transmit a message indicating that payment is to be performed in the payment application to the payment relay module 1841 . The payment relay module 1841 may determine whether to pay with MST or NFC. In the case of payment with MST, the MST driver in the TEE acquires the information necessary for payment (for example, token, token cryptogram, payment authentication data, part of PAN information, token validity period, etc.) from the payment module of the TEE. module 1827 . The MST driver module 1827 may transmit the information to the MST controller. The MST controller may transmit the information to perform payment. In addition, the MST driver module 1827 may include the functions of the MST driver module of FIGS. 32 to 35 .

According to one embodiment, the information may be transmitted to the payment application 1830 .

According to an embodiment, when paying by NFC, the electronic device may transmit information necessary for performing the payment to the NFC driver module of the TEE. The NFC driver module may transmit information necessary for performing the payment to the NFC controller. The NFC controller may perform payment based on the information.

According to an embodiment, when a payment is made through NFC, the electronic device may perform payment when a specified message is transmitted from the POS. For example, the NFC controller may deliver a designated message from the POS 750 to the NFC driver module when the NFC module detects it. The NFC driver module may transmit that the message has been delivered from the POS to the payment relay module 1841 of the REE. The payment relay module 1841 may generate a token cryptogram to perform payment. The token cryptogram may be generated in the payment module 1821 of the TEE using a key (eg, a limited used key or a single used key) capable of generating a token cryptogram. The generated token cryptogram may be transmitted to the REE. The payment relay module 1841 may transmit payment related information including the token and token cryptogram through a network module (eg, an NFC-related host card emulation module). The network module may transmit the payment related information to the POS through the NFC module.

According to an embodiment, the payment module may transmit information including the token, token validity period, token requestor ID, token cryptogram, and the like to the external electronic device. For example, the payment module may transmit the payment information to a point of sales (POS) 750 through the MST communication module. In addition, it can be transmitted to the POS through NFC communication modules.

According to an embodiment, the payment module may transmit/receive information specified in the payment operation to and from the POS 750 . NFC can be performed by first receiving information from the POS. In the case of MST, payment-related information including a token and token cryptogram may be transmitted to the POS based on an explicit input of a user or an algorithm inside the electronic device.

According to an embodiment, the biometric information module 1825 may store biometric information of a user using the electronic device and authenticate the user by comparing it with information received from a biometric sensor. The biometric information module 1825 may include a fingerprint information module, an iris information module, and the like. The biometric information module may collect information from the biometric sensor 240I. When the payment application shows on the display 160 to authenticate the user's biometric information, the user can transmit the biometric information through the biometric sensor. The authentication module of the payment application may transmit a message to collect biometric information to the biometric information driver module 1851 through the biometric information management module. The biometric information driver module may transmit the message to the biosensor. The biosensor may collect biometric information and transmit it to the TEE. The biometric information module of the TEE compares the stored user's biometric information to the authentication module of the payment application through the security environment driver module and the biometric information management module of the REE. The payment application may show whether the authentication is performed on a display. The user's biometric information may be stored in the TEE, stored in the REE in an encrypted state, or stored in the security module 236 (eg, eSE).

According to an embodiment, the security identifier processing module 1823 may obtain an input value necessary for an electronic device or related to payment-related authentication through a user input. For example, the input value may be a personal identification number (PIN) during payment. In addition, the input value may be card-related information. For example, it may be a primary account number (PAN), a card expiration date, or a card verification value (CVV). In addition, it may be a Chip PIN or an automated teller machine (ATM) PIN. The security identifier processing module 1823 may be displayed in the form of an application. A graphic library necessary for the application of the security identifier processing module to be drawn on the screen may be stored in the TEE 1820 . The graphic library stored in the TEE may be different from the graphic library in the REE 1810 . The security identifier processing module may perform user authentication based on an input value such as a PIN and transmit the result to the payment management module 1831 through the payment relay module 1841 . According to an embodiment, the secure environment relay module 1846 may receive an encrypted one-time random number (eg, nonce) transmitted through the secure environment driver module 1853 . The security identifier processing module 1823 may encrypt the input value obtained as the user input and the one-time random number using an encryption key (eg, device root key) in the TEE and transmit it to the secure environment relay module 1846 . . The secure environment relay module may transmit the encrypted input value and the one-time random number to the payment module 1821 through the secure environment driver module 1853 . The payment module may decrypt the input value and the one-time random number using a hardware key in the TEE. The payment module may confirm that the input value transmitted through the REE is intact by using that the value generated and the received value of the one-time random number are the same. The payment module may perform user authentication through the input value based on the integrity of the input value. The payment module may perform payment through user authentication. According to an embodiment, the factory reset may be an operation of returning a software image of the electronic device to a state shipped from an existing factory. The operation may be performed as an explicit operation of the user through the application. In addition, the module that determines and monitors the hacking under a specified condition (eg, when it is determined that the system has been hacked) may perform a factory reset. When the operation is performed, since data stored in the electronic device is reset, the user's payment related information may also be reset. The payment-related information may be stored in the payment server 720 . When the user accesses the payment server 720 based on an account, an operation of registering a card and installing a payment module may be performed again based on the payment-related information. When reset, the payment related module stored in the electronic device may notify the token service provider 730 through the payment server 720 to deactivate it. When the network of the electronic device is deactivated, the notification operation may not be performed. In this case, after the electronic device performs a factory reset, the electronic device may access the payment server 720 based on an account. The electronic device may check a list of cards registered in advance through the payment server 720 , and deactivate the card module or token of the electronic device registered in the token service provider 730 through the payment server 720 . can do. In addition, based on the card list of the payment server 720 , the electronic device may receive a payment module or token by performing card registration again.

19 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 19, the AP 1901 in the first mode and the AP 1903 in the second mode correspond to the processor 1200 of FIG. 12, and the first communication module 1905 is the first communication module 1905 in FIG. It may correspond to the first communication module 1210, and the second communication module 1907 may correspond to the second communication module 1212 of FIG. 12 . Here, the AP 1901 in the first mode may be the processor 1200 operating in a normal area (eg, REE), and the AP 1903 in the second mode operates in a secure world (eg, TEE). It may be an operating processor 1200 . According to various embodiments, the AP 1901 of the first mode and the AP 1103 of the second mode may be one processor or a processor of a separate configuration.

In various embodiments, the first communication module 1905 may be an MST module (eg, the MST module 810 ), and the second communication module 1907 may be an NFC module (eg, the NFC module 820 ). . The secure module 1909 may be an embedded secure element (eSE).

The first communication module 1905 and the second communication module 1907 are functionally connected to the AP 1903 of the second mode, and the security module 1909 is electrically connected to the second communication module 1907 or may be electrically connected to the AP 1903 of the second mode.

The AP 1901 in the first mode may execute and process the corresponding application in the normal area.

The AP 1903 of the second mode may execute and process applications requiring security (eg, digital rights management (DRM), payment application, business information processing application, banking application) in the security area. . All security-related functions, including interfacing with a secure peripheral device, may be performed in the security area. 19, the AP 1901 of the first mode and the AP 1903 of the second mode are shown separately, but the AP 1901 of the first mode and the AP 1903 of the second mode are one It can be implemented by a processor, and the normal area and the secure area can operate by time sharing.

The AP 1901 in the first mode may detect a first authentication service transaction and transmit an authentication service transaction command to the AP 1903 in the second mode.

The AP 1903 in the second mode may transmit an authentication service transaction command and first authentication information 1909_1 to the first communication module 1905 . The AP 1903 in the second mode may acquire the first authentication information 1909 - 1 by accessing the security module 1909 . In addition, the AP 1903 in the second mode may receive the authentication result corresponding to the second authentication information 1909-2 from the second communication module 1907 and control it to be displayed on the display module 1208. have.

According to implementation, when the AP 1903 in the second mode receives a request for the second authentication information 1909-2 from the second communication module 1907, the second authentication information from the security module 1909 (1909-2) may be acquired and transmitted to the second communication module 1907.

When the first communication module 1905 receives an authentication service transaction command and the first authentication information 1909-1 from the AP 1903 in the second mode, the first communication module 1905 receives the first authentication information 1909-1. 1 The authentication information 1909-1 may be processed and transmitted to the POS device.

The second communication module 1907 detects a second authentication service transaction when the electronic device approaches or is connected to the POS device, and obtains the second authentication information 1909_2 from the security module 1909, The second authentication information 1909-2 may be processed and transmitted to the POS device. Also, the second communication module 1907 may receive feedback on the authentication result and provide the result to the AP 1903 of the second mode.

According to the implementation, when the electronic device approaches or is connected to the POS device, the second communication module 1907 requests the second authentication information 1909-2 from the AP 1903 in the second mode to obtain the It may be provided through the AP 1903 of the second mode.

The security module 1909 is accessible only by the second communication module 1907 or the AP 1903 in the second mode, and the AP 1901 in the first mode and the first communication module 1905 It may be inaccessible storage. In an embodiment, the security module 1909 may include the first authentication information 1909-1 for near field magnetic stripe data transmission and the second authentication information 1909-2 for NFC.

In various embodiments, the first authentication information 1909 - 1 may be stored in a general memory 1911 electrically connected to the AP 1901 in the first mode.

20 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile short-distance payment service according to various embodiments of the present disclosure.

Referring to FIG. 20 , when the transaction of the first authentication service occurs in operation 2000, the AP 1901 in the first mode proceeds to operation 2002 and sends the AP 1903 in the second mode to the first authentication service. Transaction commands can be passed.

The AP 1903 of the second mode may acquire authentication information for payment from at least one of the security module 1909 and the memory 1911 in operation 2004 .

The AP 1903 in the second mode may transmit the acquired first authentication information for payment to the first communication module 1905 in operation 2006 and transmit a transaction command of the first authentication service.

The first communication module 1905 may process and transmit the authentication information in operation 2008 .

When the transaction of the second authentication service occurs in operation 2000 , the second communication module 1907 may request authentication information for payment to the AP 1903 in the second mode in operation 2010 .

The AP 1903 of the second mode may obtain authentication information for payment from the security module 1909 in operation 2012 .

The AP 1903 in the second mode may transmit the acquired authentication information for payment to the second communication module 1907 in operation 2014 .

The second communication module 1907 may transmit the authentication information in operation 2016.

In various embodiments, when a transaction of the second authentication service occurs in operation 2000 , the second communication module 1907 may directly obtain and transmit authentication information for payment from the security module 1909 .

In addition, in various embodiments, when the transaction command of the first authentication service is transmitted from the AP 1901 in the first mode to the AP 1903 in the second mode, the AP 1903 in the second mode directly Instead of acquiring authentication information for payment from the security module 1909, the transaction command of the first authentication service is transmitted from the AP 1903 in the second mode to the first communication module 1905 as shown in FIG. Thereafter, authentication information for payment may be requested from the first communication module 1905 .

21 is a flowchart for another operating method of an electronic device including a plurality of communication modules for a mobile short-distance payment service according to the third embodiment.

Referring to FIG. 21, when the transaction command of the first authentication service is transmitted from the AP 1901 in the first mode to the AP 1903 in the second mode, in operation 2101, the AP 1903 in the second mode A transaction command of the first authentication service may be transmitted to the first communication module 1905 .

In operation 2103, the first communication module 1905 may request authentication information for payment from the AP 1903 in the second mode.

In operation 2105 , the AP 1903 of the second mode may acquire authentication information for payment of at least one of the security module 1909 and the memory 1911 .

In operation 2107 , the AP 1903 in the second mode may transmit the acquired authentication information for payment to the first communication module 1905 .

In operation 2109, the first communication module 1905 may transmit the authentication information.

22 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 22, the AP 2201 in the first mode and the AP 2203 in the second mode correspond to the processor 1200 of FIG. 12, and the first communication module 2205 is the first communication module ( 1210 , and the second communication module 2207 may correspond to the second communication module 1212 of FIG. 12 . Here, the AP 2201 in the first mode may be a processor operating in a normal area (eg, REE), and the AP 2203 in the second mode may be a processor operating in a security area (eg, TEE).

The first communication module 2205 and the second communication module 2207 are electrically connected to the AP 2203 of the second mode, and the second security module 2209 is electrically connected to the second communication module 2207. , or electrically connected to the AP 2203 of the second mode. In addition, the first security module 2211 may be electrically connected to the AP 2203 of the second mode.

In various embodiments, the first communication module 2205 may be at least one of an MST module (eg, the MST module 810 ) or an NFC module (eg, the NFC module 820 ). The second communication module 2207 may be at least one of an MST module (eg, the MST module 810) or an NFC module (eg, the NFC module 820). The first security module 2211 may be a first embedded secure element (eSE). The second security module 2209 may be a second embedded secure element (eSE).

The AP 2201 in the first mode may detect a first authentication service transaction and transmit the authentication service transaction command to the AP 2203 in the second mode.

The AP 2203 in the second mode may transmit the authentication service transaction command and the first authentication information 2211-1 to the first communication module 2205 . The AP 2203 in the second mode may acquire the first authentication information 2211-1 by accessing the first security module 2211 . In addition, the AP 2203 in the second mode may receive the authentication result corresponding to the second authentication information 2209-2 from the second communication module 2207 and control it to be displayed on the display module 1208. have.

Depending on the implementation, the AP 2203 of the second mode accesses the second security area 2209 when receiving a request for the second authentication information 2209 - 2 from the second communication module 2207 . After acquiring the second authentication information 2209 - 2 , the acquired second authentication information 2209 - 2 may be transmitted to the second communication module 2207 .

The first communication module 2205 receives an authentication service transaction command and the first authentication information 2211-1 from the AP 2203 in the second mode, and processes the first authentication information 2211-1. It can transmit to the POS device.

When the electronic device approaches or is connected to the POS device, the second communication module 2207 detects a second authentication service transaction, accesses the second security module 2209 to obtain the second authentication information 2209_2 may be obtained, and the obtained second authentication information 2209_2 may be processed and transmitted to the POS device. Also, the second communication module 2207 may receive feedback on the authentication result and provide the result to the AP 2203 in the second mode.

The first security module 2211 is accessible only by the AP 2203 in the second mode, and the second security module 2209 is the AP 2203 in the second mode and the second communication module 2207 ), and the AP 2201 or the first communication module 2205 in the first mode directly accesses the first security module 2211 and the second security module 2209. It is not possible, and the AP 2201 or the second communication module 2207 in the first mode cannot directly access the first security module 2211, and may be a storage space.

In various embodiments, the first authentication information may be stored in a general memory 2213 electrically connected to the AP 2201 in the first mode.

23 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile short-distance payment service according to various embodiments of the present disclosure.

Referring to FIG. 23, when the transaction of the first authentication service occurs in operation 2300, the AP 2201 in the first mode is the AP 2203 in the second mode in operation 2302. Transaction commands can be passed.

In operation 2304 , the AP 2203 of the second mode may obtain authentication information for payment from at least one of the second security module 2209 and the memory 2213 .

In operation 2306 , the AP 2203 in the second mode may transmit the obtained authentication information for payment to the first communication module 2205 and may transmit a transaction command of the first authentication service.

In operation 2308, the first communication module 2205 may transmit the authentication information.

On the other hand, when a transaction of the second authentication service occurs in operation 2300 , in operation 2310 , the second communication module 2207 may request authentication information for payment from the AP 2203 in the second mode.

In operation 2312 , the AP 2203 in the second mode may obtain authentication information for payment from the first security module 2211 .

In operation 2314 , the AP 2203 in the second mode may transmit the acquired authentication information for payment to the second communication module 2207 .

In operation 2316 , the AP 2203 in the second mode may transmit the authentication information using the second communication module 2207 .

In various embodiments, when a transaction of the second authentication service occurs in operation 2300 , the second communication module 2207 may directly obtain and transmit authentication information for payment from the second security module 2209 . .

In addition, in various embodiments, when the transaction command of the first authentication service is transmitted from the AP 2201 in the first mode to the AP 2203 in the second mode, the AP 2203 in the second mode directly Instead of acquiring authentication information for payment from the first security area 2211, the transaction command of the first authentication service from the AP 2203 in the second mode to the first communication module 2205 as shown in FIG. 24 After transmitting , authentication information for payment may be requested from the first communication module 2205 .

24 is a flowchart for another operating method of an electronic device including a plurality of communication modules for a mobile short-distance payment service according to various embodiments.

Referring to FIG. 24 , when the transaction command of the first authentication service is transmitted from the AP 2201 in the first mode to the AP 2203 in the second mode, in operation 2401, the AP 2203 in the second mode A transaction command of the first authentication service may be transmitted to the first communication module 2205 .

In operation 2403 , the first communication module 2205 may request authentication information for payment from the AP 2203 in the second mode.

In operation 2405 , the AP 2203 in the second mode may obtain authentication information for payment from at least one of the first security module 2211 and the memory 2213 .

In operation 2407 , the AP 2203 in the second mode may transmit the acquired authentication information for payment to the first communication module 2205 .

In operation 2408, the electronic device (eg, the first communication module 2205) may transmit the authentication information to an external device (eg, PoS).

25 illustrates an interface between internal components of an electronic device according to various embodiments of the present disclosure.

Referring to FIG. 25, the AP 2501 of the first mode and the AP 2503 of the second mode correspond to the processor 1200 of FIG. 12, and the first communication module 2505 is the first communication module 2505 of FIG. It may correspond to the first communication module 1210, and the second communication module 2507 may correspond to the second communication module 1212 of FIG. Here, the AP 2501 in the first mode may be a processor 1200 operating in a normal area (eg, REE), and the AP 2503 in the second mode is a processor operating in a security area (eg, TEE) ( 1200).

The first communication module 2505 and the second communication module 2507 may be electrically connected to the AP 2503 in the second mode, and the security module 2509 may be electrically connected to the second communication module 2507 . have. In addition, the security module 2509 may be electrically connected to the first communication module 2507 .

In various embodiments, the first communication module 2505 may be at least one of an MST module (eg, the MST module 810 ) or an NFC module (eg, the NFC module 820 ). The second communication module 2507 may be at least one of an MST module (eg, the MST module 810) or an NFC module (eg, the NFC module 820). The secure module 2509 may be an embedded secure element (eSE).

The AP 2501 in the first mode may detect an authentication service transaction and transmit a first authentication service transaction command to the AP 2503 in the second mode.

The AP 2503 in the second mode may transmit the first authentication service transaction command and the first authentication information 2509 - 1 to the first communication module 2505 . In addition, the AP 2503 in the second mode may receive the authentication result corresponding to the second authentication information 2509-2 from the second communication module 2507 and control it to be displayed on the display module 1208. have.

When receiving an authentication service transaction command from the AP 2503 in the second mode, the first communication module 2505 requests the second communication module 2507 for first authentication information 2509-1, The first authentication information 2509 - 1 may be received through the second communication module 2507 .

According to the implementation, when receiving an authentication service transaction command from the AP 2503 in the second mode, the first communication module 2505 directly accesses the security module 2509 to receive the first authentication information 2509_1 may be obtained.

The first communication module 2505 may process the first authentication information 2509_1 and transmit it to the POS device.

When receiving a request for first authentication information from the first communication module 2505, the second communication module 2507 accesses the security module 2509 to obtain the first authentication information 2509_1 The authentication information 2509_1 may be provided to the first communication module 2505 .

In addition, when the electronic device approaches or is connected to the POS device, the second communication module 2507 detects a second authentication service transaction and directly accesses the security module 2509 to access the second authentication information 2509_2 ), the second authentication information 2509_2 may be processed and transmitted to the POS device. In addition, the second communication module 2507 may receive information on the authentication result as feedback and provide the result to the AP 2503 in the second mode.

The security module 2509 is accessible only by the first communication module 2505 or the first communication module 2505, and the AP 2501 in the first mode and the AP 2503 in the second mode It may be inaccessible storage. In an embodiment, the security module 2509 may store the first authentication information 2509_1 and the second authentication information 2509_2 .

In various embodiments, the first authentication information may be stored in a general memory 2511 electrically connected to the AP 2501 in the first mode.

26 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile short-distance payment service according to various embodiments of the present disclosure.

Referring to FIG. 26 , when the transaction of the first authentication service occurs in operation 2600 , in operation 2602 , the AP 2501 in the first mode transfers the AP 2503 in the second mode to the AP 2503 in the second mode. Transaction commands can be passed.

In operation 2604 , the AP 2503 in the second mode may transmit a transaction command of the first authentication service to the first communication module 2505 .

In operation 2606 , the first communication module 2505 may request the second communication module 2507 for first authentication information for payment.

In operation 2608 , the second communication module 2507 may obtain authentication information for payment (eg, the first authentication information 2509 - 1 ) from the security module 2509 .

In operation 2610 , the second communication module 2507 may transmit the acquired first authentication information for payment to the first communication module 2505 .

In various embodiments, when the transaction command of the first authentication service is transmitted to the first communication module 2505 in the second mode AP 2503, in operation 2614, directly in the first communication module 2505 First authentication information for payment may be obtained from at least one of the security module 2509 and the memory 2511 .

In operation 2620, the first communication module 2505 may transmit authentication information.

On the other hand, when the transaction of the second authentication service occurs in operation 2600 , in operation 2616 , the second communication module 2507 receives authentication information for payment from the security module 2509 (eg, the second authentication). information 2509_2) may be obtained.

In operation 2618, the second communication module 2507 may transmit the authentication information.

27 illustrates an interface between internal components of an electronic device according to the sixth embodiment. Referring to FIG. 27 , the AP 2701 in the first mode and the AP 2703 in the second mode correspond to the processor 1200 of FIG. 12 , and the first communication module 2705 of FIG. 12 . The first communication module 1210 and the second communication module 2709 may correspond to the second communication module 1212 of FIG. 12 . Here, the AP 2701 in the first mode may be a processor 1200 operating in a normal area (eg, REE), and the AP 2703 in the second mode is a processor (eg, TEE) operating in a security area (eg, TEE). 1200).

The first communication module 2705 and the second communication module 2709 are electrically connected to the AP 2703 of the second mode, and the second security module 2711 is electrically connected to the second communication module 2709. can be connected In addition, the first security module 2707 may be electrically connected to the first communication module 2705 .

In various embodiments, the first communication module 2705 may be at least one of an MST module (eg, the MST module 810 ) or an NFC module (eg, the NFC module 820 ). The second communication module 2709 may be at least one of an MST module (eg, the MST module 810) or an NFC module (eg, the NFC module 820). The first security module 2707 may be a first embedded secure element (eSE). The second security module 2711 may be a second embedded secure element (eSE).

The AP 2701 in the first mode may detect an authentication service transaction and transmit a first authentication service transaction command to the AP 2703 in the second mode.

The AP 2703 in the second mode may transmit a first authentication service transaction command and first authentication information 2707_1 to the first communication module 2705 . Also, the AP 2703 in the second mode may receive an authentication result corresponding to the second authentication information 2711_2 from the second communication module 2709 and control it to be displayed on the display module 508 .

When receiving the authentication service transaction command from the AP 2703 in the second mode, the first communication module 2705 directly accesses the first security area 2707 to obtain the first authentication information 2707_1. can In addition, the obtained first authentication information 2707_1 may be processed and transmitted to the POS device.

The second communication module 2709 detects a second authentication service transaction when the electronic device approaches or is connected to the POS device, and accesses the second security module 2711 to obtain the second authentication information 2711_2 may be obtained, and the obtained second authentication information 2711_2 may be processed and transmitted to the POS device. In addition, the second communication module 2709 may receive information on the authentication result as feedback and provide the result to the AP 2703 of the second mode.

The first secure area 2707 is accessible only by the first communication module 2705, the second secure area 2711 is accessible only by the second communication module 2709, and the first mode The AP 2701 or the AP 2703 in the second mode may be a storage space that cannot access the first secure area 2707 and the second secure area 2711 .

In various embodiments, the first authentication information may be stored in a general memory 2713 electrically connected to the AP 2701 in the first mode.

28 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile short-distance payment service according to a sixth embodiment.

Referring to FIG. 28, when the transaction of the first authentication service occurs in operation 2800, the AP 2701 in the first mode is transferred to the AP 2703 in the second mode in operation 2802. Transaction commands can be passed.

In operation 2804 , the AP 2703 in the second mode may transmit the transaction command of the first authentication service to the first communication module 2705 .

In operation 2806 , the first communication module 2705 may acquire authentication information for payment from at least one of the first security area 2707 and the memory 2713 .

In operation 2808, the first communication module 2705 may transmit the authentication information.

On the other hand, when the transaction of the second authentication service occurs in operation 2800 , the second communication module 2709 may obtain authentication information for payment from the second security module 2711 in operation 2810 .

In operation 2812, the second communication module 2709 may transmit the authentication information.

According to various embodiments, when a transaction of the second authentication service occurs in operation 2800, payment may be performed by the operation method of FIG. 29 below.

29 is a flowchart for another operating method of an electronic device including a plurality of communication modules for a mobile short-distance payment service according to the sixth embodiment.

Referring to FIG. 29 , when a transaction of the second authentication service occurs, in operation 2900 , the AP 2701 in the first mode sends a transaction command for the first authentication service to the AP 2703 in the second mode. can transmit

In operation 2902 , the AP 2703 in the second mode may transmit a transaction command of the second authentication service to the second communication module 2709 .

In operation 2904 , the second communication module 2709 may obtain authentication information for payment from the second security module 2711 .

In operation 2906 , the AP 2703 in the second mode may transmit the authentication information using the second communication module 2709 .

30 illustrates an interface between internal components of an electronic device according to the seventh embodiment.

Referring to FIG. 30, the AP 3001 of the first mode and the AP 3003 of the second mode correspond to the processor 1200 of FIG. 12, and the first communication module 3005 of FIG. It may correspond to the first communication module 1210, and the second communication module 3005 may correspond to the second communication module 1212 of FIG. 12 . Here, the AP 3001 in the first mode may be a processor 1200 operating in a normal area (eg, REE), and the AP 3003 in the second mode is a processor operating in a security area (eg, TEE) ( 1200).

The first communication module 3005 and the second communication module 3007 are electrically connected to the AP 3003 in the second mode, and the security module 3009 includes the first communication module 3005 and the second communication module. 3007 and the AP 3003 of the second mode may be electrically connected to each other.

In various embodiments, the first communication module 3005 may be at least one of an MST module (eg, the MST module 810 ) or an NFC module (eg, the NFC module 820 ). The second communication module 3007 may be at least one of an MST module (eg, the MST module 810) or an NFC module (eg, the NFC module 820). The secure module 3009 may be an embedded secure element (eSE).

The AP 3001 in the first mode may detect an authentication service transaction and transmit an authentication service transaction command to the AP 3003 in the second mode.

The AP 3003 in the second mode transmits a first authentication service transaction command to the first communication module 3003, and transmits the first authentication information 3009_1 to the security module 3009 to the first communication module ( 3005) to request delivery.

In various embodiments, when a second authentication service transaction occurs, the AP 3003 in the second mode requests the security module 3009 to transmit the second authentication information 3009_1 to the second communication module 3003 . can

The AP 3003 in the second mode may obtain the first authentication information 3009_1 by accessing the security module 3009 . Also, the AP 3003 in the second mode may receive an authentication result corresponding to the second authentication information 3009_2 from the second communication module 3007 and control it to be displayed on the display module 1208 .

The first communication module 3005 may receive an authentication service transaction command from the AP 3003 in the second mode and may receive the first authentication information 3009_1 from the security module 3009 . In addition, the first communication module 3005 may process the received first authentication information 3009_1 and transmit it to the POS device.

The second communication module 3007 detects a second authentication service transaction when the electronic device approaches or is connected to the POS device, directly accesses the security module 3009 to provide the second authentication information 3009_2 acquired, and the acquired second authentication information 3009_2 may be processed and transmitted to the POS device. In addition, the second communication module 3007 may receive information on the authentication result as feedback and provide the result to the AP 3003 in the second mode.

According to the implementation, when the electronic device approaches or is connected to the POS device, the second communication module 3007 requests the second authentication information 3009_2 from the AP 3003 in the second mode to obtain the second It may be provided through the AP 3003 of the mode.

The security module 3009 can be accessed only by the AP 3001 and the second communication module 3005 in the second mode, and may be a storage space that the AP 3001 in the first mode cannot access. . However, the first communication module 3005 may receive the first authentication information 3009_1 unidirectionally from the security module 3009 . In an embodiment, the security module 3009 may include the first authentication information 3009_1 and the second authentication information 3009_2 .

In various embodiments, the first authentication information may be stored in a general memory 3011 electrically connected to the AP 3001 in the first mode.

According to various embodiments, the AP 3001 in the second mode may store authentication information. For example, authentication information may be stored in the trusted RAM 501 illustrated in FIG. 5A . Here, the authentication information stored in the AP 3001 in the second mode may be transmitted through the first communication module 3005 and the second communication module 3007 . For example, the AP 3001 in the second mode may transmit one piece of authentication information to the receiving device through the first communication module 3005 and the second communication module 3007 .

According to another embodiment, the authentication information stored in the AP 3001 in the second mode includes the first authentication information transmitted through the first communication module 3005 and the second authentication information transmitted through the second communication module 3007 . may include. For example, the AP 3001 in the second mode may transmit the first authentication information to the receiving device through the first communication module 3005 , and receive the second authentication information through the second communication module 3007 . can be sent to the device. According to various embodiments, the AP 3001 in the second mode may transmit only at least one piece of authentication information among the stored authentication information to the receiving device. For example, it may transmit to the receiving device through a communication module corresponding to the authentication information to be transmitted.

31 is a flowchart illustrating a method of operating an electronic device including a plurality of communication modules for a mobile short-distance payment service according to a seventh embodiment.

Referring to FIG. 31 , when the transaction of the first authentication service occurs in operation 3100, the AP 3001 in the first mode is the AP 3003 in the second mode in operation 3102. Transaction commands can be passed.

In operation 3104 , the AP 3003 in the second mode may transmit a transaction command of the first authentication service to the first communication module 3005 .

In operation 3106 , the AP 3003 in the second mode may request at least one of the security module 3009 and the memory 3011 to transmit authentication information for payment to the first communication module 3105 .

In operation 3108 , at least one of the security module 3009 and the memory 3011 may transmit authentication information for payment to the first communication module 3005 .

In operation 3110 , the first communication module 3005 may transmit the authentication information received from the security module 3009 .

On the other hand, when the transaction of the second authentication service occurs in operation 3100, the AP 3001 in the first mode may transmit the transaction command of the second authentication service to the AP 3003 in the second mode in operation 3112. have.

In operation 3114 , the AP 3003 in the second mode may transmit a transaction command of the second authentication service to the second communication module 2007 .

In operation 3116 , the second communication module 3007 may request and obtain authentication information for payment from the AP 3003 in the second mode.

In operation 3118, the second communication module 3007 may transmit the authentication information.

32 illustrates an interface between internal components of an electronic device for generating information for payment according to various embodiments of the present disclosure;

The electronic device (eg, the electronic device 101 ) may include a normal world (eg, REE 410 ) and a security processing region.

The normal area may include at least one payment application 3201 , for example, the payment application 912 of FIG. 9 . The secure processing area may include a secure world (eg, TEE 420 ) and a security module (eg, an embedded Secure Element (eSE)). The secure processing area may include data requiring security. may be an area that can store and perform related operations in a secure environment.

In various embodiments, the security processing area may be configured only with at least one or more security modules (eg, eSE). If the security processing area is configured only with at least one or more security modules (eg, eSE), at least one of the security modules (eSE) controls the operation of the component in the TEE (eg, the operation of the MST driver module or the security application). can be done

In various embodiments, the security processing area may consist of only at least one or more security areas (eg, TEE). If the security processing area is configured with only at least one security area (eg, TEE), at least one of the security areas (eg, TEE) may perform an operation of the security module (eSE). application (eg, secure application 3202, trusted application, TA), secure module 3203, eg, embedded secure element (eSE), secure store 916 of FIG. 9) and MST driver module 3205, MST TA; For example, it may include the MST driver module 1827 of Fig. 18) The security module 3203 may store one or more payment-related programs (applets).

The payment application 3201 may transmit information related to the current time (eg, coordinated universal time (UTC) information) to the security area.

For example, the electronic device (eg, the electronic device 101) may acquire UTC information through an operating system (eg, Android ^TM OS) included in the electronic device. The electronic device (eg, the electronic device 101) may acquire UTC information through a network identity and time zone (NITZ) or a network time protocol (NTP), and an external server (eg, the first management server) may also obtain UTC information. When the information is obtained, the time is synchronized between the electronic device and the external server to authenticate the time authentication code. An external server may also acquire a specific time value using the same method as the electronic device (eg, NITZ or NTP).

The payment application 3201 may transmit information related to the current time (eg, UTC information) to the security application 3202 (TA). The security application 3202 may transmit information related to the current time (eg, UTC information) to the security module 3203 .

The security module 3203 may include at least one or more pieces of payment information (eg, a token, a key for generating a token cryptogram). The electronic device (eg, the electronic device 101 ) may include at least one communication module (eg, the first communication module 1210 and the second communication module 1212 of FIG. 12 ). 3203) may include authentication information corresponding to each of the at least one communication module.

The security module 3203 may generate track 2 information from the card using the payment-related program 3204 . The payment-related program 3204 may include an encryption-related algorithm, for example, a hash-based message authentication code (HMAC) algorithm.

The payment related program 3204 is based on at least one of information related to the current time (eg, UTC information) and at least one or more payment information (eg, a token, a key for generating a token cryptogram), timestamp information and payment information At least one of (eg, track 2 information) may be generated. The payment information generated using the timestamp information may be generated using authentication information corresponding to the MST module.

Track 2 information is payment information used for payment, and payment information includes timestamp information, validity information, service code, random number, verification number, It may include at least one of version information and a sequence number. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The version information may be information indicating an algorithm version of generation of payment information, and the sequence number may be information counting the number of times payment information is used.

The timestamp information may be generated using at least one of a current time, a provisioning time, a reference time, or a validity period.

The current time may be a time based on UTC information. The current time may be a time when the payment application 3201 requests payment. The provisioning time may be a time when a token is delivered from a token server or a token service provider (TSP), for example, 730 of FIG. 7 , to the electronic device when the token is distributed. The reference time may be set to a zero value. In various embodiments, the reference time may be equal to, for example, a provisioning time.

The validity period is a time preset so that the generated token can be used effectively starting from the payment request time, and the electronic device may receive information about the validity period from the payment server or the financial server. . For example, the validity period may be set to 180 seconds.

At least one of the security module 3201, the security application 3202, or the security area may generate timestamp information using the current time, provisioning time, and validity period based on UTC information.

For example, the timestamp information may be as in Equation (1).

[Equation 1]

Timestamp info=FLOOR((current time - provisioning time) / validity period)

The FLOOR function may be a function for rounding off the decimal point.

In various embodiments, at least one of the security module 3201, the security application 3202, or the security domain uses the current time based on UTC information, a reference time, and a validity period to obtain timestamp information. can create

For example, the timestamp information may be as in Equation (2).

[Equation 2]

Timestamp info=FLOOR((current time - base time) / valid period)

Security module 3201 is a token, timestamp information, validity (expiry) information, service code (service code), random number (random number), authentication number (verification number), version information (version information) or sequence number (sequence) number), an authentication code or authentication information may be generated by using the key for generating a token cryptogram.

The security module 3201 includes at least one or more of a token, timestamp information, validity information, service code, random number, verification number, and authentication code or authentication information. payment information (eg, track 2 information) can be created.

According to various embodiments, the security module 3201 generates a One Time Password code in which UTC information is encrypted using a key for generating a token cryptogram, and uses the One Time Password code. You can create payment information.

Security module 3201 is at least one of a token, timestamp information, validity information, service code (service code), random number (random number), authentication number (verification number) and one time password (one time password) code Payment information (eg, track 2 information) including the above may be generated.

The generated payment information may be transmitted to the payment application 3201 or an external electronic device using the MST driver module 3205 ( MST TA, for example, the MST driver module 1827 of FIG. 18 ).

According to various embodiments, the generated payment information may be transmitted to the payment application 3201 or an external electronic device using an NFC module (eg, 820 of FIG. 8 ).

33 illustrates an interface between internal components of an electronic device for generating information for payment according to various embodiments of the present disclosure;

The electronic device (eg, the electronic device 101 ) may include a normal world (eg, REE 410 ) and a security processing region.

The normal area may include at least one payment application 3301 , for example, the payment application 912 of FIG. 9 . The secure processing area may include a secure world (eg, TEE 420 ). The security processing area may be an area capable of storing data requiring security in a safe environment and performing a related operation.

The security realm includes applications inside the TEE (eg, trusted application (TA) 3304), token security application 3302 (eg, embedded secure element (eSE), secure storage 916 in FIG. 9) and MST. It may include a driver module 3305, MST TA, for example, the MST driver module 1827 of Fig. 18) The token security application 3302 may include a payment-related program 3303 (SDK).

The payment application 3301 may transmit information related to the current time (eg, coordinated universal time (UTC) information) to the security area.

For example, the electronic device (eg, the electronic device 101) may acquire UTC information through an operating system (eg, Android ^TM OS) included in the electronic device. The electronic device (eg, the electronic device 101) may acquire UTC information through a network identity and time zone (NITZ) or a network time protocol (NTP), and an external server (eg, the first management server) also obtains UTC information Upon obtaining , the electronic device and the external server may synchronize time and authenticate the time authentication code. An external server may also acquire a specific time value using the same method as the electronic device (eg, NITZ or NTP).

The payment application 3301 may transmit information related to the current time (eg, UTC information) to the security application 3304 (TA).

The token security application 3302 may include at least one or more payment information (eg, a token, a key for generating a token cryptogram). The electronic device (eg, the electronic device 101) may include at least one communication module (eg, the first communication module 1210 and the second communication module 1212 of FIG. 12 ). Token security application 3302 may include authentication information corresponding to each of the at least one communication module.

The token security application 3302 may generate track 2 information from the card using the payment-related program 3303 . The security application (3304, TA) is based on at least one of information related to the current time (eg, UTC information) and at least one or more payment information (eg, a token, a key for generating a token cryptogram), timestamp information and payment At least one of information (eg, modified track 2 information) may be generated. The payment information generated using the timestamp information may be generated using authentication information corresponding to the MST module. The security application 3304 (TA) may include an algorithm related to encryption, for example, a Hash-based Message Authentication Code (HMAC) algorithm.

The corrected track 2 information is payment information used for payment, and the payment information includes timestamp information, validity information, service code, random number, and verification number. ), version information, and at least one of a sequence number. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The timestamp information may be generated using at least one of a current time, a provisioning time, a reference time, or a validity period.

The current time may be a time based on UTC information. The current time may be a time when the payment application 3301 requests payment. The provisioning time may be a time when a token is delivered from a token server or a token service provider (TSP), for example, 730 of FIG. 7 , to the electronic device when the token is distributed. The reference time may be set to a zero value. In various embodiments, the reference time may be equal to, for example, a provisioning time.

The validity period is a time preset so that the generated token can be used effectively starting from the payment request time, and the electronic device may receive information about the validity period from the payment server or the financial server. . For example, the validity period may be set to 180 seconds.

At least one of the token security application 3302, the security application 3304, or the security domain may generate timestamp information using the current time, provisioning time, and validity period based on UTC information. .

In various embodiments, at least one of the token security application 3302 , the security application 3304 , or the security domain uses the current time based on UTC information, a reference time, and a validity period to time stamp information can create

Security application 3304 is a token, timestamp information, validity (expiry) information, service code (service code), random number (random number), authentication number (verification number), version information (version information) or sequence number (sequence) number), an authentication code or authentication information may be generated by using the key for generating a token cryptogram.

The security application 3304 includes at least one of a token, timestamp information, validity information, a service code, a random number, a verification number, and an authentication code or authentication information. payment information (eg, modified track 2 information) can be created. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

According to various embodiments, the security application 3304 generates a One Time Password code in which UTC information is encrypted using a key for generating a token cryptogram, and uses the One Time Password code. You can create payment information.

Security application 3304 is at least one of a token, timestamp information, validity information, service code (service code), random number (random number), verification number (verification number) and one-time password (One Time Password) code Payment information (eg, corrected track 2 information) including the above may be generated. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The generated payment information may be transmitted to the payment application 3301 or an external electronic device using the MST driver module 3305 (MST TA, for example, the MST driver module 1827 of FIG. 18).

According to various embodiments, the generated payment information may be transmitted to the payment application 3301 or an external electronic device using an NFC module (eg, 820 of FIG. 8 ).

34 illustrates an interface between internal components of an electronic device for generating information for payment according to various embodiments of the present disclosure;

The electronic device (eg, the electronic device 101 ) may include a normal world (eg, REE 410 ) and a security processing region.

The normal region may include at least one of a secure time module 3401 and a payment application 3402 , for example, the payment application 912 of FIG. 9 . The secure processing area may include a secure world (eg, TEE 420 ). The security processing area may be an area capable of storing data requiring security in a safe environment and performing a related operation.

The security realm includes applications inside the TEE (eg, trusted application (TA) 3403), a security module 3404 (eg, embedded secure element (eSE), secure storage 916 in FIG. 9) and MST driver. and a module 3406 (MST TA, for example, the MST driver module 1827 of Fig. 18) The security module 3404 may include a payment-related program 3405 (Applet).

The secure time module 3401 is a module for managing time information that is not changed by user authority, and may be included in a normal world (eg, REE 410 ). In various embodiments, it may be implemented in a normal area (eg, the REE 410), a secure area (eg, the TEE 420), or outside the electronic device (eg, a server). . The time information may be periodically synchronized with an external device. The electronic device (eg, the electronic device 101) may prevent the user from changing time information in the electronic device.

The secure time module 3401 may transmit information related to the current time (eg, coordinated universal time (UTC) information) to the payment application 3402 .

The payment application 3402 may transmit information related to the current time (eg, coordinated universal time (UTC) information) to the secure area.

For example, the electronic device (eg, the electronic device 101) may acquire UTC information through an operating system (eg, Android ^TM OS) included in the electronic device. The electronic device (eg, the electronic device 101) may acquire UTC information through a network identity and time zone (NITZ) or a network time protocol (NTP), and an external server (eg, the first management server) also obtains UTC information Upon obtaining , the electronic device and the external server may synchronize time and authenticate the time authentication code. An external server may also acquire a specific time value using the same method as the electronic device (eg, NITZ or NTP).

The payment application 3402 may transmit information related to the current time (eg, UTC information) to the security application 3403 (TA). The security application 3403 may transmit information (eg, UTC information) related to the current time to the security module 3404 .

The security module 3404 may include at least one or more pieces of payment information (eg, a token, a key for generating a token cryptogram). The electronic device (eg, the electronic device 101 ) may include at least one communication module (eg, the first communication module 1210 and the second communication module 1212 of FIG. 12 ). 3404 may include authentication information corresponding to each of the at least one communication module.

The security module 3404 may generate track 2 information in the card using the payment related program 3405 . The payment-related program 3405 may include an encryption-related algorithm, for example, a Hash-based Message Authentication Code (HMAC) algorithm.

The payment-related program 3405 is based on at least one of information related to the current time (eg, UTC information) and at least one or more payment information (eg, a token, a key for generating a token cryptogram), timestamp information and payment information At least one of (eg, track 2 information) may be generated. The payment information generated using the timestamp information may be generated using authentication information corresponding to the MST module.

Track 2 information is payment information used for payment, and payment information includes timestamp information, validity information, service code, random number, verification number, It may include at least one of version information and a sequence number. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The timestamp information may be generated using at least one of a current time, a provisioning time, a reference time, or a validity period.

The current time may be a time based on UTC information. The current time may be a time when the payment application 3402 requested payment. The provisioning time may be a time when a token is delivered from a token server or a token service provider (TSP), for example, 730 of FIG. 7 , to the electronic device when the token is distributed. The reference time may be set to a zero value. In various embodiments, the reference time may be equal to, for example, a provisioning time.

The validity period is a time preset so that the generated token can be used effectively starting from the payment request time, and the electronic device may receive information about the validity period from the payment server or the financial server. . For example, the validity period may be set to 180 seconds.

At least one of the security module 3404 , the security application 3403 , and the security region may generate timestamp information using a current time, a provisioning time, and a validity period based on UTC information.

In various embodiments, at least one of the security module 3404, the security application 3403, or the security domain uses the current time based on UTC information, a reference time, and a validity period to retrieve the timestamp information. can create

Security module 3404 is a token, timestamp information, validity (expiry) information, service code (service code), random number (random number), authentication number (verification number), version information (version information) or sequence number (sequence) number), an authentication code or authentication information may be generated by using the key for generating a token cryptogram. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The security module 3404 includes at least one or more of a token, timestamp information, validity information, service code, random number, verification number, and authentication code or authentication information. payment information (eg, track 2 information) can be created. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

According to various embodiments, the security module 3404 generates a One Time Password code in which UTC information is encrypted using a key for generating a token cryptogram, and uses the One Time Password code. You can create payment information.

The security module 3404 is at least one of a token, timestamp information, validity information, service code, random number, verification number, and One Time Password code. Payment information (eg, track 2 information) including the above may be generated. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The generated payment information may be transmitted to the payment application 3402 or an external electronic device using the MST driver module 3406 (MST TA, for example, the MST driver module 1827 of FIG. 18).

According to various embodiments, the generated payment information may be transmitted to the payment application 3402 or an external electronic device using an NFC module (eg, 820 of FIG. 8 ).

35 illustrates an interface between internal components of an electronic device for generating information for payment according to various embodiments of the present disclosure;

The electronic device (eg, the electronic device 101 ) may include a normal world (eg, REE 410 ) and a security processing region.

The normal area may include at least one payment application 3501 , for example, the payment application 912 of FIG. 9 . The secure processing area may include a secure world (eg, TEE 420 ). The security processing area may be an area capable of storing data requiring security in a safe environment and performing a related operation.

The secure domain includes a secure time module 3502 , an application inside the TEE (eg, a trusted application (TA) 3503 ), a secure module 3504 , such as an embedded secure element (eSE), and the secure storage of FIG. 9 . 916) and an MST driver module 3506, MST TA, for example, the MST driver module 1827 of Fig. 18) The security module 3504 includes a payment-related program 3505, Applet. can do.

The secure time module 3502 is a module for managing time information that is not changed by user authority, and may be included in a secure area (Secure World, for example, TEE 420 ). In various embodiments, it may be implemented in a normal area (eg, the REE 410), a secure area (eg, the TEE 420), or outside the electronic device (eg, a server). . The time information may be periodically synchronized with an external device. The electronic device (eg, the electronic device 101) may prevent the user from changing time information in the electronic device.

The payment application 3501 may request a secure time from the secure time module 3502 .

The secure time module 3502 may transmit information related to the current time (eg, coordinated universal time (UTC) information) to the secure application 3503 .

For example, the electronic device (eg, the electronic device 101) may acquire UTC information through an operating system (eg, Android ^TM OS) included in the electronic device. The electronic device (eg, the electronic device 101) may acquire UTC information through a network identity and time zone (NITZ) or a network time protocol (NTP), and an external server (eg, the first management server) also obtains UTC information Upon obtaining , the electronic device and the external server may synchronize time and authenticate the time authentication code. An external server may also acquire a specific time value using the same method as the electronic device (eg, NITZ or NTP).

The security application 3503 may transmit information (eg, UTC information) related to the current time to the security module 3504 .

The security module 3504 may include at least one or more pieces of payment information (eg, a token, a key for generating a token cryptogram). The electronic device (eg, the electronic device 101 ) may include at least one communication module (eg, the first communication module 1210 and the second communication module 1212 of FIG. 12 ). 3504) may include authentication information corresponding to each of the at least one communication module.

The security module 3504 may generate track 2 information in the card using the payment-related program 3505 . The payment-related program 3505 may include an encryption-related algorithm, for example, a Hash-based Message Authentication Code (HMAC) algorithm.

The payment-related program 3505 is based on at least one of information related to the current time (eg, UTC information) and at least one or more payment information (eg, a token, a key for generating a token cryptogram), timestamp information and payment information At least one of (eg, track 2 information) may be generated. The payment information generated using the timestamp information may be generated using authentication information corresponding to the MST module.

Track 2 information is payment information used for payment, and payment information includes timestamp information, validity, service code, random number, verification number, version It may include at least one of version information and a sequence number. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The timestamp information may be generated using at least one of a current time, a provisioning time, a reference time, or a validity period.

The current time may be a time based on UTC information. The current time may be a time when the payment application 3501 requests payment. The provisioning time may be a time when a token is delivered from a token server or a token service provider (TSP), for example, 730 of FIG. 7 , to the electronic device when the token is distributed. The reference time may be set to a zero value. In various embodiments, the reference time may be equal to, for example, a provisioning time.

The validity period is a time preset so that the generated token can be used effectively starting from the payment request time, and the electronic device may receive information about the validity period from the payment server or the financial server. . For example, the validity period may be set to 180 seconds.

At least one of the security module 3504, the security application 3503, or the security area may generate timestamp information using the current time, provisioning time, and validity period based on UTC information.

In various embodiments, at least one of the security module 3504, the security application 3503, or the security domain uses the current time based on UTC information, a reference time, and a validity period to retrieve the timestamp information. can create

The security module 3504 may include a token, timestamp information, validity information, service code, random number, verification number, version information, or sequence number (sequence). number), an authentication code or authentication information may be generated by using the key for generating a token cryptogram.

The security module 3504 includes at least one of a token, timestamp information, validity information, a service code, a random number, a verification number, and an authentication code or authentication information. payment information (eg, track 2 information) can be created.

According to various embodiments, the security module 3504 generates a One Time Password code in which UTC information is encrypted using a key for generating a token cryptogram, and uses the One Time Password code. You can create payment information.

The security module 3504 is at least one of a token, timestamp information, validity information, a service code, a random number, a verification number, and a One Time Password code. Payment information (eg, track 2 information) including the above may be generated. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The generated payment information may be transmitted to the payment application 3501 or an external electronic device using the MST driver module 3506 (MST TA, for example, the MST driver module 1827 of FIG. 18).

According to various embodiments, the generated payment information may be transmitted to the payment application 3501 or an external electronic device using an NFC module (eg, 820 of FIG. 8 ).

According to various embodiments, an electronic device (eg, the electronic device 101) may include a security module (eg, the security module 3203) operable to store at least one token; a first communication module (eg, NFC module 820); a second communication module (eg, MST module 810); and at least one processor (eg: and a processor 1200), wherein the at least one processor (eg, processor 1200) includes the first communication module (eg, NFC module 820) or the second communication module (eg, MST module 810). )) determines at least one communication module to be used for payment, and transmits payment information including a token related to the at least one communication module among the at least one token to an external electronic device (eg, a payment server, a financial server) , POS).

According to various embodiments, the processor (eg, the processor 1200 ) includes a timestamp, card expiry information, service code, random number, verification number, and version. It may be set to generate the payment information using at least one of version information and a sequence number.

According to various embodiments, the timestamp may be generated based on at least one of a provisioning time, a reference time, or a validity period.

According to various embodiments, the at least one token is a first token associated with the first communication module (eg, NFC module 820 ) and a second token associated with the second communication module (eg, MST module 810 ). and a token, and the payment information may include at least one of the first token and the second token.

According to various embodiments, the security module (eg, the security module 3203) may include an embedded security element (eSE).

According to various embodiments, the first communication module (eg, the NFC module 820 ) may include at least one Near Field Communication (NFC) module.

According to various embodiments, the second communication module (eg, the MST module 810 ) includes at least one Magnetic Stripe Data Transmission (MST) communication module.

According to various embodiments, the at least one processor (eg, the processor 1200) is the security module (eg, the first security module 1607, the security module 3203) or the processor (eg, the processor 1200) ) and another security module (eg, the second security module 1609, the token security application 3302), and generate a timestamp in the timestamp and the at least one communication module. an electronic device configured to generate the payment information in the other security module (eg, the second security module 1609, the token security application 3302) based on at least one of the associated tokens.

According to various embodiments, the at least one processor (eg, the processor 1200 ) may be configured to generate a token cryptogram based on at least one of the timestamp and the token.

According to various embodiments, the security module (eg, the first security module 1607 and the security module 3203) may include a payment-related program (eg, a payment-related program 3204, a payment applet).

According to various embodiments, a first security domain (eg, security module 3203), a second security domain (eg, token security application 3302), and at least one payment signal module (eg, MST module 810) ) or NFC module 820), in the payment information security method of an electronic device (eg, the electronic device 101), the method includes the at least one in the first security area (eg, the security module 3203) storing at least one token corresponding to each of the payment signal modules (eg, the MST module 810 or the NFC module 820); generating a timestamp in at least one of the first security region (eg, the security module 3203) or the second security region (eg, the token security application 3302); Based on at least one of a token corresponding to one of the at least one payment signal module (eg, the MST module 810 or the NFC module 820 ) among the at least one token and the timestamp, the second security area generating a payment signal in (eg, token security application 3302 ); and transmitting the payment signal to an external electronic device (eg, a payment server, a financial server, or a POS).

According to various embodiments, the generating of the payment signal includes generating a token cryptogram based on at least one of the timestamp and the token, and the payment signal includes the token and the token cryptogram. grams may be included.

According to various embodiments, the payment signal includes card validity information, service code, random number, verification number, version information, or sequence number. number) may be included.

According to various embodiments, the timestamp may be generated based on at least one of a provisioning time, a reference time, or a validity period.

According to various embodiments, the first security area (eg, the security module 3203) may include a payment applet.

According to various embodiments, the second security area (eg, the token security application 3302) may include at least one application related to the at least one payment signal module.

According to various embodiments, the payment signal may be generated by at least one application.

According to various embodiments, the at least one payment signal module (eg, the MST module 810 or the NFC module 820) may include at least one Magnetic Stripe Data Transmission (MST) communication module or at least one short-range communication (NFC, Near Field Communication) module.

According to various embodiments, the first security area (eg, TEE) includes a first security module (eg, eSE, payment-related program), or the second security area (eg, TEE) includes a second security module Including, wherein the at least one token is stored in the first security module (eg, eSE, payment-related program), or the payment signal is to be generated in the second security module (eg, eSE, payment-related program) can

36 is a diagram illustrating an effective time of payment information according to various embodiments of the present disclosure;

Referring to FIGS. 32 to 35 , payment information includes a token, timestamp information, validity information, service code, random number, verification number, and authentication code or authentication information. It may include at least one or more of In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The validity period is a preset time from a payment request time, and the electronic device may receive information on the validity period from a payment server or a financial server. For example, the validity period may be set to 180 seconds.

If payment information including timestamp information is transmitted to the financial server within the validity period, the payment can be completed. If payment information including timestamp information is not transmitted to the financial server after the validity period, payment may not be made.

In various embodiments, the timestamp information may be generated by Equation (3).

[Equation 3]

Timestamp information = (current time-timewindow)/timewindow

Referring to Equation 3, if the time window value is 90 seconds as shown in FIG. 36, and the time frame at which verification_code 2 is generated is 0 to 89 seconds, the timestamp information may be 0. The TSP (Token Service Provider) server can calculate the delay and determine the validity period from 0 to 179 seconds.

37 to 39 are diagrams illustrating an example of a structure of payment information (eg, a card) according to various embodiments of the present disclosure;

In Figure 37, when the card is passed through a reader (eg POS), the information written on the magnetic wire of the card induces an electrical signal in a coil around the iron core of the reader, so that the reader signals the induced magnetic field for the information about the card It can be detected and processed as information.

According to various embodiments, the magnetic line included in the card may include at least one or more tracks. The magnetic line may include information on track 1, track 2, and track 3, and payment can be made using the information of track 2 among them.

A card according to various embodiments may include information including at least one or more tracks.

In FIG. 38 , bank account information may be included in track 1, and the amount of data information in track 1 may be 79 kb. Track 2 may include information such as a credit card number, issue date, and expiration date, and the amount of data information in track 2 may be 40 kb. Track 3 may include information such as affiliates. For example, the information used for payment may be track 2 information.

In FIG. 39 , information included in track 2 may be as follows.

SS: Start sentinel - one character (eg ';')

PAN: Primary account number (PAN) - up to 19 characters, for example, may match the card number printed on the front of the card (up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.)

FS: Field Separator - one character (eg '=')

Expiration date - four characters in the form YYMM

Service code - three characters The first digit specifies the exchange rule, the second character specifies the authentication process, and the third character specifies the service scope (The first digit specifies the interchange rules, the second specifies authorization processing and the third specifies the range of services.)

DISCRETIONARY DATA may be the same as track 1.

ES: End sentinel - one character (eg ‘?’)

LRC: Longitudinal redundancy check (LRC) - can be one character, it is one character and a validity character calculated from other data on the track. Most readings When the device touches the card to the presentation layer, it does not return this value and can be used to validate the input internally to the reading device. (Most reader devices do not return this value when the card is swiped to the presentation layer, and use it only to verify the input internally to the reader.)

Service code values common in financial cards:

First digit

1: International interchange OK

2: International interchange, use IC (chip) where feasible)

5: National interchange only except under bilateral agreement

6: National interchange only except under bilateral agreement, use IC (chip) where feasible

7: No interchange except under bilateral agreement (closed loop)

9: Test

Second digit

0: Normal

2: Contact issuer via online means

4: Contact issuer via online means except under bilateral agreement

Third digit

0: No restrictions, PIN required

1: No restrictions

2: Goods and services only (no cash)

3: ATM only, PIN required

4: Cash only

5: Goods and services only (no cash), PIN required

6: No restrictions, use PIN where feasible

7: Goods and services only (no cash), use PIN where feasible)

40 illustrates a structure of payment information according to various embodiments.

The payment information may include a token 4001 and payment authentication data 4002 . The token 4001 may include a digital PAN (a card number that can be used in an electronic device virtually in place of an actual card number).

The payment authentication data 4002 may include a token cryptogram 4003 and transaction data 4004 .

The payment authentication data 4002 may be required to check whether a corresponding payment is valid during a payment transaction in an external device of the electronic device. The token cryptogram 4003 may be used in the same meaning as password information, password, cryptogram, encryption, and encryption method.

41 illustrates a structure of transaction data according to various embodiments.

The transaction data (4101, transaction data) may include a card expiration date (4102, card expired date) and store information (4103, merchant ID). The store information (4103, merchant ID) may be obtained from an external device using a communication module (3G, 4G, WiFI, NFC, etc.) of the electronic device.

42 illustrates a structure of payment authentication data according to various embodiments.

The payment authentication data 4201 may include at least one of a random number 4202, a verification code 4203, and a generation counter 4204.

According to an embodiment, the one-time password number (OTP number) may be an example of a token cryptogram.

Referring to FIG. 43 , a function of the payment relay module relaying an authentication request through PIN input of a payment application to the security identifier processing module of the TEE according to various embodiments is illustrated.

The payment relay module has a function of receiving a one-time random number (eg, nonce) from the payment module of the TEE through the secure environment relay module, and the PIN obtained by requesting the PIN result from the security identifier processing module through the secure environment relay module and encrypted It may include a function to find out the PIN result, and a function to request verification of the pre-encrypted PIN result from the payment module.

44 to 45 illustrate a method 4400 in which the payment relay module 1841 performs a payment using a result of performing authentication using biometric information, according to various embodiments of the present disclosure. According to an embodiment, the payment relay module may request a one-time random number (eg, nonce) from the payment module 1821 in the TEE through the secure environment relay module 1846 and the secure environment driver module 1853 .

According to an embodiment, the payment module may generate the one-time random number and encrypt it using a key in the TEE (eg, a device root key (DRK)). The payment module may transmit the encrypted one-time random number to the secure environment relay module 1846 through the secure environment driver module 1853 . Data transfer/transfer between applications or modules running within the same device may include access to data stored in memory.

According to an embodiment, the secure environment relay module 1846 may transmit the encrypted one-time random number to the biometric information module 1825 through the secure environment driver module. The biometric information module may decrypt using the key. The biometric information module may authenticate the user using information obtained from the biometric sensor. The biometric information module may encrypt the user authentication information with the key together with the one-time random number. The biometric information module may transmit the encrypted authentication status information and the one-time random number to the secure environment relay module through the secure environment driver module. The secure environment relay module may transmit the encrypted authentication information and the one-time random number to the payment module through the secure environment driver module.

According to an embodiment, the payment module may decrypt the encrypted authentication information and the one-time random number through the key. The payment module may compare whether the received one-time random number is the same as the one-time random number generated to check whether the authentication information is corrupted in the REE. The comparison may determine whether the transmitted one-time random number and the received one-time random number completely match, and the transmitted one-time random number and the received one-time random number do not match, but a one-time random number generated based on the transmitted one-time random number In this case, it may be judged to be consistent. If the two one-time random numbers match and authentication is successful, the payment module may perform payment. If the one-time random number does not match or authentication is not successful, the payment module may not be able to perform payment.

According to an embodiment, the comparison may be performed in another application or agent (eg, payment manager or kernel) running within the TEE or REE.

46 illustrates a method 4500 of generating a token cryptogram, in accordance with various embodiments. According to one embodiment, the payment module may generate a token cryptogram using a key capable of generating the token cryptogram. The payment module can use a different key according to a set rule, such as every transaction, a specific number of transactions, or a transaction within a specific time. The token service provider 730 may own a key paired with the key. The token service provider 730 may decrypt the encrypted token cryptogram through the paired key.

When the payment module uses the key to create a token cryptogram, data encrypted with the key and an encryption engine may vary according to an encryption method (eg, AES, TKIP, etc.).

47 is a flowchart illustrating a payment process using payment information generated based on timestamp information according to various embodiments of the present disclosure;

The payment application 4701 (eg, the payment application 3201 of FIG. 32 ) may request the security area 4703 to generate payment information (eg, track 2 information).

When receiving a request to generate payment information (eg, track 2 information) from the payment application 4701 , the security area 4703 is configured with a payment-related program 4705 (eg, the payment-related program 3204 of FIG. 32 ) in time Payment information (eg, track 2 information) may be generated using the stamp information.

When payment information (eg, track 2 information) is generated, the payment related program 4705 may transmit the generated payment information (eg, track 2 information) to the security area 4703 .

The security area 4703 may request transaction approval using payment information (eg, track 2 information) generated by the POS 4707 through the MST driver module 3205 of FIG. 32 , for example.

The POS 4707 receiving the transaction approval request from the security area 4703 may transmit the generated payment information (eg, track 2 information) and the transaction approval request to the first financial server 4711 .

The first financial server 4711 (eg, the first financial server 932 of FIG. 9 ) generates payment information (eg, the token server 4713 or a token service provider (TSP)) , track 2 information) can be transmitted.

The token server 4713 or a token service provider (TSP) may authenticate the token received from the first financial server 4711 , and transmit a token authentication result to the first financial server 4711 .

Token server 4713 or token service provider (token service provider (TSP)) includes timestamp information, validity information, service code, random number, authentication number included in payment information (verification number), version information (version information) or sequence number (sequence number) stored in the token server 4713 or token service provider (token service provider (TSP)) (provisioning time), reference time (reference) time) or the validity period can be compared to determine whether the token is valid. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The first financial server 4711 receives the token authentication result from the token server 4713 or a token service provider (TSP), and the second financial server 4709, the second financial server 942 of FIG. 9 . )) to transmit the token authentication result and/or request transaction approval.

The second financial server 4709 may determine whether to approve the transaction according to the token authentication result and the transaction approval request. If the token authentication result determines that the token is valid, the second financial server 4709 may transmit the transaction approval result to the first financial server 4711 .

The first financial server 4711 may transmit the transaction approval result to the POS 4707 .

48 is a flowchart illustrating a payment process using payment information generated based on timestamp information according to various embodiments of the present disclosure;

The payment application 4801 (eg, the payment application 3201 of FIG. 32 ) may request the security area 4803 to generate payment information (eg, track 2 information).

When receiving a request to generate payment information (eg, track 2 information) from the payment application 4801, the security area 4803 is a payment-related program 4805 (eg, the payment-related program 3204 of FIG. 32) is time Payment information (eg, track 2 information) may be generated using the stamp information.

When payment information (eg, track 2 information) is generated, the payment related program 4805 may transmit the generated payment information (eg, track 2 information) to the security area 4803 .

The security area 4803 may request transaction approval using payment information (eg, track 2 information) generated by the POS 4804 through the MST driver module 3205 of FIG. 32 , for example.

The POS 4804 receiving the transaction approval request from the security area 4803 transmits payment information (eg, track 2 information) generated in the second financial server 4807 (the second financial server 942 in FIG. 9 ). and a transaction approval request.

The second financial server 4807 may transmit a token included in the payment information (eg, track 2 information) generated to the token server 4809 or a token service provider (TSP). have.

The token server 4809 or a token service provider (TSP) may authenticate the token received from the second financial server 4807 , and transmit a token authentication result to the second financial server 4807 .

Token server 4809 or token service provider (token service provider (TSP)) includes timestamp information, validity information, service code, random number, authentication number included in payment information (verification number), version information (version information) or sequence number (sequence number) stored in the token server 4713 or token service provider (token service provider (TSP)) (provisioning time), reference time (reference) time) or the validity period can be compared to determine whether the token is valid. In various embodiments, the expiry information included in the payment information may be information regarding the validity period of the credit card.

The second financial server 4807 may transmit the transaction approval result to the POS 4707 .

49 illustrates a method for performing a payment transaction using a token according to various embodiments.

When a payment transaction is started, the payment application 4901 (eg, the payment application 3201 of FIG. 32) is transferred to the security module 4903 (eg, the security module 3203 of FIG. 32) through the security application (TA). Timestamp information may be transmitted.

The security module 4903 may include a payment-related program 4905 (eg, the payment-related program 3204 of FIG. 32 ). The payment-related program 4905 is based on at least one of timestamp information and at least one or more payment information (eg, a token, a key for generating a token cryptogram), payment information (eg, track 2) information ) can be created.

The security module 4903 may transmit and receive payment-related information (eg, payment information) with the TSM 4909 of the first financial server (eg, the first financial server 932 of FIG. 9 ).

The payment server 4907 (eg, the payment server 920 of FIG. 9 ) may transmit/receive information related to payment (eg, payment information) to the payment application 4901 .

The TSM 4909 of the first financial server is the TSP 4911 of the first financial server, the second financial server 4915 (eg, the second financial server 942 in FIG. 9), and the TSP of the second financial server. You can send and receive payment-related information with and approve the payment.

As used herein, the term “module” includes a unit composed of hardware, software, or firmware, and may be used interchangeably with terms such as, for example, logic, logic block, component, or circuit. A “module” may be an integrally formed component or a minimum unit or a part of performing one or more functions. A “module” may be implemented mechanically or electronically, for example, known or to be developed, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), or It may include a programmable logic device. At least a portion of an apparatus (eg, modules or functions thereof) or a method (eg, operations) according to various embodiments includes instructions stored in a computer-readable storage medium (eg, memory 130 ) in the form of a program module can be implemented as When the instruction is executed by a processor (eg, the processor 120), the processor may perform a function corresponding to the instruction. Computer-readable recording media include hard disks, floppy disks, magnetic media (eg, magnetic tape), optical recording media (eg, CD-ROM, DVD, magneto-optical media (eg, floppy disks), built-in memory, etc.) may include

According to various embodiments, a computer-readable recording medium recording a program is an electronic device (eg, TEE) and at least one payment signal module (eg, MST module 810 or NFC module 820) including a security area (eg, TEE). Example: in the electronic device 101), storing at least one token corresponding to the at least one payment signal module (eg, the MST module 810 or the NFC module 820) in the secure area; generating a timestamp in the secure area (TEE); Among the at least one token, the security area (eg: generating a payment signal in TEE); and transmitting the payment signal to an external electronic device (eg, a payment server, a financial server, or a POS).

Instructions may include code generated by a compiler or code that can be executed by an interpreter. A module or program module according to various embodiments may include at least one or more of the above-described components, some may be omitted, or may further include other components. According to various embodiments, operations performed by a module, program module, or other component are sequentially, parallel, repetitively or heuristically executed, or at least some operations are executed in a different order, are omitted, or other operations are added. can be

Claims (20)

secure storage operable to store at least one token;
a first communication module;
a second communication module; and
at least one processor operatively coupled to the secure storage, the first communication module and the second communication module;
the at least one processor
Transmitting payment information including one token among a plurality of tokens to an external electronic device using at least one of the first communication module and the second communication module,
It is determined whether a response has been received from the external electronic device within a preset time,
If the response is not received, the electronic device is configured to transmit additional payment information including one token among the plurality of tokens to the external electronic device by using the other one of the first communication module or the second communication module. The method of claim 1, wherein the processor comprises:
Use at least one of a timestamp, card expiry information, service code, random number, verification number, version information, or sequence number an electronic device set to generate the payment information. ◈Claim 3 was abandoned when paying the registration fee.◈ 3. The method of claim 2,
The timestamp is
An electronic device generated based on at least one of a provisioning time, a reference time, and a validity period. ◈Claim 4 was abandoned when paying the registration fee.◈ The method of claim 1,
the at least one token comprises a first token associated with the first communication module and a second token associated with the second communication module;
The payment information includes at least one of the first token and the second token. The method of claim 1,
The secure storage is
An electronic device comprising at least one of a secure element or a secure area. The method of claim 1,
The first communication module is
An electronic device including at least one Near Field Communication (NFC) module. The method of claim 1,
The second communication module is
An electronic device comprising at least one Magnetic Stripe Data Transmission (MST) communication module. ◈Claim 8 was abandoned when paying the registration fee.◈ The method of claim 1,
the at least one processor
generate a timestamp in at least one of the secure storage or another secure storage operatively associated with the processor;
an electronic device configured to generate the payment information in the other secure storage based on at least one of the timestamp and a token related to the first communication module or the second communication module. ◈Claim 9 was abandoned at the time of payment of the registration fee.◈ 9. The method of claim 8,
the at least one processor
An electronic device configured to generate a token cryptogram based on at least one of the timestamp and the token. ◈Claim 10 was abandoned when paying the registration fee.◈ The method of claim 1,
The secure storage is
An electronic device including a payment applet. An electronic device comprising a secure storage configured to store at least one token, a first communication module, a second communication module, and at least one processor operatively connected to the secure storage, the first communication module, and the second communication module. In the payment method,
transmitting payment information including one token among a plurality of tokens to an external electronic device using at least one of the first communication module and the second communication module;
determining whether a response is received from the external electronic device within a preset time; and
if the response is not received, transmitting additional payment information including one token among the plurality of tokens to the external electronic device using the other one of the first communication module or the second communication module Way. 12. The method of claim 11,
and generating a token cryptogram based on at least one of the at least one token and a timestamp. ◈Claim 13 was abandoned when paying the registration fee.◈ 12. The method of claim 11,
The payment using at least one of card validity information, service code, random number, verification number, version information, or sequence number The method further comprising generating the information. ◈Claim 14 was abandoned when paying the registration fee.◈ 13. The method of claim 12,
The timestamp is
A method generated based on at least one of a provisioning time, a reference time, or a validity period. 12. The method of claim 11,
The secure storage is
A method comprising at least one of a secure element or a secure realm. ◈Claim 16 has been abandoned at the time of payment of the registration fee.◈ 12. The method of claim 11,
generating a timestamp in at least one of the secure storage or another secure storage operatively coupled to the processor; and
and generating the payment information in the other secure storage based on at least one of the timestamp and a token related to the first communication module or the second communication module. ◈Claim 17 was abandoned when paying the registration fee.◈ 12. The method of claim 11,
the at least one token comprises a first token associated with the first communication module and a second token associated with the second communication module;
The payment information includes at least one of the first token or the second token. 12. The method of claim 11,
The first communication module is
A method comprising at least one Near Field Communication (NFC) module. 12. The method of claim 11,
The second communication module is
A method comprising at least one Magnetic Stripe Data Transmission (MST) communication module. delete

Images