KR102628556B1 - The method and appartus for storing transaction history and proof of onwership utilizing distributed computing - Google Patents

Abstract

Embodiments may utilize distributed computing to store transaction details and provide a method for proving ownership. At this time, the method includes obtaining first asset information based on the first node, generating a first asset block through a private blockchain based on the first asset information, and at least It may include registering with a registration entity to issue one or more tokens, and issuing at least one or more tokens based on registration with the registration entity.

Description

Method and device for storing transaction history and proving ownership utilizing distributed computing {THE METHOD AND APPARTUS FOR STORING TRANSACTION HISTORY AND PROOF OF ONWERSHIP UTILIZING DISTRIBUTED COMPUTING}

Embodiments relate to a method and device for storing transaction details and proving ownership using distributed computing.

More specifically, ownership of real assets can be proven by issuing digital securities based on blockchain, and transaction details can be stored using distributed computing to provide transactions for real assets.

Previously, real assets, such as real estate, could be owned by a single owner or by a small number of people based on shared shares. In addition, real assets such as real estate were recorded in a register through a brokerage office, so ownership was transferred, so transactions could be limited. In addition, high-value real estate could only be traded by some wealthy people, and investment was restricted to general investors who could not afford high prices. Here, it is possible to invest in high-value real estate assets through real estate funds and REITs, but this also involves a complex structure of tasks such as trustee companies, asset management companies, and sales companies, resulting in complex system design and high operating costs. There is a problem with the resulting cost burden being passed on to investors. Therefore, the following describes a plan to issue digital securities for real assets based on blockchain to enable efficient trading.

Korean Patent Application No. 10-2021-0102688

This specification relates to a method and device for storing transaction details and proving ownership using distributed computing.

This specification is about a method of configuring a private blockchain based on real assets and providing efficient transactions by issuing digital securities through the private blockchain.

This specification is about a method of recording real assets in a blockchain based on a plurality of private nodes.

This specification is about a method of providing efficient transactions by creating a non-fungible token (NFT) token for a real asset and issuing digital securities based on it.

This specification is about a method of issuing digital securities for real assets based on a private chain and trading the issued securities based on a side chain.

The problem to be solved by this specification is not limited to the above, and can be expanded to various matters that can be derived by the embodiments of the invention described below.

According to an embodiment of the present specification, a method of storing transaction history and proving ownership using distributed computing includes obtaining first asset information based on a first node, based on the first asset information generating a first asset block through a private blockchain, registering with a registration entity to issue at least one or more tokens based on the generated first asset block, issuing at least one or more tokens based on the registration with the registration entity. It may include the step of distributing at least one issued token to a plurality of terminals, and confirming fund information based on the at least one token distributed to the plurality of terminals.

Additionally, it may include a computer program stored in a computer-readable medium to store transaction details using distributed computing and execute a method of proving ownership.

In addition, according to an embodiment of the present specification, the private blockchain generates the first asset block based on a preset consensus node, and the preset consensus node may include a platform node, a first node, and a second node. .

Additionally, according to an embodiment of the present specification, the first node may be a node that processes trust information of the first asset, and the second node may be a node that processes fund information confirmed based on at least one token.

In addition, according to an embodiment of the present specification, when a registered entity node is included in the preset consensus node of the private blockchain, the first asset block is based on the platform node, the first node, the second node, and the registered entity node. At least one token generated and issued based on the first asset block is registered as a digital security without verification by the registration entity node, and if the registration entity node is not included in the pre-established consensus node of the private blockchain, the first asset A block is created based on a platform node, a first node and a second node, the platform issues at least one or more tokens based on the first asset block, and passes at least one or more token information to a registration entity, and the registration entity Based on at least one token information received, it can be decided whether to register it as a digital security.

In addition, according to an embodiment of the present specification, if the registration entity allows registration of digital securities, the platform distributes at least one issued token to multiple terminals, and if the registration entity does not allow registration of digital securities, the platform Updates the block through the platform node, the first node, and the second node and the private blockchain based on the first asset-related information, reissues at least one token based on the updated block, and then issues at least one or more reissued tokens. Information can be transmitted to the registered entity.

In addition, according to an embodiment of the present specification, the preset consensus node of the private blockchain further includes a verification node, and the verification node may be a node added to guarantee the authenticity of the first asset.

This specification utilizes distributed computing to store transaction details and prove ownership.

This specification has the effect of constructing a private blockchain based on real assets and providing efficient transactions by issuing digital securities through the private blockchain.

This specification has the effect of recording real assets on the blockchain based on a plurality of private nodes.

This specification has the effect of providing efficient transactions by creating non-fungible tokens (NFT) tokens for real assets and issuing digital securities based on them.

This specification has the effect of issuing digital securities for real assets based on a private chain and trading the issued securities based on the side chain.

It should be understood that the effect of the present specification is not limited to the matters described above, and can be expanded to various contents that can be derived from the detailed description of the embodiments of the invention below.

1 is a diagram illustrating an example of an operating environment of a system according to an embodiment of the present specification.
Figure 2 is a block diagram for explaining the internal configuration of the computing device 200 in one embodiment of the present specification.
Figure 3 is a diagram showing a method of proving ownership of a real asset and storing transaction details using distributed computing in an embodiment of the present specification.
Figure 4 is a diagram showing a method of proving ownership of real assets and issuing digital securities using distributed computing based on blockchain in an embodiment of the present specification.
Figure 5 is a diagram showing a method of proving ownership of a real asset and storing transaction details based on a non-fungible token in an embodiment of the present specification.
Figure 6 is a diagram showing a method of performing digital securities trading using distributed computing in one embodiment of the present specification.
Figure 7 is a diagram illustrating a method of recording transaction details and updating proof of ownership based on digital securities transactions in an embodiment of the present specification.
Figure 8 is a diagram showing an interface for trading digital securities based on real assets in one embodiment of the present specification.
Figure 9 is a diagram showing a method for confirming the authenticity of electronic securities according to an embodiment of the present specification.
Figure 10 is a diagram showing a method of verifying and recording transaction details in one embodiment of the present specification.
Figure 11 is a diagram showing a method of processing a transaction of a digital security owner according to an embodiment of the present specification.
Figure 12 is a diagram showing a method of configuring a consensus node for transaction processing in one embodiment of the present specification.
Figure 13 is a diagram showing a method of configuring a consensus node in one embodiment of the present specification.
Figure 14 is a diagram showing a method of trading digital securities based on the main chain and side chain in one embodiment of the present specification.
Figure 15 is a diagram showing a method of proving ownership using distributed computing and dividing and trading the proven ownership in an embodiment of the present specification.
Figure 16 is a diagram showing a method of performing ownership proof for a real asset based on a private blockchain in an embodiment of the present specification.
Figure 17 is a diagram showing a method of distributing expected profits based on ownership proof in one embodiment of the present specification.
Figure 18 is a flowchart of a method for storing transaction details and proving ownership using distributed computing.

In describing the embodiments of the present specification, if it is determined that a detailed description of a known configuration or function may obscure the gist of the embodiments of the present specification, the detailed description thereof will be omitted. In addition, in the drawings, parts that are not related to the description of the embodiments of the present specification are omitted, and similar parts are given similar reference numerals.

In the embodiments of the present specification, when a component is said to be “connected,” “coupled,” or “connected” to another component, this refers not only to a direct connection relationship, but also to an indirect relationship where another component exists in between. Connection relationships may also be included. In addition, when a component is said to "include" or "have" another component, this does not mean excluding the other component, but may further include another component, unless specifically stated to the contrary. .

In the embodiments of this specification, terms such as first, second, etc. are used only for the purpose of distinguishing one component from other components, and do not limit the order or importance of components unless specifically mentioned. No. Therefore, within the scope of the embodiments of the present specification, the first component in an embodiment may be referred to as a second component in other embodiments, and similarly, the second component in the embodiment may be referred to as the first component in other embodiments. It may also be called.

In the embodiments of the present specification, distinct components are intended to clearly explain each feature, and do not necessarily mean that the components are separated. That is, a plurality of components may be integrated to form one hardware or software unit, or one component may be distributed to form a plurality of hardware or software units. Therefore, even if not specifically mentioned, such integrated or distributed embodiments are also included in the scope of the embodiments of the present specification.

In this specification, a network may be a concept that includes both wired and wireless networks. At this time, the network may refer to a communication network in which data exchange between devices, systems, and devices can be performed, and is not limited to a specific network.

Embodiments described herein may have aspects that are entirely hardware, partly hardware and partly software, or entirely software. In this specification, “unit,” “device,” or “system” refers to computer-related entities such as hardware, a combination of hardware and software, or software. For example, in this specification, a part, module, device, or system refers to a running process, processor, object, executable, thread of execution, program, and/or computer. It may be a (computer), but is not limited thereto. For example, both an application running on a computer and the computer may correspond to a part, module, device, or system in the present specification.

Additionally, in this specification, the device may be a mobile device such as a smartphone, tablet PC, wearable device, and HMD (Head Mounted Display), as well as a fixed device such as a PC or a home appliance with a display function. Additionally, as an example, the device may be a cluster within a vehicle or an Internet of Things (IoT) device. That is, in this specification, a device may refer to devices capable of operating an application, and is not limited to a specific type. In the following, for convenience of explanation, the device on which the application runs is referred to as a device.

In this specification, the network communication method is not limited, and connections between each component may not be connected through the same network method. The network may include not only a communication method utilizing a communication network (for example, a mobile communication network, wired Internet, wireless Internet, broadcasting network, satellite network, etc.), but also short-range wireless communication between devices. For example, a network can include objects and any communication method through which objects can be networked, and is not limited to wired communication, wireless communication, 3G, 4G, 5G, or other methods. For example, wired and/or networks include Local Area Network (LAN), Metropolitan Area Network (MAN), Global System for Mobile Network (GSM), Enhanced Data GSM Environment (EDGE), High Speed Downlink Packet Access (HSDPA), W-CDMA (Wideband Code Division Multiple Access), CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access), Bluetooth, Zigbee, Wi-Fi, VoIP (Voice over Internet Protocol), LTE Advanced, IEEE802.16m, WirelessMAN-Advanced, HSPA+, 3GPP Long Term Evolution (LTE), Mobile WiMAX (IEEE 802.16e), UMB (formerly EV-DO Rev. C), Flash-OFDM, iBurst and It may refer to a communication network using one or more communication methods selected from the group consisting of MBWA (IEEE 802.20) systems, HIPERMAN, Beam-Division Multiple Access (BDMA), Wi-MAX (World Interoperability for Microwave Access), and ultrasonic communication. However, it is not limited to this.

Components described in various embodiments do not necessarily mean essential components, and some may be optional components. Accordingly, embodiments consisting of a subset of the elements described in the embodiments are also included in the scope of the embodiments of the present specification. In addition, embodiments that include other components in addition to the components described in the various embodiments are also included in the scope of the embodiments of the present specification.

Hereinafter, embodiments of the present specification will be examined in detail with reference to the drawings.

1 is a diagram illustrating an example of the operating environment of a system according to an embodiment of the present specification. Referring to FIG. 1, one or more user devices 110-1 and 110-2 and one or more servers 120, 130, and 140 are connected through a network 1. Figure 1 is an example for explaining the invention, and the number of user devices or servers is not limited as in Figure 1.

One or more user devices 110-1 and 110-2 may be fixed terminals implemented with a computer system or mobile terminals. One or more user devices 110-1 and 110-2 include, for example, a smart phone, a mobile phone, a navigation device, a computer, a laptop, a digital broadcasting terminal, a Personal Digital Assistant (PDA), or a Portable Multimedia Player (PMP). , tablet PCs, game consoles, wearable devices, IoT (internet of things) devices, VR (virtual reality) devices, AR (augmented reality) devices, etc. For example, in embodiments, user device 110 may be one of a variety of physical computer systems capable of communicating with other servers 120 - 140 over network 1 using substantially wireless or wired communication methods. It can mean.

Each server may be implemented as a computer device or a plurality of computer devices that communicate with one or more user devices 110-1 and 110-2 through the network 1 to provide commands, codes, files, content, services, etc. there is. For example, the server may be a system that provides each service to one or more user devices 110-1 and 110-2 connected through the network 1. As a more specific example, the server provides the service (for example, provision of information, etc.) targeted by the application to one or more user devices through an application as a computer program installed and running on one or more user devices (110-1, 110-2). It can be provided as (110-1, 110-2). As another example, the server may distribute files for installing and running the above-described application to one or more user devices 110-1 and 110-2, receive user input information, and provide a corresponding service.

Figure 2 is a block diagram for explaining the internal configuration of the computing device 200 in one embodiment of the present specification. This computing device 200 can be applied to one or more user devices 110-1, 110-2 or servers 120-140 described above with reference to FIG. 1, and each device and server may add some components or By being configured by excluding them, they may have the same or similar internal configuration.

Referring to FIG. 2 , the computing device 200 may include a memory 210, a processor 220, a communication module 230, and a transceiver 240. The memory 210 is a non-transitory computer-readable recording medium, and is a non-perishable large capacity device such as random access memory (RAM), read only memory (ROM), disk drive, solid state drive (SSD), flash memory, etc. It may include a permanent mass storage device. Here, non-perishable mass storage devices such as ROM, SSD, flash memory, disk drive, etc. may be included in the above-mentioned device or server as a separate persistent storage device that is distinct from the memory 210. In addition, the memory 210 stores an operating system and at least one program code (for example, code for a browser installed and running on the user device 110, etc., or an application installed on the user device 110 to provide a specific service, etc.). It can be. These software components may be loaded from a computer-readable recording medium separate from the memory 210. Such separate computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, and memory cards.

In another embodiment, software components may be loaded into the memory 210 through the communication module 230 rather than a computer-readable recording medium. For example, at least one program is a computer program (for example, installed by files provided through the network 1) by developers or a file distribution system (for example, the server described above) that distributes the installation file of the application. It may be loaded into the memory 210 based on the above-described application).

The processor 220 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations. Commands may be provided to the processor 220 by the memory 210 or the communication module 230. For example, processor 220 may be configured to execute received instructions according to program code stored in a recording device such as memory 210.

The communication module 230 may provide a function for the user device 110 and the servers 120 - 140 to communicate with each other through the network 1, and the device 110 and/or the servers 120 - 140, respectively. This can provide functions for communicating with other electronic devices.

The transceiver unit 240 may be a means for interfacing with an external input/output device (not shown). For example, external input devices may include devices such as a keyboard, mouse, microphone, and camera, and external output devices may include devices such as a display, speaker, and haptic feedback device.

As another example, the transceiver 240 may be a means for interfacing with a device that integrates input and output functions, such as a touch screen.

Additionally, in other embodiments, computing device 200 may include more components than those of FIG. 2 depending on the nature of the device to which it is applied. For example, when the computing device 200 is applied to the user device 110, it is implemented to include at least some of the above-described input/output devices, or a transceiver, a Global Positioning System (GPS) module, a camera, various sensors, It may further include other components such as a database, etc. As a more specific example, if the user device is a smartphone, the smartphone generally includes various devices such as acceleration sensors, gyro sensors, camera modules, various physical buttons, buttons using a touch panel, input/output ports, and vibrators for vibration. It can be implemented to include more components.

The following description will be made based on a computing device operating based on FIGS. 1 and 2. Here, the computing device 200 and the above-described server may be one node. As an example, a node may mean a connection point or an end point and redistribution point of data transmission in a network. Additionally, the above-described node may be a node that operates based on blockchain. Here, the data subject to management may be a block. At this time, a distributed computing technology in which small-scale data subject to management creates a distributed data storage environment based on a chain-type link created based on the P2P method, so that arbitrary modification is not possible, and the results of data changes are recorded. The underlying ledger management technology may be blockchain. In other words, blockchain can be a form of distributed data storage technology, and continuously changing data can be recorded in all of the above-mentioned nodes. In other words, all records related to data processing are recorded in all nodes included in the blockchain, making arbitrary manipulation impossible. In other words, the above-described computing device 200 and server may be one node constituting a blockchain, and each computing device 200 and server has a ledger for data processing, such as data creation and change based on the blockchain. It includes and can be recorded. As an example, the nodes described below may be the computing devices and servers described above, and all devices that transmit and receive data based on the transmitter and receiver described above and record and store blockchain-related ledgers may be nodes, and may be specific nodes. It may not be limited to form. In the following, related technologies are described focusing on blockchain and nodes for convenience of explanation, but this may not be limited to specific devices.

Figure 3 is a diagram showing a method of proving ownership of a real asset and storing transaction details using distributed computing in an embodiment of the present specification.

Referring to Figure 3, ownership of the real asset 310 can be proven and transactions between users can be performed based on blockchain using distributed computing. More specifically, the real asset 310 may be movable property or real estate. As another example, the real asset 310 may be an intellectual property right or other intangible asset that is not in physical form. In other words, the real asset 310 may not be limited to a specific form. However, for convenience of explanation, the description below is based on the case where the real asset 310 is real estate, but may not be limited thereto.

As an example, the transaction of the real asset 310 may be carried out by the entire ownership of the real asset 310 being owned by one owner or by multiple owners sharing or joint ownership.

As an example, ownership of the real asset 310 can be proven by actually owning the real asset 310. As a specific example, the owner of a movable asset can prove ownership by actually holding the real asset 310. In addition, for example, for assets of high value, such as cars or real estate, ownership can be proven by recording them in a register or other legally protected ledger. Here, general investors could be restricted from investing in high-value assets such as real estate due to limited funds, or there were restrictions on trading, such as trading only by some asset owners.

In consideration of the above, the following describes a method of issuing digital securities for real assets 310 such as real estate and transferring ownership between multiple users through transactions. As an example, digital securities of the real asset 310 may be issued as a preset number based on the value of the real asset 310 or a number guaranteed by the registration entity 350. At this time, the number of issued digital securities and the value of each digital security may be determined by the value of the real asset 310. As a specific example, the number of digital securities and the value of each digital security may be determined so that the value of the real asset 310 is the product of the number of digital securities and the value of the individual digital security.

As another example, the number of digital securities and the value of each digital security may be set to be larger or smaller than the value of the real asset 310. As a specific example, referring to FIG. 3, real assets 310 may be delegated to blockchain node A 320 based on trust contract information or trust-related information. At this time, blockchain node A (320) may be a node operated by an entity that processes real asset (310) trust or trust-related information. As an example, blockchain node A (320) may be a node managed by a trust company. At this time, blockchain node A 320 can acquire information about the ownership of the real asset 310 based on trust or consignment, and transmit the information about the acquired ownership to the platform 330. As an example, the platform 330 can prove ownership through a private blockchain based on information about ownership obtained from blockchain node A 320, which will be described later.

Additionally, the platform 330 can issue, manage, and process digital securities for real assets 310. Here, the platform 330 can also operate as a node for a private blockchain. That is, the platform 330 can be implemented as a single node while having the above-described functions, and is not limited to a specific form.

As an example, when the platform 330 selects blockchain node A (320, that is, a node related to a real asset (310) trust), the platform 330 selects blockchain node A (320) among a plurality of blockchain node types. You can choose. As a specific example, in relation to blockchain node A (320), each of a plurality of trust companies may provide their respective blockchain node information to the platform (330). At this time, each blockchain node related to the trust company is of the same type, and only each subject (i.e., trust company) may be different. As an example, the platform 330 may select a specific blockchain node among blockchain nodes for a plurality of trust companies that can perform management tasks for specific real assets. Afterwards, the selected blockchain node can obtain information about the ownership of the real asset 310 as the above-described blockchain node A 320 and transmit it to the platform 330.

As another example, the blockchain node types provided to the platform 330 may be different. As an example, the blockchain node type may be a type that prioritizes security. As another example, the blockchain node type may be one that prioritizes data processing speed. As another example, the blockchain node type may be one that prioritizes data capacity. As another example, the blockchain node type may be a type that prioritizes utility provision. As an example, utility may be information related to service provision based on blockchain nodes. As an example, it may be a node capable of creating an anonymous blockchain or a blockchain node linked to a community or mainnet, and is not limited to a specific type. The types of blockchain nodes may be different, and the platform 330 may select a specific blockchain node among the different blockchain node types as the blockchain node A 320 described above. In other words, when selecting a blockchain node related to a real asset 310 trust, the type information of the blockchain node can be further considered.

Additionally, as an example, the platform 330 may determine the blockchain node type based on the type of the real asset 320. As a specific example, when the real asset 310 is a large amount such as real estate and the number of digital securities issued is large, the platform 330 selects a blockchain node type with fast data processing speed and large data capacity as blockchain node A (320). You can select . As another example, if the value of the real asset 310 is small and the number of digital securities issued is small, a highly secure blockchain node type can be selected as blockchain node A (320). In other words, the platform 330 can determine the blockchain node type suitable for proving ownership of the real asset 310 by considering the characteristics and type of the real asset 310 and select it as blockchain node A (320). Afterwards, blockchain node A 320 can perform an ownership verification operation by obtaining information about the ownership of the real asset 310 and transmitting it to the platform 330 as described above.

As an example, based on the selected blockchain node A (320), a public offering to issue digital securities for the real asset (310) may be delivered to the platform (330). Here, blockchain node A (320) can register digital securities with registration entity (350). The registration entity 350 may be an entity 350 that collateralizes the issuance of digital securities. As an example, the registered entity 350 may be an entity of the Korea Securities Depository. As another example, the registered entity 350 may be another entity to secure the issuance of digital securities of the real asset 310, and is not limited to a specific form. Here, digital securities may be securities in digital form issued based on ownership of real assets 310. As an example, existing digital securities may be issued for specific companies in consideration of corporate value, but may also be issued for real assets 310 whose ownership has been proven. That is, digital securities are issued based on ownership of the real asset 310, and registration can be performed with the registration entity 350 to secure them.

Here, as an example, the registration entity 350 may determine whether to register a digital security by considering the verification of the real asset 310 and whether the issued digital security can be collateralized. As a specific example, the registration entity 350 may obtain information related to the real asset 310 to verify the real asset 310. As an example, information related to the real asset 310 may include at least one of the owner, asset location, asset appraisal information, asset bank record information, asset collateral information, volatility information, asset insurance information, and asset management information on the register of the real asset 310. It may include one, and is not limited to the above-described embodiment. Here, the above-described information may be information recorded when a private blockchain related to the real asset 310 is created.

As a specific example, the above-described registration entity 350, blockchain node A 320, and platform 330 create a private blockchain for the real asset 310 for initial registration of the real asset 310, and based on this, After issuing a digital security, the digital security can be registered with the registration entity 350. Here, the owner on the register of the real asset 310 may be the operator of the above-mentioned blockchain node A (320). Additionally, as an example, the owner of the real asset 310 on the registry may be a third party, and the collateral is based on the private blockchain generated by the registration entity 350, blockchain node A 320, and platform 330. It can be a subject that becomes. That is, the registered owner information of the real asset 310 can be considered, and the registration entity 350 can determine whether to register digitally registered securities by checking this information.

As another example, whether to register a digital security may be determined based on other information about the real asset 310. For example, the collateral value of the real asset 310 may be different from the trading price of the real asset 310. In other words, the appraised value of the real asset 310 may be less than the collateral value. Therefore, when determining the number of digital securities and the value of individual digital securities based on the value of the real asset 310, the actual value of the real asset 310 may not be able to collateralize the digital security, so the registration entity 350 must provide the above-mentioned information. Considering this, you can decide whether to register digital securities. Additionally, as an example, there is a need to reflect the appraised value of the real asset 310, insurance records, and other transaction history information. In other words, verification of the real asset 310 may be necessary, and the registration entity 350 can decide whether to register digital securities by considering the verification information of the real asset 310. Here, as an example, the verification information for the above-described real asset 310 may be composed of a private blockchain. As an example, the node that creates a private blockchain for the real asset 310 may be the platform 330 and blockchain node A 320. In other words, the platform 330 and blockchain node A 320 may be a consensus node that creates a private blockchain for the real asset 310. At this time, ownership of the real asset 310 can be proven through a private blockchain created based on the platform 330 and blockchain node A 320, and the corresponding information can be transmitted to the registration entity 350. there is. At this time, the registration entity 350 may decide whether to permit issuance of digital securities based on private blockchain information and information related to the real asset 310.

As another example, the nodes that create a private blockchain may be platform 330, blockchain node A 320, and registration entity 350. As an example, the registration entity 350 can also operate as a node to form a private blockchain to allow registration of digital securities, and is not limited to a specific form. At this time, the registered entity 350 is a consensus node of the private blockchain that proves ownership of the real asset 310, so it can obtain information related to the real asset in advance. As an example, the node of the registered entity 350 may not agree to the creation of a private blockchain for the real asset 310 if it does not meet preset conditions or preset standards, and may not agree to the creation of a private blockchain for the real asset 310. may not be created. In other words, ownership of the real asset 310 may not be proven, and registration of digital securities may also be impossible. On the other hand, if the registered entity 350 participates as a node in the private blockchain and creates a block of the real asset 310 through consensus in accordance with the preset conditions and standards, the block of the real asset 310 is Ownership can be proven based on a private blockchain, and the issuance of digital securities can also be considered authorized. In other words, the node of the registration entity 350 is a consensus node of the private blockchain and performs verification of the real asset 310 during the block creation process, so when a block for the real asset 310 is created, registration of digital securities issuance is permitted. can be regarded as

As another example, the nodes that create a private blockchain may be platform 330, blockchain node A (320), registered entity 350, and blockchain node B (360). As an example, blockchain node B (360) may be an account-related node. Additionally, as an example, blockchain node B (360) may be a node that manages transaction records or ledgers, and is not limited to a specific form. In other words, the registration entity 350 and blockchain node B 360 may also be consensus nodes for creating a private blockchain for issuing digital securities for the real asset 310, which will ensure security. You can.

As another example, information related to real assets 310 recorded in a private blockchain may be determined based on information obtained through artificial intelligence and the cloud.

As an example, reliable information regarding the real asset 310 may be required to secure the issuance of digital securities for the real asset 310. However, if the real asset 310 is a breakable movable property or an asset whose asset value declines due to aging, such as an apartment, it may be necessary to secure the reliability of the real asset 310. Considering the above, the real asset (310) information recorded in the private blockchain can be derived through artificial intelligence based on similar real asset (310) related information and other asset value information, and this information It can be recorded on a private blockchain. Here, the registration entity 350 can also determine whether to grant registration of digital securities by checking whether the number of digital securities and the value of individual digital securities of the real asset 310 are appropriate based on the information derived based on the above-described information.

Here, as an example, the blockchain may include a public blockchain and a private blockchain, and the blockchain for the real asset 310 may be created based on the private blockchain. For example, a public blockchain may be a type of blockchain in which anyone can participate using various computer equipment such as PCs, laptops, smartphones, servers, and computer miners connected to the Internet without approval from an authoritative organization. At this time, participation or withdrawal from the blockchain network is decided based on the free will of the participants, and transparency and security can be strengthened because many people participate. On the other hand, a private blockchain may be a blockchain in which only authorized persons with legal responsibility can participate in the blockchain network. That is, only authorized nodes, such as the above-described platform 330 and blockchain node A 320, can participate in the blockchain network, and the consensus node may be a private blockchain node.

Based on the above, if digital securities are issued based on the private blockchain of the real asset 310, and the digital securities are granted to the registration entity 350, the platform 330 can perform a digital securities offering. At this time, digital securities publicly offered by the platform 330 may be purchased and distributed by the investor 340. As an example, the investor 340 pays the public offering price based on the platform 330, and the platform 330 can process this information based on the account-related information of blockchain node A (320). Each digital security can be allocated through. At this time, as an example, investors 340 may trade allocated digital securities based on buyers 370-1 and sellers 370-2, which will be described later. Additionally, as an example, when digital securities are issued to investors 340, information about this may be transmitted to blockchain node B 360. Here, blockchain node B 360 may be a node that manages account information of the investor 340 or the buyer 370-1/seller 370-2. As an example, blockchain node B (360) may be a node whose subject is a financial institution. As another example, blockchain node B (360) may be a node of a legally approved entity. In other words, blockchain node B (360) may be a node that manages the account information of the investor (340) or the buyer (370-1)/seller (370-2), and may be a trusted node as a verified node. there is. Here, blockchain node B (360) is linked to the above-described registration entity (350) and manages the account information of the investor (340) or buyer (370-1)/seller (370-2) to ensure reliability. .

Based on the above, when a digital security for a real asset 310 is issued, the digital security can be traded through an exchange node, and the profits of the real asset 310 can be distributed to the owners of the digital security. This will be described later.

Figure 4 is a diagram showing a method of proving ownership of real assets and issuing digital securities using distributed computing based on blockchain in an embodiment of the present specification. As an example, as described above, ownership of the real asset 310 can be created by recording it in a private blockchain using distributed computing. In other words, ownership of the real asset 310 can be proven through a private blockchain using distributed computing.

Here, as a specific example, as described above, the block generation of the private blockchain may be generated based on a preset consensus node (or member node). Additionally, as an example, changing rules by reading blocks of a private blockchain or checking records can also be performed based on member nodes. Therefore, private blockchains can have faster processing speeds than public blockchains. Additionally, as an example, the consensus algorithm of a private blockchain may be PBFT (Practical Byzantine Fault Tolerance), which can improve security. Considering the above, when proving ownership of a real asset 310 and generating a block based on a private blockchain, it may be important to configure a consensus node (or member node) that participates in block generation. For example, the consensus nodes participating in block generation need to be nodes whose reliability can be guaranteed, and at least a minimum number of nodes whose reliability can be guaranteed may be required.

Considering the above, referring to FIG. 4, when a block is created through a private blockchain based on the real asset 310, blockchain node A (320), platform node (330), and blockchain node B (360) may be configured as a consensus node for block generation. Here, blockchain node A (320) may be a node containing information related to the real asset (310) trust, and blockchain node B (360) may be a node related to investors and other traders based on the value of the real asset (310). It may be a node containing account information. In other words, the node that generates a block based on a private blockchain may be a node that manages trust information for the real asset 310, a node that manages account information, and a platform node, and reliability can be guaranteed through this. Here, a block may be created through a private blockchain for the real asset 310 based on the above-described agreement, and digital securities may be issued based on the block.

Additionally, as an example, the registration entity 350 may not be a node involved in block generation based on a private blockchain, but may share trust-related information and account-related information with blockchain node A 320 and blockchain node B 360. The issuance of digital securities based on blocks created during exchange can be guaranteed, and through this, digital securities for real assets (310) can be issued. Additionally, as an example, a block created based on a private blockchain may include information related to the real asset 310. As another example, rules related to transaction processing and profit distribution in blocks created based on a private blockchain may be set based on the above-mentioned consensus node, which will be described later. In addition, digital securities issued based on the above can be provided to buyers 370-1 and sellers 370-2 through the exchange node 410, through which digital securities issued for real assets 310 can be provided. Trading of securities may be possible.

As another example, Figure 5 is a diagram showing a method of proving ownership of a real asset and storing transaction details based on a non-fungible token in an embodiment of the present specification. As an example, an NFT for a real asset 310 may be issued. As an example, a non-fungible token (NFT) is a non-fungible token that contains a unique recognition value for each digital asset, and based on this, it can form a digital asset that cannot be replaced with other products. In other words, specific digital assets can be distinguished from other assets by granting unique rights.

Here, the real asset 310 can be created as an irreplaceable digital asset based on NFT. In other words, a digital asset that corresponds only to the real asset 310 can be created. As an example, an NFT for a real asset 310 may be created based on the above-described blockchain node A (320), platform node 330, and blockchain node B (360). In other words, the node entity that creates the NFT for the real asset 310 may be blockchain node A (320), platform node 330, and blockchain node B (360). Additionally, as an example, blockchain node A 320 is a node in charge of trust-related information for real assets 310 and can update management and change information of real assets 310 corresponding to NFTs in real time. As a specific example, NFT is a unique digital asset that corresponds to a real asset (310) and may have a unique value and cannot be copied. Real assets 310 may fluctuate. For example, the value may change or fluctuate, such as the value of real estate falling or the depreciation of a car. Here, as an example, volatility information about the real asset 310 needs to be reflected in the NFT, and this information can be updated through blockchain node A (320). As a specific example, blockchain node A 320 may periodically update information related to the real asset 310 and determine whether to update the NFT based on a preset reference value. As an example, blockchain node A (320) updates NFT based on the information when a major defect occurs in the real asset (310) based on a preset standard value or a legal dispute occurs based on a preset standard value. It can be done. Here, the nodes performing the NFT update may be the above-described blockchain node A (320), platform 330, and blockchain node B (360). In other words, the NFT can be updated by comparing the information of the real asset (310) acquired based on blockchain node A (320) with the reference value information, and through this, the change information of the real asset (310) can be reflected in the NFT. You can. At this time, when the NFT is updated, the platform 330 can provide updated information to the exchange node 410, the investor 340, and the buyer (370-1)/seller (370-2), through which information is provided. can be shared. Additionally, as an example, the above-described blockchain node A (320), platform 330, and blockchain node B (360) can process transactions for blocks or NFTs created based on smart contracts, which will be described later. do.

Figure 6 is a diagram showing a method of performing digital securities trading using distributed computing in one embodiment of the present specification. Referring to FIG. 6, as described above, the platform 330 can select blockchain node A 320 related to the real asset 310 trust. At this time, blockchain node A (320) can form an off-chain based on the real asset (310). Here, the off-chain may be a chain that generates blocks related to real assets 310 or creates NFTs based on a private blockchain, as described above. Thereafter, blockchain node A 320 may register the digital security with the registration entity 350, issue a public offering, and distribute the digital security to investors through the platform 330. Here, the ledger/records and account information for the investor 340 and the buyer 370-1/seller 370-2 can be managed in the blockchain node B 360, as described above. At this time, as an example, when profits are generated in the real asset 310, blockchain node A 320 can provide profits to investors 340 through the platform 330, and information about this can be stored in the ledger or records. It can be managed.

Additionally, as an example, FIG. 7 is a diagram illustrating a method of recording transaction details and updating proof of ownership based on digital securities transactions in an embodiment of the present specification. Referring to FIG. 7, as described above, digital securities issued through blocks created based on the real asset 310 are distributed to other buyers 370-1 and sellers 370-2 through the initial investor 340. It can be exchanged by . In other words, general users can purchase and sell digital securities of real assets 310. More specifically, the buyer 370-1 and the seller 370-2 can enter the purchase and sale of digital securities based on the front end of the platform (Platform F/E, 330-1). As an example, the front end of the platform may be implemented in conjunction with the exchange node 410 engine. As an example, when the seller 370-2 sells digital securities, the digital securities held by the seller 370-2 are frozen and transferred to a state where ownership cannot be transferred, and may be registered at the ask price of the exchange node 410. there is. In addition, when the buyer 370-1 purchases digital securities, the Korean won assets used by the buyer 370-1 are frozen for the corresponding amount, converted to a non-withdrawable state, and registered as the bid price of the exchange node 410. It can be. Here, when the ask price and the ask price match, a transaction can occur, and the transaction information is linked to the exchange backend (410-1) and the frontend (720-1) and backend (720-2) of the exchange back-office. It can be performed based on That is, purchase and sale execution issuance is performed based on the exchange engine, and execution information may be transmitted to the platform backend 330-2 through the exchange backend 410-1. At this time, the platform backend 330-2 can deposit the seller's digital securities and deposit the buyer's won. Afterwards, the platform backend 330-2 may update the asset and deliver the updated asset information to the exchange 410 and the buyer 370-1/seller 370-2. Additionally, asset update information can be transmitted to the front end 710-1 and back end 710-2 of the funding training system, through which the purchase and sale of digital securities can be performed. Here, as an example, digital securities may be implemented in the form of tokens (or cryptocurrency, hereinafter referred to as tokens). More specifically, as described above, the real asset 310 may be implemented as a block or NFT based on a private blockchain. At this time, digital securities may be issued based on blocks or NFTs and registered in the registration entity 350, as described above. As an example, digital securities may be established as tokens based on the number of digital securities. In other words, tokens can be set as many as the number of digital securities, and tokens as many as the number of digital securities can be issued from one real asset 310. At this time, the seller 370-2 sells tokens based on the platform 330 and the exchange node 410, and the buyer purchases tokens in Korean Won, thereby performing a transaction. In other words, a token can be formed for each individual real asset 310, and transactions can be conducted on it.

As another example, the token may be converted into a unified token based on the platform 330 and the exchange node 410. More specifically, if a token is generated for each individual real asset 310, the number of token types may increase exponentially based on the traded real asset 310, and transactions may be limited. In consideration of the above, the platform 330 and the exchange node 410 can consider digital securities issued for individual real assets 310 and convert them into unified exchange tokens. In other words, the seller 370-2 and the buyer 370-1 can trade various types of real assets with the same token based on the platform 330 and the exchange node 410, thereby improving user convenience. there is.

Additionally, as an example, FIG. 8 is a diagram showing an interface for trading digital securities based on real assets in an embodiment of the present specification. As an example, as described above, based on the platform 330 and the exchange node 410, the seller 370-2 and the buyer 370-1 can sell and buy based on the same token. At this time, as an example, even if a transaction is carried out based on the same token as described above, there is a need to provide information about the real asset 310. In other words, the target real asset 310 can be confirmed, and a transaction for the target real asset 310 can be performed using the same token. To this end, the platform 330 may provide an interface for real asset 310 information. As a specific example, the platform 330 may classify the types of real assets 310 and provide an interface to distinguish each real asset. In other words, users of the platform 330 can check the desired real asset type and check information about the real asset 310 in the corresponding section. As a specific example, referring to FIG. 8, when the real asset is real estate, the platform 330 may provide a real estate section and provide real asset information based on a real estate-related map interface. In other words, the real asset 310 may be a real tangible asset, and since the user needs to check information about it, the platform 330 can provide information about it. At this time, the platform 330 may provide different interfaces based on the type of real asset. For example, if the real asset type is a car or other movable asset, the platform 330 can enable the user to recognize it through an interface that provides a photo of the real asset or other necessary information.

On the other hand, when the real asset is real estate, the platform 330 can provide location information or other information about the real asset in connection with the map interface. Additionally, the platform 330 may provide other information such as satellite photos or actual photo information, and may not be limited to a specific form. Here, the platform 330 can convert digital securities for individual real assets into tokens of the same type based on the map interface and provide them to the user. That is, users can obtain information related to real assets and check tokens and other information through the interface provided by the platform 330.

As another example, the platform 330 may also provide similar real asset list information based on real asset information. As an example, the platform 330 may allow users to compare with other real assets by providing information on real assets of the same or similar amount and token price information based on the total value or appraised value of the real assets. As another example, the platform 330 may provide real assets or other information with the same token price per share, and is not limited to a specific form. As another example, the platform 330 may also provide information on real assets linked to the target real asset. When the platform 330 provides information about an apartment as a real asset, nearby commercial buildings linked to the apartment may be provided as related information. For example, a user may be more likely to purchase real assets linked to or related to the real asset of interest, and the platform 330 may provide this information through an interface. In addition, linked real asset information may be in various forms such as real estate - real estate / real estate - movable property / movable property - movable property, etc., and may not be limited to a specific form. In other words, the platform 330 can provide real asset-related information to users through an interface, allowing users to trade digital securities for real assets with the same token.

As a specific example, referring to FIG. 8, the platform 330 is registered with the registration entity 350 through the platform 330 near Gangnam Station and provides information on real assets 810, 820, and 830 for which digital securities have been issued to the user. can be provided. At this time, the user can select a specific real asset (e.g. Building A, 810) and view related information. Additionally, as an example, when a user selects a specific real asset 810, the platform 330 may allow a transaction to proceed while providing bid/ask price information, and the transaction method is as described above.

Figure 9 is a diagram showing a method for confirming the authenticity of electronic securities according to an embodiment of the present specification. As described above, the private blockchain nodes for real assets 310 are blockchain node A (320), platform 330, and blockchain node B (360), and based on this, blocks for real assets (310) are created. This can be created.

Here, as an example, the authenticity or verification of digital securities using blockchain may be necessary. Considering the above, the registered entity 350 can participate as a node that generates blocks based on the private blockchain. In other words, the registration entity 350 can directly perform the authenticity and verification of digital securities by configuring one node and directly participating as a consensus node for blocks generated based on a private blockchain. As another example, if the registration entity 350 does not participate as a consensus node in the private blockchain, a block is generated based on blockchain node A 320, platform 330, and blockchain node B 360. , information about this may be transmitted to the registration entity 350. In other words, the authenticity of a digital security can be directly proven if the registered entity 350 directly participates as a private blockchain consensus node, and if the registered entity 350 does not participate as a consensus node, blockchain node A (320) ) and the block-related information generated based on the blockchain node B 360 is transmitted and verified by the platform 330 to the registration entity 350, thereby performing authenticity and verification tasks. Through this, the authenticity and verification of digital securities can be guaranteed and ownership can be proven.

Figure 10 is a diagram showing a method of verifying and recording transaction details in one embodiment of the present specification. As an example, based on a private blockchain, the authenticity of block generation and digital securities issuance for real assets 310 as well as the transactions of buyers 370-1 and sellers 370-2 and data processing for each user Verification and certification may be required.

More specifically, referring to FIG. 10, the buyer 370-1 and the seller 370-2 can trade digital securities or tokens through the transaction node 410. As an example, it is also possible to directly trade digital securities, and tokens can be constructed based on digital securities and tokens can be traded. However, for convenience of explanation, the description below is based on the case where tokens are traded, but it is not limited to this and the same can be applied to digital securities. Here, as an example, after a block for the real asset 310 is created based on a private blockchain, digital securities or tokens are created and traded based on it, so verification of the transaction may be necessary. In other words, it may be necessary to record not only block creation but also information that changes based on tokens issued based on the block. Here, as an example, each transaction may be one transaction. Additionally, as an example, an operation in which specific data processing is performed in relation to a generated block as well as a transaction may be a transaction. As an example, a transaction may refer to a unit of work or a series of operations to be performed to perform a logical function that transforms the state of a database. That is, a transaction can be a logical unit of database system processing. Accordingly, an operation that generates a change in a block based on processing of the block and tokens issued based on the block may be a transaction.

As an example, the operations of the investor 340 and the buyer 370-1/seller 370-2 in Table 1 below in relation to the block created based on the real asset 310 and the token issued based thereon, respectively. can be performed based on one transaction. However, this is only one example and is not limited to the following examples. In other words, a transaction may be a unit of work as a series of operations that cause block changes, and may not be limited to Table 1 below. Additionally, as an example, an agreement may be performed based on preset conditions based on a transaction, and the contents of the performed agreement may be recorded in a block. Here, an operation in which agreement is performed based on preset conditions may be performed based on a smart contract. As an example, a smart contract may be a system in which contents agreed upon by the contracting parties in advance are programmed in advance and recorded in an electronic contract document, and the contents of the contract are automatically executed when all contract conditions are met. In other words, based on a private blockchain, the consensus nodes related to the block record the smart contract related to the transaction in the ledger in advance, and when the smart contract is satisfied based on the corresponding transaction, the contract can be automatically executed, and the details of this are in the block. can be recorded in In other words, transactions for blocks and block-related tokens can only operate by satisfying the conditions preset by the consensus nodes, and through this, the transaction details of the investor (340) and the buyer (370-1)/seller (370-2) are recorded. You can save it and verify its authenticity.

[Table 1]

As a specific example, referring to FIG. 10, the buyer 370-1 and the seller 370-2 can perform a transaction based on the exchange node 410, and the transaction operation is as described above. Here, the transaction conclusion between the buyer 370-1 and the seller 370-2 may be one transaction. That is, a transaction may occur based on the transaction between the buyer 370-1 and the seller 370-2. At this time, as an example, the exchange node 410 and the platform 330 may not be nodes that can guarantee reliability.

More specifically, the exchange node 410 may be a public node where the platform 330 is open to a large number of users and actual transactions are conducted, so it may be relatively easy to attack from the outside. Therefore, when the exchange node 410 and platform 330 process blocks and issued tokens on their own, authenticity verification may be unclear. Therefore, in order to verify the authenticity of the real asset 310 and approve the actual transaction, approval based on a private blockchain node may be required based on the transaction that occurred. As an example, when a transaction occurs considering the above-described operation, the consensus node constituting the private blockchain can verify the transaction. Here, transaction verification can be performed automatically based on a smart contract created based on the consensus node, and when the smart contract is performed based on this, a block in which transaction information is recorded can be created, and verification can be completed. . At this time, the platform 330 transmits the above-described block information and verification information to the exchange node 410, and the exchange node 410 can confirm the final transaction.

As another example, FIG. 11 is a diagram showing a method of processing a digital security owner's transaction in an embodiment of the present specification. Referring to Table 1 above, a transaction may occur based on the transaction of the buyer 370-1 and the seller 370-2. Additionally, as an example, a transaction may occur by user 1110. Here, the user 1110 may refer to a device used by a specific subject, such as the computing device 200 of FIG. 2 or other devices, and is not limited to a specific type. However, for convenience of explanation, it is described as user 1110. As an example, a case where the user 1110 changes information or performs another operation as shown in Table 1 may be considered.

Here, as an example, the platform 330 may check the transaction type of the user 1110. More specifically, the platform 330 can check whether the transaction is unrelated to the block of the real asset 310, such as a simple change in personal information of the user 1110. At this time, if the transaction is unrelated to the real asset 310, the platform 330 can independently process the information. On the other hand, if the user's 1110 transaction is related to a real asset 310, the platform 330 can process the transaction based on verification between consensus nodes of the private blockchain. In other words, the platform 330 can determine whether to directly process the transaction of the user 1110 by checking whether it is linked to a block based on a private blockchain, and through this, the authenticity of the block of the real asset 310 can be confirmed. It can be verified.

As another example, FIG. 12 is a diagram showing a method of configuring a consensus node for transaction processing in an embodiment of the present specification. Referring to FIG. 12, consensus nodes for transaction processing can be configured in various ways based on a private blockchain. As a specific example, as described above, the platform 330 may be accessible to multiple users and may be in a public form, so its security may be weak. Therefore, considering the above, the platform 330 may be excluded from the consensus node of the private blockchain. That is, when creating a block of a real asset (310) or performing an agreement on a smart contract based on a transaction, excluding the platform (330), blockchain node A (320), blockchain node B (360), and It may be performed through at least one or more of the registration entities 350. As another example, a verified node may be added to the consensus node of a private blockchain. As an example, a verified node may be a node operated by a government agency or other already verified entity, and authenticity can be guaranteed by participating in the consensus node of a private blockchain. Additionally, legal reliability and legal regulatory conditions may be satisfied based on the above-described verification node, but may not be limited thereto.

As another example, referring to FIG. 12, the nodes of the initial investors (1210-1, 1210-2, and 1210-3) may be included as consensus nodes in the private blockchain. Here, the initial investors (1210-1, 1210-2, 1210-3) may actually refer to the node of the investor who first purchased the real asset (310) by publicly offering to issue digital securities. As an example, early investors (1210-1, 1210-2, 1210-3) may be highly related to real assets (310), so they may be involved in actual block creation and may be included as consensus nodes in the private blockchain. Here, as an example, if the initial investors (1210-1, 1210-2, 1210-3) sell all tokens and do not hold any tokens for the block of real assets (310), they are excluded from the private blockchain consensus node. It can be. On the other hand, if the early investors (1210-1, 1210-2, 1210-3) hold some tokens, the early investors (1210-1, 1210-2, 1210-3) have the status of consensus nodes in the private blockchain. It can be maintained and may not be limited to a specific form.

As another example, early investors (1210-1, 1210-2, 1210-3) are nodes of entities related to real assets (310) and may refer to nodes that actually process data related to the public offering and issuance of digital securities. there is. In other words, the initial investors (1210-1, 1210-2, 1210-3) are involved in the creation of blocks and tokens of the real asset (310), rather than the users who first received the digital securities or tokens by paying the amount after the digital securities were issued. It can refer to one node. In other words, the initial investors (1210-1, 1210-2, 1210-3) may be nodes that have a close relationship with the real asset (310) and process data related to the real asset (310), and for this, the consensus of the private blockchain is The status of a node can be given. Additionally, as an example, the initial investors (1210-1, 1210-2, and 1210-3) may be nodes that actually manage the real assets (310) and check profits or other changes. In other words, it may be a node that generates and reflects information about the volatility of the real asset 310 when it occurs. Additionally, when profits are generated based on the real asset 310, it may be a node that performs actual distribution tasks by reflecting the profit information. In other words, the initial investors (1210-1, 1210-2, 1210-3) may be nodes that process information related to real assets (310), and may also be given a consensus node in the private blockchain. In other words, the consensus node of the private blockchain can include not only blockchain node A (320), which is a trust-related entity, and blockchain node B (360), which is an entity related to account and ledger records, but also nodes related to real assets (310). Through this, security can be increased and operations linked to real assets 310 can be processed.

Additionally, as an example, FIG. 13 is a diagram showing a method of configuring a consensus node in an embodiment of the present specification. Referring to FIG. 13, a verification node 1310 may be included as a consensus node in the private blockchain described above. As an example, the verification node 1310 may be a government agency or other previously verified node. More specifically, the verification node 1310 is not related to the real asset 310 itself, but may be a node of an entity that performs management based on the real asset 310. For example, if the real asset 310 is real estate, it may be a node created based on a court that manages the register or another verifiable entity. In other words, the verification node 1310 may be a node unrelated to the actual asset 310 itself, but may be a node that participates in verifying a private blockchain-based block. Through the above, verification of blocks in the private blockchain can be performed.

Here, as an example, the verification node 1310 can confirm block creation or other transaction processing based on the real asset 310. In other words, the verification node 1310 can record and view block-related information and continuously perform verification of blocks and tokens created based on this. Additionally, as an example, the verification node 1310 may transmit information about the impossibility of verification to the platform 330 when verification is impossible. That is, the verification node 1310 can check the recorded information and exchange information with the platform 330 to monitor the platform 330, thereby securing the reliability of the platform 330.

As another example, Figure 14 is a diagram showing a method of trading digital securities based on the main chain and side chain in an embodiment of the present specification. For example, as described above, when all transactions occurring based on transactions are processed by the consensus node of a private blockchain, data processing delays may occur or the load may increase. Additionally, as an example, if actual transactions are frequent and there is no need for the consensus node of the private blockchain to recognize all transactions, only the necessary transactions can be confirmed. Considering the above, the platform 330 can configure the main blockchain 1410 based on the private blockchain and the side blockchain based on the exchange node 410. Here, the main blockchain 1410 may be a blockchain constructed from nodes agreed upon based on the private blockchain described above. As an example, the main blockchain 1410 does not confirm all transactions that occur based on the side blockchain 1420, but can only process transactions that require processing in relation to the real asset 310. As an example, when profit distribution occurs based on the real asset 310, the main blockchain 1410 may process profits distribution-related transactions based on digital securities or token ratios. Additionally, as an example, transactions that require processing among transactions that occurred based on the side blockchain 1420 may be processed, and are not limited to a specific embodiment. Here, as an example, the side blockchain 1420 is composed of a public blockchain and can be implemented through individual user nodes based on the exchange node 410. In other words, the side blockchain 1420 is a public blockchain in which anonymous nodes participate in transaction processing and can process data based on smart contracts.

As an example, the exchange node 410 may create an exchange token corresponding to the above-described digital security or token and link it. At this time, the exchange token is a token created based on a public blockchain and can be freely traded by users at the exchange node 410. As an example, the side blockchain 1420 can record information about exchange token changes by configuring each blockchain 1420-1, 1420-2, and 1420-3 to process and record each transaction. Here, since the linkage between exchange tokens and real asset tokens may be in a certain form, the main blockchain 1410 may not be involved in changes between exchange tokens. On the other hand, in order to process linked information about real asset tokens and exchange tokens, transactions can be processed based on a private blockchain consensus node in the main blockchain 1410, as described above.

In other words, by configuring the side blockchain 1420 as a public blockchain, data processing efficiency can be increased and the reliability of the private blockchain of the real asset 310 can be improved.

Figure 15 is a diagram showing a method of proving ownership using distributed computing and dividing and trading the proven ownership in an embodiment of the present specification.

Referring to FIG. 15, digital securities for real assets 310 may be issued and initial investor tokens may be assigned. As an example, fund information may be registered from the FTS front end (710-2) to the FTS back end (710-1) based on blockchain node A (320). At this time, if the conditions for raising funds are met based on FTS, ownership of the real asset 310 can be transferred based on blockchain node A 320, and information about this can be verified. Afterwards, as described above, a block is created based on the private blockchain, and digital securities or tokens can be issued based on the generated block. At this time, the back end 330-2 of the platform may check fund information from initial investors through the front end 330-1 of the platform, and deliver tokens issued based on the fund deposit information to the initial investors. In addition, the back end of the platform (330-2) can register issued tokens on the exchange, and the back end of the exchange (410-1) sends information about this to the exchange back-off back end (720-2) and the exchange. The token can be finally registered by passing it to the back-off-front end (720-1). Through the above, early investors can be allocated tokens based on depositing funds and trade the allocated tokens through the exchange. Here, as an example, token issuance may be performed according to a block created based on a private blockchain as described above.

As an example, FIG. 16 is a diagram showing a method of performing ownership proof for a real asset based on a private blockchain in an embodiment of the present specification. As an example, a private blockchain can record information about real assets 310, as described above. As an example, at least one or more of asset location information, asset appraisal information, asset bank record information, asset collateral information, volatility information, asset insurance information, and asset management information may be recorded in the private blockchain 1610.

Here, as an example, when the platform 330 issues digital securities and allocates them to initial investors, information about the private blockchain 1610 may be delivered to the initial investors. As an example, each of the initial investors may be a node, and each node may exchange information with the platform 330. More specifically, the platform 330 can transmit information about the real asset 310 and information about the private blockchain 1610 to each of the initial investor nodes. Additionally, as an example, the platform 330 may further generate specific information in the private blockchain 1610 related to the real asset 310, and this information may also be transmitted to each initial investor node. Afterwards, early investors can check information related to real assets (310) and private blockchain (1610) and transmit information on investment consent and fund deposit information to the platform (330), through which the platform can provide digital securities. It can be allocated to early investors.

Figure 17 is a diagram showing a method of distributing expected profits based on ownership proof in one embodiment of the present specification.

Referring to FIG. 17, when profits are generated in the real asset 310, dividends may be paid to users holding digital securities or tokens. For example, if the real asset 310 is real estate, the real estate may generate profits based on a rental business, etc. At this time, as an example, blockchain node A (320) may perform dividends for generated profits.

As a specific example, referring to FIG. 17, profits on real assets 310 may be generated. Here, as an example, blockchain node A (320) may generate dividend information based on the return on the real asset (310). As an example, the real asset 310 may incur costs as well as profits. As a specific example, in the case of real estate, management fees, taxes, and other costs may be incurred, and processing for these may be necessary. Therefore, blockchain node A 320 does not distribute all profits generated by the real asset 310, but can determine dividends by considering information about generated profits and cost information about the real asset 310. Here, as an example, blockchain node A (320) can directly determine the dividend amount by considering profit information and cost information. As another example, blockchain node A (320) may calculate profit information and cost information for a preset period or a certain period of time and determine the dividend amount based on this. As another example, whether to pay dividends and the amount of dividends may be determined based on the consensus nodes participating in the blockchain nodes. For example, profit information and cost information generated by the real asset 310 may be fluid, and if costs occur after all assets are distributed, the means of paying them may be limited. Therefore, taking the above-mentioned points into consideration, there is a need to determine whether and how much to pay dividends based on profit information and cost information. As an example, nodes participating in a private blockchain can automatically determine whether and how much to pay dividends based on profit and cost information based on a smart contract, and record this information in a block. As another example, blockchain node A (320) determines whether to pay dividends and the amount of dividends based on profit information and cost information on its own, receives approval from nodes participating in the private blockchain for this information, and performs dividend payments. It may be, and may not be limited to a specific form.

At this time, referring to FIG. 17, whether to pay dividends is determined, and when dividends are paid, the back end 330-2 of the platform reads dividend information from a block created based on a private blockchain based on the real asset 310. You can come. Afterwards, dividend-related information can be processed based on the FTS back end (710-1) and FTS front end (710-2), and dividends are distributed to each user through the platform 330 and exchange node 410. It can be. Afterwards, once the dividend is completed, a transaction can occur, and the transaction can be performed based on a smart contract on the private blockchain and recorded in a block.

As a specific example, when the above-described main blockchain 1410 and side blockchain 1420 exist, transactions between the buyer 370-1 and the seller 370-2 through the exchange node 410 are processed through the side blockchain. It can be performed through (1420). On the other hand, since dividends are transactions performed based on real assets 310, they can be performed on the main blockchain 1410. Here, as an example, the main blockchain 1410 may determine a user who will perform dividends in a preset section or at a preset time. More specifically, if transactions are frequent through the exchange node 410, the token subject may change at any time, so it may be necessary to determine the subject who will receive the dividend. Considering the above, the main blockchain 1410 can perform dividends by determining the dividend subject at a specific point in time or in a specific section. As a specific example, the main blockchain 1410 may determine the dividend entity based on the time when a certain block height is created in the ledger as the created block is updated. Additionally, as an example, dividends may be performed by determining a specific block height section and determining a dividend subject based on this, and may not be limited to a specific form. In other words, dividends generated based on real assets 310 may be allocated to token owners at a specific time.

Figure 18 is a flowchart of a method for storing transaction details and proving ownership using distributed computing.

Referring to FIG. 18, the first asset information can be obtained based on the first node. (S1810) Next, the first asset block can be created through a private blockchain based on the first asset information. (S1820) Next, you can register with the registration entity to issue at least one or more tokens based on the generated first asset block. (S1830) Next, issue at least one or more tokens based on the registration entity registration. (S1840), at least one issued token can be distributed to multiple terminals. (S1850) After that, fund information can be confirmed based on at least one token distributed to multiple terminals, as described above. (S1850) S1860) At this time, as an example, the private blockchain generates the first asset block based on a preset consensus node, and the preset consensus node may include a platform node, a first node, and a second node, which is as described above. It's like a bar.

In addition, as an example, the first node is the above-mentioned blockchain node A, which is a node that processes trust information of the first asset, and the second node is the above-described blockchain node B, which is fund information confirmed based on at least one token or more. It may be a node that processes, as described above. Additionally, as an example, when the preset consensus node of the private blockchain includes a registered entity node, the first asset block is created based on the platform node, the first node, the second node, and the registered entity node, and the first asset block At least one token issued based on a block is registered as a digital security without verification by a registration entity node, and if the pre-established consensus node of the private blockchain does not include a registration entity node, the first asset block is a platform node, the first asset block It is created based on a first node and a second node, and the platform issues at least one or more tokens based on the first asset block, transmits at least one or more token information to the registration entity, and the registration entity receives at least one or more tokens. Based on the information, it is possible to decide whether to register as a digital security, as described above.

At this time, if the registration entity allows registration of digital securities, the platform can distribute at least one issued token to multiple terminals. In other words, digital security registration is completed, ownership is proven, and transactions can be secured. On the other hand, if the registration entity does not allow registration of digital securities, the platform may update the block through the platform node, first node, and second node and the private blockchain based on the first asset-related information. At this time, at least one or more tokens may be reissued based on the updated block, and then at least one or more reissued token information may be transmitted to the registration entity. In other words, registration can be performed with digital securities created based on block information that has been changed for digital securities registration as a registered entity, and through this, digital securities that meet the standards of the registered entity can be issued.

Additionally, as an example, the preset consensus node of the private blockchain further includes a verification node, and the verification node may be a node added to guarantee the authenticity of the first asset, as described above.

The embodiments described above can be implemented at least partially as a computer program and recorded on a computer-readable recording medium. Computer-readable recording media on which programs for implementing the embodiments are recorded include all types of recording devices that store data that can be read by a computer. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, and optical data storage devices. Additionally, computer-readable recording media may be distributed across computer systems connected to a network, and computer-readable codes may be stored and executed in a distributed manner. Additionally, functional programs, codes, and code segments for implementing this embodiment can be easily understood by those skilled in the art to which this embodiment belongs.

Although the above-described specification has been described with reference to the embodiments shown in the drawings, these are merely illustrative examples, and those skilled in the art will understand that various modifications and modifications of the embodiments are possible therefrom. However, such modifications should be considered within the scope of technical protection of this specification. Therefore, the true technical protection scope of the present specification should be determined to include other implementations, other embodiments, and those equivalent to the claims according to the technical spirit of the appended claims.
This is a technology developed through the 2021 Fintech and Blockchain Technology Commercialization Support Project (FB210012) of the Seoul Business Agency of the Seoul Metropolitan Government, “Development of a blockchain-based digital securities issuance and distribution platform applicable to the Electronic Securities Act.”

Claims (7)

In a method of storing transaction details and proving ownership using distributed computing,
Obtaining first asset information based on the first node;
Generating a first asset block through a private blockchain based on the first asset information;
registering with a registration entity to issue at least one or more tokens based on the generated first asset block;
issuing at least one token based on the registered entity registration;
distributing the issued at least one token to a plurality of terminals; and
Confirming fund information based on the at least one token distributed to the plurality of terminals; comprising;
The private blockchain generates the first asset block based on a preset consensus node,
The preset consensus node includes a platform node, the first node, and the second node,
The first node is a node that processes trust information of the first asset, and the second node is a node that processes the fund information confirmed based on the at least one token,
When the preset consensus node of the private blockchain includes a registered entity node, the first asset block is generated based on the platform node, the first node, the second node, and the registered entity node, and the at least one token issued based on the first asset block is registered as a digital security without verification by the registration entity node,
If the registered entity node is not included in the preset consensus node of the private blockchain, the first asset block is generated based on the platform node, the first node, and the second node, and the platform is Issue the at least one or more tokens based on a first asset block, and transmit the at least one or more token information to the registration entity,
The registration entity determines whether to register as a digital security based on the received at least one token information.
delete According to claim 1,
The first node is a node that processes trust information of the first asset, and the second node is a node that processes the fund information confirmed based on at least two or more tokens.
According to claim 3,
When the preset consensus node of the private blockchain includes a registered entity node, the first asset block is generated based on the platform node, the first node, the second node, and the registered entity node, and the at least two or more tokens issued based on the first asset block are registered as digital securities without verification by the registration entity node,
If the registered entity node is not included in the preset consensus node of the private blockchain, the first asset block is generated based on the platform node, the first node, and the second node, and the platform is Issue the at least two or more tokens based on a first asset block, and transmit the at least two or more token information to the registration entity,
The registration entity determines whether to register as a digital security based on the received information on the at least two or more tokens.
According to claim 1,
If the registration entity permits registration of the digital security, the platform distributes the issued at least one token to the plurality of terminals,
If the registration entity does not authorize registration of the digital security, the platform updates the block via a private blockchain with the platform node, the first node, and the second node based on the first asset-related information, and , Re-issuing at least one or more tokens based on an updated block and then transmitting the at least one or more re-issued token information to the registration entity.
According to claim 1,
The preset consensus node of the private blockchain further includes a verification node, wherein the verification node is a node added to guarantee the authenticity of the first asset.
A computer program stored on a computer-readable medium in combination with hardware to store transaction details and execute a method for proving ownership utilizing distributed computing according to any one of claims 1 and 3 to 6.

Images