Electronic device for registering card associated with identification card information, application server, and method of operating same

Abstract

An electronic device according to an embodiment of the present disclosure may: identify a card requested to be registered; display, on a display, a first user interface (UI) for linking with an identification card, on the basis that a type of the card requested to be registered is determined to require the linking with the identification card; obtain first identification card information through an identification card module included in the electronic device, on the basis that an input based on the first UI is received; and register the card requested to be registered in association with the first identification card information. Various other embodiments are possible.

Description

Electronic device, application server, and method of operation for registering a card linked to identification information

[0001] The present disclosure relates to an electronic device, an application server, and a method of operation for registering a card linked to identification information.

[0002] With the development of digital technology and the widespread adoption of the Internet, various services are shifting from offline to online. For example, consumers can conveniently purchase tickets for performances, sports events, concerts, or exhibitions through online platforms. This trend of online ticket purchasing is becoming increasingly popular as it enables easy ticket purchases anytime and anywhere.

[0003] While online ticket purchasing can offer convenience to consumers, it poses a risk of various forms of damage, such as ticket resale and theft. Consequently, there is a growing need to strengthen authentication for ticket users.

[0004] The information described above may be provided as related art for the purpose of aiding understanding of this document. None of the foregoing is to be claimed as prior art related to this document, nor is it to be used to determine prior art.

[0005] One embodiment of the present disclosure may provide an electronic device for registering a card associated with identification information, an application server, and a method of operating the same.

[0006] One embodiment of the present disclosure may provide an electronic device, an application server, and a method of operation thereof that enables the use of a ticket authenticated based on identity information.

[0007] One embodiment of the present disclosure may provide an electronic device, an application server, and a method of operation thereof that can prevent ticket resale and theft.

[0008] One embodiment of the present disclosure may provide an electronic device, an application server, and a method of operation thereof that can simplify the entry procedure and reduce the time and cost associated with ticket inspection.

[0009] An electronic device (201) according to one embodiment of the present disclosure may include a transceiver (210), a display (220), an identification module (360), a memory (230), and at least one processor (240) including a processing circuit. The memory (230) may store commands that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to identify a card to be registered in an application (350), display a first UI (user interface) for the identification connection on the display (220) based on the determination that the type of the card to be registered is a type requiring an identification connection, obtain first identification information through the identification module (360) based on the reception of input based on the first UI, and cause the card to be registered in the application (350) in conjunction with the first identification information.

[0010] A method of operation of an electronic device (201) according to one embodiment of the present disclosure may include: an operation (1202) of identifying a card to be registered in an application (350); an operation (1204) of displaying a first UI (user interface) for the ID connection on a display (220) of the electronic device (201) based on the determination that the type of the card to be registered is a type requiring an ID connection; an operation (1206) of obtaining first ID information through an ID module (360) included in the electronic device (201) based on the reception of an input based on the first UI; and an operation (1208) of registering the card to be registered in the application (350) in conjunction with the first ID information.

[0011] An application server (340) according to one embodiment of the present disclosure may include a transceiver (250), a memory (260), and at least one processor (270) including a processing circuit. The memory (260) may store instructions that, when executed individually or collectively by the at least one processor (270), cause the application server (340) to transmit a card registration request message to the electronic device (201) via the transceiver (250) requesting the registration of a card in an application (350) of the electronic device (201), receive a card registration response message including first identification information from the electronic device (201) via the transceiver (250) in response to the card registration request message, and cause the first identification information to be registered in conjunction with information about the card.

[0012] A method of operation of an application server (340) according to one embodiment of the present disclosure may include: an operation (1502) of transmitting a card registration request message to an electronic device (201) requesting that a card be registered in an application (350) of an electronic device (201); an operation (1504) of receiving a card registration response message including first identification information from the electronic device (201) in response to the card registration request message; and an operation (1506) of registering the first identification information in conjunction with information about the card.

[0013] In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components.

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

[0015] FIG. 2a is a block diagram schematically illustrating the configuration of an electronic device according to one embodiment.

[0016] FIG. 2b is a block diagram schematically illustrating the configuration of an application server according to one embodiment.

[0017] FIG. 3 is a diagram illustrating ticket purchase and ticket usage operations according to one embodiment.

[0018] FIG. 4 is a schematic diagram illustrating the configuration and operation of a ticket registration system according to one embodiment.

[0019] FIG. 5 is a schematic diagram illustrating the configuration and operation of a ticket usage system according to one embodiment.

[0020] FIG. 6 is a schematic diagram illustrating the configuration and operation of a ticket usage system according to one embodiment.

[0021] FIG. 7a is a flowchart illustrating the operation of accessing an identification module to register a ticket-type card according to one embodiment.

[0022] FIG. 7b is a flowchart illustrating the operation of registering a ticket-type card according to one embodiment.

[0023] FIG. 8a is a flowchart illustrating the operation of performing identity verification on an application server for ticket usage according to one embodiment.

[0024] FIG. 8b is a flowchart illustrating the operation when identity verification is successful in an application server according to one embodiment.

[0025] FIG. 8c is a flowchart illustrating the operation when identity verification fails in an application server according to one embodiment.

[0026] FIG. 9a is a flowchart illustrating the operation of identity verification being performed in an application for ticket usage according to one embodiment.

[0027] FIG. 9b is a flowchart illustrating the operation based on the identity verification result of an application according to one embodiment.

[0028] FIG. 10a is a diagram illustrating a UI screen for adding a ticket to an application according to one embodiment.

[0029] FIG. 10b is a diagram illustrating a UI screen for linking identification information to a ticket according to one embodiment.

[0030] FIG. 10c is a diagram illustrating a UI screen for linking identification information to a ticket through identification information verification according to one embodiment.

[0031] FIG. 11 is a diagram illustrating a UI screen of a ticket admission ticket displayed in an application according to one embodiment.

[0032] FIG. 12 is a flowchart illustrating the operation of an electronic device for registering a ticket-type card according to one embodiment.

[0033] FIG. 13a is a flowchart illustrating the operation of an electronic device for acquiring first identification information according to one embodiment.

[0034] FIG. 13b is a flowchart illustrating the operation of an electronic device that obtains first identification information based on an identification card display according to one embodiment.

[0035] FIG. 14a is a flowchart illustrating the operation of an electronic device using a ticket-type card based on identity verification of an electronic device according to one embodiment.

[0036] FIG. 14b is a flowchart illustrating the operation of an electronic device using a ticket-type card based on identity verification of an application server according to one embodiment.

[0037] FIG. 15 is a flowchart illustrating the operation of an application server according to one embodiment.

[0038] FIG. 16 is a flowchart illustrating the identity verification operation of an application server according to one embodiment.

[0039] Hereinafter, embodiments of the present disclosure are described in detail with reference to the drawings so that those skilled in the art can easily practice them. However, the present disclosure may be embodied in various different forms and is not limited to the embodiments described herein. In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Furthermore, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and brevity.

[0040] Hereinafter, embodiments of the present disclosure are described in detail with reference to the drawings so that those skilled in the art can easily practice them. However, the present disclosure may be embodied in various different forms and is not limited to the embodiments described herein. In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Furthermore, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and brevity.

[0041] FIG. 1 is a block diagram of an electronic device (101) in a network environment (100) according to various embodiments.

[0042] Referring to FIG. 1, in a network environment (100), an electronic device (101) may communicate with an electronic device (102) through a first network (198) (e.g., a short-range wireless communication network) or with at least one of an electronic device (104) or a server (108) through a second network (199) (e.g., a long-range wireless communication network). According to one embodiment, the electronic device (101) may communicate with the electronic device (104) through a server (108). According to one embodiment, the electronic device (101) may include a processor (120), memory (130), input module (150), sound output module (155), display module (160), audio module (170), sensor module (176), interface (177), connection terminal (178), haptic module (179), camera module (180), power management module (188), battery (189), communication module (190), subscriber identification module (196), or antenna module (197). In some embodiments, at least one of these components (e.g., connection terminal (178)) may be omitted from the electronic device (101), or one or more other components may be added. In some embodiments, some of these components (e.g., sensor module (176), camera module (180), or antenna module (197)) may be integrated into a single component (e.g., display module (160)).

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

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

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

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

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

[0048] The sound output module (155) can output a sound signal to the outside of the electronic device (101). The sound output module (155) may include, for example, a speaker or a receiver. The speaker may be used for general purposes, such as multimedia playback or recording playback. The receiver may be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part thereof.

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

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

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

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

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

[0054] The haptic module (179) can convert an electrical signal into a mechanical stimulus (e.g., vibration or movement) or an electrical stimulus that can be perceived by the user through tactile or kinesthetic senses. According to one embodiment, the haptic module (179) may include, for example, a motor, a piezoelectric element, or an electric stimulation device.

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

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

[0057] The battery (189) can supply power to at least one component of the electronic device (101). According to one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

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

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

[0060] An antenna module (197) can transmit signal or power information to or from the outside (e.g., an external electronic device). According to one embodiment, the antenna module (197) may include an antenna comprising a radiator made of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). According to one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as a first network (198) or a second network (199), may be selected from the plurality of antennas, for example, by a communication module (190). Signal or power may be transmitted or received between the communication module (190) and an external electronic device through the selected at least one antenna. According to some embodiments, in addition to the radiator, other components (e.g., a radio frequency integrated circuit (RFIC)) may be additionally created as part of the antenna module (197).

[0061] According to various embodiments, the antenna module (197) can create a mmWave antenna module. According to one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent to a first surface (e.g., bottom surface) of the printed circuit board and capable of supporting a specified high frequency band (e.g., mmWave band), and a plurality of antennas (e.g., array antennas) disposed on or adjacent to a second surface (e.g., top surface or side surface) of the printed circuit board and capable of transmitting or receiving a signal of the specified high frequency band.

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

[0063] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) through a server (108) connected to a second network (199). Each of the external electronic devices (102, or 104) may be of the same type or a different type as the electronic device (101). According to one embodiment, all or part of the operations performed on the electronic device (101) may be performed on one or more of the external electronic devices (102, 104, or 108). For example, if the electronic device (101) needs to perform a function or service automatically or in response to a request from a user or another device, the electronic device (101) may request one or more external electronic devices to perform at least part of the function or service instead of performing the function or service itself or additionally. One or more external electronic devices that receive the above request may execute at least part of the requested function or service, or additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may provide the result as is or additionally processed as at least part of the response to the request. For this purpose, for example, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used. The electronic device (101) may provide ultra-low latency services using, for example, distributed computing or mobile edge computing. In one embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server using machine learning and / or neural networks. According to one embodiment, the external electronic device (104) or the server (108) may be included within a second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0064] FIG. 2a is a block diagram schematically illustrating the configuration of an electronic device according to one embodiment.

[0065] Referring to FIG. 2a, the electronic device (201) may include a transceiver (210), a display (220), a user interface (UI) module (222), a memory (230), and a processor (240). According to one embodiment, the electronic device (201) may include additional components (e.g., an input module (150) or a sensor module (176) of FIG. 1) in addition to the illustrated components, or at least one of the illustrated components may be omitted. According to one embodiment, the electronic device (201) may include components identical or similar to at least one of the components (e.g., modules) of the electronic device (101) illustrated in FIG. 1.

[0066] According to one embodiment, the electronic device (201) may be any one of a mobile device (e.g., a smartphone or tablet), a computing device (e.g., a PC (personal computer) or a laptop), a wearable device (e.g., a smart watch or HMD (head mounted display)), or a home appliance (e.g., a TV (television)), but is not limited thereto and may be any of various types of electronic devices.

[0067] According to one embodiment, the communication unit (210) may be operated independently of a processor (e.g., application processor) (240) and may include one or more communication processors or communication circuits that support wireless communication or wired communication.

[0068] According to one embodiment, the communication unit (210) may include a wireless communication module (e.g., a cellular communication module, a short-range wireless communication module, or a GNSS communication module) or a wired communication module (e.g., a LAN communication module, or a power line communication module). The corresponding communication module among these communication modules may communicate with an external electronic device or server through a first network (e.g., a short-range communication network such as NFC, Bluetooth, BLE, Wi-Fi, WFD, or IrDA) or a second network (e.g., a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a long-range communication network such as a computer network (e.g., a LAN or WAN). These various types of communication modules may be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips).

[0069] According to one embodiment, the communication unit (210) may be implemented substantially identically or similarly to the communication module (190) of FIG. 1.

[0070] According to one embodiment, the display (220) can perform various display operations according to the function of the electronic device (201). For example, the display (220) can display at least one of various service information, media information, graphic information, or text information. According to one embodiment, the display (220) can display at least one card that can be used based on the execution of an application (e.g., a wallet application), and can display various information associated with the registration or use of at least one card. According to one embodiment, at least one card can be used as a term referring to various forms of content. For example, at least one card may include various forms of content such as a ticket, business card, train ticket, employee ID, pass, or coupon. According to one embodiment, at least one card may have various types based on the content it contains. According to one embodiment, each card included in at least one card may correspond to any one of various types such as a ticket type, business card type, train ticket type, employee ID type, pass type, or coupon type. According to one embodiment, in the following description, a ticket-type card may be briefly referred to as a ticket. According to one embodiment, the type of each card may be used for card management by type.

[0071] According to one embodiment, the display (220) may be implemented as a touchscreen to enable input and output and to support intuitive interaction between the user and the electronic device (201). For example, the display (220) may be implemented with various touchscreen technologies such as pressure-sensitive (or pressure-resistant), capacitive, or infrared. The display (220) may include a touch sensor or a pressure sensor and may support direct manipulation of icons, buttons, or graphical objects displayed on the screen using the user's body (e.g., hand or finger) or an input device (e.g., stylus pen).

[0072] According to one embodiment, the display (220) may be implemented as a single independent display or may include a plurality of displays placed at different locations.

[0073] According to one embodiment, the display (220) may be implemented identically or similarly to the display module (160) of FIG. 1.

[0074] According to one embodiment, the UI module (222) may include at least one module for interacting with a user, or at least one module that operates based on the user's input or selection. For example, the UI module (222) may include an identification module (360) and a biometric recognition module (370).

[0075] According to one embodiment, the identity card module (360) may include an identity verification related SDK (software development kit) and may acquire and store information related to the identity card (e.g., face information or identification information for identity verification) from an external authentication server. According to one embodiment, the identity card module (360) may operate in a secure area such as a TEE (trusted execution environment) and may restrict access by unauthenticated users.

[0076] According to one embodiment, the biometric recognition module (370) may include at least one biometric sensor (e.g., fingerprint sensor, iris recognition sensor, or face recognition sensor) and may recognize the user's biometrics through at least one biometric sensor. The biometric recognition module (370) may authenticate the recognized biometrics either independently or through communication with an external server. According to one embodiment, the biometric recognition module (370) may perform a user authentication operation to determine whether to allow access to the identity card module (360) and provide the authentication result to the identity card module (360).

[0077] According to one embodiment, authentication for accessing the identification module (360) may be performed through various authentication methods, such as password authentication or pattern input authentication, in addition to biometric authentication, and may include a biometric recognition module (370) and other authentication modules depending on the authentication method used.

[0078] According to one embodiment, the memory (230) may store various data used by at least one component of the electronic device (201) (e.g., a communication unit (210), a display (220), a UI module (222), or a processor (240)). For example, the memory (230) may store at least one program for processing and controlling the processor (240) and may store input and / or output data. The memory (230) may store at least one artificial intelligence (AI) model (e.g., a machine learning model or a deep learning model) and may include volatile memory or non-volatile memory. According to one embodiment, the memory (230) may be implemented substantially the same or similar to the memory (130) of FIG. 1.

[0079] According to one embodiment, the processor (240) can control the overall operation of the electronic device (201). The processor (240) can perform operations or data processing regarding the control and / or communication of at least one other component of the electronic device (201). For example, the processor (240) can be electrically connected to the communication unit (210), the display (220), the UI module (222), and the memory (230), and can perform the operation of the electronic device (201) described below.

[0080] The processor (240) may include a processing circuit that executes instructions of a program stored in memory (230). The processor (240) may include at least one of a CPU (central processing unit), NPU (neural processing unit), GPU (graphics processing unit), MPU (micro processing unit), MCU (micro controller unit), AP (application processor), CP (communication processor), SoC (system on chip), IC (integrated circuit) sensor hub, supplementary processor, ASIC (application specific integrated circuit), or FPGA (field programmable gate arrays), and may have multiple cores.

[0081] The processor (240) can control the operations of the electronic device (201) by executing instructions stored in the memory (230). For example, the processor (240) may correspond to a plurality of processors that divide and collectively perform a plurality of operations among the processors. According to one embodiment, the processor (240) may be implemented substantially identically or similarly to the processor (120) of FIG. 1.

[0082] An electronic device (201) according to one embodiment may include a transceiver (210), a display (220), an identification module (360), a memory (230), and at least one processor (240) including a processing circuit. The memory (230) may store commands that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to identify a card to be registered in an application, display a first UI (user interface) for the identification connection on the display (220) based on the determination that the type of the card to be registered is a type requiring an identification connection, obtain first identification information through the identification module (360) based on the reception of input based on the first UI, and cause the card to be registered in the application in conjunction with the first identification information.

[0083] According to one embodiment, the memory (230) may store instructions that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to receive a card registration request message from an application server via the communication unit (210), identify information about the card to be registered based on the card registration request message, and display the card to be registered on the display (220) based on the identified information.

[0084] According to one embodiment, the memory (230) may store instructions that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to determine the type of the card to be registered as a type requiring the identification card connection, based on the fact that the card to be registered is a ticket type card.

[0085] According to one embodiment, the memory (230) may store instructions that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to display a second UI on the display (220) to perform biometric authentication based on the reception of an input based on the first UI, and to obtain the first identification information from the identification module (360) based on the success of the biometric authentication through the second UI.

[0086] According to one embodiment, the memory (230) stores instructions that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to display an identification card for identity authentication on the display (220) via the identification module (360) based on the receipt of input for the first UI, display a second UI on the display (220) to perform biometric authentication based on the display of the identification card, update the identification card to include personal information based on the success of the biometric authentication via the second UI, and generate the first identification information based on the personal information via the identification module (360), and the personal information included in the identification card may include information obtained from an authentication server.

[0087] According to one embodiment, the memory (230) may store instructions that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to generate a first hash value based on the personal information through the identity module (360), request authentication of the first hash value from the authentication server, and receive a message from the authentication server indicating that authentication of the first hash value has been successful, thereby causing the first identity information to be generated through the identity module (360).

[0088] According to one embodiment, the memory (230) may store instructions that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to transmit a card registration response message to an application server via the communication unit (210), indicating that the card to be registered is linked to the first identification information and registered in the application.

[0089] According to one embodiment, the memory (230) may store commands that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to register the card to be registered to the application without linking it to the first identification information based on the failure of the biometric authentication through the second UI, and to send a card registration response message to the application server through the communication unit (210) indicating that the card to be registered has been registered without linking it to the first identification information.

[0090] According to one embodiment, the memory (230) may store instructions that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to perform identity verification based on receiving a request to use the registered card, and to display card data for the use of the registered card on the display (220) based on the success of the identity verification. The card data may include a QR (quick response code) code or a barcode.

[0091] According to one embodiment, when the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) obtains second identity information from the identity module, determines whether the second identity information corresponds to the first identity information, identifies that the identity authentication is successful based on the fact that the second identity information corresponds to the first identity information, transmits a request message requesting the card data to the application server through the communication unit (210) based on the fact that the identity authentication is successful, and stores instructions to obtain the card data from the application server through the communication unit (210) in response to the request message, and the first identity information may include a first hash value, and the second identity information may include a second hash value.

[0092] According to one embodiment, the memory (230) may store instructions that, when executed individually or collectively by the at least one processor (240), cause the electronic device (201) to identify that the identity verification has failed based on the fact that the second identity information does not correspond to the first identity information, and to output a notification message indicating that the identity verification has failed to the display (220) based on the fact that the identity verification has failed.

[0093] FIG. 2b is a block diagram schematically illustrating the configuration of an application server according to one embodiment.

[0094] According to one embodiment, the application server (340) is a server on a network associated with an application included in an electronic device (e.g., the electronic device (201) of FIG. 2a), and can perform operations associated with the application or store various information for providing services of the application. According to one embodiment, the application can be a wallet application, mobile wallet, mobile wallet, electronic wallet, or app wallet platform that supports payment through the electronic device or allows the registration and use of various types of cards (e.g., identification cards, boarding passes, admission tickets, tickets, or coupon-type cards).

[0095] Referring to FIG. 2b, an application server (340) according to one embodiment may include a transceiver (250), a memory (260), and a processor (270). According to one embodiment, the application server (340) may include additional components in addition to the illustrated components, or at least one of the illustrated components may be omitted.

[0096] According to one embodiment, the communication unit (250) may be operated independently of the processor (270) and may include one or more communication processors or communication circuits that support wireless communication or wired communication.

[0097] According to one embodiment, the communication unit (250) may include a wireless communication module (e.g., a cellular communication module, a near-field wireless communication module, or a GNSS communication module) or a wired communication module (e.g., a LAN communication module, or a power line communication module). The corresponding communication module among these communication modules may communicate with an electronic device (e.g., the electronic device (201) of FIG. 2a) or an external server (e.g., a partner server) through a first network (e.g., a near-field communication network such as NFC (near field communication), Bluetooth (Bluetooth), BLE (Bluetooth low energy), Wi-Fi (Wireless-Fidelity), WFD (Wi-Fi Direct), or IrDA (Infrared Data)) or a second network (e.g., a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips).

[0098] According to one embodiment, the memory (260) can store various data used by at least one component of the application server (340) (e.g., a communication unit (250) or a processor (270)). For example, the memory (260) can store at least one program for processing and controlling the processor (270) and can store input and / or output data. The memory (260) can store at least one AI model (e.g., a machine learning model or a deep learning model) and may include volatile memory or non-volatile memory.

[0099] According to one embodiment, the processor (270) can control the overall operation of the application server (340). The processor (270) can execute operations or data processing regarding the control and / or communication of at least one other component of the application server (340). For example, the processor (270) can be electrically connected to the communication unit (250) and the memory (260) and can perform the operation of the application server (340) described below.

[0100] The processor (270) may include a processing circuit that executes instructions of a program stored in memory (260). The processor (270) may include at least one of a CPU, NPU, GPU, MPU, MCU, AP, CP, SoC, IC sensor hub, auxiliary processor, ASIC, or FPGA, and may have multiple cores.

[0101] The processor (270) can control the operations of the application server (340) by executing instructions stored in memory (260). For example, the processor (270) can correspond to multiple processors that divide multiple operations among the processors and perform them collectively.

[0102] An application server (340) according to one embodiment may include a transceiver (250), a memory (260), and at least one processor (270) including a processing circuit. The memory (260) may store instructions that, when executed individually or collectively by the at least one processor (270), cause the application server (340) to transmit a card registration request message to the electronic device (201) via the transceiver (250) requesting the registration of a card in the application (350) of the electronic device (201), receive a card registration response message including first identification information from the electronic device (201) via the transceiver (250) in response to the card registration request message, and cause the first identification information to be registered in conjunction with information about the card.

[0103] According to one embodiment, the card registration request message and the card registration response message each include an identifier corresponding to the card, and the card may include a ticket-type card.

[0104] According to one embodiment, the memory (260) stores instructions that, when executed individually or collectively by the at least one processor (270), cause the application server (340) to receive a request message for the use of the card from the electronic device (201) via the communication unit (250), determine whether the second identity information included in the request message corresponds to the first identity information, identify that the identity authentication is successful based on the second identity information corresponding to the first identity information, request card data for the use of the card from the partner server (320) via the communication unit (250) based on the successful identity authentication, and transmit the card data to the electronic device (201) based on the receipt of the card data from the partner server (320) via the communication unit (250). The first identity information may include a first hash value, and the second identity information may include a second hash value.

[0105] According to one embodiment, the memory (260) may store instructions that, when executed individually or collectively by the at least one processor (270), cause the application server (340) to identify that the identity verification has failed based on the fact that the second identity information does not correspond to the first identity information, and to send a notification message indicating that the identity verification has failed to the electronic device (201) through the communication unit (250) based on the fact that the identity verification has failed.

[0106] FIG. 3 is a diagram illustrating ticket purchase and ticket usage operations according to one embodiment.

[0107] Figure 3 (a) is a diagram illustrating a ticket purchasing environment, and Figure 3 (b) is a diagram illustrating a ticket usage environment.

[0108] Referring to FIG. 3(a), the performance organizer (or planning agency) (310) may be an organizer that plans and operates a performance (or event or exhibition). The ticket vendor (320) may receive a quantity of tickets (314) for entry to a performance opened by the performance organizer (310) after making a deposit (312) to the performance organizer (310). The ticket vendor (320) may be an online store that sells a number of tickets corresponding to the quantity of tickets (314). A user (301) may purchase tickets (322) from the ticket vendor (320). For example, the user (301) may purchase tickets by accessing the online website of the ticket vendor (320) or by running an application through an electronic device (201).

[0109] According to one embodiment, a user (301) can complete payment for a purchased ticket using a card (e.g., a credit card or a debit card) registered in an application (e.g., a wallet application) of an electronic device (201). The paid ticket may be registered in the application based on the user's choice. Information regarding the ticket to be registered in the application may be provided from a server included in the ticket vendor (320), and said server may be referred to as a partner server for the application server associated with the application.

[0110] Referring to FIG. 3(b), the user (301) can perform identity verification to use the purchased ticket. For example, the user (301) can perform on-site verification (330) based on the user's (301) personal identification to verify that the user (301) is the owner of the purchased ticket.

[0111] According to one embodiment, the performance organizer (310) can check whether the ticket is being used by the ticket owner by comparing the user information entered for the ticket with the information included in the personal identification document. If the user information entered for the ticket corresponds with the information included in the personal identification document, the performance organizer (310) determines that the ticket is being used by the ticket owner and may allow the use of the ticket (or entry through the ticket). If the user information entered for the ticket does not correspond with the information included in the personal identification document, the performance organizer (310) determines that the ticket is being used by a user other than the ticket owner and may not allow the use of the ticket (or entry through the ticket). The above-described method of ticket usage makes it possible to select an authenticated user or ticket owner for the ticket, but since a comparison operation using a physical identification document must be performed offline, it may take a lot of time.

[0112] Generally, since the time of purchase and the time of use of a ticket differ, user information entered for the ticket may be unintentionally altered, or illegal resale or transfer may occur through such changes. To prevent this, the following explains how to register and use tickets by linking them with identification information.

[0113] FIG. 4 is a schematic diagram illustrating the configuration and operation of a ticket registration system according to one embodiment.

[0114] Referring to FIG. 4, the operation of a ticket registration system according to one embodiment may be performed on the premise that the user's (301) identification card (e.g., digital ID or mobile ID) or information related to the identification card is registered or utilized in an electronic device (201), and that a ticket vendor (320) is registered as a partner or partner server in an application server (340). According to one embodiment, the user's (301) identification card or information related to the identification card may be registered in an identification card module (360) and may be utilized in an application (350) through user authentication or identity authentication.

[0115] According to one embodiment, the application server (340) is a server associated with the application (350) and can perform operations associated with the application (350) or store various information for providing services of the application (350). The application (350) is an application included in the electronic device (201) and can support online or offline payments or support the registration and use of various types of cards (e.g., ticket type, business card type, train ticket type, employee ID type, pass type, or coupon type card). The application (350) may be referred to by various terms such as wallet application, mobile wallet, mobile wallet, electronic wallet, or app wallet platform. In the following description, the operation of the application (350) may substantially represent the operation of the electronic device (201) or the processor (240) of the electronic device (201).

[0116] In operation 402, according to one embodiment, the ticket seller (320) may make a deposit to the performance organizer (310) in advance to secure the quantity of tickets.

[0117] In operation 404, according to one embodiment, a ticket vendor (320) may receive a quantity of tickets from a performance organizer (310) based on a prepayment. The quantity of tickets is the number of tickets to be sold by the ticket vendor (320) and may represent admission tickets for entry to a performance opened by the performance organizer (310). The quantity of tickets may be determined based on the contractual relationship between the performance organizer (310) and the ticket vendor (320).

[0118] In operation 406, according to one embodiment, a user (301) may purchase a ticket sold by a ticket vendor (320). For example, the user (301) may purchase a ticket through a ticket purchasing platform (e.g., an online website or application) of the ticket vendor (320) using an electronic device (201), or purchase a ticket through offline purchase or on-site purchase. According to one embodiment, offline purchase or on-site purchase may be performed through an offline store or based on communication between the electronic device (201) and an external electronic device corresponding to the ticket vendor (320). For example, communication between the electronic device (201) and the external electronic device may include at least one of short-range communication (e.g., NFC, Bluetooth, or WFD communication), direct communication (e.g., P2P (peer-to-peer) communication), or contactless communication (e.g., communication using a QR code). According to one embodiment, the electronic device (201) can purchase a ticket stored in the external electronic device (e.g., a ticket provided by the performance organizer (310) and stored for sale) through communication with the external electronic device. When payment for the ticket is completed by the electronic device (201), the external electronic device may transmit the stored ticket to the electronic device (201) via near-field communication or direct communication, or provide a code or link for obtaining the ticket, such as a QR code, to the electronic device (201). According to one embodiment, when purchasing a ticket, payment may be made using a payment card (e.g., a credit card or debit card) registered in the application (350) of the electronic device (201). However, the payment method is not limited to this and may be performed in various ways based on bank deposits or methods supported by each card company.

[0119] According to one embodiment, when a ticket purchase is completed, information about the purchased ticket may be stored at the ticket sales outlet (320). The ticket sales outlet (320) may store information about the ticket purchased by the electronic device (201) in a set format or template.

[0120] According to one embodiment, information about a ticket stored at a ticket sales outlet (320) may include at least some of the ticket information included in [Table 1] below.

[0121]

[0122] Referring to [Table 1], the partner ID or template ID may represent identification information of the ticket vendor (320). For example, the partner ID may represent an identifier of the ticket vendor (320), and the template ID may represent an identifier of the template of the ticket vendor (320). Since the template may be configured differently for each of the multiple ticket vendors, it may be possible to identify the ticket vendor (320) among the multiple ticket vendors based on the template ID. According to one embodiment, the ref ID may represent a ticket identifier assigned and managed by the ticket vendor (320). For example, the ref ID may be assigned differently for each ticket. According to one embodiment, the Title, Location, or Date / Time may be information provided by the performance organizer (310). The Title may represent the name of the performance, event, or exhibition, the Location may represent the venue of the performance, event, or exhibition, and the Date / Time may represent the schedule of the performance, event, or exhibition.

[0123] According to one embodiment, a purchased ticket may be registered in an application (350) based on a user's selection. To this end, an electronic device (201) may display a user interface (UI) (e.g., a button, a menu, an icon, or a graphic object) for registering a purchased ticket in the application (350). For example, the electronic device (201) may display or activate an 'Add to Wallet' button along with information about the purchased ticket. According to one embodiment, when the 'Add to Wallet' button is selected by user input (e.g., touch input or keyboard input), the electronic device (201) may send a message requesting ticket registration to a ticket vendor (320).

[0124] In operation 408, according to one embodiment, the ticket vendor (320) may transmit a ticket registration request message to the application server (340) based on a message from the electronic device (201). According to one embodiment, the ticket registration request message may include at least some of the ticket information (e.g., ref ID) as shown in [Table 1].

[0125] According to one embodiment, when the application server (340) receives a ticket registration request message from the ticket seller (320), it can store or register ticket information included in the ticket registration request message.

[0126] According to one embodiment, the application server (340) may generate a content ID based on a ref ID included in a ticket registration request message. The content ID may be information for identifying a card object (e.g., a ticket, a payment card, a boarding pass, or a coupon type card) registered in the application server (340). Various types of cards may be registered in the application server (340). For example, the types of registered cards may include a payment card type representing a payment method such as a credit card or debit card, a ticket type representing a ticket such as an admission ticket, a boarding pass type representing a boarding pass for a means of transportation (e.g., a bus, a train, or an airplane), or a coupon type representing a coupon. A purchased ticket may be registered in the application server (340) as a ticket type card. If the type of card registered in the application server (340) is a ticket type, the content ID may be stored corresponding to the ref ID.

[0127] According to one embodiment, the application server (340) may generate a content ID such that at least part of it is identical to the ref ID, or generate a content ID in the form of a number (e.g., 4088177717743026112) of a length (e.g., 19 digits) set based on timestamp information corresponding to the time the ref ID was acquired.

[0128] According to one embodiment, when the application server (340) receives ticket information as shown in [Table 1] from the ticket vendor (320), it may store ticket information as shown in the following [Table 2].

[0129]

[0130] Referring to [Table 2], the ticket information stored in the application server (340) may have a form in which a content ID is added to the ticket information of [Table 1]. For example, the ticket information stored in the application server (340) may include a ref ID and a content ID that indicate the same ticket as two types of ticket identifiers (Ticket ID). According to one embodiment, if the content ID is set to be the same as the ref ID, the content ID may not be included, and ticket information such as that of [Table 1] may be stored in the application server (340).

[0131] According to one embodiment, a content ID may be used to indicate a ticket in communication between an application server (340) and an application (350), and a content ID and a ref ID may be used to indicate a ticket in communication between an application server (340) and a ticket vendor (320).

[0132] In operation 410, according to one embodiment, the application server (340) may transmit a card registration request message to the application (350). For example, the card registration request message may represent a message requesting the application (350) to register a card of a ticket type corresponding to a purchased ticket. According to one embodiment, the application (350) may identify a card to be registered to the application (350) based on the receipt of the card registration request message. According to one embodiment, the application (350) may receive a card registration request message from the application server (340), identify information about the card to be registered based on the card registration request message, and display the card to be registered on the display (220) based on the identified information.

[0133] According to one embodiment, the application (350) can determine whether the type of card to be registered is a type that requires an ID link. For example, the application (350) can identify the card to be registered as a type that requires an ID link (e.g., ticket type) based on the fact that the card registration request message includes at least some of the ticket information (e.g., content ID) as shown in [Table 2]. In operation 412, according to one embodiment, the application (350) can perform a separate provisioning operation for linking the card to be registered with the ID information based on the fact that the card to be registered is identified as a type that requires an ID link. The provisioning operation may include an operation to check whether to link the ID information to the card to be registered. According to one embodiment, the application (350) can display a first UI for ID linking on the display (220) based on the fact that the type of card to be registered is determined to be a type that requires an ID link. For example, if the application (350) determines that the type of card to be registered is a ticket type requiring identification linkage, it may display a prompt message such as 'Would you like to link identification information to the ticket?' as a first UI for linking identification information, on at least a part of the execution screen or in a pop-up window. Based on the receipt of input based on the first UI (e.g., prompt message) (e.g., input instructing to link identification information to the ticket), the application (350) may obtain first identification information through an identification module (360). According to one embodiment, the identification module (360) may include, for example, an identification verification related SDK, and may obtain and store information related to identification from an external authentication server (380).According to one embodiment, the application (350) may perform user authentication (e.g., biometric authentication such as fingerprint, iris, or facial recognition, or authentication via password or pattern input) to access the identity module (360). According to one embodiment, user authentication may be performed through a separate authentication module (e.g., biometric authentication module, password authentication module, or pattern authentication module) linked with the identity module (360). Based on the success of user authentication, the application (350) may access the identity module (360) operating in a secure area such as a TEE. According to one embodiment, the application (350) may perform operation 414 based on the ability to access the identity module (360).

[0134] In operation 414, according to one embodiment, the application (350) may request first identification information from the identification module (360). According to one embodiment, the identification module (360) is a module that is included in the application (350) or operates in conjunction with the application (350), and may be executed in a security area. The security area may represent a secure space for protecting data or information from external attacks and processing it securely. For example, the security area may include a TEE that is distinct from the environment in which the application (350) is executed.

[0135] According to one embodiment, the ID module (360) can generate a first hash value (hereinafter referred to as the 'hash value') based on the ID of the user (301) based on the request for first ID information. For example, the ID module (360) can generate a first hash value based on information included in the ID of the user (301) (e.g., user face information or user identification information).

[0136] In operation 416, according to one embodiment, the identity module (360) may request authentication for the first hash value from an authentication server (e.g., an external authentication server or an authentication server on a network) (380).

[0137] In operation 418, according to one embodiment, the authentication server (380) may provide the authentication result to the identity card module (360) in response to a request from the identity card module (360), based on whether the first hash value is associated with or corresponds to the identity card (or information contained in the identity card) of the user (301) stored in the authentication server (380). For example, if the first hash value is associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication success message to the identity card module (360). For example, if the first hash value is not associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication failure message to the identity card module (360).

[0138] In operation 420, according to one embodiment, the identity card module (360) can generate first identity card information based on receiving an authentication success message as an authentication result from the authentication server (380). According to one embodiment, the identity card module (360) can generate first identity card information based on an authenticated first hash value.

[0139] In operation 422, according to one embodiment, the ID module (360) can provide the generated first ID information to the application (350).

[0140] In operation 424, according to one embodiment, the application (350) can register a card (e.g., a ticket-type card) to be registered in conjunction with the first identification information based on the first identification information obtained.

[0141] In operation 426, according to one embodiment, the application (350) may transmit a card registration response message to the application server (340) based on the fact that the card to be registered is registered. According to one embodiment, the application (350) may transmit the first identification information (e.g., the first hash value) to the application server (340) as identification information corresponding to the content ID received in operation 410, based on the fact that the card to be registered is registered in association with the first identification information.

[0142] In operation 428, according to one embodiment, the application server (340) can identify that a ticket-type card has been registered in the application (350) in association with the first identification information based on receiving a card registration response message, and can update the ticket information in [Table 2]. For example, the application server (340) can add a first hash value as identification information of a ticket user (or ticket buyer) (e.g., user (301)) to the ticket information, as shown in the following [Table 3]. According to one embodiment, the first hash value may represent a first hash value included in the first identification information and may be included in the ticket information as an attribute value of the content ID or as information associated with the content ID.

[0143]

[0144] According to one embodiment, when the operations shown in FIG. 4 are completed, a ticket usage operation as shown in FIG. 5 or FIG. 6 may be performed.

[0145] FIG. 5 is a schematic diagram illustrating the configuration and operation of a ticket usage system according to one embodiment.

[0146] Referring to FIG. 5, in operation 502, according to one embodiment, a performance organizer (310) may request a ticket from a user (301). The performance organizer (310) may be an entity that compares a ticket and an identification card at a performance venue and allows entry based on the comparison result. The performance organizer (310) may request a ticket and an identification card from the user (301), or request admission ticket data issued to an authenticated user (or ticket owner).

[0147] In operation 504, according to one embodiment, the user (301) can select a ticket registered in the application (350) of the electronic device (201). According to one embodiment, the ticket registered in the application (350) may correspond to a ticket type card registered in operation 424 of FIG. 4. According to one embodiment, the user (301) can run the application (350) on the electronic device (201) to select any one of the ticket type cards registered in the application (305) or perform an operation set for quick ticket selection. For example, the set operation may include swiping or swiping up from a set position (e.g., bottom) of the screen (e.g., home screen) of the electronic device (201) to a set direction (e.g., top direction of the display (220)). According to one embodiment, the quick access screen (or QA screen) of the application (350) may be displayed by the swipe. A ticket-type card may be displayed on the quick execution screen, and the user (301) may perform a set input (e.g., touch input on the displayed card) to select the displayed card. According to one embodiment, a ticket detail screen may be displayed based on the selection of a ticket-type card by the user. According to one embodiment, the ticket detail screen may be a screen that displays ticket information (e.g., performance name, venue, or schedule information) and may be used to obtain admission ticket data.

[0148] In operation 506, according to one embodiment, the application (350) may request second identity information from an identity module (360) running in a secure area (e.g., TEE) to obtain admission ticket data corresponding to the ticket based on the display of the ticket detail screen. According to one embodiment, before requesting the second identity information, the application (350) may perform user authentication to access the identity module (360) (e.g., biometric authentication such as fingerprint, iris, or facial recognition, authentication via password, or pattern input). Based on the success of the user authentication, the application (350) may access the identity module (360) and request the second identity information.

[0149] According to one embodiment, the ID module (360) can generate a second hash value based on the ID of the user (301) based on a second ID information request from the application (350). For example, the ID module (360) can generate a second hash value based on information included in the ID of the user (301) (e.g., user face information or user identification information).

[0150] In operation 508, according to one embodiment, the identity module (360) may request authentication for a second hash value from the authentication server (380).

[0151] In operation 510, according to one embodiment, the authentication server (380) may provide an authentication result to the identity card module (360) based on whether the second hash value is associated with or corresponds to the identity card (or information contained in the identity card) of the user (301) stored in the authentication server (380) in response to a request from the identity card module (360). For example, if the second hash value is associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication success message to the identity card module (360). For example, if the second hash value is not associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication failure message to the identity card module (360).

[0152] In operation 512, according to one embodiment, the identity card module (360) may generate second identity card information based on receiving an authentication success message as an authentication result from the authentication server (380). According to one embodiment, the identity card module (360) may generate second identity card information based on an authenticated second hash value.

[0153] In operation 514, according to one embodiment, the ID module (360) can provide the generated second ID information to the application (350).

[0154] In operation 516, according to one embodiment, the application (350) may provide second identification information provided from the identification module (360) to the application server (340). According to one embodiment, the application (350) may transmit information about a ticket selected by the user (e.g., content ID) and the user (301)'s second identification information (e.g., second hash value) to the application server (340).

[0155] In operation 518, according to one embodiment, the application server (340) may perform identity verification for ticket user authentication based on information (e.g., content ID and a second hash value) received from the application (350). According to one embodiment, the application server (340) may identify a ticket based on the content ID and compare the first identity information (e.g., a first hash value) stored at the time of registration of the identified ticket with the second identity information (e.g., a second hash value) received in operation 516. According to one embodiment, if the first hash value and the second hash value do not correspond, the application server (340) may send a message to the application (350) indicating that identity verification has failed. Based on the message from the application server (340), the application (350) may output a notification message indicating that identity verification has failed. According to one embodiment, if the first hash value and the second hash value correspond, the application server (340) may, in operation 520, send a request message requesting admission ticket data to the second server (e.g., partner server, ticket vendor (320)). According to one embodiment, the request message may include a ref ID corresponding to a content ID.

[0156] In operation 522, according to one embodiment, the ticket vendor (320) may transmit admission ticket data to the application server (340) in response to a request message. According to one embodiment, the ticket vendor (320) may identify the ticket based on a ref ID and generate admission ticket data corresponding to the identified ticket. For example, the admission ticket data may include a barcode, a QR (quick response code) code, or other forms of admission authentication data. The barcode or QR code may be a dynamic barcode or dynamic QR code valid for a set period of time. According to one embodiment, the ticket vendor (320) may transmit the admission ticket data along with the ref ID to the application server (340).

[0157] According to one embodiment, the application server (340) can receive admission ticket data from the ticket vendor (320). According to one embodiment, the application server (340) can identify the received admission ticket data as admission ticket data associated with a content ID corresponding to a ref ID.

[0158] In operation 524, according to one embodiment, the application server (340) can transmit identified ticket data to the application (350). According to one embodiment, the ticket vendor (320) can transmit ticket data to the application (350) along with the content ID.

[0159] In operation 526, according to one embodiment, the application (350) may provide ticket data received from the application server (340) to the performance organizer (310) based on the user's selection. For example, if the ticket data is a barcode or a QR code, the ticket data may be scanned by the performance organizer (310) and transmitted to the performance organizer (310).

[0160] According to one embodiment, the admission ticket data can indicate that the authentication operation has been completed and can be issued to an authenticated user and used without providing an identification card or additional authentication. Therefore, since entry can be permitted by scanning the admission ticket data, the performance organizer (310) can simplify the entry procedure and the user (301) can have the convenience of entering the performance venue more quickly.

[0161] FIG. 6 is a schematic diagram illustrating the configuration and operation of a ticket usage system according to one embodiment.

[0162] Since operations 602 to 614 of FIG. 6 correspond to operations 502 to 514 of FIG. 5, a detailed description will be omitted. Unlike FIG. 5, in FIG. 6, the identity verification operation can be performed by an application (350) instead of an application server (340).

[0163] Referring to FIG. 6, in operation 616, according to one embodiment, the application (350) can perform identity verification. According to one embodiment, the application (350) can identify a content ID corresponding to a ticket selected by the user in operation 604, and compare a first identity information (e.g., a first hash value) stored at the time of registration corresponding to the content ID with a second identity information (e.g., a second hash value) obtained from the identity module (360) in operation 614. For example, if the first hash value and the second hash value do not correspond, the application (350) can output a notification message indicating that identity verification has failed. If the first hash value and the second hash value correspond, the application (350) can send a first request message requesting admission ticket data to the application server (340) in operation 618. According to one embodiment, the first request message may include a content ID.

[0164] In operation 620, according to one embodiment, the application server (340) receives a first request message from the application (350) and can send a second request message requesting admission ticket data to the ticket vendor (320) based on the received first request message. According to one embodiment, the application server (340) identifies a ref ID corresponding to the content ID included in the first request message and can send a second request message including the identified ref ID to the ticket vendor (320).

[0165] In operation 622, according to one embodiment, the ticket vendor (320) may transmit admission ticket data to the application server (340) in response to the second request message. According to one embodiment, the ticket vendor (320) may identify the ticket based on the ref ID and generate admission ticket data corresponding to the identified ticket. For example, the admission ticket data may include a barcode, a QR code, or other forms of admission authentication data. The barcode or QR code may be a dynamic barcode or a dynamic QR code valid for a set period of time. According to one embodiment, the ticket vendor (320) may transmit the admission ticket data along with the ref ID to the application server (340). The application server (340) may receive the admission ticket data from the ticket vendor (320). According to one embodiment, the application server (340) may identify the received admission ticket data as admission ticket data associated with a content ID corresponding to the ref ID.

[0166] In operation 624, according to one embodiment, the application server (340) can transmit identified ticket data to the application (350). According to one embodiment, the ticket vendor (320) can transmit ticket data to the application (350) along with the content ID.

[0167] In operation 626, according to one embodiment, the application (350) may provide ticket data received from the application server (340) to the performance organizer (310) based on the user's selection. For example, if the ticket data is a barcode or QR code, the ticket data may be scanned by the performance organizer (310) and transmitted to the performance organizer (310). According to one embodiment, the ticket data is issued to an authenticated user and can be used without providing an ID or additional authentication. When the ticket data is used, on-site authentication based on the user's (301) personal ID and the purchased ticket may be omitted for user authentication regarding the purchased ticket. Thus, entry to the performance can proceed more accurately and quickly.

[0168] With reference to FIGS. 7a to 9b, the ticket registration operation and the ticket usage operation will be described in detail below. According to one embodiment, the operation of the application (350) illustrated in FIGS. 7a to 9b can be understood as an operation performed by an electronic device (201) or a processor (240) of the electronic device (201). The operations illustrated in FIGS. 7a to 9b may be performed in various orders, not limited to the order illustrated. According to one embodiment, at least some of the operations illustrated in FIGS. 7a to 9b may be omitted, or more operations may be performed than those illustrated in FIGS. 7a to 9b.

[0169] FIG. 7a is a flowchart illustrating the operation of accessing an identification module to register a ticket-type card according to one embodiment.

[0170] Referring to FIG. 7a, in operation 702, according to one embodiment, a user (301) can purchase a ticket. According to one embodiment, the user (301) can purchase a ticket using an electronic device (201) through a ticket purchase platform (e.g., an online website or application) of a ticket vendor (320) or through an offline store or on-site purchase (e.g., near-field communication, direct communication, or communication using a QR code with an external electronic device corresponding to the ticket vendor (320). Based on the completion of the ticket purchase, the electronic device (201) may display an input means for adding the ticket to an application (350) (e.g., a wallet application, a mobile wallet, or an electronic wallet). For example, the electronic device (201) may display or activate an 'Add to Wallet' button as an input means on the screen of the electronic device (201) (e.g., a ticket purchase completion screen).

[0171] In operation 704, according to one embodiment, the user (301) may select the 'Add to Wallet' button based on touch input or key input. The electronic device (201) may send a message requesting the registration of the purchased ticket to the ticket vendor (320) based on the selection of the 'Add to Wallet' button. According to one embodiment, the ticket vendor (320) has a function associated with the 'Add to Wallet' button integrated, and the selection of the 'Add to Wallet' button may trigger an action to add information or data of the ticket to the application server (340). The input means for adding a ticket to the application (350) is not limited to the example of a button, and the action of registering a ticket to the application (350) from the user may be performed through other multimodal input means (e.g., voice, gesture, etc.).

[0172] In operation 706, according to one embodiment, the ticket vendor (320) may send a ticket registration request message to the application server (340) based on the selection of the 'Add to Wallet' button. According to one embodiment, the ticket registration request message may include information about a ticket purchased by the user (301). For example, the first ticket registration request message may include at least a portion of the ticket information stored in the ticket vendor (320) as shown in [Table 1] (e.g., a ref ID set by the ticket vendor (320)).

[0173] According to one embodiment, the application server (340) receives a ticket registration request message from a ticket vendor (320) and can store or register ticket information included in the ticket registration request message. According to one embodiment, the application server (340) can generate a content ID based on a ref ID included in the ticket registration request message and add the generated content ID to the ticket information. The content ID is identification information assigned to the ticket by the application server (340) and can be used to manage the ticket. According to one embodiment, the ticket can be registered as a ticket-type card in the application server (340), and the content ID can be used to identify or indicate the ticket-type card. In the application server (340), the content ID can be stored in correspondence with the ref ID, which is the ticket identifier of the ticket vendor (320).

[0174] In operation 708, according to one embodiment, the application server (340) may transmit a card registration request message to the application (350). According to one embodiment, the card registration request message may represent a message requesting the application (350) to register a card of a ticket type corresponding to the ticket to be registered. According to one embodiment, the card registration request message may include ticket information, and the ticket information may include at least a portion of the ticket information (e.g., content ID) as shown in [Table 2], for example.

[0175] According to one embodiment, the application (350) receives a card registration request message from the application server (340) and can identify a card to be registered in the application (350). According to one embodiment, the application (350) receives a card registration request message from the application server (340) and can identify information about the card to be registered based on the card registration request message. The application (350) can display the card to be registered on the display (220) based on the identified information.

[0176] According to one embodiment, the application (350) can determine whether the type of card to be registered is a type that requires an ID linkage. For example, the application (350) can identify the card to be registered as a ticket type card based on the fact that ticket information is included in the card registration request message, and determine that the card to be registered is a type that requires an ID linkage based on the fact that the card to be registered is a ticket type card.

[0177] According to one embodiment, the application (350) may receive confirmation from a user to perform an ID connection based on the determination that the type of card to be registered is a type requiring an ID connection. For example, the application (350) may perform operations 710 and 712 to receive confirmation from the user, but this may be omitted. According to one embodiment, the application (350) may immediately perform operations for an ID connection (e.g., operations 714 and below) without user confirmation based on the determination that the type of card to be registered is a type requiring an ID connection.

[0178] In operation 710, according to one embodiment, the application (350) may request the user (301) to select whether to link identification information based on the determination that the type of card to be registered is a type that requires an identification link. For example, based on the determination that the type of card to be registered is a type that requires an identification link, the application (350) may display a first UI for linking identification (e.g., a message such as "Would you like to link identification to the ticket?" and "Yes" and "No" buttons) on the display (220) (e.g., at least part of the execution screen or a pop-up window).

[0179] In operation 712, according to one embodiment, the application (350) may receive input from a user (301) who has chosen to link identification information to a ticket (e.g., input based on a "Yes" button).

[0180] In operation 714, according to one embodiment, the application (350) may load an identity module (360) based on input from a user (301). According to one embodiment, the application (350) may load an identity module (360) to obtain first identity information of the user (301) to be connected to a ticket-type card. According to one embodiment, the identity module (360) may be a module included in the application (350) or operated in conjunction with the application (350), and may be executed in a security area. The security area may represent a secure space for protecting data or information from external attacks and processing it securely. For example, the security area may include a TEE that is distinct from the environment in which the application (350) is executed.

[0181] According to one embodiment, the identity module (360) may include, for example, an identity verification related SDK and may obtain and store identity-related information from an external authentication server (380). According to one embodiment, the identity module (360) may provide first identity information based on the identity-related information of the user (301), but access may be limited. For example, the identity module (360) may be accessed through user authentication (e.g., identity authentication for the user (301)) and may be linked with at least one authentication module for user authentication (e.g., biometric recognition module (370)). As described below, user authentication may be performed through biometric authentication, but is not limited thereto, and other methods of authentication, such as password or pattern input, may also be performed.

[0182] In operation 716, according to one embodiment, the identity module (360) may request an identity authentication operation associated with the user (301) of the application (350) to the biometric module (370) based on what is loaded by the application (350). The biometric module (370) may perform an authentication operation to determine whether access to the identity module (360) is performed by an allowed user. For example, the biometric module (370) may recognize the user (301)'s fingerprint, iris, or face and perform identity authentication by comparing the recognition result with pre-stored information.

[0183] According to one embodiment, if identity authentication fails, the biometric recognition module (370) may provide information indicating that identity authentication has failed to the identity identification module (360). In this case, the identity identification module (360) may provide to the application (350) that the first identity identification information cannot be provided due to the identity authentication failure, and the application (350) may display a message on the screen indicating that the first identity identification information cannot be linked to a ticket-type card.

[0184] According to one embodiment, when identity authentication is successful, the biometric recognition module (370) may provide information indicating that identity authentication has been successful to the identity identification module (360) in operation 718. According to one embodiment, the identity identification module (360) may allow access to the user (301) of the application (350) based on the fact that identity authentication has been successful. According to one embodiment, the identity identification module (360) may receive a request message from the application (350) requesting the first identity information of the user (301) based on the fact that access has been allowed.

[0185] According to one embodiment, based on the execution of operation 718 of FIG. 7a, operation 720 of FIG. 7b may be performed.

[0186] FIG. 7b is a flowchart illustrating the operation of registering a ticket-type card according to one embodiment. Referring to FIG. 7b, in operation 720, according to one embodiment, an ID module (360) can generate a first hash value based on the ID of a user (301). For example, the ID module (360) can generate a first hash value based on information included in the ID of the user (301) (e.g., user face information or user identification information) based on receiving a request message from an application (350) requesting the first ID information of the user (301).

[0187] In operation 722, according to one embodiment, the identity module (360) may request authentication for the first hash value from the authentication server (380).

[0188] In operation 724, according to one embodiment, the authentication server (380) may provide the authentication result to the identity card module (360) in response to a request from the identity card module (360), based on whether the first hash value is associated with or corresponds to the identity card (or information contained in the identity card) of the user (301) stored in the authentication server (380). For example, if the first hash value is associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication success message to the identity card module (360).

[0189] In operation 726, according to one embodiment, the ID module (360) may provide the first ID information to the application (350) based on the successful authentication of the first hash value. According to one embodiment, the first ID information may include data different from the original data of the ID, for example, a first hash value authenticated by an authentication server (380). Since the first hash value represents a general data value rather than a value indicating the original data included in the ID, direct exposure of personal information may be prevented and it may be possible to store it in the application server (340). Since the first hash value may be generated based on data or information included in the ID (e.g., user face information or user identification information), it may remain the same value as long as the data or information included in the ID is not changed.

[0190] In operation 728, according to one embodiment, the application (350) can register a card to be registered in the application (350) in conjunction with the first identification information based on the acquisition of the first identification information.

[0191] In operation 730, according to one embodiment, the application (350) may transmit a card registration response message to the application server (340) based on the fact that a card to be registered has been registered. According to one embodiment, the card registration response message may include an attribute value of the content ID received in operation 708 of FIG. 7a or a first hash value as first identification information corresponding to the content ID.

[0192] In operation 732, according to one embodiment, the application server (340) can update ticket information based on a card registration response message received from the application (350). According to one embodiment, the application server (340) can update ticket information such that a first hash value corresponding to the content ID is included.

[0193] In operation 734, according to one embodiment, the application server (340) may send a ticket information update notification message to the application (350) based on the fact that the ticket information has been updated. The ticket information update notification message may indicate to the application server (340) that a first hash value has been registered.

[0194] In operation 736, according to one embodiment, the application (350) may perform an operation to notify the user (301) of a notification message that the identification information connection is complete, based on a ticket information update notification message. According to one embodiment, the application (350) may output a message on an execution screen or pop-up window indicating that the first identification information has been connected to the ticket (or ticket-type card).

[0195] According to one embodiment, when a ticket registration operation is completed based on the operations shown in FIGS. 7a and 7b, a ticket usage operation as shown in FIGS. 8a to 8c, or FIGS. 9a to 9c, may be performed. According to one embodiment, FIGS. 8a to 8c may represent a ticket usage operation based on identity verification of an application server (340), and FIGS. 9a to 9c may represent a ticket usage operation based on identity verification of an application (350).

[0196] FIG. 8a is a flowchart illustrating the operation of performing identity verification on an application server for ticket usage according to one embodiment.

[0197] Referring to FIG. 8a, in operation 802, according to one embodiment, a user (301) can select a registered ticket. According to one embodiment, the user (301) can swipe up the screen of the electronic device (201) to launch an application (350) and select a ticket type card displayed on the quick launch screen (or QA screen) of the application (350) as a registered ticket.

[0198] In operation 804, according to one embodiment, the user (301) can enter the detail screen of the selected ticket through a set input for the selected ticket on the quick execution screen (e.g., a touch input on a card of ticket type). The detail screen of the selected ticket can be entered to obtain admission ticket data (e.g., a QR code or a barcode).

[0199] In operation 806, according to one embodiment, the application (350) may load an identity card module (360). According to one embodiment, the identity card module (360) may include, for example, an identity card verification related SDK and may obtain and store information related to the identity card from an external authentication server (380). According to one embodiment, the application (350) may load the identity card module to use information related to the identity card.

[0200] In operation 808, according to one embodiment, the identity module (360) may request an identity authentication operation from the biometric module (370) to allow access by an authenticated user as a module operating in a secure area (e.g., TEE). The biometric module (370) may perform an identity authentication operation based on biometric authentication based on the request of the identity module (360). For example, the biometric module (370) may recognize the fingerprint, iris, or face of the user (301) and perform identity authentication by comparing the recognition result with pre-stored information.

[0201] In operation 810, according to one embodiment, the biometric recognition module (370) may provide information indicating that identity authentication has been successful to the identity identification module (360) based on the fact that identity authentication has been successful. The biometric recognition module (370) may provide information indicating that identity authentication has failed to the identity identification module (360) based on the fact that identity authentication has failed.

[0202] In operation 812, according to one embodiment, the identity module (360) may allow access to the application (350) of the identity module (360) based on receiving information indicating that identity authentication has been successful. According to one embodiment, the identity module (360) may not allow access to the application (350) of the identity module (360) based on receiving information indicating that identity authentication has failed. If access to the identity module (360) is not allowed, the application (350) may not be able to obtain the second identity information from the identity module (360) and thus may be unable to use the ticket.

[0203] In operation 814, according to one embodiment, the application (350) may request second identity information from the identity module (360) based on the fact that access to the identity module (360) is permitted. According to one embodiment, the second identity information may be identity information associated with the user (301) who is the ticket user.

[0204] In operation 816, according to one embodiment, the ID module (360) may generate a second hash value based on the ID (or ID-related information) of a user (301) registered in the ID module (360) based on a request from the application (350). For example, the ID module (360) may generate a second hash value based on information included in the ID of the user (301) (e.g., user face information or user identification information).

[0205] In operation 818, according to one embodiment, the identity module (360) may request authentication for a second hash value from the authentication server (380).

[0206] In operation 820, according to one embodiment, the authentication server (380) may send an authentication success message to the identity card module (360) in response to a request from the identity card module (360).

[0207] According to one embodiment, the authentication server (380) may determine, based on a request from the identity card module (360), whether the second hash value is associated with or corresponds to the identity card (or information contained in the identity card) of the user (301) stored in the authentication server (380). If the second hash value is associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication success message to the identity card module (360). If the second hash value is not associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication failure message to the identity card module (360).

[0208] In operation 822, according to one embodiment, the ID module (360) may transmit second ID information containing a second hash value to the application (350) based on receiving an authentication success message from the authentication server (380). According to one embodiment, if the ID module (360) receives an authentication failure message from the authentication server (380), it may transmit a message to the application (350) indicating that the second hash value for which authentication failed cannot be used, and thus the provision of the second ID information is impossible. In this case, the application (350) may not be able to obtain the second ID information from the ID module (360) and thus the ticket may not be usable.

[0209] In operation 824, according to one embodiment, the application (350) may request identity verification from the application server (340) based on receiving second identity information. According to one embodiment, the application (350) may transmit the second identity information (e.g., second hash value) obtained in operation 822 to the application server (340) as information based on the content ID, so that it is compared with the first identity information (e.g., first hash value) registered at the time of ticket registration. For example, the application (350) may request identity verification by transmitting the content ID and the second hash value to the application server (340).

[0210] In operation 826, according to one embodiment, the application server (340) can perform identity verification based on a request from the application (350). According to one embodiment, the application server (340) can compare a first hash value registered as first identity information corresponding to a content ID with a second hash value received in operation 824, and perform identity verification based on the comparison result.

[0211] According to one embodiment, if the first hash value and the second hash value correspond, the application server (340) determines that identity verification is successful and can perform the operations shown in FIG. 8b.

[0212] According to one embodiment, if the first hash value and the second hash value do not correspond, the application server (340) determines that identity verification has failed and can perform the operations illustrated in FIG. 8c.

[0213] FIG. 8b is a flowchart illustrating the operation when identity verification is successful in an application server according to one embodiment.

[0214] Referring to FIG. 8b, in operation 818, according to one embodiment, the application server (340) can identify that identity verification has been successful. Operation 828 may be an operation performed following operation 826 of FIG. 8a. According to one embodiment, the application server (340) can identify that identity verification has been successful based on the identity verification result of operation 826.

[0215] In operation 830, according to one embodiment, the application server (340) may send a request message requesting admission ticket data to the ticket vendor (320) based on the fact that identity verification has been successful. According to one embodiment, the request message may include a ref ID corresponding to the content ID of the ticket.

[0216] In operation 832, according to one embodiment, a ticket vendor (320) may transmit admission ticket data to an application server (340) in response to a request message. According to one embodiment, the ticket vendor (320) may identify a ticket based on a ref ID and generate admission ticket data corresponding to the identified ticket. For example, the admission ticket data may include a barcode or a QR code, or may include a dynamic barcode or a dynamic QR code valid for a set time to enhance security. According to one embodiment, the ticket vendor (320) may transmit the admission ticket data along with the ref ID to the application server (340).

[0217] In operation 834, according to one embodiment, the application server (340) may receive admission ticket data from the ticket vendor (320). According to one embodiment, the application server (340) may identify a content ID corresponding to a ref ID and identify the received admission ticket data as admission ticket data of the ticket corresponding to the content ID.

[0218] According to one embodiment of operation 836, the application (350) can activate a ticket based on ticket data. According to one embodiment, the operation of activating a ticket may include at least one of the operation of displaying ticket data on a screen, the operation of enlarging or brightening ticket data, or the operation of adding and displaying an authentication mark to ticket data. For example, the authentication mark may include a UI authentication mark indicating that the ticket user's identity verification has been completed or indicating that the user is an authenticated user.

[0219] In operation 838, according to one embodiment, the performance organizer (310) can select and admit valid audience members without a separate identity verification procedure by scanning a ticket with completed identity verification.

[0220] FIG. 8c is a flowchart illustrating the operation when identity verification fails in a wallet server according to one embodiment.

[0221] Referring to FIG. 8c, in operation 840, according to one embodiment, the application server (340) can identify that identity verification has failed. Operation 840 may be an operation performed following operation 826 of FIG. 8a, and may identify that identity verification has failed based on the identity verification result of operation 826.

[0222] In operation 842, according to one embodiment, the application server (340) can transmit the identity verification failure result to the application (350).

[0223] In operation 844, according to one embodiment, the application (350) may output a notification message to the display (220) indicating that identity verification has failed based on the result of identity verification failure. Based on the failure of identity verification, the use of the ticket registered in the application (350) may be impossible. As described above, since the ticket registered in the application (350) can be used by an authenticated user, the theft or illegal resale of the ticket can be prevented.

[0224] The operations of FIGS. 8a to 8c are not limited to examples of tickets (or admission tickets) and can be extended to various content requiring identity verification. For example, the ticket may be replaced with a train ticket, admission ticket, employee ID, or receipt, and the operations of FIGS. 8a to 8c may be performed for identity verification of various content.

[0225] FIG. 9a is a flowchart illustrating the operation of identity verification being performed in an application for ticket usage according to one embodiment.

[0226] Referring to FIG. 9a, in operation 902, according to one embodiment, a user (301) can select a registered ticket. According to one embodiment, the user (301) can swipe up the screen of the electronic device (201) to launch an application (350) and select a ticket type card displayed on the quick launch screen (or QA screen) of the application (350) as a registered ticket.

[0227] In operation 904, according to one embodiment, the user (301) can enter the detail screen of the selected ticket through a set input for the selected ticket on the quick execution screen (e.g., a touch input on a card of ticket type). The detail screen of the selected ticket can be entered to obtain admission ticket data (e.g., a QR code or a barcode).

[0228] In operation 906, according to one embodiment, the application (350) may request ticket information of the selected ticket from the application server (340) based on entering the detail screen of the selected ticket. According to one embodiment, the application (350) may request that ticket information be provided by transmitting a content ID to the application server (340).

[0229] In operation 908, according to one embodiment, the application server (340) may transmit ticket information to the application (350) in response to a ticket information request from the application (350). According to one embodiment, the ticket information may include a content ID and a first identification information (e.g., a first hash value) registered in correspondence with the content ID.

[0230] In operation 910, according to one embodiment, the application (350) may load an identity card module (360). According to one embodiment, the identity card module (360) may include, for example, an identity card verification related SDK and may obtain and store information related to the identity card from an external authentication server (380). According to one embodiment, the application (350) may load the identity card module to use information related to the identity card.

[0231] In operation 912, according to one embodiment, the identity module (360) may request an identity authentication operation from the biometric module (370) to allow access by an authenticated user as a module operating in a secure area (e.g., TEE). The biometric module (370) may perform an identity authentication operation based on biometric authentication based on the request of the identity module (360). For example, the biometric module (370) may recognize the fingerprint, iris, or face of the user (301) and perform identity authentication by comparing the recognition result with pre-stored information.

[0232] In operation 914, according to one embodiment, the biometric recognition module (370) may provide information indicating that identity authentication has been successful to the identity identification module (360) based on the fact that identity authentication has been successful. The biometric recognition module (370) may provide information indicating that identity authentication has failed to the identity identification module (360) based on the fact that identity authentication has failed.

[0233] In operation 916, according to one embodiment, the identity module (360) may allow access to the application (350) of the identity module (360) based on receiving information indicating that identity authentication has been successful. According to one embodiment, the identity module (360) may not allow access to the application (350) of the identity module (360) based on receiving information indicating that identity authentication has failed. If access to the identity module (360) is not allowed, the application (350) may not be able to obtain the second identity information from the identity module (360) and thus may be unable to use the ticket.

[0234] In operation 918, according to one embodiment, the application (350) may request second identity information from the identity module (360) based on the fact that access to the identity module (360) is allowed. According to one embodiment, the second identity information may be identity information associated with the user (301) who is the ticket user.

[0235] In operation 920, according to one embodiment, the ID module (360) may generate a second hash value based on the ID (or ID-related information) of a user (301) registered in the ID module (360) based on a request from the application (350). For example, the ID module (360) may generate a second hash value based on information included in the ID of the user (301) (e.g., user face information or user identification information).

[0236] In operation 922, according to one embodiment, the identity module (360) may request authentication for a second hash value from the authentication server (380).

[0237] In operation 924, according to one embodiment, the authentication server (380) may send an authentication success message to the identity card module (360) in response to a request from the identity card module (360). According to one embodiment, the authentication server (380) may determine, based on a request from the identity card module (360), whether a second hash value is associated with or corresponds to the identity card (or information contained in the identity card) of the user (301) stored in the authentication server (380). If the second hash value is associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication success message to the identity card module (360). If the second hash value is not associated with or corresponds to the identity card of the user (301) stored in the authentication server (380), the authentication server (380) may send an authentication failure message to the identity card module (360).

[0238] In operation 926, according to one embodiment, the ID module (360) may transmit second ID information containing a second hash value to the application (350) based on receiving an authentication success message from the authentication server (380). According to one embodiment, if the ID module (360) receives an authentication failure message from the authentication server (380), it may transmit a message to the application (350) indicating that the second hash value for which authentication failed cannot be used, and thus the provision of the second ID information is impossible. In this case, the application (350) may not be able to obtain the second ID information from the ID module (360) and thus the ticket may not be usable.

[0239] In operation 928, according to one embodiment, the application (350) can perform identity authentication based on a content ID and a second hash value included in the second identity information. According to one embodiment, the application (350) can compare the first identity information (e.g., a first hash value) and the second identity information (e.g., a second hash value) for the ticket corresponding to the content ID. For example, the application (350) can compare whether the first hash value received in operation 908 corresponds to the second hash value obtained in operation 926. Based on the identity authentication result through comparison, the application (350) can perform the operation illustrated in FIG. 9b.

[0240] FIG. 9b is a flowchart illustrating the operation based on the identity verification result of a wallet application according to one embodiment.

[0241] Referring to FIG. 9b, operation 930 may be an operation performed following operation 928 of FIG. 9a. In operation 920, according to one embodiment, the application (350) may determine whether identity verification has been successful.

[0242] According to one embodiment, if the first hash value received in operation 908 of FIG. 9a and the second hash value obtained in operation 926 do not correspond, the application (350) determines that identity verification has failed and can output a notification message indicating that identity verification has failed in operation 944 to a display (e.g., the display (220) of FIG. 2a).

[0243] According to one embodiment, if the first hash value received in operation 908 of FIG. 9a corresponds to the second hash value obtained in operation 926, the application (350) may determine that identity verification is successful and perform operation 932.

[0244] In operation 932, according to one embodiment, the application (350) may send a request message to the application server (340) requesting ticket data based on the successful authentication of the identity card. According to one embodiment, the request message may include the content ID of the ticket.

[0245] In operation 934, according to one embodiment, the application server (340) may send a request message requesting admission ticket data to the ticket vendor (320) based on a request message from the application (350). According to one embodiment, the request message sent by the application server (340) may include a ref ID corresponding to the content ID of the ticket.

[0246] In operation 936, according to one embodiment, a ticket vendor (320) may transmit admission ticket data to an application server (340) in response to a request message. According to one embodiment, the ticket vendor (320) may identify a ticket based on a ref ID and generate admission ticket data corresponding to the identified ticket. For example, the admission ticket data may include a barcode or a QR code, or a dynamic barcode or a dynamic QR code valid for a set time to enhance security. According to one embodiment, the ticket vendor (320) may transmit the admission ticket data along with the ref ID to the application server (340).

[0247] In operation 938, according to one embodiment, the application server (340) can transmit admission ticket data received from the ticket vendor (320) to the application (350). According to one embodiment, the application server (340) can transmit a content ID along with the admission ticket data to the application (350).

[0248] According to one embodiment of operation 940, the application (350) can activate a ticket based on ticket data. According to one embodiment, the operation of activating a ticket may include at least one of the following: an operation of displaying ticket data on a screen, an operation of enlarging or brightening ticket data, or an operation of adding and displaying an authentication mark to ticket data. For example, the authentication mark may include a UI authentication mark indicating that the ticket user's identity verification has been completed or indicating that the user is an authenticated user.

[0249] In operation 942, according to one embodiment, the performance organizer (310) can select and admit valid audience members without a separate identity verification procedure by scanning a ticket with completed identity verification.

[0250] FIG. 10a is a diagram illustrating a UI screen for adding a ticket to an application according to one embodiment.

[0251] Referring to (a) of FIG. 10a, according to one embodiment, a user (e.g., user (301) of FIG. 4) can purchase a ticket through a ticket purchasing platform (e.g., an online website or application) of a ticket vendor (or partner server) (e.g., ticket vendor (320) of FIG. 4) on an electronic device (201). Based on the completion of the ticket purchase, the electronic device (201) may display information (1002) about the purchased ticket and a UI for registering the purchased ticket to an application (e.g., application (350) of FIG. 4), such as an Add to Wallet button (1004), on a display (220).

[0252] According to one embodiment, information (1002) about a purchased ticket is information stored at a ticket sales outlet and may include Title information (information on the name of a performance, event, or exhibition), Location information (information on the location of a performance, event, or exhibition), or Date / Time information (information on the schedule of a performance, event, or exhibition).

[0253] According to one embodiment, the electronic device (201) can output a screen as shown in (b) of FIG. 10a based on whether the Add to Wallet button (1004) is touched, selected, or pressed by a user.

[0254] Referring to (b) of FIG. 10a, according to one embodiment, an electronic device (201) may display a UI indicating that a purchased ticket is being registered as a ticket-type card in an application (350). For example, while displaying a ticket (or ticket-type card) (1006), the electronic device (201) may output a message (e.g., Adding ticket...) and / or graphic information to a display (220) indicating that the ticket (1006) is being added to the application (350).

[0255] According to one embodiment, the electronic device (201) can output a screen as shown in (c) of FIG. 10a when the addition of the ticket (1006) to the application is completed.

[0256] Referring to (c) of FIG. 10a, according to one embodiment, an electronic device (201) can display a ticket (1006) added to an application and a message indicating that a ticket has been added (e.g., Ticket added) on a display (220).

[0257] According to one embodiment, the electronic device (201) may display a message (e.g., "Would you like to link to ID? Later | Continued") (1008) on the display (220) asking the user whether to link the added ticket (1006) to an ID.

[0258] According to one embodiment, if the electronic device (201) selects not to link the added ticket (1006) to an ID card (e.g., select 'later'), it may output a message to the display (220) indicating that the ticket (1006) has been registered without linking to an ID card.

[0259] According to one embodiment, when the electronic device (201) selects to link the added ticket (1006) to the ID card (e.g., select 'Continue'), it may output a screen for linking the ID card, as shown in FIG. 10b or FIG. 10c, to the display (220).

[0260] FIG. 10b is a diagram illustrating a UI screen for linking identification information to a ticket according to one embodiment.

[0261] Referring to (a) of FIG. 10b, according to one embodiment, an electronic device (201) may display on a screen an identification card (e.g., National ID Card) (1010) to be linked to a ticket (e.g., ticket (1006) of FIG. 10a (c)). The identification card (1010) may be provided from an identification card module (360) included in an application (350). The electronic device (201) may link the identification card (1010) to the ticket through identity verification.

[0262] According to one embodiment, the electronic device (201) may display a UI on the display (220) to induce biometric authentication. For example, the electronic device (201) may display a graphic element (1012) and / or a message (e.g., "Authenticate with fingerprint") on the display (220) for fingerprint authentication.

[0263] According to one embodiment, if fingerprint authentication fails, the electronic device (201) can output a message to the display (220) indicating that fingerprint authentication failed and that the identification card (1010) cannot be connected to the ticket.

[0264] According to one embodiment, when fingerprint authentication is successful, the electronic device (201) can output a screen as shown in (b) of FIG. 10b to the display (220).

[0265] Referring to (b) of FIG. 10b, according to one embodiment, an electronic device (201) may display an ID-linked ticket (1014) created by linking an ID (1010) to a ticket. According to one embodiment, when the ID-linked ticket (1014) is selected by a user (e.g., user (301) of FIG. 5), a ticket may be displayed after identity verification, such as biometric authentication. The ticket may include ticket data (e.g., a barcode or OR code, or a dynamic barcode or dynamic OR code) (e.g., ticket data (518) of FIG. 5). According to one embodiment, the ticket data may include a UI authentication mark indicating that the ticket user's ID verification has been completed or indicating that the user is an authenticated user. When the ticket data is used, the user can enter the performance without presenting an ID, and the performance organizer (e.g., performance organizer (310) of FIG. 5) can have the convenience of selecting and admitting valid audience members simply by scanning or checking the ticket data.

[0266] FIG. 10c is a diagram illustrating a UI screen for linking identification information to a ticket through identification information verification according to one embodiment.

[0267] According to one embodiment, when the electronic device (201) selects to link the ticket (1006) added in (c) of FIG. 10a to an ID card (e.g., select 'Continue'), it can output a screen for linking the ID card as shown in (a) of FIG. 10c to a display (220).

[0268] Referring to (a) of FIG. 10c, according to one embodiment, an electronic device (201) may display on a screen an identification card (e.g., National ID Card) (1016) to be linked to a ticket (1006). The identification card (1016) may be provided from an identification card module (360) included in an application (e.g., the application (350) of FIG. 4). According to one embodiment, the identification card (1016) may not display or may obscure other personal information (e.g., facial information, personal identification number, issuance date, or expiration date) except for user identification information (e.g., name). In some cases, parts of the user identification information (e.g., part of the name) may also not display or may obscure with special characters.

[0269] According to one embodiment, the electronic device (201) may display a UI on the display (220) to induce biometric authentication so that an identification card (1016) is linked to a ticket (1006) through identity verification. For example, the electronic device (201) may display a graphic element (1018) for fingerprint authentication and / or a message (e.g., "Authenticate with fingerprint") on the display (220). According to one embodiment, the biometric authentication of the electronic device (201) is not limited to fingerprint authentication but may include various biometric authentications such as iris authentication, voice authentication, or face authentication. According to one embodiment, if biometric authentication is not possible for a user (e.g., a person with a disability), a second authentication means may be used. For example, the second authentication means may be for performing authentication other than biometric authentication for user authentication.

[0270] According to one embodiment, if fingerprint authentication fails, the electronic device (201) can output a message to the display (220) indicating that fingerprint authentication failed and that the identification card (1016) cannot be connected to the ticket (1006).

[0271] According to one embodiment, when fingerprint authentication is successful, the electronic device (201) can output a screen as shown in (b) of FIG. 10c to the display (220).

[0272] Referring to (b) of FIG. 10c, the electronic device (201) may display an identification card (1020) with personal information disclosed based on successful fingerprint authentication. The identification card (1020) may have user identification information (e.g., name) as well as other personal information (e.g., facial information, personal identification number, issuance date, or expiration date) disclosed.

[0273] According to one embodiment, the electronic device (201) may display a UI (e.g., 'Connect (1022)' and / or 'Cancel (1024)' button) that asks whether to connect the identification card (1020) to the ticket (1006).

[0274] According to one embodiment, if the electronic device (201) selects not to connect the identification card (1020) to the ticket (1006) (e.g., select the 'Cancel (1024)' button), it may output a message to the display (220) indicating that the ticket (1006) has been registered without connecting the identification card (1020).

[0275] According to one embodiment, when the electronic device (201) selects to connect the identification card (1020) to the ticket (1006) (e.g., select the 'connect (1022)' button), it can output a screen as shown in (c) of FIG. 10c to the display (220).

[0276] Referring to (c) of FIG. 10c, the electronic device (201) may display an ID-linked ticket (1026) created by linking an ID (1020) to a ticket (1006). According to one embodiment, when the ID-linked ticket (1026) is selected by a user or when a set icon, button, or graphic object (e.g., Show QR code (1028)) is selected, a ticket admission ticket may be displayed. The ticket admission ticket may also be displayed after identity verification, such as biometric authentication. The ticket admission ticket may include admission ticket data (e.g., a barcode or OR code, or a dynamic barcode or dynamic OR code).

[0277] According to one embodiment, the ticket data may include a UI authentication mark indicating that the ticket user's identity verification has been completed or that the user is an authenticated user. When the ticket data is used, the user can enter the performance without presenting an identity card, and the performance organizer (e.g., the performance organizer of FIG. 5 (310)) can have the convenience of selecting and admitting valid audience members simply by scanning or checking the ticket data.

[0278] FIG. 11 is a diagram illustrating a UI screen of a ticket admission ticket displayed in an application according to one embodiment.

[0279] Referring to FIG. 11 (a), the admission data included in the ticket may include a QR code (or dynamic QR code) (1120). The QR code (1120) may be scanned by the performance organizer (e.g., the performance organizer (310) of FIG. 5) upon entry.

[0280] Referring to FIG. 11 (b), a QR code (1140) may also be displayed on the ticket detail screen. According to one embodiment, when the QR code (1140) is selected by user input such as touch input (e.g., user (301) in FIG. 5), an enlarged QR code (1120) may be displayed as shown in FIG. 11 (a).

[0281] The operation of an electronic device (e.g., the electronic device (201) of FIG. 2a) will be explained below with reference to FIG. 12 to FIG. 14b.

[0282] According to one embodiment, the operations illustrated in FIGS. 12 through 14b can be understood as being performed by a processor of an electronic device (e.g., the processor (240) of FIG. 2a) and may include operations performed through an application (e.g., the application (350) of FIG. 4). The operations illustrated in FIGS. 12 through 14b may be performed in various orders, not limited to the order illustrated. According to one embodiment, at least some of the operations illustrated in FIGS. 12 through 14b may be omitted, or more operations may be performed than those illustrated in FIGS. 12 through 14b.

[0283] FIG. 12 is a flowchart illustrating the operation of an electronic device for registering a ticket-type card according to one embodiment.

[0284] Referring to FIG. 12, according to one embodiment, in operation 1202, the electronic device can identify a card to be registered in an application (e.g., application (350) of FIG. 4).

[0285] According to one embodiment, an electronic device receives a card registration request message from an application server (e.g., the application server (340) of FIG. 2b) and can identify information about a card to be registered (e.g., a card identifier and / or card information corresponding to the card to be registered, such as a content ID) based on the card registration request message. According to one embodiment, the electronic device may display the card to be registered on a display (e.g., the display (220) of FIG. 2a) based on the identified information.

[0286] According to one embodiment, a card registration request message may be received based on a card registration request from a user (e.g., user (301) of FIG. 4). For example, the card registration request message may be received based on the user performing UI-based input (e.g., selecting the 'Add to Wallet' button) after purchasing a ticket on a ticket purchasing platform.

[0287] In operation 1204, according to one embodiment, the electronic device (201) may display a first UI for linking an ID (e.g., the message shown in (c) of FIG. 10a (Would you like to link with an ID? Later | continued) (1008)) on the display based on the determination that the type of card to be registered is a type requiring ID linking. According to one embodiment, the type of card to be registered may vary. For example, the type of card to be registered may correspond to any one of a first type representing a payment method (e.g., a credit card or debit card), a second type representing a ticket, a third type representing a boarding pass for a means of transportation (e.g., a bus, train, or airplane), or a fourth type representing a coupon. The type requiring ID linking may be the second type, but may be another type (e.g., the third type) if the aforementioned ticket registration and usage method is applicable.

[0288] In operation 1206, according to one embodiment, the electronic device may obtain first identity information through an identity module (e.g., identity module (360) of FIG. 2a) based on the receipt of an input based on the first UI (e.g., selecting 'Continue' in the message (1008) shown in (c) of FIG. 10a). According to one embodiment, the electronic device may obtain information related to an identity from an authentication server (e.g., authentication server (380) of FIG. 4) through the identity module and generate first identity information based on the obtained information. For example, the electronic device may obtain information related to an identity from the authentication server through identity authentication (or user authentication or identity authentication). According to one embodiment, the electronic device may generate first identity information to include original data of the identity included in the information related to the identity, or data values ​​generated based on data or information included in the identity. According to one embodiment, information related to an identification document may include data capable of proving a user's identity, and, not limited to this embodiment, may include various information such as a user's social security number, a user's resident registration number, or a user's driver's license number, and this information may be obtained in the form of encrypted data. According to one embodiment, an electronic device may generate first identification document information based on information related to an identification document obtained from an authentication server through an identification document module. For example, the first identification document information may include a first hash value.

[0289] In operation 1208, according to one embodiment, an electronic device may register a card in an application in association with first identification information. According to one embodiment, the electronic device may transmit a card registration response message to an application server indicating that the card has been registered in association with the first identification information, based on the fact that the card has been added or registered in the application. For example, the card registration response message may include a content ID and a first hash value corresponding to the card registered in the application (350), and the application server may store the first hash value as identification information corresponding to the content ID based on the card registration response message.

[0290] FIG. 13a is a flowchart illustrating the operation of an electronic device for acquiring first identification information according to one embodiment.

[0291] According to one embodiment, the operations illustrated in FIG. 13a may be detailed operations of operation 1206 of FIG. 12.

[0292] Referring to FIG. 13a, in operation 1302, according to one embodiment, the electronic device may receive an input based on a first UI. For example, the input based on the first UI may represent an input instructing to link an identification card to a card to be registered (e.g., selecting 'Continue' in the message (1008) shown in FIG. 10a (c)).

[0293] In operation 1304, according to one embodiment, the electronic device may display a second UI (e.g., a graphic element (1018) for fingerprint authentication shown in (a) of FIG. 10c) and / or a message (e.g., "Authenticate with fingerprint") on a display (e.g., the display (220) of FIG. 2a) so that identity authentication is performed through biometric authentication. According to one embodiment, biometric authentication may be performed through fingerprint authentication, but may also be performed through iris authentication, voice authentication, or face authentication in addition to fingerprint authentication. According to one embodiment, the authentication method for identity authentication is not limited to biometric authentication, and other methods of authentication (e.g., password authentication, pattern authentication, or code authentication) may be performed.

[0294] In operation 1306, according to one embodiment, the electronic device can determine whether biometric authentication has been successful through the second UI. According to one embodiment, the electronic device can recognize the fingerprint, iris, or face of a user (e.g., user (301) in FIG. 4) using a biometric recognition module (e.g., biometric recognition module (370) in FIG. 2a), and determine whether biometric authentication has been successful based on whether the recognized result corresponds to information stored in advance.

[0295] In operation 1308, according to one embodiment, the electronic device may obtain first identity information (e.g., first hash value) from an identity module (e.g., identity module (360) of FIG. 2b) based on the success of biometric authentication.

[0296] FIG. 13b is a flowchart illustrating the operation of an electronic device that obtains first identification information based on an identification card display according to one embodiment.

[0297] According to one embodiment, the operations illustrated in FIG. 13b may be detailed operations of operation 1206 of FIG. 12.

[0298] Referring to FIG. 13b, according to one embodiment, in operation 1322, the electronic device may receive an input based on the first UI. For example, the input based on the first UI may represent an input instructing the identification card to be linked to the card to be registered (e.g., selecting 'Continue' in the message (1008) shown in FIG. 10a (c)).

[0299] In operation 1324, according to one embodiment, the electronic device may display an identification card for identity authentication (e.g., the National ID Card (1016) shown in (a) of FIG. 10c) on a display (e.g., the display (220) of FIG. 2a). According to one embodiment, the identification card may have at least some of the personal information not displayed or obscured by special characters. For example, the identification card may have at least some of the name of the ID card holder displayed, while the remaining personal information is obscured.

[0300] In operation 1326, according to one embodiment, the electronic device may display a second UI on a display so that identity authentication is performed through biometric authentication. According to one embodiment, the biometric authentication may include fingerprint, iris, or face authentication. According to one embodiment, the second UI may include a UI for inducing biometric authentication. For example, if the biometric authentication is fingerprint authentication, the second UI may include a graphic element (1018) for fingerprint authentication of FIG. 10b and / or a message (e.g., Authenticate with fingerprint).

[0301] In operation 1328, according to one embodiment, the electronic device can determine whether biometric authentication has been successful through the second UI. According to one embodiment, the electronic device can recognize the fingerprint, iris, or face of a user (e.g., user (301) in FIG. 4) using a biometric recognition module (e.g., ID recognition module (370) in FIG. 2a), and determine whether biometric authentication has been successful based on whether the recognized result corresponds to information stored in advance.

[0302] In operation 1330, according to one embodiment, the electronic device can update the identification card to include personal information based on the success of biometric authentication, and obtain first identification information (e.g., first hash value) from an identification module (e.g., identification module (360) of FIG. 2a).

[0303] According to one embodiment, the electronic device can update the identification card so that personal information is disclosed, as shown in (b) of FIG. 10c.

[0304] According to one embodiment, the electronic device may acquire the first identity information based on the user's choice. For example, the electronic device may acquire or not acquire the first identity information from the identity module based on the user's choice based on an updated identity card (or an identity card with personal information disclosed).

[0305] FIG. 14a is a flowchart illustrating the operation of an electronic device using a ticket-type card based on identity verification of an electronic device according to one embodiment.

[0306] Referring to FIG. 14a, in operation 1402, according to one embodiment, an electronic device may receive a request for use of a registered card (e.g., a ticket-type card). According to one embodiment, the electronic device may receive the request for use based on the card being selected by a user (e.g., user (301) of FIG. 6) in an application (e.g., application (350) of FIG. 6) or based on entering the detail screen of a ticket-type card.

[0307] In operation 1404, according to one embodiment, the electronic device may obtain first identification information from an application server (e.g., the application server (340) of FIG. 6). For example, the first identification information may be registered with the application server at the time of registering a ticket-type card (or at the time of performing operation 1208 of FIG. 12).

[0308] According to one embodiment, an electronic device requests an application server to provide first identification information (e.g., a first hash value) based on identification information (e.g., a content ID) of a ticket-type card, and in response to the request, can obtain the first identification information from the application server.

[0309] According to one embodiment, if the electronic device stores the first identification information in the memory of the electronic device (e.g., memory (230) of FIG. 2a) at the time of registering a ticket-type card, the first identification information can be obtained from the memory without requesting the first identification information from the application server.

[0310] In operation 1406, according to one embodiment, the electronic device may obtain second identity information from an identity module through identity authentication. According to one embodiment, the electronic device may obtain second identity information in a manner similar to the method of obtaining first identity information. For example, the electronic device may perform biometric authentication through a biometric recognition module (e.g., biometric recognition module (370) of FIG. 2a), and based on the success of the biometric authentication, obtain second identity information (e.g., second hash value) from an authentication server through an identity module (360).

[0311] In operation 1408, according to one embodiment, the electronic device can determine whether the first identification information and the second identification information correspond. For example, the electronic device can determine whether the first identification information and the second identification information correspond based on the comparison result of the first hash value and the second hash value corresponding to each of the first identification information and the second identification information.

[0312] In operation 1410, according to one embodiment, the electronic device may request card data from an application server based on the correspondence between first identification information and second identification information. According to one embodiment, card data of a ticket-type card may correspond to admission ticket data. According to one embodiment, the electronic device may request the application server to provide card data corresponding to the content ID by transmitting the content ID to the application server.

[0313] In operation 1412, according to one embodiment, an electronic device may obtain card data from an application server and display it on a display (e.g., the display (220) of FIG. 2a). For example, the electronic device may include, from the application server, a barcode or QR code or other form of admission authentication data corresponding to admission ticket data. The barcode or QR code may be a dynamic barcode or dynamic QR code valid for a set time.

[0314] In operation 1414, according to one embodiment, the electronic device may output an ID authentication failure notification message to a display based on the fact that the first ID information and the second ID information do not correspond. According to one embodiment, if ID authentication fails, the use of a ticket-type card may be impossible.

[0315] FIG. 14b is a flowchart illustrating the operation of an electronic device using a ticket-type card based on identity verification of an application server according to one embodiment.

[0316] Referring to FIG. 14b, in operation 1422, according to one embodiment, an electronic device may receive a request for use of a registered card (e.g., a ticket-type card). According to one embodiment, the electronic device may receive the request for use based on the card being selected by a user (e.g., user (301) of FIG. 5) in an application (e.g., application (350) of FIG. 5) or based on entering the detail screen of a ticket-type card.

[0317] In operation 1424, according to one embodiment, the electronic device may obtain second identity information from an identity module through identity authentication. According to one embodiment, the electronic device (201) performs biometric authentication through a biometric recognition module (e.g., biometric recognition module (370) of FIG. 2a), and based on the success of the biometric authentication, may obtain second identity information (e.g., second hash value) from an authentication server through an identity module (e.g., identity module (360) of FIG. 2a).

[0318] In operation 1426, according to one embodiment, the electronic device (201) can transmit second identification information to an application server (e.g., the application server (340) of FIG. 2b). According to one embodiment, the electronic device can request the application server to provide card data through identification by transmitting identification information of a ticket-type card (e.g., content ID) and second identification information (e.g., second hash value) to the application server.

[0319] In operation 1428, according to one embodiment, the electronic device can determine whether identity authentication through an application server has been successful. According to one embodiment, the electronic device receives an identity authentication result from an application server and can determine whether identity authentication has been successful based on the received identity authentication result.

[0320] According to one embodiment, identity verification through an application server may be performed based on whether the first identity information (e.g., first hash value) registered in the application server at the time of registering a ticket-type card (or at the time of performing operation 1208 of FIG. 12) corresponds to the second identity information (e.g., second hash value) transmitted by the electronic device in operation 1426.

[0321] According to one embodiment, if the first identity information and the second identity information correspond, the application server may send an identity verification success notification message indicating that identity verification has been successful to the electronic device. Based on the fact that identity verification has been successful, the application server may obtain card data (e.g., admission ticket data such as a barcode or QR code) from a ticket vendor (e.g., ticket vendor (or partner server) (320) of FIG. 5) and transmit it to the electronic device.

[0322] In operation 1430, according to one embodiment, the electronic device receives an ID authentication success notification message from an application server to identify that ID authentication has been successful, and obtains card data from the application server and displays it on a display (e.g., the display (220) of FIG. 2a).

[0323] According to one embodiment, if the first identity information and the second identity information do not correspond, the application server may send an identity authentication failure notification message to the electronic device indicating that identity authentication has failed. Based on the fact that identity authentication has failed, the application server may not perform the operation of obtaining card data from the ticket vendor.

[0324] In operation 1432, according to one embodiment, the electronic device receives an identity verification failure notification message from an application server, identifies that identity verification has failed, and can display a message indicating that identity verification has failed on a display.

[0325] The operation of an application server (e.g., the application server (340) of FIG. 2b) will be explained below with reference to FIG. 15 and FIG. 16.

[0326] According to one embodiment, the operations illustrated in FIGS. 15 and 16 may be understood to be performed by a processor of an application server (e.g., the processor (270) of FIG. 2b). The operations illustrated in FIGS. 15 and 16, respectively, may be performed in various orders, not limited to the order illustrated. According to one embodiment, at least some of the operations illustrated in FIGS. 15 and 16, respectively, may be omitted, or more operations may be performed than those illustrated in FIGS. 15 and 16, respectively.

[0327] FIG. 15 is a flowchart illustrating the operation of an application server according to one embodiment.

[0328] Referring to FIG. 15, in operation 1502, according to one embodiment, an application server may transmit a card registration request message to an electronic device (e.g., the electronic device (201) of FIG. 2a) requesting the application (e.g., the application (350) of FIG. 4) of the electronic device to register a card. According to one embodiment, the card registration request message may include information about the card for which registration is requested (e.g., a card identifier and / or card information corresponding to the card for which registration is requested, such as a content ID).

[0329] In operation 1504, according to one embodiment, an application server may receive a card registration response message containing first identification information from an electronic device in response to a card registration request message. According to one embodiment, the application server may receive a card registration response message containing first identification information from an electronic device based on the fact that the card requested for registration is of a type requiring an identification link (e.g., ticket type). According to one embodiment, the card registration response message may include a card identifier (e.g., content ID) along with the first identification information.

[0330] In operation 1506, according to one embodiment, the application server may register the first identification information in conjunction with information about the card. According to one embodiment, the application server may identify a card corresponding to a card identifier and store the first identification information as identification information corresponding to the identified card.

[0331] FIG. 16 is a flowchart illustrating the identity verification operation of an application server according to one embodiment.

[0332] Referring to FIG. 16, in operation 1602, according to one embodiment, an application server may receive a request message for the use of a card from an electronic device (e.g., the electronic device (201) of FIG. 2a). According to one embodiment, the request message may be a message requesting identity verification for the use of the card and may include second identity information associated with the card user.

[0333] In operation 1604, according to one embodiment, the application server can identify the second identification information included in the request message.

[0334] In operation 1606, according to one embodiment, the application server may perform an identity verification operation to determine whether the first identity information stored through the operation of FIG. 15 corresponds to the second identity information identified in operation 1604.

[0335] In operation 1608, according to one embodiment, the application server identifies that identity verification has been successful based on the correspondence between the first identity information and the second identity information, and may request card data for card usage from a partner server (e.g., ticket vendor (320) of FIG. 5).

[0336] In operation 1610, according to one embodiment, the application server may receive card data from a partner server in response to a request for card data.

[0337] In operation 1612, according to one embodiment, the application server can transmit card data received from the partner server to an electronic device.

[0338] According to one embodiment, if the application server determines in operation 1606 that the first identification information and the second identification information do not correspond, it can identify that the identification authentication has failed.

[0339] In operation 1614, according to one embodiment, the application server may transmit an identity verification failure message to an electronic device based on the fact that identity verification has failed.

[0340] A method of operation of an electronic device (201) according to one embodiment may include: an operation (1202) of identifying a card to be registered in an application; an operation (1204) of displaying a first UI (user interface) for the ID connection on a display (220) of the electronic device (201) based on the determination that the type of the card to be registered is a type requiring an ID connection; an operation (1206) of obtaining first ID information through an ID module (360) included in the electronic device (201) based on the reception of an input based on the first UI; and an operation (1208) of registering the card to be registered in the application (350) in conjunction with the first ID information.

[0341] According to one embodiment, the operation of identifying the card to be registered may include receiving a card registration request message from an application server, identifying information about the card to be registered based on the card registration request message, and displaying the card to be registered on the display (220) based on the identified information.

[0342] According to one embodiment, the type of card to be registered may be a ticket type card.

[0343] According to one embodiment, the operation of obtaining the first identification information may include an operation (1304) of displaying a second UI on the display (220) to perform biometric authentication based on receiving an input to the first UI (1302), and an operation (1308) of obtaining the first identification information from the identification module (360) based on the success of the biometric authentication through the second UI (1306).

[0344] According to one embodiment, the operation of obtaining the first identification information may include: an operation (1324) of displaying an identification card for identity authentication on the display (220) through the identification module (360) based on receiving input for the first UI (1322); an operation (1326) of displaying a second UI on the display (220) to perform biometric authentication based on the display of the identification card (1328); and an operation (1330) of updating the identification card to include personal information and generating the first identification information through the identification module (360) based on the success of the biometric authentication through the second UI (1328). The personal information included in the identification card may include information obtained from an authentication server.

[0345] According to one embodiment, the operation of generating the first identity card information may include the operation of generating a first hash value based on the personal information through the identity card module (360), the operation of requesting authentication of the first hash value to the authentication server (380), and the operation of generating the first identity card information based on the first hash value through the identity card module (360) based on receiving a message from the authentication server (380) indicating that authentication of the first hash value has been successful.

[0346] According to one embodiment, the method of operation of the electronic device (201) may further include the operation of transmitting a card registration response message to an application server (340) indicating that the card to be registered is linked to the first identification information and registered in the application (350).

[0347] According to one embodiment, the method of operation of the electronic device (201) may further include, based on the failure of the biometric authentication through the second UI, the operation of registering the card to be registered without linking it with the first identification information, and the operation of sending a card registration response message to the application server (340) indicating that the card to be registered has been registered in the application (350) without linking it with the first identification information.

[0348] According to one embodiment, the method of operation of the electronic device (201) further includes, upon receiving a request for use of the registered card, an operation of performing identity verification, upon successful identity verification, an operation of obtaining card data for use of the registered card, and an operation of displaying the card data on the display (220), and the card data may include a QR (quick response code) code or a barcode.

[0349] According to one embodiment, the operation of acquiring the card data may include: acquiring second identity information from the identity module (360); determining whether the second identity information corresponds to the first identity information; identifying that the identity authentication is successful based on the fact that the second identity information corresponds to the first identity information; transmitting a request message requesting the card data to an application server (340) based on the fact that the identity authentication is successful; and acquiring the card data from the application server in response to the request message. The first identity information may include a first hash value, and the second identity information may include a second hash value.

[0350] According to one embodiment, the method of operation of the electronic device (201) may further include the operation of identifying that the identity verification has failed based on the fact that the second identity information does not correspond to the first identity information, and the operation of outputting a notification message indicating that the identity verification has failed to a display (220) based on the fact that the identity verification has failed.

[0351] A method of operation of an application server (340) according to one embodiment may include: an operation (1502) of transmitting a card registration request message to an electronic device (201) requesting that a card be registered in an application (350) of an electronic device (201); an operation (1504) of receiving a card registration response message including first identification information from the electronic device (201) in response to the card registration request message; and an operation (1506) of registering the first identification information in conjunction with information about the card.

[0352] According to one embodiment, the card registration request message and the card registration response message each include a card identifier corresponding to the card, and the card may include a ticket-type card.

[0353] According to one embodiment, the electronic device (201) may be linked with at least one external electronic device (e.g., a smart watch). The at least one external electronic device may be used by the same user as the user of the electronic device (201). The electronic device (201) may perform ticket registration and usage operations linked to the aforementioned identification information and may transmit admission ticket data (e.g., a QR code or barcode) of the application (350) to the at least one external electronic device. The at least one external electronic device may display the admission ticket data received from the electronic device (201) through identity verification via biometric authentication. Accordingly, the user (301) may have the convenience of using the admission ticket data through the at least one external electronic device instead of the electronic device (201).

[0354] According to the various embodiments described above, since a ticket authenticated based on identification information can be used, ticket resale and theft can be prevented, and the entry procedure can be simplified to reduce the time and cost associated with ticket verification.

[0355] The electronic device according to the various embodiments disclosed in this document may be of various forms. The electronic device may include, for example, a portable communication device (e.g., a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a consumer electronics device. The electronic device according to the embodiments of this document is not limited to the devices described above.

[0356] The various embodiments of this document and the terms used therein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various modifications, equivalents, or substitutions of said embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of said items unless the relevant context clearly indicates otherwise. In this document, phrases such as "A or B," "at least one of A and B," "at least one of A or B," "A, B or C," "at least one of A, B and C," and "at least one of A, B, or C" may each include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used simply to distinguish said components from other said components and do not limit said components in any other aspect (e.g., importance or order). Where any (e.g., 1st) component is referred to as “coupled” or “connected” to another (e.g., 2nd) component, with or without the terms “functionally” or “communicationly,” it means that said any component may be connected to said other component directly (e.g., via a wire), wirelessly, or through a third component.

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

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

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

[0360] According to various embodiments, each component (e.g., module or program) of the components described above may include a singular or multiple entities, and some of the multiple entities may be separated and placed in other components. According to various embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Generally or additionally, multiple components (e.g., module or program) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as those performed by the corresponding component among the multiple components prior to integration. According to various embodiments, operations performed by the module, program, or other components may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In an electronic device (201), Transceiver (210); Display (220); ID module (360); Memory (230); and It includes at least one processor (240) including a processing circuit, and When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: Identify the card to be registered in the application (350), Based on the determination that the type of card to be registered is a type requiring identification card connection, a first UI (user interface) for the identification card connection is displayed on the display (220). Based on the input received based on the above first UI, the first identification information is obtained through the identification module (360), and An electronic device that stores commands that cause the card to be registered to be registered in the application (350) in conjunction with the first identification information.

2. In Paragraph 1, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: A card registration request message is received from an application server (340) through the communication unit (210), and Based on the above card registration request message, identify information about the card to be registered, and An electronic device that stores commands causing the card to be registered to be displayed on the display (220) based on the identified information.

3. In Paragraph 1, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: An electronic device storing commands that cause the type of the card to be registered to be determined as a type requiring the identification card linkage, based on the fact that the card to be registered is a ticket type card.

4. In Paragraph 1, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: Based on the input received based on the first UI, a second UI is displayed on the display (220) so that biometric authentication is performed, and An electronic device that stores commands causing the first identification information to be obtained from the identification module (360) based on the success of the biometric authentication through the second UI.

5. In Paragraph 1, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: Based on the input received for the first UI, an identification card for identity authentication is displayed on the display (220) through the identification module (360), and Based on the identification card displayed above, a second UI is displayed on the display (220) so that biometric authentication is performed, and Based on the success of the biometric authentication through the second UI, the ID card is updated to include personal information through the ID module (360), and commands are stored that cause the first ID information to be generated based on the personal information through the ID module (360). The electronic device, wherein the personal information contained in the identification card above includes information obtained from the authentication server (380).

6. In Paragraph 5, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: A first hash value is generated based on the personal information through the ID module (360), and Request authentication for the first hash value above to the authentication server (380), and An electronic device that stores commands that cause the first identity information to be generated based on the first hash value through the identity module (360), based on receiving a message from the authentication server (380) indicating that authentication for the first hash value has been successful.

7. In Paragraph 1 or 2, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: An electronic device that stores commands that cause a card registration response message to be transmitted to an application server (340) via the communication unit (210), indicating that the card to be registered is linked to the first identification information and registered in the application (350).

8. In Paragraph 4 or 5, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: Based on the failure of the biometric authentication through the second UI, the card to be registered is registered in the application (350) without linking with the first identification information, and An electronic device that stores commands that cause a card registration response message to be transmitted to an application server (340) via the communication unit (210), indicating that the card to be registered has been registered without being linked to the first identification information.

9. In Paragraph 1, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: Based on the receipt of a request to use the above-mentioned registered card, identity verification is performed, and Based on the success of the above identification verification, commands are stored to cause card data for the use of the above registered card to be displayed on the display (220), and The above card data is an electronic device including a QR (quick response code) code or a barcode.

10. In Paragraph 9, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: The second identification information is obtained through the above identification module (360), and Determining whether the above-mentioned second identification information corresponds to the above-mentioned first identification information, and Based on the fact that the second identification information corresponds to the first identification information, it is identified that the identification authentication has been successful, and Based on the success of the above identity verification, a request message requesting the card data is transmitted to the application server (340) through the communication unit (210), and In response to the above request message, commands that cause the card data to be obtained from the application server (340) through the communication unit (210) are stored, and An electronic device comprising: the first identification information including a first hash value, and the second identification information including a second hash value.

11. In Paragraph 10, When the memory (230) is executed individually or collectively by the at least one processor (240), the electronic device (201) is: Identifying that the identity verification has failed based on the fact that the second identity information does not correspond to the first identity information, and An electronic device that stores commands that cause a notification message indicating that the identity verification has failed to be output to a display (220) based on the fact that the identity verification has failed.

12. In the application server (340), Transceiver (250); Memory (260); and It includes at least one processor (270) including a processing circuit, and When the above memory (260) is executed individually or collectively by the at least one processor (270), the application server (340) is: Through the above communication unit (250), a card registration request message requesting to register a card in the application (350) of the electronic device (201) is transmitted to the electronic device (201), and Through the communication unit (250), a card registration response message including first identification information is received from the electronic device (201) in response to the card registration request message, and An application server that stores commands causing the above-mentioned first identification information to be registered in conjunction with the information for the above-mentioned card.

13. In Paragraph 12, When the above memory (260) is executed individually or collectively by the at least one processor (270), the application server (340) is: Through the communication unit (250), a request message for the use of the card is received from the electronic device (201), and Determining whether the second identification information included in the above request message corresponds to the first identification information, and Based on the fact that the second identification information corresponds to the first identification information, it is identified that the identification authentication has been successful, and Based on the success of the above identity verification, card data for the use of the card is requested from the partner server (320) through the communication unit (250), and Based on the fact that the card data is received from the partner server (320) through the communication unit (250), instructions are stored that cause the card data to be transmitted to the electronic device (201). An application server in which the first identification information includes a first hash value and the second identification information includes a second hash value.

14. In Paragraph 13, When the above memory (260) is executed individually or collectively by the at least one processor (270), the application server (340) is: Identifying that the identity verification has failed based on the fact that the second identity information does not correspond to the first identity information, and An application server that stores commands that cause a notification message indicating that the identity verification has failed to be sent to the electronic device (201) via the communication unit (250) based on the failure of the identity verification.

15. In the method of operating the electronic device (201), An action (1202) to identify a card to be registered in an application (350); Based on the determination that the type of card to be registered is a type requiring identification card connection, an operation (1204) of displaying a first UI (user interface) for identification card connection on the display (220) of the electronic device (201); An operation (1206) of obtaining first identification information through an identification module (360) included in the electronic device (201) based on receiving input based on the first UI; and A method of operation of an electronic device comprising the operation (1208) of registering the card to be registered in the application (350) in conjunction with the first identification information.

Images