Electronic device for managing security token on blockchain and method of managing security token using the same

Abstract

According to the embodiments of the present disclosure An electronic device for managing token securities on a blockchain may include a memory for storing at least one instruction and at least one processor for executing said at least one instruction. The at least one processor may issue token securities for wages on a Consortium Chain based on TR data and, upon the expiration of said token securities on the maturity date, settle said token securities based on whether the owner of said token securities has changed.

Description

Technology Field

[0001] The embodiments disclosed in this document relate to technology for managing token securities on a blockchain, and more specifically, to an electronic device for creating, transferring, and settling token securities based on underlying transactions on a blockchain, and a method for managing token securities using the same. Background Technology

[0002] Gig work refers to a form of labor in which companies hire personnel on short-term contract or temporary basis as needed and pay them accordingly.

[0003] Gig work can be provided based on online platforms and is expanding into various fields of work, including delivery, designated driver services, and quick service, as well as restaurant assistant and serving, caregiving and hospice care, cleaning, and security services.

[0004] With the expansion of gig work and the development of on-demand platforms that provide personalized services based on digital technology, the gig economy is growing rapidly, but there is no wage payment system suitable for the gig economy.

[0005] In particular, freelancers are business owners but workers rather than employers, and are typical workers of the gig economy; however, because they are not employed by a specific company or workplace, they are not currently recognized as workers in society and the financial sector as a whole.

[0006] Therefore, in order to use financial services such as loans and card issuance in the gig economy, a flexible payment method is required instead of the existing fixed-income payment method. The problem to be solved

[0007] One objective of the present invention is to provide a device and method for securing liquidity for wage payments and guaranteeing the safety of token securities by issuing token securities on a blockchain based on the performance of work by workers and the payment of wages by employers.

[0008] Another objective of the present invention is to provide an apparatus and method that increase accessibility to token securities and convenience of managing token securities on a blockchain by creating, transferring, and settling token securities on a consortium chain connected to at least one service on a blockchain.

[0009] However, the problem that the present invention aims to solve is not limited to the problem mentioned above, and may be expanded in various ways without departing from the spirit and scope of the present invention. means of solving the problem

[0010] According to the embodiments of the present disclosure An electronic device for managing token securities on a blockchain may include a memory for storing at least one instruction and at least one processor for executing said at least one instruction. The at least one processor may issue token securities for wages on a Consortium Chain based on TR data and, upon the expiration of said token securities on the maturity date, settle said token securities based on whether the owner of said token securities has changed.

[0011] In one embodiment, the consortium chain may be connected to at least one user service through a bridge. The consortium chain may receive TR data from the at least one user service, issue the token security based on the TR data, and manage the token security based on the issuance conditions of the token security.

[0012] In one embodiment, the TR data may include at least one of a work performance status (State), work performance date (Date), total working time (Total time), work evaluation (Feedback), basic salary (Income), and additional salary (Extra bonus) generated based on the work history performed by the worker.

[0013] In one embodiment, the consortium chain may include at least one of a DATA ID smart contract that records and manages the DATA ID, a payment smart contract that pays the wages, a validation smart contract that validates the validity of transaction data, a token security smart contract that issues the token security, and a marketplace smart contract that brokers the buying and selling of the token security.

[0014] In one embodiment, the at least one processor receives a request to issue a token security from a user, verifies the validity of the underlying transaction of the token security using the validation smart contract, sets the issuance conditions for the token security, and issues the token security using the token security smart contract.

[0015] In one embodiment, the token security may include at least one of a monetary security for claiming money and a capital security for claiming capital gains. The monetary security may include at least one of a bill and a check. The capital security may include at least one of a debt security and an equity security.

[0016] In one embodiment, the issuance conditions of the token security may include at least one of worker information, employer information, issuer information, owner information, maturity date, settlement amount, currency information, description, and settlement status.

[0017] In one embodiment, the at least one processor determines whether the owner of the token security has changed, and if the owner of the token security has not changed, determines whether there is a request for advance payment based on the token security.

[0018] In one embodiment, the at least one processor may pay the settlement amount as a DC to the worker who performed the underlying transaction on the settlement date of the token security if there is no advance payment request based on the token security.

[0019] In one embodiment, the at least one processor may pay the settlement amount as an EWA DC to the worker who performed the underlying transaction on the advance payment date according to the advance payment request when there is an advance payment request based on the token security.

[0020] In one embodiment, the at least one processor determines whether the owner of the token security has changed, and if the owner of the token security has changed, it may pay the settlement amount as DC to the current owner of the token security on the settlement date of the token security.

[0021] A method for managing token securities on a blockchain according to embodiments of the present disclosure may include the operation of issuing token securities for wages on a Consortium Chain based on TR data, and the operation of settling said token securities based on whether the owner of said token securities has changed upon the expiration of said token securities' maturity date.

[0022] In one embodiment, the consortium chain may be connected to at least one user service through a bridge. The consortium chain may receive TR data from the at least one user service, issue the token security based on the TR data, and manage the token security based on the issuance conditions of the token security.

[0023] In one embodiment, the TR data may include at least one of a work performance status (State), work performance date (Date), total working time (Total time), work evaluation (Feedback), basic salary (Income), and additional salary (Extra bonus) generated based on the work history performed by the worker.

[0024] In one embodiment, the consortium chain may include at least one of a DATA ID smart contract that records and manages the DATA ID, a payment smart contract that pays the wages, a validation smart contract that validates the validity of transaction data, a token security smart contract that issues the token security, and a marketplace smart contract that brokers the buying and selling of the token security.

[0025] In one embodiment, the operation of issuing the token security may include receiving a request to issue the token security from a user, verifying the validity of the underlying transaction of the token security with the validity verification smart contract, setting the issuance conditions of the token security, and issuing the token security with the token security smart contract.

[0026] In one embodiment, the token security may include at least one of a monetary security for claiming money and a capital security for claiming capital gains. The monetary security may include at least one of a bill and a check. The capital security may include at least one of a debt security and an equity security.

[0027] In one embodiment, the issuance conditions of the token security may include at least one of worker information, employer information, issuer information, owner information, maturity date, settlement amount, currency information, description, and settlement status.

[0028] In one embodiment, the operation of settling the token security may include an operation of determining whether the owner of the token security has changed, and, if the owner of the token security has not changed, an operation of determining whether there is a request for advance payment based on the token security.

[0029] In one embodiment, the operation of settling the token security may pay the settlement amount as a DC to the worker who performed the underlying transaction on the settlement date of the token security when there is no prior payment request based on the token security.

[0030] In one embodiment, the operation of settling the token security may, when there is a request for advance payment based on the token security, pay the settlement amount as an EWA DC to the worker who performed the underlying transaction on the advance payment date according to the advance payment request.

[0031] In one embodiment, the operation of settling the token security may include an operation of determining whether the owner of the token security has changed, and, if the owner of the token security has changed, an operation of paying the settlement amount as a DC to the current owner of the token security on the settlement date of the token security. Effects of the invention

[0032] The electronic device for managing token securities and the method for managing token securities according to the various embodiments disclosed in this document can secure liquidity for wage payments in the gig economy and guarantee the safety of token securities by issuing token securities based on the performance of work by workers and the payment of wages by employers on a blockchain.

[0033] In addition, the electronic device for managing token securities and the method for managing token securities according to the various embodiments disclosed in this document can increase accessibility to token securities and convenience of managing token securities on the blockchain by creating, transferring, and settling token securities on a consortium chain connected to at least one service on the blockchain.

[0034] The effects obtainable from the exemplary embodiments of the present disclosure are not limited to those mentioned above, and other unmentioned effects can be clearly derived and understood by those skilled in the art to which the exemplary embodiments of the present disclosure belong from the description below. That is, unintended effects resulting from the implementation of the exemplary embodiments of the present disclosure can also be derived by those skilled in the art from the exemplary embodiments of the present disclosure. Brief explanation of the drawing

[0035] FIG. 1 illustrates the configuration of a blockchain platform according to one embodiment. FIG. 2 illustrates a block configuration of an electronic device according to one embodiment. FIG. 3 illustrates a smart contract of a consortium chain according to one embodiment. FIG. 4 illustrates a wage payment operation flow based on TR data according to one embodiment. FIG. 5 illustrates the operation flow of issuing token securities according to one embodiment. FIG. 6 illustrates the types of token securities according to one embodiment. FIG. 7 illustrates data included in a token security according to one embodiment. FIG. 8 illustrates the operation flow for settling token securities according to one embodiment. FIG. 9 illustrates a first settlement method of token securities according to one embodiment. FIG. 10 illustrates a second settlement method of token securities according to one embodiment. FIG. 11 illustrates a third settlement method of token securities according to one embodiment. In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Specific details for implementing the invention

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

[0037] FIG. 1 illustrates the configuration of a blockchain platform according to one embodiment, and FIG. 2 illustrates the block configuration of an electronic device according to one embodiment.

[0038] Referring to FIGS. 1 and 2, the blockchain platform (10) of the present disclosure may include a consortium chain (11) and at least one service (12, 13) connected to the consortium chain (11) through a bridge (e.g., Bridge1, Bridge2) to share transaction data between heterogeneous services on the blockchain. For example, at least one service (12, 13) can efficiently share transaction data with the consortium chain (11) by being connected to the consortium chain (11) through a bridge on the blockchain. For example, at least one service (e.g., provider service (12)) can efficiently share transaction data with at least one other service (e.g., requester service (13)) by being connected to the consortium chain (11) through a bridge on the blockchain.

[0039] The consortium chain (11) may be a blockchain tier including at least one consortium node. The consortium chain (11) may mediate the sharing of transaction data between at least one service (12, 13) by being connected to at least one service (12, 13) through a bridge. For example, the consortium chain (11) may verify transaction data received from at least one service (12, 13) and create a new consortium node based on said transaction data.

[0040] A consortium chain (11) may be a permitted blockchain layer for sending and receiving transaction data of at least one service (12, 13). At least one service (12, 13) may request a lookup of a consortium node of the consortium chain (11). At least one service (12, 13) may request a record of a consortium node of the consortium chain (11). For example, the consortium chain (11) may receive authentication data from at least one service (12, 13). The consortium chain (11) may record authentication data to a consortium node. For example, the consortium chain (11) may receive a request for an authentication data lookup from at least one service (12, 13) and send an authentication data lookup response to at least one service.

[0041] A bridge may be a data exchange system (e.g., a data transmission protocol) that transmits transaction data received from at least one service (12, 13) to a consortium chain (11). For example, at least one service (12, 13) and a consortium chain (11) may transmit and receive transaction data by being interconnected through at least one bridge.

[0042] In one embodiment, at least one service (12, 13) may lock transaction data and transmit the locked transaction data to a bridge. The bridge may transmit the transaction data received from at least one service (12, 13) to a consortium chain (11). The consortium chain (11) may receive the locked transaction data through the bridge and unlock the locked transaction data.

[0043] In one embodiment, the consortium chain (11) may lock transaction data and transmit the locked transaction data to a bridge. The bridge may transmit the transaction data received from the consortium chain (11) to at least one service (12, 13). At least one service (12, 13) may receive the locked transaction data through the bridge and unlock the locked transaction data.

[0044] At least one service (12, 13) may include an off-chain layer including at least one processor and an on-chain layer including said at least one block node. For example, the on-chain layer may be a private blockchain layer for recording DATA ID. At least one service (12, 13) may generate transaction data based on input data received from an external source (e.g., a user) and store transaction data. For example, said off-chain layer may generate said transaction data based on input data. For example, said on-chain layer may record said transaction data on said at least one block node.

[0045] As shown in FIG. 2, the off-chain layer can be implemented as an electronic device (200). The electronic device (200) may include a memory (210), a processor (220), and a communication unit (230). For example, the electronic device (200) can transmit transaction data generated in the off-chain layer to the on-chain layer and manage said transaction data on the on-chain layer. For example, the on-chain layer may include at least one block node for recording said transaction data. For example, the on-chain layer may include a smart contract for managing said transaction data.

[0046] Meanwhile, the configuration illustrated in FIG. 2 illustrates a configuration for describing an embodiment according to the present disclosure, and other configurations for performing functions of the electronic device (200) and the on-chain layer may be added in addition to the illustrated configuration, and the illustrated configurations may be omitted. For example, the electronic device (200) may be a transaction data generation server. For example, the electronic device (200) may be a personal information server.

[0047] In one embodiment, the memory (210) is a storage medium used by the electronic device (200) and can store data such as at least one instruction or setting information corresponding to at least one program. The program may include an operating system (OS) program and various application programs.

[0048] In one embodiment, the memory (210) may include at least one type of 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.), RAM (random access memory, RAM), SRAM (static random access memory), ROM (read only memory, ROM), EEPROM (electrically erasable programmable ROM), PROM (programmable ROM), magnetic memory, a magnetic disk, and an optical disk.

[0049] A communication unit (230) according to one embodiment can perform direct (e.g., wired) communication between an electronic device (200) and at least one external device (e.g., client device (not shown), IAM server (not shown), billing server (not shown), cloud server (not shown), IPFS (not shown)). For example, the communication unit (230) can receive input data transmitted from a client device. Additionally, for example, the communication unit (230) can transmit unique NFT attribute values ​​of the generated NFT to a cloud server (not shown) and IPFS (not shown).

[0050] In one embodiment, the communication unit (230) may include a wireless communication unit (e.g., a cellular communication module, a short-range wireless communication module, or a GNSS (global navigation satellite system) communication module) or a wired communication unit. The corresponding communication unit among these may communicate with at least one external device (e.g., a client device, an IAM server, a billing server, a cloud server, an IPFS) through a network (e.g., a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a wide-area communication network such as a computer network (e.g., a LAN or WAN).

[0051] In one embodiment, the communication unit (230) may support a 5G network following a 4G network and next-generation communication technology, for example, new radio access technology. The NR access technology may support high-speed transmission of high-capacity data (enhanced mobile broadband (eMBB)), minimization of terminal power and connection of multiple terminals (massive machine type communications (mMTC)), or high reliability and low latency (ultra-reliable and low-latency communications (URLLC)). The communication unit (230) may support a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate, for example. The communication unit (230) can support various technologies for securing performance in the high-frequency band, such as beamforming, massive MIMO (multiple-input and multiple-output), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna.

[0052] In one embodiment, the communication unit (230) can support various requirements defined in the electronic device (200), at least one external device (e.g., client device (not shown), IAM server (not shown), billing server (not shown), cloud server (not shown), IPFS (not shown)) or network system.

[0053] In one embodiment, the processor (220) can execute software (e.g., a program) to control at least one other component (e.g., a hardware or software component) of the electronic device (200) connected to the processor (220) and can perform various data processing or operations.

[0054] In one embodiment, the processor (220) may store commands or data received from another component (e.g., communication unit (230)) in volatile memory as at least part of data processing or computation, process the commands or data stored in volatile memory, and store the result data in non-volatile memory.

[0055] In one embodiment, the processor (220) may include a main processor (e.g., a central processing unit or an application processor) or an auxiliary processor that can be operated independently or together with it (e.g., a graphics processing unit, a neural processing unit (NPU), or a communication processor).

[0056] In one embodiment, the processor (220) can generate transaction data based on input data and transmit the transaction data to the consortium chain. For example, the processor (220) can generate TR data containing information about work performed by a worker based on a work specification received from a worker. For example, the processor (220) can record the TR data on the on-chain layer and transmit the TR data to the consortium chain based on a request from the consortium chain. The processor (220) can query the transaction data recorded on the consortium node on the consortium chain. For example, the processor (220) can access the TR data recorded on the consortium node based on a request from an employer and query the information about work performed by a worker included in the TR data. The processor (220) can request the execution of at least one smart contract on the consortium chain. For example, the processor (220) may request the consortium chain to execute at least one of the DATA ID smart contract, payment smart contract, validation smart contract, token security smart contract, and marketplace smart contract.

[0057] In one embodiment, the processor (220) issues a token security for wages on a consortium chain based on TR data, and at the expiration date of the token security, may settle the token security based on whether the owner of the token security has changed.

[0058] As shown in FIG. 2, the on-chain layer may be a blockchain layer that operates in conjunction with the off-chain layer. For example, the on-chain layer may be a decentralized network including smart contracts and multiple block nodes.

[0059] In one embodiment, the electronic device (200) may be configured to support a user's access to an on-chain layer smart contract and a specific node. For example, the electronic device (200) may act as an intermediary for connection to a node by transmitting a front-end code to the user. In another example, the electronic device (200) may act as a direct link between the user and the specific node.

[0060] In one embodiment, a smart contract may be an automated program executed on the on-chain layer in the form of a digital contract. For example, the smart contract may be executed upon the fulfillment of certain conditions. For example, the result of the smart contract execution may be permanently recorded on a block node of the on-chain layer.

[0061] In one embodiment, a smart contract can record transaction data received from an off-chain layer on a block node of an on-chain layer. Additionally, the smart contract can generate transaction data on the on-chain layer based on input data. For example, the smart contract can ensure transparency and reliability regarding transaction data by directly generating transaction data or by recording transaction data on a block node.

[0062] In one embodiment, at least one service may include a provider service (12) that provides the transaction data and a requester service (13) that requests the transaction data. For example, the provider service (12) may be a job matching service that generates a DATA ID based on work performance history. For example, the requester service (13) may be a financial service that evaluates a user's financial credit using the DATA ID. The provider service (12) may provide the transaction data to the requester service (13) based on a consortium chain (11). The requester service (13) may verify the validity of the transaction data based on a consortium chain (11).

[0063] Specifically, the provider service (12) can generate main data and authentication data based on the transaction data recorded in at least one block node. The provider service (12) can provide the main data to the requester service (13). The provider service (12) can provide the authentication data to the consortium chain (11). The requester service (13) can verify the validity of the main data based on the authentication data of the consortium chain (11).

[0064] The provider service (12) can generate main data and validation data for transaction data based on the transaction data request from the requester service (13). For example, the total data generated by the provider service (12) may include main data and validation data. The main data may include at least one of a transaction data summary, aggregated data, and raw data. The validation data may include at least one of KYC information, PoE information, and template information.

[0065] The consortium chain (11) can be connected to the provider service (12) through the first bridge (Bridge1). The consortium chain (11) can receive the authentication data from the provider service (12) through the first bridge (Bridge1). The consortium chain (11) can write the authentication data to at least one consortium node.

[0066] The consortium chain (11) can be connected to the requester service (13) through the second bridge (Bridge2). The consortium chain (11) can receive a request for authentication data lookup from the requester service (13) through the second bridge (Bridge2). The consortium chain (11) can send an authentication data lookup response to the requester service (13) based on the authentication data.

[0067] The requester service (13) can verify the validity of the main data received from the provider service (12) based on the authentication data lookup response received from the consortium chain (11). For example, the requester service (13) can verify at least one of the details regarding the user of the main data, details regarding the existence of the main data, and details regarding the transaction data included in the main data.

[0068] In this way, the blockchain platform of the present disclosure can securely share transaction data between heterogeneous services and secure trust among sharers regarding the shared transaction data by verifying main data using authentication data recorded in the consortium chain (11).

[0070] FIG. 3 illustrates a smart contract of a consortium chain (300) according to one embodiment.

[0071] Referring to FIG. 3, the consortium chain (300) may include at least one smart contract. The smart contract may be an automated program executed on the consortium chain (300). For example, the smart contract may be executed upon fulfillment of certain conditions. For example, the result of the execution of the smart contract may be permanently recorded on the consortium node of the consortium chain (300).

[0072] In one embodiment, the consortium chain (300) may include at least one of a DATA ID smart contract (310) that records and manages DATA IDs, a payment smart contract (320) that pays wages, a validation smart contract (330) that validates the validity of transaction data, a token security smart contract (340) that issues token securities, and a marketplace smart contract (350) that brokers the buying and selling of token securities.

[0073] For example, at least one service (e.g., service (12, 13) of FIG. 1) may request the consortium chain (300) to execute at least one of a DATA ID smart contract (310), a payment smart contract (320), a validation smart contract (330), a token security smart contract (340), and a marketplace smart contract (350). The consortium chain (300) may execute at least one smart contract based on the smart contract execution request from at least one service.

[0074] The DATA ID smart contract (310) can manage at least one transaction data. The DATA ID may be a worker’s CV (Curriculum Vitae) generated based on information regarding work. For example, the DATA ID may include at least one of worker personal information (e.g., worker name, worker age, DATA ID authentication means), work performance history (e.g., number of times the worker performed work, worker evaluation grade), and revenue information (e.g., total revenue, monthly average revenue, average hourly wage).

[0075] For example, a DATA ID smart contract (310) can record and manage a DATA ID containing at least one of information about work performed by a worker, TR data, an employment contract, and a worker's resume. For example, the DATA ID smart contract (310) can record the DATA ID on at least one consortium node. For example, the DATA ID smart contract (310) can unlock the DATA ID recorded on the consortium node based on a DATA ID lookup request from at least one service and transmit the DATA ID to at least one service. For example, the DATA ID smart contract (310) can request a validation smart contract (330) to validate the DATA ID.

[0076] The payment smart contract (320) can pay money to at least one service based on transaction data. For example, the payment smart contract (320) can pay wages to a worker based on a DATA ID that includes at least one of information about work performed by the worker, TR data, a labor contract, and the worker's resume.

[0077] For example, the payment smart contract (320) can settle wages agreed upon by the worker and the employer in the employment contract based on TR data. For example, the payment smart contract (320) can request the employer service to deposit the settlement amount. For example, the payment smart contract (320) can transmit the settlement amount to the worker service.

[0078] The validation smart contract (330) can validate the validity of transaction data. For example, the validation smart contract (330) can validate the validity of the DATA ID based on a DATA ID lookup request.

[0079] For example, the validation smart contract (330) can validate the validity of an employment contract based on a wage settlement request. For example, the validation smart contract (330) can validate the validity of TR data based on a request to issue token securities with wages as the underlying transaction.

[0080] The token securities smart contract (340) can manage issued token securities based on transaction data. Specifically, the token securities smart contract (340) can create, transfer, and settle token securities based on transaction data. For example, the token securities smart contract (340) can issue token securities of a predetermined type based on a request for issuance of token securities from at least one service. For example, the token securities smart contract (340) can change the owner of the token securities based on a request to change the owner of the token securities. For example, the token securities smart contract (340) can request the payment smart contract (320) to pay the settlement amount of the token securities based on the issuance conditions of the token securities.

[0081] A marketplace smart contract (350) can mediate transactions of goods or non-goods based on transaction data. For example, the marketplace smart contract (350) can mediate transactions of goods or non-goods including at least one of data, tokens, intangible assets, and tangible assets. For example, the marketplace smart contract (350) can register the sale of said goods or non-goods based on a request to sell said goods or non-goods of at least one service.

[0082] For example, the marketplace smart contract (350) may generate a sales contract for said goods or non-goods based on a purchase request for said goods or non-goods of at least one service. For example, the marketplace smart contract (350) may request the proceeds from the sale of said goods or non-goods of at least one service from the buyer service and transfer the proceeds received from the buyer service to the seller service. The marketplace smart contract (350) may use at least one of DC, EWA DC, tokens, and fiat currency as the proceeds from the sale of said goods or non-goods.

[0084] FIG. 4 illustrates a wage payment operation flow based on TR data according to one embodiment.

[0085] Referring to FIG. 4, the electronic device (200) can convert the work performance history of a worker into data and register it in a blockchain network, and pay wages based on the work performance history. As described in FIG. 2, the electronic device (200) may be an off-chain layer of at least one service.

[0086] According to one example, in operation 410, the electronic device (200) may receive a work statement based on the input of a worker. The work statement may include a record of the worker's work performance. For example, the work statement may include at least one of the type of work performed by the worker, the worker's working hours, and the worker's work allowance.

[0087] According to one example, in operation 420, the electronic device (200) can generate TR data based on the work specification. For example, the electronic device (200) can generate TR data by converting the work performance history included in the work specification into data. The TR data may include information (Task Contract) regarding work performed by an employee at the request of an employer.

[0088] In one embodiment, TR data may include at least one of a work performance status (State), work performance date (Date), total time (Total time), work evaluation (Feedback), basic salary (Income), and additional salary (Extra bonus) generated based on the work history performed by a worker. The TR data may be generated based on TC data.

[0089] TC data may be a type of mutual contract between third parties regarding at least one of goods and non-goods. For example, TC data may be generated for each task performed by a worker. Each TC data may include unique identification information (TC ID). For example, TC data may include at least one of Task Data, Asset Data, and Time Data regarding the work performed by an employee at the request of an employer. For example, TC data may include the type of work performed by the worker, date, time, location, content of the work, and evaluation information regarding the employer.

[0090] For example, TC data can be classified in the form shown in [Table 1] below.

[0092] Category Subcategory example TC data Task Data Task Task information performed by the worker Task information created by the employer Asset Data For sale Digital Content Physical Goods Membership Non-commercial Certification Recipe Formula (e.g., how to make cosmetics) Time Data License Usage rights for recipes / formulas, etc. Course voucher Cooking class voucher

[0094] According to one example, in operation 430, the electronic device (200) can register the TR data to the blockchain network. For example, the electronic device (200) can register TR data corresponding to at least one work specification to at least one block node of the on-chain layer. According to one example, in operation 440, the electronic device (200) can pay wages to a worker account registered in the blockchain network based on the TR data. For example, the electronic device (200) can request wage payment from the consortium chain. The consortium chain can execute a payment smart contract based on the wage payment request from the electronic device (200). For example, the payment smart contract can receive TR data from the DATA ID smart contract. The payment smart contract can request the validation smart contract to validate the TR data. The payment smart contract can calculate the payment timing and amount of wages to be paid to the worker based on the TC data included in the TR data. For example, the payment smart contract can pay at least one of Digital Currency (DC) and fiat currency in response to a wage payment request from at least one of the worker service and the employer service. Based on TR data, the payment smart contract can pay the wages received from the employer service to the worker service on the wage payment date.

[0096] FIG. 5 illustrates the operation flow of issuing token securities according to one embodiment, FIG. 6 illustrates the type of token securities according to one embodiment, and FIG. 7 illustrates the data included in the token securities according to one embodiment.

[0097] Referring to FIGS. 5 through 7, the electronic device can issue token securities for wages on a Consortium Chain based on TR data. For example, the Consortium Chain can be connected to at least one user service through a bridge. As described in FIG. 2, the electronic device may be an off-chain layer of at least one service. The electronic device can record TR data on an on-chain layer. At least one service can transmit TR data from the on-chain layer to the Consortium Chain.

[0098] Specifically, the electronic device may receive a request to issue a token security from a user (operation 510), verify the validity of the underlying transaction of the token security (operation 520), set conditions for issuing the token security (operation 530), and issue the token security (operation 540).

[0099] According to one example, in operation 510, the electronic device may receive a request from a user to issue a token security. The user may request the issuance of the token security based on an underlying transaction that serves as the premise for the token security. For example, the underlying transaction may be a claim for wage payment under an employment contract between an employer and a worker. For example, a worker may request the issuance of a token security for wages to be paid based on TR data. In this case, the token security may be a promissory note with the claim for wage payment as the underlying transaction.

[0100] As shown in FIG. 6, a security token may include at least one of a money security for claiming money and a capital security for claiming capital gains. The money security may include at least one of a promissory note and a bank check. The capital security may include at least one of debt securities and equity securities. However, the security token of FIG. 6 is merely an example, and the security token of the present disclosure may include various forms of securities depending on the underlying transaction and purpose of use, in addition to the security token shown in FIG. 6.

[0101] According to one example, in operation 520, an electronic device can verify the validity of the underlying transaction of a token security. For example, the electronic device can receive information regarding the underlying transaction based on a request to issue a token security. For example, the underlying transaction may be a wage payment claim under an employment contract between an employer and a worker. The electronic device may request the consortium chain to verify the validity of the underlying transaction. The consortium chain may receive the TR data from at least one user service. For example, a validation smart contract can verify the validity of the TR data based on a request to issue a token security with wages as the underlying transaction. For example, the validation smart contract can verify the validity of at least one of the work performance status, work performance date, total working hours, work evaluation, base salary, and additional salary of the TR data.

[0102] According to one example, in operation 530, the electronic device can set the issuance conditions of the token security. For example, the electronic device can set the issuance conditions of the token security based on a request for the issuance of the token security and an underlying transaction. For example, as shown in FIG. 7, the issuance conditions of the token security may include at least one of the information of the parties to the underlying transaction (Employee, Employer) (e.g., employer and worker), issuer information (Issuer), holder information (Holder), maturity date (Maturity Date), value, currency information (Currency), memo, and settlement status (Settlement).

[0103] According to one example, in operation 540, an electronic device may issue a token security. A consortium chain may issue the token security based on the TR data. For example, the electronic device may issue the token security using a token security smart contract of the consortium chain. For example, the token security smart contract may issue a token security of a predetermined type based on the electronic device's request for the issuance of a token security. For example, the token security smart contract may issue a promissory note based on a wage payment receivable as the underlying transaction based on the TR data and the conditions for the issuance of the token security. Additionally, the consortium chain may manage the token security based on the conditions for the issuance of the token security.

[0105] FIG. 8 illustrates the operation flow for settling token securities according to one embodiment.

[0106] Referring to FIG. 8, the electronic device can settle the token security based on whether the owner of the token security has changed upon the expiration of the token security's maturity date.

[0107] The electronic device may determine whether the owner of the said token security has changed (operation 810), and if the owner of the said token security has not changed, determine whether there is a request for advance payment based on the said token security (operation 820). For example, the owner of the token security may change as the owner transfers or sells the token security. For example, the owner of the token security may change as it is sold on a marketplace.

[0108] If the owner of the said token security has not changed, the electronic device may determine whether there is a request for advance payment based on the said token security. Advance payment may refer to a payment method in which the settlement amount of the token security is settled in advance prior to the maturity date of the token security. For example, if there is a request for advance payment, the consortium chain may use a payment smart contract to pay the settlement amount of the token security in advance to the owner of the token security.

[0109] In the event that there is no advance payment request based on the above token securities, the electronic device may pay the settlement amount in DC on the settlement date of the above token securities to the worker who performed the underlying transaction (operation 830). For example, the worker may receive the settlement amount in DC according to the issuance conditions of the token securities when the settlement date arrives, without transferring or selling the token securities.

[0110] The electronic device may pay the settlement amount as an EWA DC on the advance payment date corresponding to the advance payment request to the worker who performed the underlying transaction when there is an advance payment request based on the said token security (Operation 840). For example, the worker may receive the settlement amount as an EWA DC before the settlement date by making an advance payment request without transferring or selling the token security. For example, the EWA DC may be an amount to which an advance payment discount rate is applied to the settlement amount according to the issuance conditions of the token security. For example, the advance payment discount rate for the EWA DC may be higher the earlier the advance payment request date.

[0111] The electronic device determines whether the owner of the said token security has changed (operation 810), and if the owner of the said token security has changed, it may pay the settlement amount to the current owner of the said token security on the settlement date of the said token security as DC (operation 850).

[0112] For example, the ownership of a token security may change as the owner transfers or sells the token security. For example, the ownership of a token security may change as it is sold on a marketplace. In this case, the consortium chain can mediate the sale and purchase of the token security on the marketplace using the marketplace smart contract. If the owner of the token security changes, the token security smart contract of the consortium chain can change the owner information (Holder) in the issuance conditions of the token security. The changed owner information can be recorded on the consortium node.

[0113] The electronic device may pay the settlement amount in DC on the settlement date of said token securities to the current owner who has received ownership by acquiring or purchasing the token securities from an employee or a previous owner. For example, the current owner of the token securities may receive the settlement amount in DC according to the issuance conditions of the token securities upon the arrival of the settlement date without transferring or selling the token securities. Alternatively, the current owner of the token securities may transfer or sell the token securities again.

[0115] FIG. 9 illustrates a first settlement method of token securities according to one embodiment.

[0116] Referring to Fig. 9, the worker can receive the settlement amount according to the issuance conditions of the token securities as a DC when the settlement date arrives, without transferring or selling the token securities.

[0117] Specifically, when the token security smart contract of the consortium chain issues token securities, the worker can wait until the settlement date according to the token issuance conditions. The electronic device can check the payment status of the token securities using the token security smart contract.

[0118] The Token Securities smart contract can periodically check whether the settlement date of the Token Securities has expired. When the settlement date arrives in accordance with the Token Securities issuance conditions, the Token Securities smart contract can request the payment of the settlement amount from the Payment smart contract.

[0119] The payment smart contract can pay a DC equivalent to the settlement amount to the worker based on the conditions for the issuance of token securities.

[0121] FIG. 10 illustrates a second settlement method of token securities according to one embodiment.

[0122] Referring to Fig. 10, the worker can receive the settlement amount as EWA DC before the settlement date by requesting advance payment without transferring or selling the token securities.

[0123] Specifically, when the consortium chain's token security smart contract issues token securities, the worker may request an advance payment. If an advance payment request is made, the consortium chain may use a payment smart contract to pay the settlement amount of the token security to the holder of the token security in advance. For example, by requesting an advance payment, the worker may receive the settlement amount in EWA DC before the settlement date. For example, EWA DC may be an amount to which an advance payment discount rate is applied to the settlement amount according to the token security issuance conditions.

[0124] For example, an electronic device may request the minting of EWA DCs to the payment smart contract of the consortium chain. Based on the conditions for the issuance of token securities, the payment smart contract may pay EWA DCs to the worker, to which an advance payment discount rate is applied to the settlement amount. For example, the said advance payment discount rate may be calculated higher the earlier the advance payment date. For example, the payment smart contract may pay EWA DCs to the worker that are discounted more from the settlement amount the earlier the advance payment date. For example, the said advance payment discount rate may be prorated based on the advance payment date.

[0126] FIG. 11 illustrates a third settlement method of token securities according to one embodiment.

[0127] Referring to Fig. 11, the worker can earn sales revenue by transferring or selling the token securities. Here, when the settlement date of the token securities arrives, the buyer of the token securities can receive the settlement amount according to the issuance conditions of the token securities as a DC.

[0128] Specifically, when the consortium chain's token securities smart contract issues token securities, the worker can transfer or sell the token securities. For example, the worker can sell the token securities on a marketplace. In this case, the consortium chain can use the marketplace smart contract to mediate the sale and purchase of token securities on the marketplace.

[0129] A worker may request the sale of token securities on an electronic device. The electronic device may register the sale of token securities on a marketplace (e.g., a token securities trading brokerage platform) using a marketplace smart contract. The marketplace smart contract may sell token securities to a buyer.

[0130] For example, the marketplace may be at least one service connected to the consortium chain through a bridge. The marketplace may receive at least one of the sell request and the buy request from the consortium chain through the bridge. Based on the sell request, the marketplace may launch a selling offer for the token security. Based on the buy request, the marketplace may request the consortium chain to create the buy / sell contract.

[0131] The marketplace smart contract can create a trading contract based on sell requests and buy requests. Based on the execution of the trading contract, the marketplace smart contract can request the token security smart contract to change the owner.

[0132] The Token Securities smart contract can change the owner to the buyer based on the issuance conditions of the Token Securities. The Token Securities smart contract can periodically check whether the settlement date of the Token Securities has expired. When the settlement date arrives according to the issuance conditions of the Token Securities, the Token Securities smart contract can request the payment of the settlement amount from the Payment smart contract.

[0133] The payment smart contract can pay the buyer a DC equivalent to the settlement amount based on the conditions of the token security issuance.

[0134] In this way, the electronic device for managing token securities and the method for managing token securities disclosed in the present disclosure can secure liquidity for wage payments in the gig economy and guarantee the safety of token securities by issuing token securities based on the performance of work by workers and the payment of wages by employers on a blockchain.

[0135] In addition, the electronic device for managing token securities and the method for managing token securities of the present disclosure can increase accessibility to token securities and convenience of managing token securities on the blockchain by creating, transferring, and settling token securities on a consortium chain connected to at least one service on the blockchain.

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

[0137] The various embodiments of this document and the terms used therein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various modifications, equivalents, or substitutions of said embodiments. For example, a component expressed in the singular should be understood as a concept including a plural component unless the context clearly implies only the singular. It should be understood that the term "and / or" as used in this document encompasses any possible combination of one or more of the listed items. Terms such as "comprising," "having," and "consisting of" used in this disclosure are intended merely to indicate the existence of the features, components, parts, or combinations thereof described in this disclosure, and the use of such terms is not intended to exclude the existence or addition of one or more other features, components, parts, or combinations thereof. In this document, each of the phrases such as “A or B,” “at least one of A and B,” “at least one of A or B,” “A, B or C,” “at least one of A, B and C,” and “at least one of A, B, or C” may include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as “first,” “second,” or “first” or “second” may be used simply to distinguish a component from another component and do not limit the components in any other aspect (e.g., importance or order).

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

[0139] In the various embodiments of this document, the term “in the case of” as used may be interpreted, depending on the context, to mean “when,” “at the time of,” or “in response to a decision,” or “in response to a detection.” Similarly, “in the case where it is determined,” or “in the case where it is detected,” may be interpreted, depending on the context, to mean “at the time of determination,” or “in response to a decision,” or “at the time of detection,” or “in response to a detection.”

[0140] A program executed by an electronic device described in this document may be implemented by hardware components, software components, and / or a combination of hardware and software components. The program may be executed by any system capable of executing computer-readable instructions.

[0141] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or command the processing unit independently or collectively. Software may be implemented as a computer program containing instructions stored on computer-readable storage media. Examples of computer-readable storage media include magnetic storage media (e.g., ROM (Read-Only Memory), RAM (Random-Access Memory), floppy disks, hard disks, etc.) and optical reading media (e.g., CD-ROMs, DVDs (Digital Versatile Discs)). Computer-readable storage media may be distributed across networked computer systems, allowing computer-readable code to be stored and executed in a distributed manner. Computer programs may be distributed online (e.g., download or upload) via an application store (e.g., Play Store™) or directly between two worker devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

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

Claims

Claim 1 An electronic device for managing token securities on a blockchain, comprising: a memory for storing at least one instruction; and at least one processor for executing said at least one instruction, wherein the at least one processor issues token securities for wages on a Consortium Chain based on TR data, and settles said token securities based on whether the owner of said token securities has changed upon the expiration of the maturity date of said token securities. Claim 2 An electronic device according to claim 1, wherein the consortium chain is connected to at least one user service through a bridge, receives TR data from the at least one user service, issues the token security based on the TR data, and manages the token security based on the issuance conditions of the token security. Claim 3 An electronic device according to claim 1, wherein the TR data comprises at least one of a work performance status (State), work performance date (Date), total time, work evaluation (Feedback), basic salary (Income), and additional salary (Extra bonus) generated based on the work history performed by the worker. Claim 4 An electronic device according to claim 1, wherein the consortium chain comprises at least one of a DATA ID smart contract for recording and managing the DATA ID, a payment smart contract for paying the wages, a validation smart contract for verifying the validity of transaction data, a token security smart contract for issuing the token security, and a marketplace smart contract for brokering the buying and selling of the token security. Claim 5 An electronic device according to claim 4, wherein at least one processor receives a request to issue a token security from a user, verifies the validity of the underlying transaction of the token security using the validity verification smart contract, sets the issuance conditions of the token security, and issues the token security using the token security smart contract. Claim 6 An electronic device according to paragraph 4, wherein the token security comprises at least one of a monetary security for claiming money and a capital security for claiming capital gains, wherein the monetary security comprises at least one of a bill and a check, and the capital security comprises at least one of a debt security and an equity security. Claim 7 In paragraph 4, the issuance conditions of the above token security include at least one of worker information, employer information, issuer information, owner information, maturity date, settlement amount, currency information, description, and settlement status, an electronic device. Claim 8 An electronic device according to claim 1, wherein at least one processor determines whether the owner of the token security has changed, and if the owner of the token security has not changed, determines whether there is a request for advance payment based on the token security. Claim 9 In paragraph 8, the above-mentioned at least one processor is an electronic device that pays a settlement amount in DC on the settlement date of the said token security to the worker who performed the underlying transaction in the event that there is no advance payment request based on the said token security. Claim 10 In paragraph 8, the above-mentioned at least one processor is an electronic device that, in the event of an advance payment request based on the above-mentioned token security, pays the settlement amount as an EWA DC on the advance payment date according to the advance payment request to the worker who performed the underlying transaction. Claim 11 An electronic device according to claim 1, wherein at least one processor determines whether the owner of the token security has changed, and if the owner of the token security has changed, pays the current owner of the token security a settlement amount in DC on the settlement date of the token security. Claim 12 A method for managing token securities on a blockchain, comprising: an operation of issuing token securities for wages on a Consortium Chain based on TR data; and an operation of settling said token securities based on whether the owner of said token securities has changed upon the expiration of said token securities' maturity date. Claim 13 A method for managing token securities according to claim 12, wherein the consortium chain is connected to at least one user service through a bridge, receives TR data from the at least one user service, issues the token securities based on the TR data, and manages the token securities based on the issuance conditions of the token securities. Claim 14 A method for managing token securities according to claim 12, wherein the TR data comprises at least one of a work performance status (State), work performance date (Date), total working time (Total time), work evaluation (Feedback), basic salary (Income), and additional salary (Extra bonus) generated based on the work history performed by the worker. Claim 15 In claim 12, the consortium chain comprises at least one of a DATA ID smart contract for recording and managing the DATA ID, a payment smart contract for paying wages, a validation smart contract for verifying the validity of transaction data, a token security smart contract for issuing the token security, and a marketplace smart contract for brokering the buying and selling of the token security, a method for managing token securities. Claim 16 A method for managing token securities according to claim 15, wherein the operation of issuing the token securities comprises: receiving a request to issue token securities from a user; verifying the validity of the underlying transaction of the token securities using the validity verification smart contract; setting the issuance conditions of the token securities; and issuing the token securities using the token securities smart contract. Claim 17 A method for managing token securities according to claim 15, wherein the token securities comprise at least one of a monetary security for claiming money and a capital security for claiming capital gains, wherein the monetary security comprises at least one of a bill and a check, and the capital security comprises at least one of a debt security and an equity security. Claim 18 In paragraph 15, the issuance conditions of the above token securities include at least one of worker information, employer information, issuer information, owner information, maturity date, settlement amount, currency information, description, and settlement status, a method for managing token securities. Claim 19 A method for managing token securities according to claim 12, wherein the operation of settling the token securities comprises: an operation of determining whether the owner of the token securities has changed; and, if the owner of the token securities has not changed, an operation of determining whether there is a request for advance payment based on the token securities. Claim 20 In paragraph 19, the operation of settling the above token securities is a method of managing token securities, wherein, in the absence of a request for advance payment based on the above token securities, the settlement amount is paid as a DC to the worker who performed the underlying transaction on the settlement date of the above token securities. Claim 21 In paragraph 19, the operation of settling the above token securities is a method of managing token securities, wherein, in the event of an advance payment request based on the above token securities, the settlement amount is paid as an EWA DC to the worker who performed the underlying transaction on the advance payment date according to the advance payment request. Claim 22 A method for managing token securities according to claim 12, wherein the operation of settling the token securities comprises: an operation of determining whether the owner of the token securities has changed; and, if the owner of the token securities has changed, an operation of paying the settlement amount as a DC to the current owner of the token securities on the settlement date of the token securities.

Images