Digital asset secure transfer method and apparatus

Abstract

The present disclosure relates to a digital asset secure transfer method and an apparatus therefor, and provides a method and an apparatus therefor, in which mutual authentication using signature information is performed between devices transferring a digital asset, and a service provider is provided with information certifying that digital asset specification information for the transfer of the digital asset has been generated in a secure space in accordance with a contract with the service provider, and thus the security level associated with the transfer of the digital asset may be enhanced.

Description

Method and device for securely transferring digital assets

[0001] The present disclosure relates to a wireless communication system, and more specifically, to a method and apparatus for securely transferring digital assets.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz (THX) band (e.g., the 3 terahertz band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and Massive Machine-Type Communications (mMTC), technologies included beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands; support for various numerologies (such as operating multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources; initial access techniques to support multi-beam transmission and broadband; the definition and operation of Band-Width Parts (BWP); Low Density Parity Check (LDPC) codes for high-volume data transmission; new channel coding methods such as Polar Codes for the reliable transmission of control information; and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) for supporting new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) for incorporating Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas to guarantee coverage in the terahertz band of 6G mobile communication technology; metamaterial-based lenses and antennas; high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM); and Reconfigurable Intelligent Surface (RIS) technology to improve terahertz band signal coverage; as well as full-duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and Artificial Intelligence (AI) from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] The technical problem of the present disclosure is to provide a method for securely transferring digital assets and an apparatus for doing so.

[0009] The technical problem of the present disclosure is to provide a method and apparatus for a service provider to verify that the transfer of digital assets is safely performed in a security device (SE).

[0010] The technical problem of the present disclosure is to provide a method and apparatus for improving the security level related to the transfer of digital assets by enabling not only mutual authentication between devices but also verification by the service provider that digital asset specification information was generated in a specific secure space contracted with the service provider during the transfer of digital assets requiring security.

[0011] The technical problems to be solved in the various embodiments of the present disclosure are not limited to those mentioned above, and other technical problems not mentioned may be considered by those skilled in the art from the various embodiments of the present disclosure described below.

[0012] In one embodiment of the present disclosure, a method performed by a first device is provided, the method comprising: transmitting a first message to a second device including first digital asset statement information and signature information of the first device; receiving a second message from the second device including second digital asset statement information and signature information of the second device; identifying a digital asset based on the second digital asset statement information and verifying the second device based on the signature information of the second device; and transmitting a third message including the second digital asset statement information to a service provider server based on the result of identifying the digital asset and the result of verifying the second device, wherein the third message may include information for attesting to a service provider certificate entity of the second device.

[0013] In one embodiment of the present disclosure, a first device is provided, the first device comprises: a memory comprising a program or at least one instruction; and at least one processor connected to the memory and configured to execute the program or at least one instruction so that the first device performs an operation, wherein the operation comprises: transmitting a first message comprising first digital asset statement information and signature information of the first device to a second device; receiving a second message comprising second digital asset statement information and signature information of the second device from the second device; identifying a digital asset based on the second digital asset statement information and verifying the second device based on the signature information of the second device; and transmitting a third message comprising the second digital asset statement information to a service provider server based on the result of identifying the digital asset and the result of verifying the second device, wherein the third message may include information for attestation of a service provider certificate entity of the second device.

[0014] In one embodiment of the present disclosure, information for proving a service provider authentication entity of the second device may include a service provider authentication entity identifier of the second device or signature information of the service provider authentication entity of the second device.

[0015] In one embodiment of the present disclosure, the first message may include information for proving a service provider authentication entity of the first device.

[0016] In one embodiment of the present disclosure, information for proving a service provider authentication entity of the first device may include a service provider authentication entity identifier of the first device or signature information of the service provider authentication entity of the first device.

[0017] In one embodiment of the present disclosure, the first digital asset specification information or the second digital asset specification information may include at least one of information regarding the digital asset, information regarding the start time of use of the digital asset, information regarding the end time of use of the digital asset, or information indicating whether authentication is required when using the digital asset.

[0018] In one embodiment of the present disclosure, information regarding the digital asset may include at least one of information regarding the name of the digital asset, information regarding the quantity of the digital asset, information regarding the unit of the digital asset, or information regarding the description of the digital asset.

[0019] In one embodiment of the present disclosure, if the fourth message received from the service provider server indicates that the service provider server has succeeded in verifying information for proving the service provider authentication entity of the second device, the method may further include the step of transmitting a fifth message containing the second digital asset specification information to the second device.

[0020] In one embodiment of the present disclosure, a method performed by a second device is provided, the method comprising: receiving a first message from the first device including first digital asset statement information and signature information of the first device; verifying a digital asset based on the first digital asset statement information and verifying the first device based on the signature information of the first device; transmitting a second message including the first digital asset statement information to a service provider server based on the result of verifying the digital asset and the result of verifying the first device, wherein the second message includes information for attesting a service provider certificate entity of the first device; and, if a third message received from the service provider server indicates that the service provider server has succeeded in verifying the information for attesting the service provider certificate entity of the first device, transmitting a fourth message including second digital asset statement information and signature information of the second device to the first device.

[0021] In one embodiment of the present disclosure, a second device is provided, wherein the second device comprises: a memory comprising a program or at least one instruction; and at least one processor connected to the memory and configured to execute the program or at least one instruction so that the second device performs an operation, wherein the operation comprises receiving a first message from the first device comprising first digital asset statement information and signature information of the first device; verifying a digital asset based on the first digital asset statement information and verifying the first device based on the signature information of the first device; and transmitting a second message comprising the first digital asset statement information to a service provider server based on the result of verifying the digital asset and the result of verifying the first device, wherein the second message comprises information for attestation of a service provider certificate entity of the first device; A second device comprising, when a third message received from the service provider server indicates that the service provider server has succeeded in verifying information for proving the service provider authentication entity of the first device, transmitting a fourth message including second digital asset specification information and signature information of the second device to the first device.

[0022] In one embodiment of the present disclosure, information for proving a service provider authentication entity of the first device may include a service provider authentication entity identifier of the first device or signature information of the service provider authentication entity of the first device.

[0023] In one embodiment of the present disclosure, the fourth message may include information for proving the service provider authentication entity of the second device.

[0024] In one embodiment of the present disclosure, information for proving a service provider authentication entity of the second device may include a service provider authentication entity identifier of the second device or signature information of the service provider authentication entity of the second device.

[0025] In one embodiment of the present disclosure, the first digital asset specification information or the second digital asset specification information may include at least one of information regarding the digital asset, information regarding the start time of use of the digital asset, information regarding the end time of use of the digital asset, or information indicating whether authentication is required when using the digital asset.

[0026] In one embodiment of the present disclosure, information regarding the digital asset may include at least one of information regarding the name of the digital asset, information regarding the quantity of the digital asset, information regarding the unit of the digital asset, or information regarding the description of the digital asset.

[0027] In one embodiment of the present disclosure, the step of receiving a fifth message including the second digital asset specification information from the first device may be further included.

[0028] According to the present disclosure, digital assets can be safely transferred.

[0029] According to the present disclosure, by enabling a service provider to verify that the transfer of digital assets is being performed securely in a safety device (SE), digital assets can be transferred more securely.

[0030] According to the present disclosure, when transferring digital assets requiring security, the security level associated with the transfer of digital assets can be improved by enabling the service provider to verify that the digital asset specification information was generated in a specific secure space contracted with the service provider, as well as mutual authentication between devices.

[0031] The effects obtainable in the present disclosure are not limited to those mentioned in the various embodiments, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below.

[0032] FIG. 1 illustrates a system to which the present disclosure may be applied.

[0033] FIG. 2 illustrates the structure of an applet within a safety device (SE) according to the present disclosure.

[0034] FIG. 3 illustrates the configuration of a safety device (SE) included in the device (110, 120) in the present disclosure.

[0035] FIG. 4 illustrates an example of transferring digital assets according to the present disclosure.

[0036] FIG. 5 illustrates an example of transferring digital assets according to the present disclosure.

[0037] FIG. 6 illustrates a flowchart of a method performed by a first device (110) according to the present disclosure.

[0038] FIG. 7 illustrates a flowchart of a method performed by a device (120) according to the present disclosure.

[0039] FIG. 8 illustrates the structure of an electronic device (800) according to one embodiment of the present disclosure.

[0040] FIG. 9 illustrates the structure of a server (900) according to one embodiment of the present disclosure.

[0041] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0042] In describing the embodiments, technical details that are well known in the technical field to which this disclosure belongs and are not directly related to this disclosure are omitted. This is intended to convey the essence of this disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0043] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the size of each component does not entirely reflect its actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference numbers.

[0044] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. The embodiments provided are merely to make the present disclosure complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0045] At this time, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing means of instruction to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0046] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specified logical function(s). Also, it should be noted that in some alternative embodiments, the functions mentioned in the blocks may occur out of order. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order according to the corresponding function from time to time.

[0047] In this embodiment, the term "part" refers to a software or hardware component, such as an FPGA or ASIC, and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to operate one or more processors. Accordingly, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." Furthermore, the components and "parts" may be implemented to operate one or more CPUs within a device or secure multimedia card.

[0048] In the present disclosure, modifiers such as "first," "second," etc., referring to terms may be used to distinguish each term from one another when describing embodiments. The terms modified by the modifiers such as "first," "second," etc., may refer to different objects. However, the terms modified by the modifiers such as "first," "second," etc., may refer to the same object. That is, the modifiers such as "first," "second," etc., may be used to refer to the same object from different perspectives. For example, the modifiers such as "first," "second," etc., may be used to distinguish the same object in terms of function or operation.

[0049] FIG. 1 illustrates a system to which the present disclosure may be applied. The example of FIG. 1 is solely for the purpose of illustrating the present disclosure, and the present disclosure is not limited to the example of FIG. 1. Some components in the example of FIG. 1 may be omitted, and components not exemplified in FIG. 1 may be added.

[0050] Referring to FIG. 1, the device (110, 120) may include a Secure Element (SE). The SE may refer to a security module composed of a semiconductor chip capable of storing security information (e.g., mobile network access information, user identification information, credit card information, encryption key, etc.) and operating a control module that utilizes the stored security information (e.g., network access control module such as USIM, encryption module, key generation module, etc.). The SE may be installed in or used in various electronic devices (e.g., smartphones, tablets, wearable devices, automobiles, IoT devices, etc.) and may provide security services (e.g., mobile network access, digital asset transfer, payment, user authentication, etc.) through the security information and the control module.

[0051] SE can be divided into UICC (Universal Integrated Circuit Card), eSE (Embedded Secure Element), and SSP (Smart Secure Platform), which is a form in which UICC and eSE are integrated. Depending on the form in which it is connected to or installed in an electronic device, it can be subdivided into removable, embedded, and integrated types that are integrated into a specific component or SoC (system on chip).

[0052] An eSE (Embedded Secure Element) may refer to a fixed SE used by being fixed to an electronic device. Typically, an eSE is manufactured exclusively for a manufacturer at the request of the terminal manufacturer and may be manufactured to include an operating system and a framework. A service provider certificate entity in the form of an applet and / or a service control module may be downloaded and installed in the eSE remotely. The service provider certificate entity may perform functions such as digital signatures, encryption, and generating and / or managing encryption keys, certificates, etc., for each service of the service provider. The installed service control module may perform various security service functions such as electronic wallets, ticketing, electronic passports, and digital keys. In this disclosure, an SE in the form of a semiconductor chip attached to an electronic device, to which a service provider certificate entity and / or a service control module may be downloaded and installed remotely, is referred to as an eSE, and in this disclosure, the eSE may be collectively referred to as an SE.

[0053] Referring to FIG. 1, the service provider server (130) may refer to a server operated by a service provider to provide at least one service to a user of the device (110, 120). For example, the service may include services such as internet banking, credit card payment, e-commerce, and internet membership management, and the service provider may include companies such as banks, credit card companies, e-commerce platform operators, airlines, and hypermarkets. The service provider server (130) may include user account information such as user ID and password, and user information databases such as product or service information. For example, a hypermarket may accumulate reward points for members who have signed up for the service provider server (130) via the internet whenever they purchase goods or services, and store the reward points in the user information database. For example, an airline may accumulate mileage for members who use air services whenever they purchase air services or goods, and store the mileage in the user information database. In these examples, the reward points and mileage may be considered digital assets.

[0054] Referring to FIG. 1, the application server (140, 150) represents a server that manages and operates an application for securely managing digital assets using a security device (SE). For example, digital assets may include cash, securities, points used as a substitute for cash or securities, reward points for purchasing goods or services, gift cards, coupons, etc. For example, the application server (140, 150) is Samsung Wallet TM (Samsung Wallet TMIt may include a server that manages and operates applications such as ). The application server (140, 150) may provision, install, and / or manage applets (e.g., service provider authentication entities, service control modules, etc.) and / or security information (e.g., certificates, encryption keys such as private keys / public keys, etc.) running on the SE of the device (110, 120). For example, the application server (140, 150) may provision applets and / or security information on the SE of the device (110, 120) in accordance with an agreement between the manufacturer of the device (110, 120) or the manufacturer of the electronic device on which the device (110, 120) is installed and the service provider. For example, the application server (140, 150) can provision, install, and / or manage applet instances and / or security information on the device (110, 120) on a per-service basis when a user of the device (110, 120) or an electronic device equipped with the device (110, 120) subscribes to a service provided by the service provider server (130).

[0055] The application server (140, 150) may be the same or different for each device (110, 120). For example, if the manufacturer of the electronic device equipped with the device (110, 120) is the same, the device (110, 120) communicates with the same application server (140 or 150), and the applets and / or security information within the device (110, 120) may be managed by the same application server (140 or 150). For example, if the manufacturers of the electronic devices equipped with the devices (110, 120) are different, the application servers (140, 150) may be different, and the first device (110) may communicate with the application server (140) of the first device and the applets and / or security information within the first device (110) may be managed by the application server (140) of the first device, and the second device (120) may communicate with the application server (150) of the second device and the applets and / or security information within the second device (120) may be managed by the application server (150) of the second device. In addition to this, for various other reasons, the application servers (140, 150) for the devices (110, 120) may be the same or different.

[0056] FIG. 2 illustrates the structure of an applet within a safety device (SE) according to the present disclosure. The example in FIG. 2 is solely for the purpose of illustrating the present disclosure, and the present disclosure is not limited to the example in FIG. 2. In the example in FIG. 2, the number of service providers is for illustrative purposes only, and the present disclosure may be applied identically or similarly even if the number of service providers changes. Furthermore, the present disclosure is not limited to the number of services per service provider exemplified in FIG. 2, and may be applied identically or similarly even if the number of services per service provider changes.

[0057] Referring to FIG. 2, service provider authentication entities (210, 220, 230) may be provisioned or created per service provider in accordance with an agreement between the manufacturer of the device (110, 120) or the manufacturer of the electronic device on which the device (110, 120) is installed and the service provider. For example, service provider authentication entities (210, 220, 230) may be provisioned or created by an application server (140, 150). When service provider authentication entities (210, 220, 230) are provisioned or created, private key / public key (210a, 220a, 230a) and / or service provider authentication entity identifiers (210b, 220b, 230b) for service provider authentication entities (210, 220, 230) may be provisioned or created. A certificate containing a public key for a service provider authentication entity (210, 220, 230) and / or a service provider authentication entity identifier (210b, 220b, 230b) may be transmitted to a service provider server (130). The service provider authentication entity (210, 220, 230) may perform the function of, for example, a root certificate authority for a related service provider and / or the service provider's service.

[0058] As described with reference to FIG. 1, a service provider server (130) may provide at least one service to a user of a device (110, 120). When a user of a device (110, 120) subscribes to or joins a service provided by the service provider server (130), security information and / or digital asset information may be generated for each service. For example, security information (212a, 214a, 222a, 232a, 234a) may include at least one of user identification information, credit card information, encryption key (e.g., private key / public key), and certificate associated with the service (212, 214, 222, 232, 234). For example, digital asset information (212b, 214b, 222b, 232b, 234b) may include information regarding digital assets (e.g., cash, securities, points used as a substitute for cash or securities, reward points for purchasing goods or services, gift cards, coupons, etc.) associated with the service (212, 214, 222, 232, 234). For example, service-specific security information (212a, 214a, 222a, 232a, 234a) may be generated by the corresponding service provider authentication entity (210, 220, 230), but may also be provisioned or generated by the application server (140, 150). For example, digital asset information (212b, 214b, 222b, 232b, 234b) may be generated and / or managed by the application server (140, 150) through the linkage between the application server (140, 150) and the service provider server (130), but may also be generated and / or managed by the service provider server (130).

[0059] For example, if a user of a device (110, 120) subscribes to Service 1-1 (212) and Service 1-2 (214) among a plurality of services provided by a first service provider, security information (212a, 214a) and / or digital asset information (212b, 214b) may be generated for each service (212, 214). For example, if a user of a device (110, 120) subscribes to Service 2-1 (222) among a plurality of services provided by a second service provider, security information (222a) and / or digital asset information (222b) for the service (222) may be generated. For example, if a user of a device (110, 120) subscribes to service 3-1 (232) and service 3-2 (234) among a plurality of services provided by a third service provider, security information (232a, 234a) and / or digital asset information (232b, 234b) may be generated for each service (232, 234).

[0060] FIG. 3 illustrates the configuration of a safety device (SE) included in the device (110, 120) in the present disclosure. In the example of FIG. 3, the SE (300) is illustrated as including a communication interface (310), a memory (320), and a processor (330), but the safety device (SE) may include other configurations not illustrated in FIG. 3, and some illustrated configurations may be omitted.

[0061] Referring to FIG. 3, SE (300) is an independent secure storage device and is a secure area accessible only to authenticated applications. SE (300) can be configured to be physically isolated from other hardware components. For example, SE (300) may include an embedded Secure Element (eSE), a Universal Integrated Circuit Card (UICC), a Secure Digital Card (SD Card), an embedded UICC (eUICC), etc.

[0062] The communication interface (310) can communicate with an external device of the SE (300). The communication interface (310) may include at least one of various wired and wireless communication interfaces for communicating with an external device. For example, the communication interface (310) may be configured to communicate with at least one processor, memory, transceiver, etc. (e.g., see FIG. 8 and related description) included in an electronic device in which the SE (300) is mounted. The communication interface (310) may be a serial interface such as ISO 7816, USB (Universal Serial Bus), I2C (Inter-Integrated Circuit), SPI (Serial Peripheral Interface), SWP (Single Wire Protocol), for example, or any serial interface commonly used for communication between two hardware devices. Additionally, it may be a wireless interface such as ISO 14443, Zigbee, Bluetooth, etc., which connects an antenna directly to a hardware device. Furthermore, the communication interface (310) may be a parallel interface connected to a central bus (BUS) of an electronic device (e.g., the electronic device of FIG. 8), in which case the communication interface (310) may include a buffer for receiving commands and data from an external device.

[0063] Various types of data, such as programs like applets and files, may be installed and stored in the memory (320). The processor (330) may access and use the data stored in the memory (320) or store new data in the memory (320). In one embodiment, programs and data configured to perform the proposed method of the present disclosure may be installed and stored in the memory (320).

[0064] The processor (330) controls the overall operation of the SE (300) and may include at least one processor such as a CPU, GPU, etc. For example, the processor (330) may execute a program stored in memory (320), read a stored file, or save a new file. In one embodiment, the processor (330) may be configured to perform the embodiment illustrated in FIG. 4 or FIG. 5 and / or the method illustrated in FIG. 6 or FIG. 7 by executing a program stored in memory (320).

[0065] The proposed method of the present disclosure

[0066] The present disclosure provides a method for securely transferring digital assets created and / or managed within a security device (SE) of devices (110, 120) between devices (110, 120). In the present disclosure, the term "transfer" may have a general meaning of an action that causes a change in ownership relationships (of digital assets), such as sharing, use, buying, selling, lending, etc. Accordingly, in the present disclosure, the term "transfer" may be replaced with another term meaning an action that causes a change in ownership relationships, such as sharing, buying, selling, lending, etc.

[0067] Some service providers manage digital assets on their own servers for each user account, separate from security mechanisms, and offer features to transfer these assets to other users when specific conditions are met. For example, some airlines operate servers for mileage management, managing miles by user account and providing a function to transfer them to other users when certain conditions are satisfied. However, since building a function for transferring digital assets between users can require significant time and cost, it can be a heavy burden for service providers to build and operate their own servers. Therefore, there is a need for a method that allows service providers to offer digital asset-related services to users without significant financial strain. Furthermore, as there may be differences in the methods and / or conditions for transferring digital assets among service providers, users may find it difficult to understand these varying approaches. Consequently, there is a need for a method that enables users to easily manage their digital assets and conveniently transfer them between users.

[0068] Accordingly, the present disclosure proposes a method that reduces the burden on service providers and enables users to easily manage and transfer digital assets by providing a function to manage and / or transfer digital assets per service provider within a secure application platform provided by application servers (140, 150) using a security device (SE). For example, the present disclosure describes Samsung Wallet TM Through application platforms based on security mechanisms (SE) such as [the above], it is possible to provide a way for users to safely and conveniently transfer digital assets.

[0069] The proposed method of the present disclosure may include a two-step verification procedure for transferring digital assets. Specifically, the verification procedure for transferring digital assets according to the present disclosure may include mutual authentication between devices (110, 120) and attesting to a service provider server (130) that digital asset statement information regarding the digital assets to be transferred has been generated within a security device (SE) of the devices (110, 120).

[0070] Mutual authentication between devices (110, 120) can be performed for each service related to digital assets, and can be performed using a key pair of private / public keys included in security information (212a, 214a, 222a, 232a, 234a) related to the service. For example, device (110) can generate digital asset specification information regarding digital assets to be transferred, sign the generated digital asset specification information, and provide it to device (120), and device (120) can authenticate device (110) and digital asset specification information by verifying the digital asset specification information and verifying the signature information of device (110). Similarly, for example, device (120) can generate digital asset specification information regarding digital assets to be transferred, sign the generated digital asset specification information, and provide it to device (110), and device (110) can authenticate device (120) and digital asset specification information by verifying the digital asset specification information and verifying the signature information of device (120). For example, the device (110, 120) can generate a hash value using digital asset specification information and a predetermined hash algorithm, sign the generated hash value with a private key included in security information (212a, 214a, 222a, 232a, 234a), and generate signature information of the device (110, 120).

[0071] For example, the digital asset specification information in the present disclosure may include at least one of the information exemplified in Table 1. The examples in Table 1 are solely for the purpose of illustrating the present disclosure, and the present disclosure is not limited to the examples in Table 1. Some components in the examples in Table 1 may be omitted, and components not exemplified in Table 1 may be added. Additionally, the names of each field in Table 1 may be changed and may have different types and descriptions than those exemplified in Table 1.

[0072] [Table 1]

[0073]

[0074] In the example in Table 1, the Start date / time field may contain information regarding the start date and / or time when the digital asset to be transferred is available for use and may have a string type. The End date / time field may contain information regarding the last date and / or time when the digital asset to be transferred is available for use and may have a string type. The Is_user_authentication_required field may contain information indicating whether user authentication is required to use the digital asset and may have a boolean type. For example, if the Is_user_authentication_required field has a value of True, it may indicate that user authentication is required to use the digital asset, and if the Is_user_authentication_required field has a value of False, it may indicate that user authentication is not required to use the digital asset (or the field value may be set to the opposite). The digital asset information field may include at least one of information regarding the name, quantity, unit, and description of the digital asset, and each piece of information included in the digital asset information field may have a string type. The service provider certificate entity identifier or service provider certificate entity signature field represents the identifier of the service provider certificate entity or the signature of the service provider certificate entity within the applet in the device (110, 120), and may have a string type.For example, the service provider authenticated entity identifier or service provider authenticated entity signature field may include a service provider authenticated entity identifier (210b, 220b, 230b) associated with the digital asset or service to be transferred. For example, the service provider authenticated entity identifier or service provider authenticated entity signature field may include signature information of the service provider authenticated entity associated with the digital asset or service to be transferred. The signature information of the service provider authenticated entity may be generated, for example, by generating a hash value using digital asset specification information and a predetermined hash algorithm, and signing the generated hash value with the private key (210a, 220a, 230a) of the service provider authenticated entity. For example, the identifier of the service provider authenticated entity and the signature information of the service provider authenticated entity may be included in the digital asset specification information as separate fields. In the example of Table 1, it was described that the digital asset statement information includes a service provider authenticated entity identifier and / or signature, but the service provider authenticated entity identifier and / or signature may also be provided to the service provider separately from the digital asset statement information.

[0075] The operation of proving to a service provider server (130) that digital asset specification information regarding a digital asset to be transferred according to the present disclosure has been generated within a security device (SE) of a device (110, 120) may include providing information for proving a service provider authentication entity of the device (110, 120) to the service provider server (130) through or together with the digital asset specification information. By the device (110, 120) providing information for proving a service provider authentication entity to the service provider server (130), the service provider server (130) is enabled to verify that the digital asset specification information was generated within a secure space contracted with the service provider, namely, within the security device (SE) of the device (110, 120).

[0076] For example, information for proving a service provider authentication entity of a device (110, 120) may include a service provider authentication entity identifier described with reference to Table 1 or a service provider authentication entity identifier (210b, 220b, 230b) described with reference to FIG. 2. For example, information for proving a service provider authentication entity of a device (110, 120) may include signature information of a service provider authentication entity of a device (110, 120). The signature information of a service provider authentication entity may be generated, for example, by generating a hash value using digital asset specification information and a predetermined hash algorithm, and signing the generated hash value with the private key (210a, 220a, 230a) of the service provider authentication entity. For example, the information for proving the service provider authentication entity of the device (110, 120) may include both the service provider authentication entity identifier described with reference to Table 1 or the service provider authentication entity identifier (210b, 220b, 230b) described with reference to FIG. 2 and the signature information of the service provider authentication entity.

[0077] In the present disclosure, the service provider authentication entity identifier may be encrypted to enhance security. When the service provider authentication entity identifier is encrypted, the service provider authentication entity identifier may be encrypted using the public key of the service provider server. Alternatively, the service provider authentication entity identifier may be provided to the service provider server without encryption.

[0078] Mutual authentication between devices (110, 120) according to the present disclosure may mean that the user of the device (110, 120) has consented to the transfer of digital assets indicated by the digital asset specification information. Additionally, according to the present disclosure, proving to the service provider server (130) that the digital asset specification information was generated within the security device (SE) of the device (110, 120), and the service provider server (130) verifying information for proving the service provider authentication entity may mean that the service provider server (130) notarizes the transfer of digital assets between the devices (110, 120). According to the present disclosure, in addition to mutual authentication between the devices (110, 120), a technical effect can be expected in which the security of the digital asset transfer can be further enhanced by proving to the service provider server (130) that the digital asset specification information was generated within the SE of the device (110, 120) and the service provider server (130) verifying.

[0079] FIG. 4 illustrates an exemplary embodiment of transferring digital assets according to the present disclosure. The example in FIG. 4 is solely for the purpose of illustrating the present disclosure, and the present disclosure is not limited to the example in FIG. 4. In the example in FIG. 4, some components may be omitted, and components not exemplified in FIG. 4 may be added. Additionally, the sequence of operations exemplified in FIG. 4 may be changed.

[0080] In the example of FIG. 4, it is assumed that the first device (110) has a service provider certificate entity, a certificate of the second device (120), and a certificate of the service provider (130). Additionally, it is assumed that the second device (120) has a service provider certificate entity, a certificate of the first device (110), and a certificate of the service provider (130). Additionally, it is assumed that the service provider (130) has an identifier and / or certificate of the service provider certificate entity of the first device (110) and an identifier and / or certificate of the service provider certificate entity of the second device (120).

[0081] In the example of FIG. 4, it is assumed that the first device (110) and the second device (120) have established a connection. The connection establishment can be performed using communication technologies such as 4G, 5G, 6G, etc. according to the 3GPP technical specification (TS), communication technologies such as Ethernet, Wi-Fi, Wireless PAN (personal area network), etc. according to the IEEE 802 standard, and communication technologies such as NFC (Near Field Communication) and Bluetooth. In addition, various other communication technologies may be used to establish a connection between the first device (110) and the second device (120), and the present disclosure is not limited to any one of these communication technologies.

[0082] Referring to FIG. 4, the first device (110) can generate digital asset specification information regarding a digital asset to be transferred and sign the generated digital asset specification information to obtain signature information of the first device (110) (404). The digital asset specification information may include information for attestation of the service provider certificate entity of the first device (110). For example, the digital asset specification information (generated in 404) may include at least one of the information exemplified in Table 1, and may include the service provider certificate entity identifier of the first device (110) as information for attestation of the service provider certificate entity of the first device (110). Alternatively, the information for attestation of the service provider certificate entity of the first device (110) may be information separate from the digital asset specification information. The signature information of the first device (110) can be generated by signing the digital asset specification information (generated in 404) using the private key of the first device (110) (e.g., the private key included in the service-specific security information (212a, 214a, 222a, 232a, 234a)) (e.g., see “Proposed Method of the Present Disclosure”).

[0083] The first device (110) may transmit a message to the second device (120) containing information for proving the service provider authentication entity of the first device (110) (e.g., the service provider authentication entity identifier of the first device (110)) (406). For example, the information for proving the service provider authentication entity of the first device (110) (e.g., the service provider authentication entity identifier of the first device (110)) may be included in the digital asset statement information (generated in 404), but may also be included in the message (406) separately from the digital asset statement information. The message (406) may further include the digital asset statement information (generated in 404) and the signature information of the first device (110). The message (406) is intended to request the second device (120) to authenticate or verify the first device (110) and / or confirm the digital asset statement information, and may be referred to as a request message, a verification request, or an authentication request.

[0084] The second device (120) can verify the digital asset statement information received through the message (406) and verify the first device (110) (408). For example, the second device (120) can verify the first device (110) by verifying the signature information of the first device (110) using the public key included in the certificate of the first device (110). If the second device (120) successfully verifies the digital asset statement information received through the message (406) and succeeds in verifying the first device (110), the second device (120) can sign the digital asset statement information and obtain the signature information of the second device (120).

[0085] In the example of FIG. 4, if the digital asset is inconsistent or has an error as a result of verifying the digital asset specification information (received from 406) (408), or if the verification of the first device (110) fails (408), the second device (120) may send a message indicating the error and / or verification failure to the first device (110) (not shown).

[0086] Referring to FIG. 4, the second device (120) can transmit a message to a service provider server (130) containing information for proving the service provider authentication entity of the first device (110) (e.g., the service provider authentication entity identifier of the first device (110)) (410). By providing the information for proving the service provider authentication entity of the first device (110) (e.g., the service provider authentication entity identifier of the first device (110)) to the service provider server (130), the service provider server (130) is enabled to verify that the digital asset specification information was generated in a secure space (e.g., the SE of the first device (110)). For example, the message (410) may include digital asset statement information (identified in 408), and information for proving the service provider authentication entity of the first device (110) (e.g., the service provider authentication entity identifier of the first device (110)) may be included in the digital asset statement information (identified in 408) (or may be included in the message (410) separately from the digital asset statement information). For example, the message (410) may include signature information of the second device (120) (obtained in 408). The signature information of the second device (120) may enable the service provider server (130) to authenticate the second device (120) and prevent repudiation of the digital asset statement information, etc. The message (410) is intended to request the service provider server (130) to authenticate or verify the second device (120) and / or verify the digital asset statement information, and may be referred to as a request message, a verification request, or an authentication request.

[0087] The service provider server (130) can verify information for proving the service provider authentication entity of the first device (110) included in the received message (410) (e.g., the service provider authentication entity identifier of the first device (110)) (412). For example, the service provider server (130) can compare the service provider authentication entity identifier of the first device (110) that it already possesses with the service provider authentication entity identifier of the first device (110) included in the message (410), and determine whether the verification is successful based on the comparison result. For example, if the service provider authentication entity identifier of the first device (110) that is already possessed is identical or corresponds to the service provider authentication entity identifier of the first device (110) included in the message (410), the service provider server (130) may determine that the verification of the service provider authentication entity identifier of the first device (110) has been successful, and may determine that the digital asset specification information included in the message (410) was generated in a secure space (e.g., SE) within the first device (110). For example, if the service provider authentication entity identifier of the first device (110) that is already possessed is not the same or does not correspond to the service provider authentication entity identifier of the first device (110) included in the message (410), the service provider server (130) may determine that the verification of the service provider authentication entity identifier of the first device (110) has failed, and may determine that the digital asset specification information included in the message (410) was not generated in a secure space (e.g., SE) within the first device (110) or has been forged or altered.

[0088] For example, if the verification of the service provider authentication entity identifier of the first device (110) is successful, the service provider server (130) may store the digital asset statement information received through the message (410). For example, if the verification of the service provider authentication entity identifier of the first device (110) fails, the service provider server (130) may discard the digital asset statement information received through the message (410).

[0089] The service provider server (130) may transmit a message (414) to the second device (120) in response to the message (410). In the present disclosure, the message (414) may be referred to as a response message, a verification response, etc. For example, if the service provider server (130) succeeds in verifying information for proving the service provider authentication entity of the first device (110) (e.g., the service provider authentication entity identifier of the first device (110)), the message (414) may be a message indicating successful verification and / or an acceptance message. For example, if the service provider server (130) fails to verify information for proving the service provider authentication entity of the first device (110) (e.g., the service provider authentication entity identifier of the first device (110)), the message (414) may be a message indicating failure of verification and / or a rejection message.

[0090] Referring to FIG. 4, the second device (120) can perform mutual authentication with the first device (110) based on a message (414). If the message (414) is a message indicating successful verification and / or an acceptance message, the second device (120) can generate digital asset specification information regarding digital assets to be transferred for mutual authentication with the first device, and sign the generated digital asset specification information to obtain signature information of the second device (120) (416). The digital asset specification information may include information for proving the service provider authentication entity of the second device (120). For example, the digital asset specification information (generated in 416) may include at least one of the information exemplified in Table 1, and may include the service provider authentication entity identifier of the second device (120) as information for proving the service provider authentication entity of the second device (120). Alternatively, information for proving the service provider authentication entity of the second device (120) may be information separate from the digital asset statement information. The signature information of the second device (120) may be generated by signing the digital asset statement information (generated in 416) using the private key of the second device (120) (e.g., the private key included in the service-specific security information (212a, 214a, 222a, 232a, 234a)) (e.g., see “Proposed Method of the Present Disclosure”).

[0091] The second device (120) may transmit a message to the first device (110) containing information for proving the service provider authentication entity of the second device (120) (e.g., the service provider authentication entity identifier of the second device (120)) (418). For example, the information for proving the service provider authentication entity of the second device (120) (e.g., the service provider authentication entity identifier of the second device (120)) may be included in the digital asset statement information (generated in 416), but may also be included in the message (418) separately from the digital asset statement information. The message (418) may further include the digital asset statement information (generated in 416) and the signature information of the second device (120). The message (418) is intended to request the first device (110) to authenticate or verify the second device (120) and / or confirm the digital asset statement information, and may be referred to as a request message, a verification request, or an authentication request.

[0092] The first device (110) can verify the digital asset statement information received through the message (418) and verify the second device (120) (420). For example, the first device (110) can verify the second device (120) by verifying the signature information of the second device (120) using the public key included in the certificate of the second device (120). If the first device (110) successfully verifies the digital asset statement information received through the message (418) and succeeds in verifying the second device (120), the first device (110) can sign the digital asset statement information and obtain the signature information of the first device (110).

[0093] In the example of FIG. 4, if the digital asset is inconsistent or has an error (420) as a result of verifying the digital asset specification information received through the message (418), or if the verification of the second device (120) fails (420), the first device (110) may send a message indicating the error and / or verification failure to the second device (120) (not shown).

[0094] Referring to FIG. 4, the first device (110) can transmit a message to a service provider server (130) containing information for proving the service provider authentication entity of the second device (120) (e.g., the service provider authentication entity identifier of the second device (120)) (422). By providing the information for proving the service provider authentication entity of the second device (120) (e.g., the service provider authentication entity identifier of the second device (120)) to the service provider server (130), the service provider server (130) is enabled to verify that the digital asset specification information was generated in a secure space (e.g., the SE of the second device (120)). For example, the message (422) may include digital asset statement information (identified in 420), and information for proving the service provider authentication entity of the second device (120) (e.g., the service provider authentication entity identifier of the second device (120)) may be included in the digital asset statement information (identified in 420) (or may be included in the message (422) separately from the digital asset statement information). For example, the message (422) may include signature information of the first device (110) (obtained in 420). The signature information of the first device (110) may enable the service provider server (130) to authenticate the first device (110) and prevent repudiation of the digital asset statement information, etc. For example, the message (422) is intended to request the service provider server (130) to authenticate or verify the second device (120) and / or verify the digital asset statement information, and may be referred to as a request message, a verification request, or an authentication request.

[0095] The service provider server (130) can verify information for proving the service provider authentication entity of the second device (120) included in the received message (422) (e.g., the service provider authentication entity identifier of the second device (120)) (424). For example, the service provider server (130) can compare the service provider authentication entity identifier of the second device (120) that it already possesses with the service provider authentication entity identifier of the second device (120) included in the message (422), and determine whether the verification is successful based on the comparison result. For example, if the service provider authentication entity identifier of the second device (120) that is already possessed is identical or corresponds to the service provider authentication entity identifier of the second device (120) included in the message (422), the service provider server (130) may determine that the verification of the service provider authentication entity identifier of the second device (120) has been successful, and may determine that the digital asset specification information included in the message (422) was generated in a secure space (e.g., SE) within the second device (120). For example, if the service provider authentication entity identifier of the second device (120) that is already possessed is not the same or does not correspond to the service provider authentication entity identifier of the second device (120) included in the message (422), the service provider server (130) may determine that the verification of the service provider authentication entity identifier of the second device (120) has failed, and may determine that the digital asset specification information included in the message (422) was not generated in a secure space (e.g., SE) within the second device (120) or has been forged or altered.

[0096] For example, if the verification of the service provider authentication entity identifier of the second device (120) is successful, the service provider server (130) may store the digital asset statement information received via the message (422). For example, if the verification of the service provider authentication entity identifier of the second device (120) fails, the service provider server (130) may discard the digital asset statement information received via the message (422).

[0097] For example, the service provider server (130) may additionally verify digital asset statement information by comparing the digital asset statement information (412) stored after successfully verifying the service provider authentication entity identifier of the first device (110) with the digital asset statement information (424) stored after successfully verifying the service provider authentication entity identifier of the second device (120). For example, if the digital asset statement information (412, 424) is identical or corresponding, the service provider server (130) may determine that the verification of the digital asset statement information has been successful. For example, if the digital asset statement information (412, 424) is not identical or corresponding, the service provider server (130) may determine that the verification of the digital asset statement information has failed and may discard the stored digital asset statement information.

[0098] The service provider server (130) may transmit a message (426) to the first device (110) in response to the message (422). In the present disclosure, the message (426) may be referred to as a response message, a verification response, etc. For example, if the service provider server (130) succeeds in verifying information for proving the service provider authentication entity of the second device (120) (e.g., the service provider authentication entity identifier of the second device (120)) (and / or succeeds in verifying digital asset specification information), the message (426) may be a message indicating successful verification and / or an acceptance message. For example, if the service provider server (130) fails to verify information for proving the service provider authentication entity of the second device (120) (e.g., the service provider authentication entity identifier of the second device (120)) (and / or fails to verify digital asset specification information), the message (426) may be a message indicating failure of verification and / or a rejection message.

[0099] Referring to FIG. 4, when the first device (110) receives a message indicating successful verification and / or an acceptance message (426), the first device (110) may transmit a message for a request for the transfer of a digital asset to the second device (120) (428). The message (428) may include digital asset specification information (confirmed by the first device (110) in 420 and verified by the service provider server (130) in 424). In the present disclosure, the message (428) may be referred to as a request message or a transfer request, etc.

[0100] The second device (120) receives a message (428) and can store the digital asset specification information received through the message (428) in a secure storage (430). Additionally, the second device (120) can transmit a message for a digital asset registration request to the application server (150) of the second device (432). For example, the message (432) may include the digital asset specification information received through the message (428). The message (432) for a digital asset registration request may be briefly referred to as a digital asset registration request. The order of operations (430, 432) may be reversed.

[0101] The application server (150) of the second device receives a message (432) and can forward the message (432) to the service provider server (130) (434). The message (434) may include the digital asset statement information included in the message (432) as is. The application server (150) of the second device may also store the digital asset statement information received through the message (432).

[0102] A service provider server (130) receives a message (434) and can perform a transfer registration of a digital asset based on the digital asset specification information included in the message (434) (not shown). For example, the service provider server (130) can transfer the digital asset indicated by the digital asset specification information included in the message (434) from the user account of the first device (110) to the user account of the second device (120). After performing the transfer registration, the service provider server (130) can send a response message to the message (434) to the application server (150) of the second device (436). In the present disclosure, the message (436) may be referred to as a registration response, etc.

[0103] When receiving message (436), the application server (150) of the second device may change digital assets in the user account of the second device (120) based on the digital asset specification information received and stored via message (432) (not shown). For example, the application server (150) of the second device may change digital assets in the user account of the second device (120) by an amount of digital assets indicated by the digital asset specification information. The application server (150) of the second device may send a response message to the message (432) to the second device (120) (438). In the present disclosure, the message (438) may be referred to as a response message or a registration response, etc.

[0104] The application server (140) of the first device and the application server (150) of the second device may be different from each other (e.g., see FIG. 1 and related description). For example, if the manufacturer of the first device (110) and the manufacturer of the second device (120) are different, the application server (140) of the first device and the application server (150) of the second device may be different from each other. In this case, the service provider server (130) may send a message to the application server (140) of the first device to notify the transfer registration (event) of a digital asset (440). In the present disclosure, the message (440) may be referred to as a notification message or an event notification, etc.

[0105] When receiving a message (440), the application server (140) of the first device may change digital assets in the user account of the first device (110) based on the digital asset specification information received through the message (440) (not shown). For example, the application server (140) of the first device may change digital assets in the user account of the first device (110) by an amount of digital assets indicated by the digital asset specification information. The application server (140) of the first device may send a response message to the message (440) to the service provider server (130) (442). In the present disclosure, the message (442) may be referred to as an event notification response, etc.

[0106] The application server (140) of the first device and the application server (150) of the second device may be the same (e.g., see FIG. 1 and related description). For example, if the manufacturer of the first device (110) and the manufacturer of the second device (120) are the same, the application server (140) of the first device and the application server (150) of the second device may be the same. In this case, the operation of the service provider server (130) transmitting a message (440) and receiving a message (442) may be omitted. The application server (150) of the second device may change digital assets in the user account of the first device (110) based on digital asset specification information received and stored via message (432) (not shown). For example, the application server (150) of the second device may change digital assets in the user account of the first device (110) by the amount of digital assets indicated by the digital asset specification information.

[0107] In the example of FIG. 4, it is described that operations (404 to 414) are performed before operations (416 to 426), but the proposed method of the present disclosure can be applied in the same or similar way even when operations (416 to 426) are performed before operations (404 to 414). For example, when the operations exemplified in FIG. 4 are initiated by the second device (120), operations (404 to 414) may be performed after operations (416 to 426) are performed. In this example, a message (428) may be transmitted to the first device (110) by the second device (120), and operations (430 to 438) may be performed by the first device (110) and the application server (140) of the first device.

[0108] In the example of FIG. 4, it has been explained that the service provider authentication entity identifier of the device (110, 120) is used as information for proving the service provider authentication entity of the device (110, 120), but other information may be used. In one embodiment of the present disclosure, signature information of the service provider authentication entity of the device (110, 120) may be used instead of the service provider authentication entity identifier of the device (110, 120), and an embodiment in which the signature information of the service provider authentication entity of the device (110, 120) is used is described with reference to FIG. 5.

[0109] FIG. 5 illustrates an exemplary embodiment of transferring digital assets according to the present disclosure. The example of FIG. 5 is solely for the purpose of illustrating the present disclosure, and the present disclosure is not limited to the example of FIG. 5. In the example of FIG. 5, some components may be omitted, and components not exemplified in FIG. 5 may be added. Additionally, the sequence of operations exemplified in FIG. 5 may be changed.

[0110] Comparing the example of FIG. 5 with the example of FIG. 4, in the example of FIG. 5, the signature information of the service provider authentication entity of the device (110, 120) may be used instead of the service provider authentication entity identifier of the device (110, 120) as information for proving the service provider authentication entity of the device (110, 120). Accordingly, the entire description of FIG. 4 is included as a description of FIG. 5, wherein the service provider authentication entity identifier of the first device (110) may be replaced with the signature information of the service provider authentication entity of the first device (110), and the service provider authentication entity identifier of the second device (120) may be replaced with the signature information of the service provider authentication entity of the second device (120). The following description focuses on the differences from the example of FIG. 4.

[0111] Referring to FIG. 5, the first device (110) generates digital asset specification information regarding a digital asset to be transferred and obtains signature information of the first device (110) (see description related to 404 in FIG. 4), and additionally, the first device (110) may obtain signature information of the service provider authentication entity of the first device (110) (404). In the example of FIG. 5, the signature information of the service provider authentication entity of the first device (110) may be used as information for proving the service provider authentication entity of the first device (110). Accordingly, in the example of FIG. 5, an example of information for proving the service provider authentication entity of the first device (110) may include the signature information of the service provider authentication entity of the first device (110). For example, signature information of a service provider authentication entity of the first device (110) can be generated by signing digital asset statement information (generated in 404) using the private keys (210a, 220a, 230a) of the service provider authentication entity of the first device (110).

[0112] In the example of FIG. 5, as previously explained, an example of information for proving the service provider authentication entity of the first device (110) included in the message (406, 410) may include signature information of the service provider authentication entity of the first device (110) instead of the service provider authentication entity identifier of the first device (110).

[0113] In the example of FIG. 5, the service provider server (130) can verify the signature information of the service provider authentication entity of the first device (110) included in the received message (410) (512). For example, the service provider server (130) can verify the signature information of the service provider authentication entity of the first device (110) using the public key included in the certificate of the service provider authentication entity of the first device (110) that it already possesses. For example, if the service provider server (130) succeeds in verifying the signature information of the service provider authentication entity of the first device (110), the service provider server (130) can determine that the digital asset specification information included in the message (410) was generated in a secure space (e.g., SE) within the first device (110). For example, if the service provider server (130) fails to verify the signature information of the service provider authentication entity of the first device (110), it may be determined that the digital asset specification information included in the message (410) was not generated in a secure space (e.g., SE) within the first device (110) or that it has been forged or altered.

[0114] For example, if the service provider server (130) succeeds in verifying the signature information of the service provider authentication entity of the first device (110), the service provider server (130) may store the digital asset specification information received through the message (410). For example, if the service provider server (130) fails to verify the signature information of the service provider authentication entity of the first device (110), the service provider server (130) may discard the digital asset specification information received through the message (410).

[0115] In the example of FIG. 5, if the service provider server (130) succeeds in verifying the signature information of the service provider authentication entity of the first device (110), the message (414) may be a message indicating successful verification and / or an acceptance message. In the example of FIG. 5, if the service provider server (130) fails to verify the signature information of the service provider authentication entity of the first device (110), the message (414) may be a message indicating failed verification and / or a rejection message.

[0116] In the example of FIG. 5, if the message (414) is a message indicating successful verification and / or an acceptance message, the second device (120) generates digital asset specification information and obtains signature information of the second device (120) (see description related to 416 in FIG. 4), and additionally, the second device (120) may obtain signature information of the service provider authentication entity of the second device (120) (416). In the example of FIG. 5, the signature information of the service provider authentication entity of the second device (120) may be used as information for proving the service provider authentication entity of the second device (120). Accordingly, in the example of FIG. 5, an example of information for proving the service provider authentication entity of the second device (110) may include the signature information of the service provider authentication entity of the second device (110). For example, signature information of a service provider authentication entity of the second device (120) can be generated by signing digital asset statement information (generated in 416) using the private keys (210a, 220a, 230a) of the service provider authentication entity of the second device (120).

[0117] In the example of FIG. 5, as previously explained, the example of information for proving the service provider authentication entity of the second device (120) included in the message (418, 422) may include signature information of the service provider authentication entity of the second device (120) instead of the service provider authentication entity identifier of the second device (120).

[0118] In the example of FIG. 5, the service provider server (130) can verify the signature information of the service provider authentication entity of the second device (120) included in the received message (422) (524). For example, the service provider server (130) can verify the signature information of the service provider authentication entity of the second device (120) using the public key included in the certificate of the service provider authentication entity of the second device (120) that it already possesses. For example, if the service provider server (130) succeeds in verifying the signature information of the service provider authentication entity of the second device (120), the service provider server (130) can determine that the digital asset specification information included in the message (422) was generated in a secure space (e.g., SE) within the second device (120). For example, if the service provider server (130) fails to verify the signature information of the service provider authentication entity of the second device (120), it may be determined that the digital asset specification information included in the message (422) was not generated in a secure space (e.g., SE) within the second device (120) or was forged or altered.

[0119] For example, if the service provider server (130) succeeds in verifying the signature information of the service provider authentication entity of the second device (120), the service provider server (130) may store the digital asset specification information received through the message (422). For example, if the service provider server (130) fails to verify the signature information of the service provider authentication entity of the second device (120), the service provider server (130) may discard the digital asset specification information received through the message (422).

[0120] In the example of FIG. 5, for instance, the service provider server (130) may additionally verify digital asset statement information by comparing the digital asset statement information (512) stored after successfully verifying the signature information of the service provider authentication entity of the first device (110) with the digital asset statement information (524) stored after successfully verifying the signature information of the service provider authentication entity of the second device (120). For example, if the digital asset statement information (512, 524) is identical or corresponding, the service provider server (130) may determine that the verification of the digital asset statement information has been successful. For example, if the digital asset statement information (512, 524) is not identical or corresponding, the service provider server (130) may determine that the verification of the digital asset statement information has failed and may discard the stored digital asset statement information.

[0121] In the example of FIG. 5, if the service provider server (130) succeeds in verifying the signature information of the service provider authentication entity of the second device (120) (and / or succeeds in verifying the digital asset specification information), the message (426) may be a message indicating successful verification and / or an acceptance message. In the example of FIG. 5, if the service provider server (130) fails to verify the signature information of the service provider authentication entity of the second device (120) (and / or fail to verify the digital asset specification information), the message (426) may be a message indicating failed verification and / or a rejection message.

[0122] In the example of FIG. 5, the remaining operations (428 to 442) may be the same as those described with reference to FIG. 4.

[0123] The embodiments of FIGS. 4 and FIGS. 5 may be implemented independently or in combination. For example, the service provider authentication entity identifier of the device (110, 120) and the signature information of the service provider authentication entity of the device (110, 120) may be used together as information for proving the service provider authentication entity of the device (110, 120).

[0124] FIG. 6 illustrates a flowchart of a method performed by a first device (110) according to the present disclosure. The example of FIG. 6 is solely for the purpose of illustrating the present disclosure, and the present disclosure is not limited to the example of FIG. 6. Some components in the example of FIG. 6 may be omitted, and components not exemplified in FIG. 6 may be added. Additionally, the sequence of operations exemplified in FIG. 6 may be changed.

[0125] Referring to FIG. 6, the first device (110) may transmit a first message (602) to the second device (120) that includes first digital asset statement information and signature information of the first device (110). For example, 602 in FIG. 6 may correspond to 406 in FIG. 4 or FIG. 5. For example, the first digital asset statement information may include at least one of the information exemplified in Table 1. For example, the signature information of the first device (110) may be generated by signing the digital asset statement information using the private key of the first device (110) (e.g., the private key included in the security information (212a, 214a, 222a, 232a, 234a) of the service associated with the first digital asset statement information). The first device (110) may transmit information for proving the service provider authentication entity of the first device (110) to the second device (120) through the first message. For example, information for proving the service provider authentication entity of the first device (110) may include the service provider authentication entity identifier of the first device (110) and / or signature information of the service provider authentication entity of the first device (110). For example, information for proving the service provider authentication entity of the first device (110) may be included in the first digital asset statement information, but may also be included in the first message as information separate from the first digital asset statement information.

[0126] As described with reference to FIGS. 4 and 5, the second device (120) can verify the first digital asset specification information received from 602 and verify the first device (110) (e.g., see 408 in FIG. 4 or 5), and then transmit the first digital asset specification information and information for proving the service provider authentication entity of the first device (110) to the service provider server (130) (e.g., see 410 in FIG. 4 or 5). The signature information of the first device (110) can be used by the second device (120) to verify the first device (110) (e.g., see 408 in FIG. 4 or 5). Information for proving the service provider authentication entity of the first device (110) can be used by the service provider server (130) to verify that the first digital asset specification information was generated within a secure space contracted with the service provider, namely within the SE of the device (110) (e.g., see 412 in FIG. 4 or 512 in FIG. 5).

[0127] Referring to FIG. 6, the first device (120) may receive a second message (604) from the second device (120) for mutual authentication, the message including second digital asset statement information and signature information of the second device. For example, 604 in FIG. 6 may correspond to 418 in FIG. 4 or FIG. 5. For example, the second digital asset statement information may include at least one of the information exemplified in Table 1. For example, the signature information of the second device (120) may be generated by signing the second digital asset statement information using the private key of the second device (120) (e.g., a private key included in the security information (212a, 214a, 222a, 232a, 234a) of the service associated with the second digital asset statement information) (e.g., see 416 in FIG. 4 or FIG. 5). The first device (110) may receive information for proving the service provider authentication entity of the second device (120) from the second device (120) through a second message (e.g., see 418 in FIG. 4 or FIG. 5). For example, the information for proving the service provider authentication entity of the second device (120) may include the service provider authentication entity identifier of the second device (120) and / or the signature information of the service provider authentication entity of the second device (120). For example, the information for proving the service provider authentication entity of the second device (120) may be included in the second digital asset statement information, but may also be included in the second message as information separate from the second digital asset statement information.

[0128] The first device (110) can verify the digital asset and the second device (120) based on the second digital asset specification information received from 604 (606). For example, 606 in FIG. 6 may correspond to 420 in FIG. 4 or FIG. 5. The first device (110) can verify the second device (120) using the signature information of the second device (120). Information for proving the service provider authentication entity of the second device (120) can be used by the service provider server (130) to verify that the second digital asset specification information was generated within a secure space contracted with the service provider, namely within the SE of the device (120) (e.g., see 424 in FIG. 4 or 524 in FIG. 5).

[0129] The first device (110) may transmit a third message containing second digital asset specification information to a service provider server (130) based on the verification result of the digital asset and the verification result of the second device (608). For example, 608 in FIG. 6 may correspond to 422 in FIG. 4 or FIG. 5. Additionally, the first device (110) may transmit information for proving the service provider authentication entity of the second device (120) to the service provider server (130) through the third message (e.g., see 422 in FIG. 4 or FIG. 5). For example, information for proving the service provider authentication entity of the second device (120) may be included in the second digital asset specification information, but may also be included in the third message as information separate from the second digital asset specification information.

[0130] When the first device (110) receives a fourth message from the service provider server (130) and the fourth message indicates that the service provider server (130) has succeeded in verifying the second digital asset specification information (e.g., see 426 in FIG. 4 or FIG. 5), the first device (110) may transmit a fifth message containing the second digital asset specification information to the second device (120) for the transfer of the digital asset (e.g., see 428 in FIG. 4 or FIG. 5).

[0131] FIG. 7 illustrates a flowchart of a method performed by a device (120) according to the present disclosure. The example in FIG. 7 is solely for the purpose of illustrating the present disclosure, and the present disclosure is not limited to the example in FIG. 7. Some components in the example in FIG. 7 may be omitted, and components not exemplified in FIG. 7 may be added. Additionally, the sequence of operations exemplified in FIG. 7 may be changed.

[0132] Referring to FIG. 7, the second device (120) may receive a first message from the first device (110) that includes first digital asset statement information and signature information of the first device (110) (702). For example, 702 in FIG. 7 may correspond to 406 in FIG. 4 or FIG. 5. For example, the first digital asset statement information may include at least one of the information exemplified in Table 1. For example, the signature information of the first device (110) may be generated by signing the first digital asset statement information using the private key of the first device (110) (e.g., the private key included in the security information (212a, 214a, 222a, 232a, 234a) of the service associated with the first digital asset statement information). The second device (120) may receive information for proving the service provider authentication entity of the first device (110) from the first device (110) through the first message. For example, information for proving the service provider authentication entity of the first device (110) may include the service provider authentication entity identifier of the first device (110) and / or signature information of the service provider authentication entity of the first device (110). For example, information for proving the service provider authentication entity of the first device (110) may be included in the first digital asset statement information, but may also be included in the first message as information separate from the first digital asset statement information.

[0133] The second device (120) can verify the digital asset and the first device (110) based on the first digital asset specification information received from 702 (704). For example, 704 in FIG. 7 may correspond to 408 in FIG. 4 or FIG. 5. The second device (120) can verify the first device (110) using the signature information of the first device (110). Information for proving the service provider authentication entity of the first device (110) can be used by the service provider server (130) to verify that the digital asset specification information was generated within a secure space contracted with the service provider, namely within the SE of the device (110) (e.g., see 412 in FIG. 4 or 512 in FIG. 5).

[0134] The second device (120) may transmit a second message containing second digital asset specification information to a service provider server (130) based on the verification result of the digital asset and the verification result of the first device (110) (706). For example, 706 in FIG. 7 may correspond to 410 in FIG. 4 or FIG. 5. Additionally, the second device (120) may transmit information for proving the service provider authentication entity of the first device (110) to the service provider server (130) through the second message (e.g., see 410 in FIG. 4 or FIG. 5). For example, information for proving the service provider authentication entity of the first device (110) may be included in the first digital asset specification information, but may also be included in the second message as information separate from the first digital asset specification information.

[0135] If a third message received from the service provider server (130) indicates that the service provider server (130) has succeeded in verifying information for proving the service provider authentication entity of the first device (110) (e.g., see 414 in FIG. 4 or FIG. 5), the second device (120) may transmit a fourth message to the first device (110) for mutual authentication, the message including second digital asset specification information and signature information of the second device (708). For example, 708 in FIG. 7 may correspond to 418 in FIG. 4 or FIG. 5. For example, the second digital asset specification information may include at least one of the information exemplified in Table 1. For example, signature information of the second device (120) may be generated by signing the second digital asset statement information using the private key of the second device (120) (e.g., the private key included in the security information (212a, 214a, 222a, 232a, 234a) of the service related to the second digital asset statement information) (e.g., see 416 in FIG. 4 or 5). The second device (120) may transmit information for proving the service provider authentication entity of the second device (120) to the first device (110) via the fourth message (e.g., see 418 in FIG. 4 or 5). For example, the information for proving the service provider authentication entity of the second device (120) may include the service provider authentication entity identifier of the second device (120) and / or signature information of the service provider authentication entity of the second device (120). For example, information for proving the service provider authentication entity of the second device (120) may be included in the second digital asset statement information, but may also be included in the fourth message as information separate from the second digital asset statement information.

[0136] As described with reference to FIGS. 4 and 5, the first device (110) can verify the second digital asset statement information received from 708 and verify the second device (120) (e.g., see 420 in FIG. 4 or 5), and then transmit the second digital asset statement information and information for proving the service provider authentication entity of the second device (120) to the service provider server (130) (e.g., see 422 in FIG. 4 or 5). The signature information of the second device (120) can be used by the first device (110) to verify the second device (120) (e.g., see 420 in FIG. 4 or 5). Information for proving the service provider authentication entity of the second device (120) can be used by the service provider server (130) to verify that the second digital asset specification information was generated within a secure space contracted with the service provider, namely within the SE of the device (120) (e.g., see 424 in FIG. 4 or 524 in FIG. 5).

[0137] The second device (120) may receive a fifth message containing fourth digital asset specification information from the first device (110) for the transfer of digital assets (e.g., see 428 in FIG. 4 or FIG. 5).

[0138] FIG. 8 illustrates the structure of an electronic device (800) according to one embodiment of the present disclosure.

[0139] Referring to FIG. 8, the electronic device (800) may include a transceiver (820), a processor (810), and a memory (830). Additionally, the electronic device (800) may further include a safety device (SE) (300). The electronic device described above in the present disclosure may correspond to the electronic device (800) described in FIG. 8.

[0140] However, the configuration of the electronic device (800) is not limited to FIG. 8 and may include more or fewer components than those shown in FIG. 8. In one embodiment, the transceiver (820), processor (810), memory (830), and safety device (300) may be implemented in the form of a single semiconductor chip. In one embodiment, the transceiver (820), processor (810), and memory (830) may be implemented in the form of a single chip, and the safety device (300) may be implemented as a separate semiconductor chip. Additionally, the processor (820) may be configured as at least one processor.

[0141] According to various embodiments, the transceiver (820) may transmit and receive signals, information, data, etc. according to various embodiments of the present disclosure with the transceiver of another electronic device or an external server. The transceiver (820) may be composed of an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (820), and the components of the transceiver (820) are not limited to an RF transmitter and an RF receiver. Additionally, the transceiver (820) may receive a signal through a wireless channel and output it to a processor (810), and transmit the signal output from the processor (810) through a wireless channel.

[0142] Meanwhile, the processor (810) is a component for controlling the electronic device (800) overall. The processor (810) can control the overall operation of the electronic device (800) according to various embodiments of the present disclosure as described above.

[0143] Meanwhile, the electronic device (800) may further include a memory (830) and may store data such as a basic program, an application program, and setting information for the operation of the electronic device (800). Additionally, the memory (830) may include at least one storage medium among a Flash Memory Type, a Hard Disk Type, a Multimedia Card Micro Type, a card type memory (e.g., SD or XD memory, etc.), magnetic memory, a magnetic disk, an optical disk, a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read-Only Memory (ROM), a Programmable Read-Only Memory (PROM), and an Electrically Erasable Programmable Read-Only Memory (EEPROM).

[0144] In addition, the processor (810) can perform various operations using various programs, content, data, etc. stored in memory (830).

[0145] The safety device (300) includes the configuration described with reference to FIG. 3 and may be configured to perform the embodiments and / or proposed methods of the present disclosure.

[0146] FIG. 9 illustrates the structure of a server (900) according to one embodiment of the present disclosure.

[0147] Referring to FIG. 9, the server (900) may include a transceiver (920), a processor (910), and a memory (930). The servers (130, 140, 150) described above in the present disclosure may each correspond to the server (900) described in FIG. 9. For example, the service provider server (130) and the application server (140, 150) may each include the configuration of the server (900) described in FIG. 9.

[0148] However, the configuration of the server (900) is not limited to FIG. 9 and may include more or fewer components than those shown in FIG. 9. According to some embodiments, the transceiver (920), the processor (910), and the memory (930) may be implemented in the form of a single semiconductor chip. Additionally, the processor (910) may be configured as at least one processor.

[0149] According to one embodiment, the transceiver (920) can transmit and receive signals, information, data, etc. according to various embodiments of the present disclosure to and from the safety device (300) through the electronic device (800) or through the electronic device (800). The transceiver (920) may be composed of an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (920), and the components of the transceiver (920) are not limited to an RF transmitter and an RF receiver. Additionally, the transceiver (920) can receive a signal through a wireless channel and output it to a processor (910), and transmit the signal output from the processor (910) through a wireless channel.

[0150] Meanwhile, at least one processor (910) is a component for overall control of the server (900). The processor (910) can control the overall operation of the server (900) according to various embodiments of the present disclosure as described above. The at least one processor (910) may be referred to as a control unit.

[0151] Meanwhile, the server (900) may further include memory (930) and may store basic programs, application programs, and data for the operation of the server (900). Additionally, the memory (930) may include at least one storage medium among Flash Memory Type, Hard Disk Type, Multimedia Card Micro Type, Card Type Memory (e.g., SD or XD memory, etc.), Magnetic Memory, Magnetic Disk, Optical Disk, Random Access Memory (RAM), Static Random Access Memory (SRAM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). Additionally, the processor (910) may perform various operations using various programs, content, data, etc. stored in the memory.

[0152] In the specific embodiments of the present disclosure described above, the components included in the disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0153] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

[0154] The various embodiments of the present disclosure and the terms used therein are not intended to limit the technology described in the present disclosure to specific embodiments and should be understood to include various modifications, equivalents, and / or substitutions of said embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar components. A singular expression may include a plural expression unless the context clearly indicates otherwise. In the present disclosure, expressions such as "A or B," "at least one of A and / or B," "A, B or C," or "at least one of A, B and / or C" may include all possible combinations of items listed together. Expressions such as "first," "second," "first," or "second" may modify said components regardless of order or importance and are used only to distinguish one component from another and do not limit said components. When it is mentioned that a certain (e.g., 1st) component is "(functionally or telecommunicationally) connected" or "connected" to another (e.g., 2nd) component, said certain component may be directly connected to said other component or connected through another component (e.g., 3rd component).

[0155] As used in this disclosure, the term "module" includes a unit composed of hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be a component formed integrally, or a minimum unit or part thereof that performs one or more functions. For example, a module may be composed of an application-specific integrated circuit (ASIC).

[0156] Various embodiments of the present disclosure may be implemented as software (e.g., a program) comprising instructions stored in a machine-readable storage medium (e.g., internal memory or external memory) that is readable by a machine (e.g., a computer). The machine may include a terminal according to various embodiments, which is a device capable of calling instructions stored from the storage medium and operating according to the called instructions. When the instructions are executed by a processor, the processor may perform a function corresponding to the instructions directly or by using other components under the control of the processor. The instructions may include code generated or executed by a compiler or an interpreter.

[0157] A device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' means merely that the storage medium does not contain a signal and is tangible, without distinguishing whether data is stored semi-permanently or temporarily on the storage medium.

[0158] Methods according to the various embodiments disclosed in this disclosure 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 in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)) or an application store (e.g., Play Store). TM It may be distributed online via ). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a storage medium such as the memory of a manufacturer's server, an application store's server, or a relay server. Each component (e.g., module or program) according to various embodiments may be composed of a singular or multiple entities, and some of the aforementioned sub-components may be omitted, or other sub-components may be further included in various embodiments. Generally or additionally, some components (e.g., module or program) may be integrated into a single entity to perform the same or similar functions as those performed by each of the respective components prior to integration. The actions performed by the module, program, or other components according to various embodiments may be executed sequentially, in parallel, iteratively, or heuristically, or at least some actions may be executed in a different order, omitted, or other actions added.

Claims

1. In the method performed by the first device, A step of transmitting a first message to a second device, the message including first digital asset statement information and signature information of the first device; A step of receiving a second message from the second device, the message including second digital asset specification information and signature information of the second device; A step of verifying a digital asset based on the information of the second digital asset specification above and verifying the second device based on the signature information of the second device; and Based on the verification result of the digital asset and the verification result of the second device, the method includes the step of transmitting a third message containing the second digital asset specification information to a service provider server. A method in which the third message above includes information for the attestation of a service provider certificate entity of the second device.

2. In Claim 1, A method comprising information for proving a service provider authentication entity of the second device, the service provider authentication entity identifier of the second device or signature information of the service provider authentication entity of the second device.

3. In Claim 1, A method in which the first message above includes information for proving a service provider authentication entity of the first device.

4. In Claim 3, A method comprising information for proving a service provider authentication entity of the first device, the service provider authentication entity identifier of the first device or signature information of the service provider authentication entity of the first device.

5. In Claim 1, A method comprising at least one of the first digital asset specification information or the second digital asset specification information, the information regarding the digital asset, the information regarding the start time of use of the digital asset, the information regarding the end time of use of the digital asset, or the information indicating whether authentication is required when using the digital asset.

6. In Claim 5, A method comprising at least one of information regarding the digital asset, information regarding the name of the digital asset, information regarding the quantity of the digital asset, information regarding the unit of the digital asset, or information regarding the description of the digital asset.

7. In Claim 1, A method further comprising the step of transmitting a fifth message containing the second digital asset specification information to the second device when the fourth message received from the service provider server indicates that the service provider server has succeeded in verifying information for proving the service provider authentication entity of the second device.

8. In the method performed by the second device, A step of receiving a first message from the first device including first digital asset statement information and signature information of the first device; A step of verifying a digital asset based on the first digital asset specification information and verifying the first device based on the signature information of the first device; Based on the verification result of the digital asset and the verification result of the first device, the step of transmitting a second message including the first digital asset specification information to a service provider server, wherein the second message includes information for the attestation of the service provider certificate entity of the first device; and A method comprising the step of transmitting a fourth message to the first device, the fourth message including second digital asset specification information and signature information of the second device, when the third message received from the service provider server indicates that the service provider server has succeeded in verifying information for proving the service provider authentication entity of the first device.

9. In Claim 8, A method comprising information for proving a service provider authentication entity of the first device, the service provider authentication entity identifier of the first device or signature information of the service provider authentication entity of the first device.

10. In Claim 8, A method in which the above-mentioned fourth message includes information for proving the service provider authentication entity of the above-mentioned second device.

11. In Claim 10, A method comprising information for proving a service provider authentication entity of the second device, the service provider authentication entity identifier of the second device or signature information of the service provider authentication entity of the second device.

12. In claim 8, A method comprising at least one of the first digital asset specification information or the second digital asset specification information, the information regarding the digital asset, the information regarding the start time of use of the digital asset, the information regarding the end time of use of the digital asset, or the information indicating whether authentication is required when using the digital asset.

13. In Claim 12, A method comprising at least one of information regarding the digital asset, information regarding the name of the digital asset, information regarding the quantity of the digital asset, information regarding the unit of the digital asset, or information regarding the description of the digital asset.

14. In the first device, Memory containing a program or at least one instruction; and It includes at least one processor connected to the memory and configured to execute the program or at least one instruction so that the first device performs an operation, wherein the operation is, Transmitting a first message to a second device that includes first digital asset statement information and signature information of the first device; Receiving a second message from the second device that includes second digital asset specification information and signature information of the second device; Identifying a digital asset based on the information of the second digital asset specification above and verifying the second device based on the signature information of the second device above; and Based on the verification result of the digital asset and the verification result of the second device, the method includes transmitting a third message containing the second digital asset specification information to a service provider server, The first device, wherein the third message above includes information for the attestation of a service provider certificate entity of the second device.

15. In the second device, Memory containing a program or at least one instruction; and It includes at least one processor connected to the memory and configured to execute the program or at least one instruction so that the second device performs an operation, wherein the operation is Receiving a first message from the first device that includes first digital asset statement information and signature information of the first device; Identifying a digital asset based on the first digital asset specification information and verifying the first device based on the signature information of the first device; Based on the verification result of the digital asset and the verification result of the first device, transmitting a second message including the first digital asset specification information to a service provider server, wherein the second message includes information for the attestation of the service provider certificate entity of the first device; and A second device comprising, when a third message received from the service provider server indicates that the service provider server has succeeded in verifying information for proving the service provider authentication entity of the first device, transmitting a fourth message including second digital asset specification information and signature information of the second device to the first device.

Images