Blockchain platform for brokering transaction of security token and method of brokering transaction of security token using the same

Abstract

A blockchain platform for mediating the trading of token securities according to one embodiment of the present disclosure may include a consortium chain, at least one user service connected to the consortium chain through a bridge, and a marketplace connected to the consortium chain through the bridge. The consortium chain may issue token securities, register the token securities for sale on the marketplace based on a sale request from the owner of the token securities, create a sales contract for the token securities based on a purchase request from a buyer, transmit the DC deposited by the buyer to the owner of the token securities, and change the owner information of the token securities.

Description

Technology Field

[0001] The embodiments disclosed in this document relate to technology for mediating the trading of token securities, and more specifically, to a blockchain platform for mediating the sale and purchase of token securities for workers' wages on a blockchain and a method for mediating the trading of token securities using the same. Background Technology

[0002] Recently, digital assets such as cryptocurrencies have emerged as it has become possible to implement a distributed ledger that enables trust between participants without intermediaries and is impossible to tamper with, by utilizing blockchain technology.

[0003] As the number of investors interested in investing in security tokens—which are tokenized digital assets—increases, P2P (Peer-to-Peer) investment targeting security tokens is gaining attention as one of the new investment trends.

[0004] Meanwhile, token securities can be created based on various underlying transactions. For instance, token securities can be assets that guarantee the payment of wages, with workers' wage claims serving as the underlying transaction. For instance, in the gig economy, where companies hire and pay workers on short-term or temporary contracts as needed, token securities can provide a flexible method of wage payment rather than the traditional fixed-income payment method for workers' labor.

[0005] Therefore, there is a need for a token securities trading platform and a token securities trading method that can incorporate various digital assets into the institutional framework, remove technical entry barriers for general investors, and guarantee transparency in digital asset trading. The problem to be solved

[0006] One objective of the present invention is to provide a token securities trading platform and a token securities trading method that can incorporate various digital assets into the institutional framework, remove technical entry barriers for general investors, and guarantee transparency in digital asset trading.

[0007] Another objective of the present invention is to provide a blockchain platform that ensures gig workers can access various financial services by providing a wage payment system suitable for gig workers in the gig economy and increasing the liquidity of gig workers' wage claims.

[0008] 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

[0009] A blockchain platform for mediating the trading of token securities according to embodiments of the present disclosure may include a consortium chain, at least one user service connected to the consortium chain through a bridge, and a marketplace connected to the consortium chain through the bridge. The consortium chain may issue token securities, register the token securities for sale on the marketplace based on a sale request from the owner of the token securities, create a sales contract for the token securities based on a purchase request from a buyer, transmit the DC deposited by the buyer to the owner of the token securities, and change the owner information of the token securities.

[0010] 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.

[0011] In one embodiment, the at least one user service may include an owner service that transmits the owner's sales request to the consortium chain through a first bridge, and a buyer service that transmits the buyer's purchase request to the consortium chain through a second bridge.

[0012] In one embodiment, the marketplace receives at least one of the sale request and the purchase request from the consortium chain through a third bridge, and based on the sale request, launches a selling offer of the token security, and based on the purchase request, requests the consortium chain to create the sales contract.

[0013] In one embodiment, the consortium chain may include at least one of a DATA ID smart contract that records the TR data, a payment smart contract that pays the settlement amount of the token security, a validation smart contract that verifies the validity of the data, a token security smart contract that issues the token security, and a marketplace smart contract that brokers the trading of the token security.

[0014] In one embodiment, the marketplace smart contract may calculate a minimum discount rate of the token security based on the trading records of the owner of the token security, determine a sales discount rate based on the owner's sales request and the minimum discount rate, and determine the sales price of the token security by applying the sales discount rate to the settlement amount of the token security.

[0015] In one embodiment, the trading record of the owner may include at least one of the owner's DATA ID, TR data of the underlying transaction, and the owner's transaction score.

[0016] In one embodiment, the minimum discount rate may increase as the owner's transaction score is lower and decrease as the owner's transaction score is higher.

[0017] In one embodiment, the marketplace smart contract may determine the higher of the desired discount rate included in the owner's sales request and the minimum discount rate as the sales discount rate.

[0018] In one embodiment, the marketplace smart contract may receive a DC from the buyer that includes the purchase fee added to the sale price of the token security, transmit a DC to the seller that excludes the sale fee from the sale price of the token security, and provide a DC to the marketplace that corresponds to the purchase fee and the sale fee.

[0019] In one embodiment, the token security smart contract periodically checks whether the settlement date of the token security has expired, and if the settlement date according to the issuance conditions of the token security has arrived, it may request the payment smart contract to pay the settlement amount of the token security. The payment smart contract may pay the settlement amount according to the issuance conditions of the token security to the buyer.

[0020] A method for brokering the transaction of a token security on a blockchain according to embodiments of the present disclosure may include the operation of registering the token security for sale on a marketplace based on a sale request from the owner of the token security, the operation of creating a sales contract for the token security based on a purchase request from a buyer, the operation of transmitting the DC deposited by the buyer to the owner of the token security, and the operation of changing the owner information of the token security.

[0021] 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.

[0022] In one embodiment, the consortium chain may receive the owner's sales request from the owner service through a first bridge and receive the buyer's purchase request from the buyer service through a second bridge.

[0023] In one embodiment, the marketplace receives at least one of the sale request and the purchase request from the consortium chain through a third bridge, and based on the sale request, launches a selling offer of the token security, and based on the purchase request, requests the consortium chain to create the sales contract.

[0024] In one embodiment, the consortium chain may include at least one of a DATA ID smart contract that records the TR data, a payment smart contract that pays the settlement amount of the token security, a validation smart contract that verifies the validity of the data, a token security smart contract that issues the token security, and a marketplace smart contract that brokers the trading of the token security.

[0025] In one embodiment, the operation of registering the token security for sale on the marketplace may include the operation of calculating a minimum discount rate of the token security based on the trading records of the owner of the token security, the operation of determining a sales discount rate based on the owner's sales request and the minimum discount rate, and the operation of determining the sales price of the token security by applying the sales discount rate to the settlement amount of the token security.

[0026] In one embodiment, the trading record of the owner may include at least one of the owner's DATA ID, TR data of the underlying transaction, and the owner's transaction score.

[0027] In one embodiment, the minimum discount rate may increase as the owner's transaction score is lower and decrease as the owner's transaction score is higher.

[0028] In one embodiment, the operation of determining the sales discount rate may determine the higher of the desired discount rate included in the owner's sales request and the minimum discount rate as the sales discount rate.

[0029] In one embodiment, the operation of transmitting the DC deposited by the buyer to the owner of the token security may include the operation of receiving the DC from the buyer, which is the sum of the purchase fee and the sale price of the token security; the operation of transmitting the DC to the seller, which is the sale price of the token security minus the sale fee; and the operation of providing the marketplace with the DC corresponding to the purchase fee and the sale fee.

[0030] In one embodiment, the token security smart contract periodically checks whether the settlement date of the token security has expired, and if the settlement date according to the issuance conditions of the token security has arrived, it may request the payment smart contract to pay the settlement amount of the token security. The payment smart contract may pay the settlement amount according to the issuance conditions of the token security to the buyer. Effects of the invention

[0031] The token securities trading platform and token securities trading method according to the various embodiments disclosed in this document can incorporate various digital assets into the institutional framework, remove technical entry barriers for general investors, and ensure transparency in digital asset trading.

[0032] The token securities trading platform and token securities trading method according to the various embodiments disclosed in this document can ensure that gig workers can use various financial services by providing a wage payment system suitable for gig workers in the gig economy and increasing the liquidity of gig workers' wage claims.

[0033] 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

[0034] 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 user service and a marketplace connected to a consortium chain according to one embodiment. FIG. 5 illustrates the operation of a consortium chain according to one embodiment. FIG. 6 illustrates the trading process of token securities according to a single time example. FIG. 7 illustrates data included in a token security according to one embodiment. FIG. 8 illustrates the operation of registering the sale of token securities of a consortium chain according to one embodiment. FIG. 9 illustrates the DC transmission process of a consortium chain according to one embodiment. FIG. 10 illustrates the payment of a settlement amount of a token security 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

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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).

[0049] 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).

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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).

[0055] 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.

[0056] In one embodiment, the processor (220) may use a consortium chain to issue a token security, register the token security for sale on the marketplace based on a sale request from the owner of the token security, create a sales contract for the token security based on a purchase request from a buyer, transfer the Digital Currency (DC) deposited by the buyer to the owner of the token security, and change the owner information of the token security.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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 provider service (12) may be an owner service used by an owner selling token securities. For example, the requester service (13) may be a financial service that evaluates a user's financial credit using the DATA ID. For example, the requester service (13) may be a buyer service used by a buyer purchasing token securities. The provider service (12) may provide the transaction data to the requester service (13) based on the consortium chain (11). The requester service (13) may verify the validity of the transaction data based on the consortium chain (11).

[0062] 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).

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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).

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

[0070] 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).

[0071] 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 the settlement amount of token securities, a validation smart contract (330) that validates the validity of transaction data, a token securities smart contract (340) that issues token securities, and a marketplace smart contract (350) that brokers the buying and selling of token securities.

[0072] 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.

[0073] 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).

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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 token securities based on a seller's request to sell the token securities.

[0081] For example, the marketplace smart contract (350) may create a sales contract for said token security based on a purchase request for said token security. For example, the marketplace smart contract (350) may request the proceeds from the sale of the token security from the buyer service and transfer the proceeds received from the buyer service to the owner service. The marketplace smart contract (350) may use at least one of DC, EWA DC, token, and fiat currency as the proceeds from the sale of the token security.

[0083] FIG. 4 illustrates a user service and a marketplace connected to a consortium chain according to one embodiment, FIG. 5 illustrates the operation of a consortium chain according to one embodiment, FIG. 6 illustrates the trading process of a token security according to one embodiment, and FIG. 7 illustrates data included in a token security according to one embodiment.

[0084] Referring to FIGS. 4 and 5, a blockchain platform for mediating the trading of token securities according to embodiments of the present disclosure may include a consortium chain (41), at least one user service (42, 43) connected to the consortium chain (41) through a bridge, and a marketplace (44) connected to the consortium chain (41) through the bridge.

[0085] The consortium chain (41) may be a blockchain layer including at least one consortium node. The consortium chain (41) may mediate token securities trading between at least one user service (42, 43) and a marketplace (44) by being connected via a bridge.

[0086] For example, the consortium chain (41) may receive at least one of a sell request and a buy request for a token security from at least one user service (42, 43). The consortium chain (41) may transmit at least one of a sell request and a buy request for a token security to the marketplace (44). The consortium chain (41) may receive a request to create a trading contract from the marketplace (44). The consortium chain (41) may transmit a DC between at least one user service (42, 43) and the marketplace (44).

[0087] A bridge may be a data exchange system (e.g., a data transmission protocol) that transmits transaction data received from at least one user service (42, 43) and a marketplace (44) to the consortium chain (41). For example, at least one user service (42, 43) and a marketplace (44) may be connected to the consortium chain (41) through at least one bridge, thereby selling token securities, buying token securities, or brokering the trading of token securities.

[0088] For example, the at least one user service may include an owner service (42) that transmits the owner's sales request to the consortium chain (41) through a first bridge. For example, the at least one user service may include a buyer service (43) that transmits the buyer's purchase request to the consortium chain (41) through a second bridge.

[0089] For example, the marketplace (44) may receive at least one of the sales request and the purchase request from the consortium chain (41) through a third bridge. Based on the sales request, the marketplace (44) may launch a selling offer for the token security. Based on the purchase request, the marketplace (44) may request the consortium chain (41) to create the sales contract.

[0090] Specifically, as shown in FIGS. 5 and 6, the consortium chain (41) can issue a token security (operation 510), register the token security for sale on the marketplace (44) based on a sale request from the owner of the token security (operation 520), create a sales contract for the token security based on a purchase request from a buyer (operation 530), transfer the DC deposited by the buyer to the owner of the token security (operation 540), and change the owner information of the token security (operation 550).

[0091] According to one example, in operation 510, the consortium chain (41) can issue token securities. For example, the consortium chain (41) can receive a request to issue token securities from a user and verify the validity of the underlying transaction of the token securities. Based on the request to issue token securities, the consortium chain (41) can set conditions for issuing token securities and issue token securities.

[0092] In one embodiment, the consortium chain (41) 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 wage payment claim 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 wage payment claim as the underlying transaction.

[0093] TR data may include at least one of the following: State, Date, Total time, Feedback, Income, and Extra bonus, which are generated based on the work history performed by the worker. For example, the TR data may be generated based on TC data.

[0094] 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.

[0095] A security token may include at least one of a money security (Money MS) for claiming money and a capital security (Capital MS) 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 is merely an example, and the security token of the present disclosure may include various forms of securities in addition to the security token exemplified above, depending on the underlying transaction and purpose of use.

[0096] The consortium chain (41) can set the issuance conditions for the token securities based on the request for issuance of the token securities and the underlying transaction. For example, as shown in FIG. 7, the issuance conditions for the token securities may include at least one of the following: information on the parties to the underlying transaction (Employee, Employer) (e.g., employer and worker), information on the issuer (Issuer), information on the holder (Holder), maturity date (Maturity Date), value, currency information (Currency), memo, and settlement status (Settlement).

[0097] The consortium chain (41) can issue token securities using a token securities smart contract. For example, the token securities smart contract can issue token securities of a predetermined type based on a request for the issuance of token securities from the consortium chain (41). For example, the token securities smart contract can issue a promissory note based on a wage payment claim as the underlying transaction based on TR data and token securities issuance conditions.

[0098] According to one example, in operation 520, the consortium chain (41) may register the token security for sale on the marketplace (44) based on a sale request from the owner of the token security. The owner of the token security (e.g., seller) may request the sale of the token security through the owner service (42). For example, the consortium chain (41) may receive a sale request for the token security from the owner service (42) through the first bridge. The marketplace smart contract may register the token security for sale based on the sale request for the token security.

[0099] A request to sell token securities may include information for the sale of the token securities, such as the underlying transaction, type, quantity, and price. For example, a request to sell token securities may include the seller's desired discount rate. For instance, the desired discount rate may refer to the discount percentage applied to the settlement amount of the token securities when determining the sale price. Meanwhile, the sale price of the token securities may be determined based on the aforementioned desired discount rate and minimum discount rate.

[0100] The marketplace (44) can launch a selling offer for said token securities by registering the sale of said token securities. For example, the marketplace (44) can officially launch the selling offer once the registration of the sale of said token securities is completed. For example, the marketplace (44) can launch the selling offer for said token securities using a website, an application, and other communication channels. The marketplace (44) can provide detailed information about said token securities to induce a buyer to purchase said token securities. For example, the detailed information about said token securities may include at least one of the current owner of said token securities, the underlying transaction of said token securities, the investment risk of said token securities, and the expected return of said token securities.

[0101] According to one example, in operation 530, the consortium chain (41) may create a sales contract for the said token security based on a buyer's purchase request. The buyer may use the buyer service (43) to view the token security listed for sale on the marketplace (44). The marketplace (44) may provide detailed information about the said token security to induce the buyer's purchase of the token security through a third bridge. For example, the buyer service (43) may provide the buyer with detailed information about the token security listed for sale on the marketplace (44) through the consortium chain (41). For example, the marketplace (44) may receive a purchase request for the token security from the buyer service (43). Based on receiving a purchase request for the sale of the token security, the marketplace (44) may request the consortium chain (41) to create the said sales contract. The marketplace smart contract of the consortium chain (41) can create a sales contract between a seller and a buyer based on a request to create a sales contract. Based on the sales contract, the marketplace smart contract can request the buyer to pay a purchase price corresponding to the sale price of the token security.

[0102] According to one example, in operation 540, the consortium chain (41) may transfer the DC deposited by the buyer to the owner of the token security. For example, the marketplace smart contract may transfer the DC received from the buyer service (43) to the owner of the token security (e.g., seller). When the marketplace smart contract transfers the DC to the owner of the token security, it may transfer the DC corresponding to the amount excluding a predetermined fee from the settlement amount. For example, the fee may include at least one of a sales fee and a purchase fee.

[0103] According to one example, in operation 550, the consortium chain (41) can change the owner information of the token security. For example, the owner information may change as the token security is sold on the marketplace (44). The marketplace smart contract may request the token security smart contract to change the owner of the token security. For example, if the owner of the token security is changed, the token security smart contract of the consortium chain (41) may change the owner information (Holder) in the issuance conditions of the token security. The changed owner information may be recorded on at least one consortium node.

[0105] FIG. 8 illustrates the operation of registering the sale of token securities of a consortium chain according to one embodiment.

[0106] Referring to FIG. 8, the consortium chain (41) can register the token security for sale on the marketplace (44) based on a sale request from the owner of the token security. When registering the token security for sale, the marketplace smart contract can determine the sale price of the token security. Specifically, the consortium chain (41) can calculate the minimum discount rate of the token security based on the trading records of the token security owner (operation 810), determine the sale discount rate based on the sale request from the token security owner and the minimum discount rate (operation 820), and determine the sale price of the token security by applying the sale discount rate to the settlement amount of the token security (operation 830).

[0107] According to one example, in operation 810, the consortium chain (41) may calculate a minimum discount rate for the token security based on the trading records of the token security owner. The minimum discount rate is a standard discount rate applied to the sale price of the token security, and may be a discount rate calculated by the marketplace smart contract based on the owner's trading records. The owner's trading records may include at least one of the owner's DATA ID, TR data of the underlying transaction, and the owner's transaction score. The owner's transaction score may be an evaluation score calculated based on at least one of the owner's past token security transaction execution history, the counterparty's evaluation of the owner's past token security transaction, and the settlement history of token security sold by the owner in the past. For example, the minimum discount rate may increase as the owner's transaction score is lower. For example, the minimum discount rate may decrease as the owner's transaction score is higher.

[0108] According to one example, in operation 820, the consortium chain (41) may determine a sales discount rate based on a sales request from a token security owner and a minimum discount rate. The sales discount rate may refer to a discount rate on the settlement amount determined based on the underlying transaction of the token security. For example, the sales request from the token security owner may include the owner's desired discount rate. The desired discount rate may be a discount rate set by the owner of the token security, regardless of the minimum discount rate. The marketplace smart contract may determine the higher of the desired discount rate included in the owner's sales request and the minimum discount rate as the sales discount rate.

[0109] According to one example, in operation 830, the consortium chain (41) can determine the selling price of the token security by applying a sales discount rate to the settlement amount of the token security. For example, the marketplace smart contract can determine the selling price of the token security by applying the higher of the desired discount rate and the minimum discount rate to the settlement amount of the token security.

[0110] In this way, the blockchain platform of the present disclosure can ensure reasonable and secure token securities transactions between a seller and a buyer by reflecting the trading records of the token securities owner in the determination of the token securities sale price.

[0112] FIG. 9 illustrates the DC transmission process of a consortium chain according to one embodiment.

[0113] Referring to FIG. 9, the consortium chain (41) can transfer the DC deposited by the buyer to the owner of the token security. For example, the marketplace smart contract can transfer the DC received from the buyer service (43) to the owner of the token security (e.g., seller).

[0114] In one embodiment, when the marketplace smart contract transmits DC to the owner of the token security, it may transmit DC corresponding to an amount excluding a predetermined fee from the settlement amount. For example, the fee may include at least one of a sales fee and a purchase fee.

[0115] As shown in Fig. 9, the marketplace (44) can earn commission revenue by brokering the trading of token securities.

[0116] The marketplace smart contract may receive a DC from the buyer that includes the purchase fee added to the sale price of the token security. For example, the purchase fee may be determined based on the buyer's purchase request and at least one of the token security brokerage policies of the marketplace (44).

[0117] The marketplace smart contract can transfer the DC to the seller, excluding the sales commission from the sales price of the token security. For example, the sales commission may be determined based on at least one of the seller's sales request and the token security brokerage policy of the marketplace (44).

[0118] The marketplace smart contract can provide the marketplace (44) with a DC corresponding to the purchase fee and the sales fee. In this way, the blockchain platform of the present disclosure can guarantee the fee revenue of the marketplace (44) by providing an automated token securities brokerage service using the marketplace smart contract.

[0120] FIG. 10 illustrates the payment of a settlement amount of a token security according to one embodiment.

[0121] Referring to FIG. 10, the owner of the token security (e.g., buyer) may receive a settlement amount based on the issuance conditions of the token security when the settlement date of the token security arrives.

[0122] A marketplace smart contract can request a change of owner from a token security smart contract based on the execution of a sales contract. For example, the token security smart contract can change the owner to a buyer in the issuance conditions of the token security.

[0123] The Token Securities smart contract can periodically check whether the settlement date of the Token Securities has expired. For example, when the settlement date according to the Token Securities issuance conditions arrives, the Token Securities smart contract can request the payment of the settlement amount from the Payment smart contract.

[0124] The payment smart contract may pay the aforementioned settlement amount to the purchaser in accordance with the issuance conditions of the token security. For example, the payment smart contract may pay a DC equivalent to the settlement amount to the current owner of the token security on the settlement date (e.g., wage payment date) based on the underlying transaction of the token security (e.g., wage payment bond). In this case, the purchaser of the token security may obtain a profit equal to the difference between the aforementioned settlement amount in accordance with the issuance conditions of the token security and the sale price of the token security.

[0125] Meanwhile, the buyer of the token securities may also earn a profit from the resale by selling the purchased token securities back to the marketplace (44).

[0126] In this way, the token securities trading platform of the present disclosure can incorporate various digital assets into the institutional framework, remove technical entry barriers for general investors, and guarantee transparency regarding digital asset trading.

[0127] In addition, the token securities trading platform of the present disclosure can ensure that gig workers can access various financial services by providing a wage payment system suitable for gig workers in the gig economy and increasing the liquidity of gig workers' wage claims.

[0128] 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.

[0129] 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).

[0130] 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).

[0131] 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.”

[0132] 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.

[0133] 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.

[0134] 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 A blockchain platform for mediating the trading of token securities on a blockchain, comprising: a consortium chain; at least one user service connected to the consortium chain through a bridge; and a marketplace connected to the consortium chain through the bridge, wherein the consortium chain issues token securities, registers the token securities for sale on the marketplace based on a sale request from the owner of the token securities, creates a trading contract for the token securities based on a purchase request from a buyer, transmits the DC deposited by the buyer to the owner of the token securities, and changes the owner information of the token securities. Claim 2 A blockchain platform according to claim 1, 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 3 A blockchain platform according to claim 1, wherein at least one user service comprises: a owner service that transmits the owner's sales request to the consortium chain through a first bridge; and a buyer service that transmits the buyer's purchase request to the consortium chain through a second bridge. Claim 4 A blockchain platform according to claim 1, wherein the marketplace receives at least one of the sales request and the purchase request from the consortium chain through a third bridge, launches a selling offer of the token security based on the sales request, and requests the consortium chain to create the sales contract based on the purchase request. Claim 5 In claim 1, the consortium chain comprises at least one of a DATA ID smart contract that records the TR data, a payment smart contract that pays the settlement amount of the token security, a validity verification smart contract that verifies the validity of the data, a token security smart contract that issues the token security, and a marketplace smart contract that brokers the trading of the token security. Claim 6 In paragraph 5, the marketplace smart contract calculates a minimum discount rate of the token security based on the trading records of the owner of the token security, determines a sales discount rate based on the owner's sales request and the minimum discount rate, and determines the sales price of the token security by applying the sales discount rate to the settlement amount of the token security. Claim 7 In the 6th, the trading record of the said owner comprises at least one of the said owner's DATA ID, the TR data of the underlying transaction, and the said owner's transaction score, on a blockchain platform. Claim 8 In the 7th, the above minimum discount rate increases as the above owner’s above transaction score is lower and decreases as the above owner’s above transaction score is higher, in a blockchain platform. Claim 9 In the sixth, the marketplace smart contract determines the higher of the desired discount rate included in the owner's sales request and the minimum discount rate as the sales discount rate, the blockchain platform. Claim 10 In claim 6, the marketplace smart contract receives a DC from the buyer that is the sum of the purchase fee and the sale price of the token security, transmits a DC to the seller that is the sale price of the token security minus the sale fee, and provides a DC to the marketplace that is equivalent to the purchase fee and the sale fee. Claim 11 A blockchain platform according to claim 5, wherein the token security smart contract periodically checks whether the settlement date of the token security has expired, and when the settlement date according to the issuance conditions of the token security has arrived, requests the payment smart contract to pay the settlement amount of the token security, and the payment smart contract pays the settlement amount according to the issuance conditions of the token security to the buyer. Claim 12 A method for brokering the trading of token securities on a blockchain, comprising: an operation in which a consortium chain issues token securities; an operation in which said token securities are registered for sale on a marketplace based on a sale request from the owner of said token securities; an operation in which a trading contract for said token securities is created based on a purchase request from a buyer; an operation in which the DC deposited by said buyer is transmitted to said owner of said token securities; and an operation in which the owner information of said token securities is changed. Claim 13 A method for brokering token securities according to claim 12, wherein the token securities comprise at least one of monetary securities for claiming money and capital securities for claiming capital gains, wherein the monetary securities comprise at least one of bills and checks, and the capital securities comprise at least one of debt securities and equity securities. Claim 14 In claim 12, the consortium chain receives the owner's sales request from the owner service through a first bridge and receives the buyer's purchase request from the buyer service through a second bridge, a token securities brokerage method. Claim 15 A method for brokering token securities according to claim 12, wherein the marketplace receives at least one of the sales request and the purchase request from the consortium chain through a third bridge, launches a selling offer of the token securities based on the sales request, and requests the consortium chain to create the sales contract based on the purchase request. Claim 16 In claim 12, the consortium chain comprises at least one of a DATA ID smart contract that records the TR data, a payment smart contract that pays the settlement amount of the token security, a validity verification smart contract that verifies the validity of the data, a token security smart contract that issues the token security, and a marketplace smart contract that brokers the trading of the token security. Claim 17 A method for brokering token securities according to claim 16, wherein the operation of registering the token securities for sale on the marketplace comprises: the operation of calculating a minimum discount rate of the token securities based on the trading records of the owner of the token securities; the operation of determining a sales discount rate based on the owner's sales request and the minimum discount rate; and the operation of determining the sales price of the token securities by applying the sales discount rate to the settlement amount of the token securities. Claim 18 In the 17th, the trading record of the owner comprises at least one of the owner's DATA ID, the TR data of the underlying transaction, and the owner's transaction score, a token securities brokerage method. Claim 19 A token securities brokerage method in which, in the 18th, the minimum discount rate increases as the trading score of the owner is lower and decreases as the trading score of the owner is higher. Claim 20 In the 17th, the operation of determining the sales discount rate determines the higher of the desired discount rate included in the owner's sales request and the minimum discount rate as the sales discount rate, a token securities brokerage method. Claim 21 A method for brokering token securities according to claim 17, wherein the operation of transmitting the DC deposited by the buyer to the owner of the token security comprises: receiving the DC obtained by adding a purchase fee to the sales price of the token security from the buyer; transmitting the DC obtained by subtracting a sales fee from the sales price of the token security to the seller; and providing the marketplace with the DC corresponding to the purchase fee and the sales fee. Claim 22 A method for brokering token securities according to claim 16, wherein the token security smart contract periodically checks whether the settlement date of the token security has expired, and when the settlement date according to the issuance conditions of the token security has arrived, requests the payment smart contract to pay the settlement amount of the token security, and the payment smart contract pays the settlement amount according to the issuance conditions of the token security to the buyer.

Images