KR102528925B1 - Blockchain system for managing task non-fungible token data of user - Google Patents

Abstract

Disclosed is a system. The system according to an embodiment of the present disclosure comprises: a plurality of user devices which generate task contract (TC) data and transmit it to the server device; and the server device which receives TC data from the plurality of user devices and generates CV data based on it. The plurality of user devices include: a device corresponding to the employer providing the task; and an equipment corresponding to workers performing tasks provided by the above employer, wherein the server device may store the TC data through a blockchain network and generates CV data based on the TC data through a plurality of aggregators, and transmit the TC data and the CV data to the user's device through an application programming interface (API) according to the user's request. Accordingly, the present invention can efficiently manage data related to the user's work performance history, assets, income, etc. through the blockchain system.

Description

Blockchain system for managing users' NFT data {BLOCKCHAIN SYSTEM FOR MANAGING TASK NON-FUNGIBLE TOKEN DATA OF USER}

Embodiments disclosed in this document relate to a system for managing user's NFT data.

Gig work refers to a form of labor in which companies recruit and pay for short-term contracts or temporary workers as needed. Gig labor can be provided based on online platforms, and is expanding to various work fields such as delivery, surrogate operation, and quick service, as well as restaurant assistance and serving, nursing and hospice, cleaning, and security services.

In this regard, blockchain technology can be used to fairly distribute work to workers and provide objective evaluation and reasonable compensation for the work performed. For example, it is possible to minimize fees and pay appropriate fees through cryptocurrency operated based on blockchain technology. In addition, for example, data related to job evaluation can be recorded through the blockchain to create data that cannot be manipulated, thereby accumulating reliable evaluation data for workers. It also makes it easy to verify the identity of workers, for example, minimizing the risk of hacking.

Embodiments disclosed in this document provide a system for managing a task contract (TC) generated by a user (eg, gig worker) performing a task and generating a curriculum vitae (CV) based on the management.

In addition, a system is provided so that information on the work performed by the user can be viewed by authorized persons (eg, workers who performed the work, employers who provided the work).

In addition, it provides a system for generating NFT data that can be sold based on non-fungible tokens (NFTs), such as soul bound tokens (SBTs), and generating reliable data for individual credentials.

In addition, based on various types of NFT data, a user's CV (curriculum vitae) data is created, and a plurality of aggregators are created to access various types of NFT data, and a system for managing them is provided. .

In addition, an apparatus and an operating method for storing TC data with integrity and correctly correcting TC data including missing or erroneous information are provided.

A system according to an embodiment of the present disclosure includes a plurality of user devices generating and transmitting TC (task contract) data to a server device, receiving TC data from the plurality of user devices, and generating CV data based thereon. and the plurality of user devices include a device corresponding to an employer providing a task and a device corresponding to a worker performing a task provided by the employer, the server device comprising: , Store the TC data through a blockchain network, generate CV data based on the TC data through a plurality of aggregators, and send the CV data to the user's device through an application programming interface (API) according to the user's request. TC data and the CV data may be transmitted.

According to the system according to the embodiments disclosed in this document, it provides an effect of efficiently managing data related to a user's job performance history, assets, income, etc. through a blockchain system.

In addition, according to the system according to an embodiment, an effect capable of generating asset NFT data based on a non-transferable non-fungible token (NFT) such as a soul bound token (SBT) is provided.

In addition, according to the system according to an embodiment, an effect of managing a plurality of aggregators and adaptively generating CV (curriculum vitae) data based on various types of TC (task contract) data is provided. .

In addition, according to the system according to an embodiment, according to the server and its operating method according to various embodiments disclosed in this document, the effect of storing TC data having integrity and correcting TC data including errors to provide.

Effects obtainable in the exemplary embodiments of the present disclosure are not limited to the effects mentioned above, and other effects not mentioned are common knowledge in the art to which exemplary embodiments of the present disclosure belong from the following description. can be clearly derived and understood by those who have That is, unintended effects according to the implementation of the exemplary embodiments of the present disclosure may also be derived by those skilled in the art from the exemplary embodiments of the present disclosure.

1A shows a configuration of a system including an electronic device, a server, and a blockchain network according to an embodiment.
1B illustrates a block configuration of a server according to an embodiment.
2 illustrates an example of generating a curriculum vitae (CV) of a server according to an embodiment.
3 illustrates an example of server CV generation according to an embodiment.
4 illustrates an example of server CV generation according to an embodiment.
5 illustrates an example of a blockchain system according to an embodiment.
6 illustrates an example of setting access authority of a server according to an embodiment.
7 illustrates an operational flow of a server according to an embodiment.
8 illustrates an operation flow of a server according to an embodiment.
9 illustrates an operation flow of a server according to an embodiment.
10 illustrates an operation flow of a server according to an embodiment.
11 illustrates a functional configuration of a server device according to an embodiment.
12 illustrates an operational flow of a server device according to an embodiment.
13 illustrates an example of an integrity verification flow according to an embodiment.
14 illustrates an operation flow of a server according to an embodiment.
15 illustrates an example of TC data storage in a server according to an embodiment.
In connection with the description of the drawings, the same or similar reference numerals may be used for the same or similar elements.

Hereinafter, various embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that this is not intended to limit the present invention to the specific embodiments, and includes various modifications, equivalents, and/or alternatives of the embodiments of the present invention. In the following description, the same/similar reference numerals have been used for substantially the same components, and redundant descriptions may be omitted.

1A shows a configuration of a transaction system including an electronic device, a server, and a blockchain network according to an embodiment.

Referring to FIG. 1A , the transaction system 100 may include an electronic device 110, a server 130, and a blockchain network 150.

In one embodiment, the electronic device 110 may include communication circuitry 112 , secure memory 114 , processor 116 and display 118 . In one embodiment, the communication circuit 112 may establish a communication channel between the electronic device 110 and an external electronic device (eg, the server 130) and transmit and receive data. For example, the communication circuit 112 may transmit data of the electronic device 110 performing the transaction to the server 130 .

In an embodiment, the electronic device 110 may generate a key pair using an asymmetric key cryptography (eg, public-key cryptography). A key pair may include a private key and a public key. In one embodiment, secure memory 114 may store the generated private key. In one embodiment, the secure memory 114 may mean a memory in the form of hardware that provides a security environment. For example, the secure memory 114 may be built into the electronic device 110 or may be in the form of a device (eg, a micro SD card) that can be separately inserted into the electronic device 110 . For example, the secure memory 114 may refer to a memory that is hardware-separated from a general memory. In another embodiment, the secure memory 114 may mean a memory in the form of encrypted software to provide a secure environment. For example, the secure memory 114 may be in the form of software that encrypts and stores data so that it can only be accessed through some configuration (eg, TEE). For example, the secure memory 114 may be implemented on the same memory as a general memory, but may be in the form of software stored in a secure memory area separated by software (eg, a memory address).

In one embodiment, the display 118 may visually provide information to the outside of the electronic device 110 (eg, a user). For example, the display 118 may provide at least one of transaction generation information, balance information, transaction transmission delay information, and transaction transmission completion information of the electronic device 110 to the outside.

In one embodiment, the server 130 may include a communication unit 132 , a memory 134 and a processor 136 . In one embodiment, the communication unit 132 may transmit and receive data by establishing a communication channel between the server 130 and an external device (eg, the electronic device 110 or the blockchain network 150). For example, the communication unit 132 may transmit data received from the electronic device 110 to the blockchain network 150 . The transmitted data may be stored in the blockchain node 152.

In one embodiment, the processor 136 may receive data from the electronic device 110 through the communication unit 132 . In one embodiment, the processor 136 may identify a division flag included in data received from the electronic device 110 . In one embodiment, the processor 136 may determine whether to transmit the received data to the blockchain network 150 based on the classification flag included in the data. For example, when a specific segmentation flag is included in the received data (or when the value of the included segmentation flag is the first segmentation value), the processor 136 may store the received data in the memory 134. . For another example, when the received data does not include a specific distinction flag (or when the value of the included distinction flag is a second distinction value different from the first distinction value), the processor 136 receives the received data. Data can be transmitted to the blockchain network 150. In one embodiment, the classification flag may mean a classification value included in a data packet. For example, when some bits of the data packet received from the electronic device 110 include the first division value “1”, the processor 136 may store the received data in the memory 134. For another example, when the second division value “0” is included for some bits of the received data packet, the processor 136 may transmit the received data to the blockchain network 150. 1A shows only a transaction system in which data generated by the electronic device 110 is transmitted to the blockchain network 150 via the server 130, but in another embodiment, data generated by the electronic device 110 A portion of may be transmitted directly to the blockchain network 150. For example, the electronic device 110 may directly transmit data not including a specific identification flag to the blockchain network 150 . For another example, the electronic device 110 may transmit data including a specific identification flag to the server 130 . The server 130 that has received the data including the specific classification flag may monitor the blockchain network 150. When an abnormal transaction is detected in the blockchain network 150, the server 130 may transmit data including a specific classification flag to the blockchain network 150. As another example, the electronic device 110 may store data including a specific division flag in a memory (eg, the secure memory 114). When an abnormal transaction is detected in the blockchain network 150, the server 130 may request the electronic device 110 to transmit data including a specific identification flag to the blockchain network 150.

Figure 1b shows a block configuration of a server according to an embodiment.

According to an embodiment, the server 130 may refer to a server device for managing and providing information on tasks performed by a plurality of client devices (eg, task contract (TC)).

In one embodiment, the client device may refer to an electronic device used by employers and employees (hereinafter referred to as “service users”) who use the resume creation and management service to receive the service. For example, the client device may refer to a service user's portable terminal (eg, a smart phone, a personal digital assistant (PDA), a tablet PC, a wearable device, etc.), a laptop, or a PC.

Referring to FIG. 1 , a server 130 according to an embodiment may include a processor 136, a memory 134, and a communication circuit 132. The configuration shown in FIG. 1 shows the configuration related to the description of the embodiment according to the present disclosure, and other configurations for performing the function of the server may be added in addition to the illustrated configuration, and the illustrated configurations may be omitted.

The memory 134 according to an embodiment is a storage medium used by the server 130 and may store data such as at least one command 121 corresponding to at least one program or setting information. The program may include an Operating System (OS) program and various application programs.

In one embodiment, the memory 134 is a flash memory type, a hard disk type, a multimedia card micro type, or a card type memory (eg SD or XD). memory, etc.), RAM (random access memory, RAM), SRAM (static random access memory), ROM (read only memory, ROM), EEPROM (electrically erasable programmable ROM), PROM (programmable ROM), magnetic memory, magnetic disk, It may include at least one type of storage medium among optical disks.

The communication circuit 132 according to an embodiment includes a server 130 and an external electronic device (eg, a client device (not shown), an IAM server (not shown), a billing server (not shown), a cloud server (not shown), Direct (eg, wired) communication between IPFS (not shown) may be performed. For example, the communication circuitry 132 can receive TC data transmitted from a client device. Also, for example, the communication circuit 132 may transmit TC data to a cloud server (not shown) and an IPFS (not shown) (eg, the blockchain network 150).

In an embodiment, the communication circuitry 132 may include a wireless communication unit (eg, a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication unit. Corresponding one of these communication units communicates with an external electronic device (e.g. client device, IAM server 130, billing server 170, cloud server 140, IPFS 150).

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

In one embodiment, the communication circuit 132 may include a server 130, an external electronic device (eg, a client device (not shown), an IAM server (not shown), a billing server (not shown), a cloud server (not shown), IPFS (not shown)) or various requirements stipulated in the network system may be supported.

The processor 136 according to an embodiment may, for example, execute software (eg, a program) and at least one other component (eg, hardware or software component) of the server 130 connected to the processor 136. can be controlled, and various data processing or calculations can be performed.

In one embodiment, the processor 136, as at least part of data processing or operation, stores commands or data received from other components (eg, the communication circuit 132) in volatile memory, and stores instructions or data stored in the volatile memory. The data can be processed and the resulting data stored in non-volatile memory.

In one embodiment, the processor 136 may include a main processor (eg, a central processing unit or application processor) or a secondary processor (eg, a graphics processing unit, a neural processing unit (NPU), or a communication processor).

In one embodiment, the processor 136 may receive TC data including information about a task performed by a user of the at least one client device from at least one client device.

The processor 136 according to an embodiment may perform operations of the server 130 described with reference to the drawings below.

2 illustrates an example of generating CV (Curriculum vitae) according to an embodiment. 3 illustrates an example of CV generation according to one embodiment. 4 illustrates an example of CV generation according to one embodiment. The server device described in FIGS. 2 to 4 may mean the server 130 of FIG. 1 .

The server device according to an embodiment includes a client device (a first device used by a worker performing a task, and a second device used by an employer who provides a task to a worker) and a blockchain-based cloud server (not shown) or a blockchain At least one node (not shown) on the network (not shown) and information about work performed by the employee may be transmitted and received. In the following description, an employer may mean a person who directs work to an employee and provides compensation accordingly, and may be referred to as “company”, “employee” or equivalent terms. An employee may mean a person who performs work instructed by an employer and receives compensation accordingly, and may be referred to as “worker”, “employee”, “gig” or equivalent terms. In addition, the employer and the employee using the CV management service according to embodiments of the present disclosure may be referred to as “service users”. In the following description, the first device may refer to a device used by an employee to receive a resume management service. The second device may refer to a device used by the employer to receive a resume management service.

2 to 4, the server device generates TCs 220, 320, and 420 based on TC data (eg, 210, 310, and 410), and CVs (eg, 230, 420) based on the generated TCs. 330, 430) can be created.

In one embodiment, the server device provides task contract information (TC) from the first device and the second device to the employer by the employee (e.g., tasks performed by the user (worker) of the first device). information and information about work provided by the user (employer) of the second device). Although not shown in the drawing, the server device, the first device, and the second device may communicate TC through a specific interface (eg, mobile application, etc.).

In one embodiment, the server device may generate a curriculum vitae (CV) through a plurality of blockchain layers. CV may mean data including information about at least one job performed by a worker and information about at least one job provided by an employee.

In an embodiment, the server device may generate TC data based on the TCs received from the first device and the second device. In one embodiment, TC data may be generated for each task to be performed. TC data may include unique identification information (TC ID).

In one embodiment, the TC data may include task data (non-fungible token (NFT) task), asset data (NFT-asset), and time (NFT-time) data. . For example, TC data may be classified in the form shown in Table 1 below.

category subcategory example TC data NFT Task
(Task NFT data) Task Task information performed by the user
Task information created by the employer NFT Assets
(Asset NFT data) for sale digital content
physical goods
membership for non-sale certificate
recipe
A formula (e.g. how to make a cosmetic product) NFT Time
(time NFT data) license License for recipes/formulas, etc. course ticket Cooking Class Voucher

In one embodiment, the task NFT data may include information about tasks performed by the employee and information about tasks created by the employer. For example, the TC data may include the type of work performed by the employee, the date, time, place, content of the work, and evaluation information on the employee. 2 shows an example of combining task NFT data to create a task NFT data CV, FIG. 3 shows an example of combining asset NFT data to create an asset NFT data CV, and FIG. 4 shows an example of combining time NFT data. It shows an example of generating time NFT data CV by doing. Referring to FIG. 2 , the server device according to an embodiment includes a plurality of TCs (eg, TC (210-1), TC (210-2), TC (210-3), ... TC (210-l)) Combined task NFT data can be generated based on. A plurality of TCs may represent task NFT data.

In one embodiment, the task NFT data is an identification number (ID), employee key value, category of task, sub category, date of task performance, time of task performance, location of task performance, and task performed. It may include the employer's assessment of the performance, income paid for work performed, and attachments.

In one embodiment, task NFT data can be created and managed in the form of a table. For example, TC data may be generated and managed in the form shown in Table 2 below.

Category Data Task ID 001 Employer ABC Food State Matched User Address DFKDUYF08A90FD Category Restaurant Sub Category Serving Date 2022-06-03 Time 3 hours Location Gangnam-gu, Seoul Feedback Excellent Income 60,000

The contents included in Table 1 above are only examples, and the TC data may include other contents related to the work performed by the employee as well as the contents included in Table 1 above, and some of the contents included in Table 1 above may be omitted. In one embodiment, the task NFT data may include identification information (eg, Task ID) of the work performed by the worker. Identification information of the work performed by the worker may indicate an identifier generated for each work for the worker.

In one embodiment, the task NFT data may include information (eg, Employer) about an object that is provided with work performed by a worker. For example, an entity that receives work performed by a worker may be an employer. For example, an object that is provided with work performed by a worker may be a third party other than the worker or the employer.

In one embodiment, the task NFT data may include information about the state of the task NFT data. For example, the state of the task NFT data may include a first state indicating a state in which an employer has created a task, but a worker to perform the task has not yet been matched. For example, the state of the task NFT data may include a second state indicating a state in which a worker to perform a task created by an employer has been determined, but the task has not yet been performed. For example, the state of the task NFT data may include a third state indicating a state in which the worker has started performing the task. For example, the state of the task NFT data may include a fourth state indicating a state in which the worker has completed the performance of the task. For example, the state of the task NFT data may include a fifth state indicating a state in which the worker completes the performance of the task and the employer completes the payment of compensation therefor. Task NFT data of the fifth state may also be referred to as TR (task receipt) data.

Referring to FIG. 2, the server device according to an embodiment includes a plurality of task NFT data (eg, TC (210-1), TC (210-2), TC (210-3), ... TC (TR-l) )) to generate combined task NFT data 220 (TC aggregation). For example, in the combined task NFT data, the categories of tasks performed by the user are “restaurant” and “cleaning”, and the subcategories are “serving”, “delivery” and “house cleaning ( home clean)”. Also, for example, the combined task NFT data may include information indicating that the user has performed work in “Gangnam-Gu” and “Yangcheon-Gu”. Also, for example, the combined data may include information about work execution time (eg, 140 hours for delivery and 200 hours for serving). In addition, for example, the combined task NFT data may include feedback information about the task performed by the user (eg, delivery is “excellent” and serving is “excellent”). can

In one embodiment, each of the plurality of TCs 210 may include a category, a subcategory, a work place, a work time, and feedback information.

In one embodiment, the CV 230 includes information about the user's personal information 232, information about certification of work performed 234, information about the user's educational background 236, and work experience performed. It may include information 238 about. The information 238 on the work experience performed may include at least a portion of combined task NFT data.

Referring to FIG. 3 , the server device according to an embodiment includes at least one TC 310 among a plurality of TCs (eg, TC 310-1, TC 310-2, TC 310-3, Based on the TC (310-m)), combined asset NFT data (NFT Tasks aggregation) can be created. At least one TC 310 may include a TC corresponding to asset NFT data among a plurality of TCs (task NFT data).

In one embodiment, asset NFT data (NFT asset) may mean information about an asset that a worker or employer has. In one embodiment, the asset NFT data may include an asset for sale that can be sold and an asset for non-sale that cannot be sold. For example, among asset NFT data, an asset for sale may include digital content (eg, image, video, etc.), goods, membership, and the like. In addition, for example, among asset NFT data, assets for non-sale may include licenses, recipes, formulas for making cosmetics, and the like. For example, asset NFT data may have the form shown in Table 3 below.

Category Data (example) Task ID 002 State Authorized User Address DSLFJI988DSVJSDKF Category Digital Contents Sub Category Movie Clip CID QmbWqx... … qsKc92xm

In one embodiment, the asset NFT data may include task identification information (eg, Task ID). In an embodiment, the asset NFT data may include information about the state (eg, state) of the asset NFT data. can

For example, the status of asset NFT data for sale may include “creation status” indicating the status in which asset NFT data is created. Also, for example, the status of asset NFT data for sale may include “authentication status” indicating a state in which authentication has been completed regarding whether the asset NFT data is recognized as a valid asset. Also, for example, the status of the asset NFT data for sale may include a “matching status” indicating a state in which authentication of the asset NFT data is not completed, but is not yet sold and waiting for matching. Also, for example, the status of the asset NFT data for sale may include a “sold complete status” indicating that the asset NFT data has been sold.

For example, the status of asset NFT data for non-sale may include “creation status” indicating the status in which asset NFT data is created. Also, for example, the status of non-sale asset NFT data may include “authentication status” indicating a state in which authentication is completed regarding whether the asset NFT data is recognized as valid asset NFT data. Also, for example, the status of asset NFT data for non-sale may include a “registration complete” status indicating a state in which authentication and registration for asset NFT data have been completed.

In one embodiment, asset NFT data may include identification information (eg, user address) of a worker or employer. In one embodiment, asset NFT data may include information about the type of asset (eg, Category: Digital contents, Sub-Category: Movie Clip).

In one embodiment, the asset NFT data may include information (eg, CID (content ID)) about the location where the asset is stored.

Referring to FIG. 3, the server device according to an embodiment includes a plurality of task NFT data (e.g., TC (310-1), TC (310-2), TC (310-3), ... TC (TR-m) )) to generate combined asset NFT data 320 (NFT Assets aggregation). For example, in the combination task NFT data, the category of the task performed by the user may be “Digital Contents” and the subcategory may be “image” and “movie clip”. In addition, for example, the combined asset NFT data includes the number of asset NFT data (# of assets), asset NFT data sales volume (# of sold assets), total assets, and market estimated price information ), total income, income avg per month, etc.

Referring to FIG. 4 , the server device according to an embodiment includes at least one TC 410 (eg, TC 410-1, TC 410-2, TC 410-3, ... TC 410 Based on -l)), time NFT data 420 may be generated. The at least one TC 410 may include a TC corresponding to a non-sale asset among the at least one TC 310 .

In an embodiment, the time NFT data may refer to data obtained by converting non-saleable asset NFT data into a form that can be sold in the form of a course ticket or a usage right. For example, time NFT data may have the form shown in Table 4 below.

Category Data (example) Task ID 003 State Completed User Address VCJBKJSO0890DFJL12 Category Voucher Sub Category Recipe Expired date (or duration) 2022-10-08

In one embodiment, the time NFT data may include identification information (eg, Task ID) of the time NFT data. In one embodiment, the temporal NFT data may include information about the state of the temporal NFT data. For example, the state of the time NFT data may include a “creation state” indicating a state in which the time NFT data is generated. For example, the state of the time NFT data may include “authentication status” indicating a state in which authentication on whether or not the time NFT data is valid is completed. For example, the state of the time NFT data may include a “matching state” indicating a state in which a buyer of the time NFT data is waiting to be matched. For example, the status of the time NFT data may include a “sold” status indicating a state in which the buyer for the time NFT data is matched. For example, the state of the time NFT data may include a “usage complete state” indicating a state in which the use of the time NFT data is completed (eg, use of license completed) after completion of sale. For example, the status of the time NFT data may include a “time expiration status” indicating that the validity period of the time NFT data has expired after the sale is completed. In one embodiment, time NFT data in a “used” or “time expired” state can be delivered back to the owner (eg, worker or employer).

In one embodiment, the time NFT data may include worker or employer identification information (eg, user address). In one embodiment, asset NFT data may include information about the type of asset (eg, Category: Voucher, Sub-Category: Recipe).

In one embodiment, the time NFT data may include information on the validity period of the time NFT data (eg, Expiration date).

Referring to Figure 4, the server device according to an embodiment of the plurality of time NFT data (eg, TC (410-1), TC (410-2), TC (410-3), ... TC (410-n) )) to generate combined time NFT data 420 (NFT Time Aggregation). For example, the category of combination time NFT data may be “Voucher” and the subcategory may be “Recipe” “Class”. In addition, for example, combining time NFT data includes the number of asset NFT data (# of assets), total income, average income per month (income avg per month), feedback information (e.g., Class feedback: Excellent”, etc.) information may be included.

The server device according to an embodiment may generate CVs 230, 330, and 430 based on combined TC data (eg, combined task NFT data, combined asset NFT data, and combined time NFT data) combined through an aggregator. In one embodiment, the server device may transfer the CV to the first device and the second device through an application programming interface (API).

In one embodiment, the server device may receive information about the worker's profile (eg, information about personal information, information about qualifications, education information, etc.) from the first device. In an embodiment, the server device may receive information about the employer's profile (eg, information about personal information, information about business operations, information about a company run by the employer, etc.) from the second device.

In one embodiment, although not shown in the figure, the server device may transmit a message requesting to store information about the profiles of workers and employers received from the first device and the second device to the cloud server. Accordingly, the cloud server may store information regarding the profiles of workers and employers.

5 shows an example of a blockchain system according to one embodiment.

The operation of the server device performed in FIG. 5 may be performed on a block chain layer, and the result (eg, TC data, TC table, CV data, etc.) performed and generated in each layer is not only the memory of the server device but also the block chain It can be stored on any node in the network.

A blockchain system according to an embodiment includes user devices (eg, first devices 501-1 and 501-2 corresponding to workers, second devices 502-1 and 502-2 corresponding to employers), A server device 130 may be included.

In one embodiment, the server device 130 may receive TC data through a plurality of blockchain layers based on data received from the user device. The reception of the TC data 512, 514, and 516, the operation of the aggregators 522 and 524, and the generation of the CV data 532 and 534 may be performed in different blockchain layers, respectively.

In one embodiment, the server device 130 generates a plurality of CV data 532 and 534 based on the plurality of TC data 512 , 514 and 516 through the plurality of aggregators 522 and 524 . can

In one embodiment, server device 130 communicates user devices 502-3, 502-4, and 502 to user devices 502-3, 502-4, and 502-5 via an application programming interface (API) 540. -5) and data can be transmitted and received. Like user interfaces such as mobile and desktop applications, APIs can be used for interaction between the server device 130 and the user. APIs can function as a communication layer between applications and databases, passing and processing data quickly and securely. End users of applications can use APIs to complete the tasks of multiple applications in one solution and send and receive information whenever and wherever needed.

According to an embodiment, the server device may receive the TC of the first device for the first task from the first device. For example, referring to FIG. 5 , the server 130 may receive the TC of the first device 501-1 for the first task from the first device 501-1.

In one embodiment, the first device may represent a device used by an employee to receive a resume management service. In one embodiment, the second device may represent a device used by the employer.

In one embodiment, the TC of the first device may mean information about work performed by the worker. For example, the TC of the first device may include task NFT data, asset NFT data, and time NFT data described in FIGS. 2 to 4 .

The type and number of user devices (eg, the first device and the second device) shown in FIG. 5 are only examples, and interactions between more or fewer user devices and server devices may exist. In addition, the number of aggregators shown in FIG. 5 is only an example, and TC data may be combined and CV data may be generated through more or less than two aggregators.

In one embodiment, the first device 501-2 performed a task with the second device 502-1 and the second device 502-2, through which TC data 514 and TC data 516 can be created. Based on TC data 514 and TC data 516 , aggregator 524 may generate CV data 524 . The CV data 524 may be CV data of the first device 502-2.

In one embodiment, the second device 502-1 provided tasks to the first device 501-1 and the first device 501-2, through which TC data 512 and TC data 514 can be created. Based on the TC data 512 and TC data 514 , the aggregator 522 may generate CV data 532 . The CV data 532 may be CV data of the second device 502-1.

In one embodiment, the server device 130 may generate a dynamic CV based on each TC data. The server device may generate CV data for each category of TC data. For example, the server device 130 may generate CV data based on the sum of times for performing tasks for each category. For example, the server device 130 may generate CV data based on feedback information on tasks for each category.

In one embodiment, CV data 534 may represent CV data of an employer (eg, the second device). CV data 534 includes the category of tasks provided by the employer, the number of workers hired by the employer, information on the wages provided to the workers, information about late payments, information about the difficulty of the tasks provided, and information about the level of friendliness of the employer. information may be included.

In one embodiment, the server device may generate asset CV data by combining asset NFT data through an aggregator. Asset CV data includes information on the number of asset NFT data held by the user (e.g. # of Assets), information on the number of asset NFT data sold by the user, information on total asset NFT data, and asset NFT data held by the user. It may include information on the market value of the asset, information on the revenue earned based on the held asset NFT data, and information on the average monthly revenue.

In one embodiment, the server device may generate time CV data based on the time NFT data. The time CV data may include the number of issued time NFT data, information on revenue raised through time NFT data, information on average revenue, and consumer feedback information on time NFT data.

The server device 130 according to an embodiment may include a plurality of aggregators.

In one embodiment, CV data may include dynamic CV data, asset CV data, and temporal CV data.

In one embodiment, when identifying TC data, the server device may identify a subject (eg, Worker ID or Creator ID) that transmitted the TC data. The server device 130 checks the user table and, if a user already exists, can update all CVs of the corresponding user. The server device 130 checks the user table, and if the user does not exist, it can create new CV data for the user.

In one embodiment, the user table may include dynamic CV data for each user, asset CV data, and time CV data.

In one embodiment, when the server device 130 updates the user's CV data, it may determine which value is aggregated for each CV data and update the information of the TC data. For example, the server device can update the Dynamic CV when a Task Contract with Category for Dynamic CV data is created and completed. If there is Income in the Task Contract, the server device can update the CV data while updating the Dynamic CV data or Time CV data according to the Category.

In one embodiment, the server device 130 may update the user's CV data by reflecting this when the user's asset NFT data or time NFT data is sold.

In one embodiment, when the server device 130 receives a viewing request from a user (eg, 502-3, 4, 5) through the API 540, CV data is stored based on whether the user has access rights. can be sent All CV data of the user may be provided, or only some data may be provided. In addition, the server device may provide only information that meets the conditions according to conditions. For example, the server device may transmit date information in order to obtain statistical values of a certain period. For example, the server device 130 may bring only specific Category values or values of specific Digital Contents.

In one embodiment, when receiving a request for CV data through an API, the server device 130 may check whether the requested CV exists. If the requested CV exists, it can respond to the user through API, and if the requested CV does not exist, it can determine which aggregator to call to create the requested CV, and request the CV from the aggregator. . For example, if you receive a request for the entire NFT CV, you can respond right away, but if you are asked for a CV value for a specific period, you must create a custom CV. When a CV is generated from the Aggregator, it responds.

In one embodiment, the server device may include additional information in the NFT CV through the Off-Chain Handler. CV data can be stored on the blockchain layer, and the server device can provide it to the user through an API, including additional information other than the blockchain, such as the user's profile. In other words, the Off-Chain Handler has the information stored off-chain and provides the CV that meets the request.

6 illustrates an example of access authority setting of a server device according to an embodiment. 7 illustrates an operation flow of a server device according to an embodiment. The operation of the server device performed in FIGS. 6 and 7 may be performed on a block chain layer, and the result (eg, TC data, TC table, CV data, etc.) performed and generated in each layer is only the memory of the server device It can be stored in the nodes of the blockchain network.

According to an embodiment, in operation 710, the server device may receive the TC of the first device for the first task from the first device. For example, referring to FIG. 6 , the server 130 may receive the TC of the first device 501-1 for the first task from the first device 501-1.

In one embodiment, the first device may represent a device used by an employee to receive a resume management service.

In one embodiment, the TC of the first device may mean information about work performed by the worker. For example, the TC of the first device may include task NFT data, asset NFT data, and time NFT data described in FIGS. 2 to 4 .

According to an embodiment, in operation 720, the server device may receive a TC of the second device for the first task from a second device matching the first device. For example, the server 130 may receive the TC of the second device 502-1 for the first task from the second device 502-1.

In one embodiment, the second device may refer to a device used by an employer to receive a resume management service.

In one embodiment, the TC of the second device may refer to information about work provided by the employer to the worker. For example, the TC of the first device may include task NFT data, asset NFT data, and time NFT data described in FIGS. 2 to 4 .

In one embodiment, the first device and the second device may be matched when a worker is determined to perform an employer-generated task.

According to an embodiment, in operation 730, the server device may generate first TC data based on a TC of the first device for the first task and a TC of the second device for the first task. For example, the server 130 generates the first TC data 512 based on the TC of the first device 501-1 for the first task and the TC of the second device 502-1 for the first task. can create

According to an embodiment, in operation 740, the server device may create a first TC table 613 including information about devices and applications having access to the first TC.

In an embodiment, the access authority may include access authority to TC and access authority to CV. In one embodiment, the access authority may include a first authority capable of reading only, a second authority capable of viewing and modifying, and a third authority capable of viewing, modifying, and granting authority. For example, access rights may have the form shown in Table 5 below.

permission level scope of authority Owner (third-party authority) - Possible to edit/view by the owner- Possible to assign Acting, Viewer rating Acting (Second Authority) - Possible to act on behalf of the owner, edit/view - Possible to assign viewer ratings Viewer (first authority) - Readable

In one embodiment, permission levels may include Owner, Acting, and Viewer. Owner can represent the owner of the Task Contract or NFT CV. If you have owner authority, you can modify or view TC or CV. In addition, a device with Owner authority may designate Acting and Viewer authority. In an embodiment, a device with Acting class may mean a role acting as Owner. For example, if a user A performs B work through an application called C, if C is given an Acting grade, after it is made with the work performed, when a date or time error is found, TC correction is made to C can do it quickly Also, a device with an Acting level can modify Viewer authority.

In one embodiment, a device having a Viewer level may view TC or CV, but may not have the right to modify.

In one embodiment, priority may exist among access rights, and may have priority in the order of Owner, Acting, and Viewer.

In one embodiment, the server device can set the Owner first when a Task Contract is created. For example, the worker who performed the task and the employer who provided the task can have owner authority. Also, for example, the server device may set the owner of the asset as the owner in the case of an NFT asset.

In one embodiment, when the owner authority for TC or CV is determined, the owner may designate a device having acting authority. A device with acting authority can act as an agent by receiving authority from the owner. In addition, after a device with acting authority is determined, a device with Owner or Acting authority may determine a device with Viewer authority.

In one embodiment, a table representing access authority may also have a form such as Table 6 or Table 7 below.

authority item expiration period Owner Worker02 Permanent Acting App02(client application) sign up Viewer Platform company A Permanent Platform company B Permanent Platform company C 2022.12.31. Financial company A Permanent Financial company B 2022.08.31.

In one embodiment, the authority table may include information about who is assigned to each authority and until when the validity period is. For example, in the case of the owner, it may have a permanent validity period without a separate validity period. Also, for example, the validity period of the permission may be set during subscription to the app. Also, for example, platform companies A and B can always have the authority of the viewer, and platform company C can have the authority until the end of 22 years. For example, when an authorization request is received from a specific device (eg, Financial Company B) in a server device, it may be set to have authorization for a predetermined period (eg, one week).

authority item expiration period Owner Worker 02 Permanent Acting APP02 (Client Application) Sign up Viewer All platform company Permanent All financial companies 2022-12-31

In one embodiment, Viewer items may be designated one by one, such as Platform Company A, B, and C, but may be set according to a predetermined preset. For example, the server device can enable all work platform companies to inquire about my NFT CV, and financial related companies to be able to inquire at a specific point in time (eg, 2022). In one embodiment, the server device transmits the combined TC to generate TC data (e.g., in the case of the first TC data 613, the first device 501-1 and the second device 502-1) Since each TC is received from TC data, the first device 501-1 and the second device 502-1 may be determined to have third authority for TC data.

For example, the server 130 determines that the first device 501-1, the second device 502-1, the third device 502-3, and App01 are the first authority for the first TC data 512. , the first TC table 613 can be created so that the first device 501-1 and the second device 501-2 have the second authority and the third authority.

In an embodiment, the server device may receive TC data of the second device for the second task from the second device, and TC data of the other first device for the second task from another first device. The server device may generate the second TC data based on a TC of the second device for the second task and a TC of another first device for the second task. The server device may create a second TC table including information about devices and applications having access to the second TC data. For example, the server 130 receives the TC of the second device for the second task from the second device 502-1, and receives the TC of the first device for the second task from the first device 501-1. TC can be received. The server 130 may generate the second TC data 514 based on the TC of the second device 502-1 for the second task and the TC of the first device 501-2 for the second task. there is. The server 130 is a device having access rights to the second TC data 514 (e.g., first rights: the second device 502-1, the second device 502-2, and the third device 502-2). 3), a second TC table 615 including information about the fourth device 502-4) and second authority: application (App01) may be created.

In an embodiment, the server device may generate the first CV by combining the first TC data and the second TC data. The server device may create a first CV table including information about devices and applications having access to the first CV. For example, the server 130 may generate the first CV 532 by combining the first TC data 512 and the second TC data 514 through the aggregator 522 . The server 130 may create a first CV table 633 including information about devices and applications having access rights to the first CV 532 .

In an embodiment, the server 130 may receive the TC of the other first device for the third task from the other first device, and receive the TC of the other second device for the third task from the other second device. there is. The server device may generate third TC data based on a TC of another first device for the third task and a TC of another second device for the third task. The server device may set a third TC table including information about devices and applications having access to third TC data. For example, in one embodiment, the server 130 receives the TC of the first device 501-2 for the third task from the first device 501-2, and receives the TC of the second device 502-2. TC of the second device 502-2 for the third task may be received from The server 130 may generate third TC data 516 based on the TC of the first device 5021-2 for the third task and the TC of the second device 502-2 for the third task. there is. The server 130 provides information on devices and applications having access rights to the third TC data 516 (e.g., third rights include the first device 501-2, the second device 502-2, and the second device 502-2). 1 authority includes the second device 502-1, the second device 502-2, the third device 502-3, the fourth device 502-4, and the second authority includes APP01). The TC table 633 can be set.

In an embodiment, the server device may generate a second CV by combining the second TC data and the third TC data, and the second CV including information about devices and applications having access to the second CV table can be created. For example, the server 130 may generate the second CV 534 by combining the second TC data 514 and the third TC data 516 through the aggregator 524 . The server 130 may create a second CV table 635 including information about devices and applications having access rights to the second CV 534 .

8 illustrates an operation flow of a server device according to an embodiment.

According to an embodiment, in operation 810, the server device may receive a CV access request from a third device. The CV access request may include a view request or modification request for the CV.

According to an embodiment, in operation 820, the server device may determine whether the third device has CV access authority in response to receiving the CV access request. In an embodiment, the server device may determine whether the third device has CV access authority based on a CV table for a CV corresponding to the CV access request. For example, if the third device is included in the access authority table of the CV corresponding to the CV access request, it may be determined that the third device has the CV access authority. When the third device is not included in the access authority table of the CV corresponding to the CV access request, the server device may determine that the third device does not have CV access authority.

According to an embodiment, in operation 830, when the server device determines that the third device has CV access authority, it may transmit CV-related data corresponding to the CV access request to the third device.

According to an embodiment, in operation 840, when the server device determines that the third device does not have CV access rights, it transmits an access permission request to at least one device having access rights to the CV corresponding to the CV access request. can do.

In one embodiment, when receiving an access permission response from at least one device having access authority, the server device may transmit CV-related data to the third device. In one embodiment, when an access permission response is not received from at least one device having access authority, a rejection may be transmitted to a third device.

9 illustrates an operation flow of a server device according to an embodiment.

According to an embodiment, in operation 910, the server device may receive a TC modification request from the fourth device. If there is incorrect information in the TC, or if there is something to be added, it can be corrected, but the entity with the right to correct the TC (e.g., the employer who created the TC, the worker who performed the task of the TC) needs to correct it there is

According to an embodiment, in operation 920, the server device may determine whether a second authority or a third authority for the TC exists in the fourth device.

In an embodiment, the server device may determine whether the fourth device has second authority or third authority for the TC based on whether the fourth device is included in the TC table.

According to an embodiment, when the server device determines that the second authority or the third authority exists in the fourth device, in operation 930, the server device may modify the TC corresponding to the TC modification request.

According to an embodiment, when the server device determines that the fourth device does not have the second permission or the third permission, in operation 940, the server device grants the third permission to the TC based on the access permission table of the TC. A modification confirmation request can be sent to a device that has

In an embodiment, when the server device receives a modification permission response from a device having third authority, the server device may modify the TC table by reflecting the modification requested by the fourth device.

In one embodiment, when the server device does not receive a modification permission response from the device having the third authority, the server device may transmit a rejection to the fourth device.

In one embodiment, when the server device receives a CV access request from a specific application, it may transmit all CVs given to the specific application with acting authority to the specific application.

In one embodiment, in the description according to FIGS. 1 to 9 , data (eg, TC) received by the server device 130 from the electronic device 110 and data generated by the server device 130 (eg, TC data) , TC table, CV data) may be stored on a memory (eg, memory 134 ) of a server device, an external server (eg, a cloud server), or a node 152 of the blockchain network 150 .

10 illustrates an operational flow of a server device according to an embodiment. The server device of FIG. 10 may mean a device corresponding to the server devices of FIGS. 1 to 4 .

According to an embodiment, in operation 1010, the server device may receive a request for generating time NFT data from the electronic device. An electronic device may refer to a portable terminal device of a user using a platform service.

In one embodiment, the request for generating time NFT data may refer to a request for generating time NFT data based on non-sale asset NFT data among asset NFT data possessed by a user of an electronic device. The generation request of time NFT data may correspond to at least one asset NFT data. In other words, the time NFT data requested by the user may mean data generated in response to the user's specific asset NFT data (eg, a manufacturing formula).

In one embodiment, the request for generating time NFT data may include information (eg, identification information of asset NFT data) for specifying asset NFT data used to generate time NFT data.

In one embodiment, the server device may generate time NFT data based on at least one asset NFT data. In other words, one time NFT data may be generated based on one asset NFT data, or one NFT data may be generated by combining multiple asset NFT data.

According to one embodiment, in operation 1020, the server device may identify asset NFT data corresponding to the generation request of time NFT data.

In one embodiment, the server device may identify asset NFT data corresponding to a time NFT data generation request among TC data for an electronic device stored in a blockchain network. For example, if the information on the asset NFT data included in the time NFT data generation request relates to a recipe specified by the user, the server device may identify the asset NFT data related to the recipe.

In one embodiment, the asset NFT data identified by the server device may include information included in the table shown in Table 3.

According to one embodiment, in operation 1030, the server device may receive information about asset NFT data from a blockchain network.

In one embodiment, the server device may receive information about the asset NFT data identified in operation 1020 from the blockchain network.

According to one embodiment, in operation 1040, the server device may determine whether the asset NFT data is a first type.

In one embodiment, the asset NFT data may be of either the first type or the second type. The first type means a type that can generate time NFT data, and can mean asset NFT data (eg, certificate) that cannot be sold, and the second type means a type that cannot generate time NFT data. As such, it may mean asset NFT data (eg, video, image, etc.) that can be sold.

In one embodiment, the server device may determine whether the asset NFT data is the first type based on information about the asset NFT data (eg, Table 3). The server device may determine whether the asset NFT data is unsellable asset NFT data based on category or subcategory information included in the asset NFT data. For example, if the category is “digital contents” and the subcategory is “movie clip”, the server device may determine that the asset NFT data is the second type. For example, if the category is "voucher" and the subcategory is "recipe", the server device may determine that the asset NFT data is of the first type.

In one embodiment, the server device may determine whether the asset NFT data is a soul bound token (SBT). For example, the server device may determine whether the asset NFT data is non-transferable asset NFT data for sale to others. For example, if the category or subcategory of the asset NFT data is a license, diploma, patent, method for manufacturing a specific substance (eg perfume), recipe, etc., the server device says that the asset NFT data is non-sale asset NFT data. can decide

In one embodiment, the server device may determine whether a voucher can be generated from asset NFT data. The voucher may include a first voucher corresponding to a course ticket and a second voucher corresponding to a use right. When a first voucher corresponding to a course ticket is to be generated using a user's qualification, diploma, recipe, formula, etc. of the electronic device, it may be determined that the voucher can be created. For example, the server device may determine that the voucher cannot be generated when attempting to generate a second voucher corresponding to the right to use by using the user's qualification or diploma of the user of the electronic device. For example, the server device may determine that the voucher can be created when a second voucher corresponding to the right to use is created using a recipe or formula of the user of the electronic device.

In one embodiment, the server device may determine whether the asset NFT data is valid. In the case of asset NFT data with an expiration date, such as a certificate or patent, the server device may generate time NFT data after checking the expiration date.

According to one embodiment, in operation 1050, when the server device determines that the asset NFT data is the first type, it may transmit a request for authentication of the asset NFT data to a server (not shown) for authentication of the NFT data.

In one embodiment, when the information on the asset NFT data includes information indicating that the asset NFT data has already been authenticated, the server device sends a request for authentication of the asset NFT data to a server (not shown) for authentication of the NFT data. Operation 1060 may be performed without transmission.

According to one embodiment, in operation 1060, the server device may determine whether to receive authentication confirmation for the asset NFT data from the server for authentication. Authentication confirmation for asset NFT data may include information indicating that the user's asset NFT data has been authenticated.

According to an embodiment, in operation 1070, when the server device receives authentication confirmation for the asset NFT data from the server for authentication, the server device may receive setting information of the time NFT data from the electronic device.

In one embodiment, the setting information of the time NFT data may include information about the price, expiration date, category (eg, first voucher, second voucher), and quantity of the time NFT data to be generated based on the asset NFT data. there is. The price of the time NFT data may indicate information about the cost to be paid in order to use the generated time NFT data. The validity period of the time NFT data may include information about a period during which the generated time NFT data is valid (eg, usable period, expiration period, etc.). The category of time NFT data may include information (eg, usage right, course ticket, etc.) about the category to which the generated time NFT data belongs. Information on the quantity of time NFT data may include information on the amount of generated time NFT data (eg, only one time NFT data may be generated, or a plurality of time NFT data may be generated).

In one embodiment, the information about the validity period of the time NFT data may be generated according to a predetermined condition based on the information about the price of the time NFT data. For example, the predetermined condition may be configured in the form shown in Table 8 below.

price period 100,000 1 week + 1 day 200,000 2 weeks + 3 days 300,000 3 weeks + 5 days

As illustrated in Table 8 above, the price may be determined according to the received period. In relation to Table 8, the validity period of time NFT data can be expressed as the following equation. <Equation 1>

Period = (Price / 100,000) * 7 + (Price / 100,000) * 2 -1

In Equation 1, period may indicate the validity period of time NFT data, and price may indicate the price of time NFT data.

According to one embodiment, in operation 1080, when the server device determines that the asset NFT data is not the first type in operation 1040, it may transmit a first response notifying that generation of time NFT data is impossible.

According to one embodiment, in operation 1080, if the server device does not receive authentication confirmation for the asset NFT data from the server for authentication in operation 1060, it may transmit a first response notifying that generation of time NFT data is impossible. .

In one embodiment, the time NFT data may be generated based on setting information of the time NFT data. The server device may store the generated time NFT data in the blockchain network.

In one embodiment, the server device may update information about the asset NFT data on the blockchain network based on the generated time NFT data. For example, it is possible to update the time NFT data generated with respect to the asset NFT data. Information about the updated asset NFT data may include information about the state of the time NFT data, setting information of the time NFT data, and information about the buyer of the time NFT data.

11 illustrates a functional configuration of a server device according to an embodiment. The server device of FIG. 11 may refer to a device corresponding to the server device 130 of FIG. 1 .

Referring to FIG. 11 , a server device 130 may include an aggregator manager 1110 and a plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N. The plurality of aggregators 1120 - 1 , 1120 - 2 , 1120 - 3 , ... 1120 -N and the aggregator manager 1110 may mean functional components of the server device 130 . For example, the plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N and the aggregator manager 1110 each mean a functional unit of a processor. (1120-1, 1120-2, 1120-3, ... 1120-N) and the aggregator manager 1110 may refer to a set of instructions stored in memory to be executed by the processor. In the following description, an aggregator may mean any one of the plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N.

The aggregator according to an embodiment may generate a CV based on TC data (eg, task NFT data, asset NFT data, time NFT data) related to a task performed by a user. The server device may generate CV data based on TC data stored in the blockchain network through the aggregator.

The server device 130 according to an embodiment may include a plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N. The aggregators constituting the plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N may generate CV data based on different TC data. For example, the aggregator 1120-1 may generate CV data based on task NFT data. The aggregator 1120-2 may generate CV data based on asset NFT data. For example, the aggregator 1120-3 may generate CV data based on temporal NFT data. For example, the aggregator 1120 -N may generate CV data based on asset NFT data and time NFT data.

In one embodiment, the aggregators constituting the plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N may have different access rights. For example, the aggregator 1120-1 may have access to TC data generated by the first user, but the aggregator 1120-N may have access to TC data generated by the first user. may not have authority.

The aggregator manager 1110 according to an embodiment may manage a plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N.

In an embodiment, the aggregator manager 1110 may create a new aggregator other than the plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N. For example, when identifying an aggregator creation request, the aggregator manager 1110 assigns the aggregator to a plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N. can be added to An operation of adding a new aggregator by the aggregator manager 1110 may be described in detail in the description of FIG. 12 .

In one embodiment, the aggregator manager 1110 is a server device or blockchain can be deleted from the network. For example, the aggregator 1110 may delete the aggregator from the server device when a specific aggregator malfunctions or when a deletion request for a specific aggregator is identified.

In one embodiment, the aggregator manager 1110 may create and manage a table including information about aggregators. For example, the information about the aggregator may include information about conditions for the aggregator to operate or be called, an input value of the aggregator, an output value of the aggregator, and TC data accessible by the aggregator. can

In one embodiment, the aggregator manager 1110 may include information about a relationship between the plurality of aggregators 1120-1, 1120-2, 1120-3, ... 1120-N.

12 illustrates an operation flow of a server device according to an embodiment. The server device described in FIG. 12 may be a device corresponding to the server device 130 . The aggregator manager described in FIG. 12 may be a component corresponding to the aggregator manager 1110 .

According to an embodiment, in operation 1210, the aggregator manager 1110 may identify a request for adding a new aggregator. A new aggregator may mean an additionally requested aggregator. For convenience of description, the new aggregator may be referred to as an additional aggregator in the following description. For example, an additional request for an additional aggregator may be received from the user device. For example, additional requests from additional aggregators may be received from the blockchain network. For example, additional requests from additional aggregators may be identified in the process of generating CV data.

According to an embodiment, in operation 1220, the aggregator manager 1110 may determine whether additional aggregators have been verified by the consortium on the blockchain network through the blockchain network 1110. A consortium may correspond to a group of objects that a server device transacts with (eg, devices of multiple users (eg, workers, employers) managed by the server device, blockchain networks with which the server device communicates, etc.). For sharing of TC data, entities included in the consortium may mutually share specific information about TC data. A plurality of consortiums may exist, and which users form the consortium through which groups may be stored in the memory of the server device or on the blockchain network.

In one embodiment, the server device may determine whether the additional aggregator is a consortium-validated aggregator. Verification of the aggregator can be performed in advance between users through the NFT CV consortium and stored in a server device or blockchain network. Based on whether the additional aggregator requests access to invalid TC data, information about the data creation or management history of the additional aggregator, whether the additional aggregator transmits data to an unauthorized object, etc. It can be determined whether the additional aggregator is a verified aggregator in the consortium.

According to an embodiment, when the aggregator manager determines in operation 1220 that the additional aggregator has been verified, operation 1230 may be performed.

According to an embodiment, if the aggregator manager determines in operation 1220 that the additional aggregator has not been verified, operation 1270 may be performed. In other words, the aggregator manager can inform the user or blockchain network that the aggregator addition has been rejected.

According to an embodiment, in operation 1230, the server device may create a table related to additional aggregators. The table related to the additional aggregator may include information about the additional aggregator.

In one embodiment, the information about the additional aggregator includes an input value of the additional aggregator, information about a function used by the additional aggregator to generate CV data, and conditions for calling the additional aggregator. information, may include information about TC data to which the additional aggregator has access.

According to an embodiment, in operation 1240, the aggregator manager may identify information about the type of TC data to which the additional aggregator has access authority and store it in a table.

In one embodiment, the aggregator manager may identify access rights to TC data of additional aggregators.

In one embodiment, additional aggregators may have access to specific TC data. For example, additional aggregators may have access to all types of TC data (eg, task NFT data, asset NFT data, time NFT data). For example, additional aggregators may have access only to asset NFT data. For example, additional aggregators may have access only to time NFT data. For example, additional aggregators may have access only to asset NFT data and time NFT data.

According to an embodiment, in operation 1250, the aggregator manager may identify information about a condition for calling an additional aggregator and store it in a table.

In one embodiment, the aggregator manager may identify conditions that must be followed before invoking additional aggregators. For example, if there is no prerequisite condition before calling the additional aggregator, the additional aggregator can be called immediately. For example, the condition for calling the additional aggregator may include information about an aggregator that should be called earlier, and information about input values and output values of the aggregator that should be called earlier.

According to an embodiment, in operation 1260, the aggregator manager may identify an input value of an additional aggregator and information about a function used by the additional aggregator to generate CV data and store them in a table.

An aggregator manager according to an embodiment may manage a table related to information of a plurality of aggregators. For example, a table of information on a plurality of aggregators may have the form shown in Table 9 below.

According to an embodiment, in Table 9, “Name” may indicate information corresponding to the name of the aggregator.

In one embodiment, “Account” may represent information about the address of the aggregator.

In one embodiment, the aggregator manager may call the aggregator based on information about the address of the aggregator.

In one embodiment, the aggregator manager may indicate “Verified” identification information of a company that verified the aggregator.

In one embodiment, the aggregator manager adds, if there is no company identification information included in the “verified” item of the aggregator requested additionally, or if it is not included in the company identification information stored as registered in the NFT CV consortium, It may be determined that the requested aggregator has not been verified.

In one embodiment, “Role” may indicate information about a task performed by an aggregator. For example, if “” is time NFT data, it may indicate that the aggregator performs an operation related to time NFT data. The aggregator manager can generate time NFT data or call an API based on information about the work performed by the aggregator. For example, if a user wants to create time NFT data, the user can request a list of APIs related to time NFT data. Accordingly, the aggregator manager may identify a time NFT data aggregator (eg, TimeNFT_aggregator) and a time NFT data aggregator (eg, TimeNFT_aggregator2). Then, excluding TimeNFT_aggregator with invalid “Valid” value, TimeNFT_aggregator2 API with valid “Valid” value can be provided as a list.

In one embodiment, the table related to the information of the aggregator may include a “Prerequisite” item. “” may represent information about the conditions for calling the Aggregator. For example, information on conditions for calling AssetNFT_Extenstion Aggregator may include content that 9023ikljrjflkwefvpdsio (AssetNFT_aggregator) should be called first.

In one embodiment, when the aggregator manager is requested to call a function called “dividend”, the aggregator manager may call “function” after checking a table related to aggregator information. Accordingly, the aggregation function can be obtained as an output value in AssetNFT_aggregator. In addition, the aggregator manager can call the “dividend function” without the “aggregation function” output value, and thus obtain the dividend function as an output value from AssetNFT_extention.

In one embodiment, “Data (TC/NFT) Access” may indicate the type of TC data that the aggregator can access. For example, “all” could mean that the aggregator has access to all kinds of TC data. For example, referring to Table 9, “Financial_aggregator” may mean that only TC data with the “verified only” attribute can be accessed. “verified only” may mean that TC or NFT has been verified by a financial institution or company in order for TC data to produce a financial product. It can mean that the company that provided the job proves the TC that performed the job and received the wages, and the record of selling the Asset NFT can be confirmed through a transaction on the blockchain.

In one embodiment, “Function (API)”, “Param”, and “Output” may represent information for calling a corresponding Aggregator. Function is a function name exposed to the outside, and communication can be performed between aggregators or between aggregators and aggregator managers through the function. For example, referring to Table 9, information that Financial_aggregator can provide two functions can be included in the table. Param may mean a parameter passed when calling the corresponding API. Param may be an array of TCs (TC[]) or an array of NFTs (NFT[]).

In one embodiment, referring to Table 9, AssetNFT_Extension aggregator can provide a dividend function and measure dividends based on the assets it has.

In one embodiment, Financial_aggregator provides two functions, which in turn may provide measurement functions for loan limit amount and holdings.

In one embodiment, “alid” may represent information about whether the aggregator is valid. For example, since TimeNFT_aggregator is not valid, Aggregator Manager can reject TimeNFT_aggregator when it is called. In this case, the aggregator manager can determine that the Valid value is X so that TimeNFT_aggregator2 is newly distributed on the blockchain and called instead of TimeNFT_aggregator.

In one embodiment, “Description” may indicate information about the role of the aggregator. For example, when a user checks a list of available APIs through an API, it can be used to inform the user of the role of an aggregator by using the Name and Description items.

In one embodiment, when receiving a request for an API list from a user, the aggregator manager may check the table and provide the API list to the user.

13 illustrates an example of an integrity verification flow according to an embodiment. The server device of FIG. 13 may be a device corresponding to the server device 130 of FIG. 1 .

Referring to FIG. 13, an example of TC data storage through a transaction between a plurality of gig workers (1301-1, 1301-2, 1301-3, ... 1301-N), a server device, and a blockchain network is shown.

The plurality of users 1301-1, 1301-2, 1301-3, ... 1301-N shown in FIG. 13 may refer to electronic devices used by users generating TC data 1303.

In one embodiment, the plurality of users 1301-1, 1301-2, 1301-3, ... 1301-N may transmit TC data to the server device 130. An aggregator may generate a CV based on TC data received from a plurality of users 1301-1, 1301-2, 1301-3, ... 1301-N.

In one embodiment, the server device performs integrity verification on TC data received from a plurality of users (1301-1, 1301-2, 1301-3, ... 1301-N), and configures the blockchain network. It can be stored in a plurality of nodes 152-1, 152-2, 152-3, ... 152-N.

Embodiments of the present disclosure are to verify the integrity of the received TC data in order to prevent storing the erroneous TC data when erroneous TC data (eg, when some information is missing or includes erroneous information) is received from the user. It's about process. Incorrect TC data may mean, for example, a case in which any one of the TC data items shown in Tables 2 to 4 is missing. For example, when a storage request for TC data missing a user address is received, it is difficult to know who the TC data belongs to because the TC data does not have a user address. When such TC data is stored, garbage data is accumulated in the block chain, and gas may occur due to storing it in the block chain.

In one embodiment, the server device may perform an integrity verification process on TC data received from a plurality of users (1301-1, 1301-2, 1301-3, ... 1301-N).

In one embodiment, server device 130 may store the TC data in the blockchain network if it determines that the TC data has integrity.

In an embodiment, the server device 130 may store the TC data in a first queue 1322 (recovery queue) when determining that the TC data does not have integrity. In the following description, TC data without integrity may be referred to as TC data. The first queue 1322 may refer to a queue for storing TC data requiring recovery. In other words, in order to recover unnecessary TC data that causes problems or is unusable before storing the TC data in the blockchain network, the server device may store these TC data in the first queue 1322.

In one embodiment, the server device 130 may store TC data generated by performing recovery on the TC data stored in the first queue 1322 in a second queue 1324 (waiting queue). The second queue 1324 may refer to a queue that stores TC data that needs to be confirmed by the user after the recovery check has been completed in the first queue 1322 .

In one embodiment, the TC data stored in the first queue 1322 and the second queue 1324 may be stored in the memory of the server device 130 . A blockchain may include a first memory and a second memory. The first memory may refer to a storage space permanently stored on a blockchain. The second memory may refer to a storage space temporarily stored in the server device.

In one embodiment, Internal Recovery 1326 may refer to a configuration for processing TC data requiring confirmation within a blockchain.

In one embodiment, External Recovery 1328 may refer to a configuration for processing TC data requiring confirmation outside of the blockchain. For example, TC data requiring user confirmation may be restored through External Recovery 1328.

14 illustrates an operation flow of a server device according to an embodiment. The server device of FIG. 14 may refer to a device corresponding to the server device 130 of FIG. 1 .

According to an embodiment, in operation 1410, the server device may receive a request for storing the first TC data.

In one embodiment, the first TC data may refer to TC data received from the user's electronic device. The first TC data may be data with integrity without missing information or data without integrity with missing information.

According to an embodiment, in operation 1420, the server device may determine whether the first TC data is of a first type. The first type of data may refer to data that is force updated regardless of whether the TC data is intact.

In an embodiment, the server device may determine that the first TC data is of the first type when the first TC data satisfies a predetermined condition. The predetermined condition may include a case where a user who transmits a transmission request for the first TC data is a user having special authority. Information about users with special authority may be stored in advance in a memory on the server device.

In an embodiment, the server device may perform operation 1470 when determining that the first TC data is of the first type. When determining that the first TC data is not of the first type, the server device may perform operation 1430.

In an embodiment, the server device may check whether TC data having identification information corresponding to identification information of the first TC data is stored in the second queue. The second queue may refer to a queue in which TC data that has completed recovery checks and is waiting for user confirmation is stored.

In one embodiment, the server device may determine whether recovery is complete when the first TC data is stored in the second queue. When the recovery of the first TC data stored in the second queue is completed, the server device may store the first TC data stored in the second queue through the blockchain network. When restoration of the first TC data stored in the second queue is not completed, the server device may restore the first TC data.

In one embodiment, the server device may determine whether the first TC data is TC data already stored on the blockchain network. For example, the server device may check whether TC data corresponding to the identification information of the first TC data exists in the blockchain network based on the identification information of the first TC data.

In one embodiment, the server device may perform operation 1440 when determining that the first TC data is TC data already stored in the blockchain network.

In one embodiment, the server device may perform operation 1430 when determining that the first TC data is not TC data already stored in the blockchain network.

According to an embodiment, in operation 1430, the server device may determine whether there is no error or incomplete information in the first TC data.

In one embodiment, the first TC data may include information in Table 2, Table 3, or Table 4 according to the type of TC data. TC data with errors or incomplete information may indicate cases in which some of the information included in Table 2, Table 3, or Table 4 described above is missing or some of the information is erroneous. For example, the server device may check whether essential attribute values (eg, information included in Tables 2 to 4) of the first TC data are all filled in. Required attribute values may include TC ID, information about the state of TC data, user address of TC data, category of TC data, information about the period of TC data, information about the amount of TC data, and the like. Information about the amount of TC data may include 0.

In one embodiment, the server device may perform operation 1470 when it determines that there is no erroneous or incomplete information in the first TC data. In one embodiment, when the server device determines that the first TC data contains erroneous or incomplete information, operation 1440 may be performed.

According to an embodiment, in operation 1440, the server device may store the first TC data in a first queue. The first queue may refer to the first queue 1322 of FIG. 13 . The first queue may refer to a queue in which TC data requiring modification is stored. Recovery may be performed on the first TC data stored in the first queue.

According to an embodiment, in operation 1450, the server device may generate second TC data by performing recovery on the first TC data stored in the first queue. The second TC data may refer to TC data generated by re-entering information missing from the first TC data.

In one embodiment, recovery may include internal recovery and external recovery. Internal recovery may be performed by Internal Recovery 1326 of FIG. 13 , and external recovery may be performed by External Recovery 1328 of FIG. 13 .

In one embodiment, internal recovery may mean recovery performed inside the block chain, and external recovery may mean recovery that requires confirmation by a user outside the block chain. For convenience of explanation, the internal recovery may be referred to as “first recovery” and the external recovery may be referred to as “second recovery”.

In one embodiment, the first recovery may determine whether there is data overlapping with the first TC data among the TC data previously stored in the blockchain network based on the identification information of the first TC data requested to be stored. When there is data overlapping with the first TC data among the TC data stored in the blockchain network, the server device may determine that the request to store the first TC data is a request to update the existing TC data. Accordingly, the server device may compare the received first TC data with attribute values of the TC data stored in the blockchain network. If there are other attribute values, the TC data previously stored in the blockchain network can be modified through the attribute values included in the storage-requested first TC data. If all attribute values of the first TC data are the same as attribute values of the TC data previously stored in the blockchain network, the server device determines that the storage request for duplicate data is rejected and rejects the storage request for the first TC data. can Accordingly, the server device may delete the first TC data temporarily stored in the memory.

In one embodiment, the second recovery may refer to an operation of re-entering missing information (attribute value) in the first TC data. To this end, the server device may transmit a TC data recovery request to the electronic device used by the user so that the user can input TC data again. Until the user confirms again, the server device may store the first TC data in the second queue. In one embodiment, when the server device fails to identify a user's input to the first TC data for a predetermined time from the point of time when the first TC data stored in the second queue is stored, the first TC data can be deleted on the memory of the server device.

According to an embodiment, in operation 1460, the server device may store the generated second TC data in a blockchain network.

According to one embodiment, in operation 1470, the server device may store the first TC data in the blockchain network.

15 illustrates an example of a structure of a queue according to an embodiment.

A queue according to an embodiment may have a circular shape as shown in FIG. 15 . The queue shown in FIG. 15 may include a first queue or a second queue.

In one embodiment, the server device may fill the TC data one by one from the front of the queue, and the moment the rear meets the front, the existing TC in the front is deleted, and a new TC can be filled in its place. Over

Referring to FIG. 15 , it can be confirmed that the cue 1510 is stored from TC0 to TC15 from the front to the rear. Queue 1520 represents the form of the queue after TC8 is newly added to queue 1510. That is, TC0 located in the front part of the queue 1510 is deleted, and TC8 may be stored in its place. When TC8 is newly entered, TC0 is deleted from the queue, and front and rear can be moved clockwise by one space.

In one embodiment, queue 1530 represents a structure of a queue when TC3 is deleted after the server device completes recovery for TC3. When TC3 is deleted, TC1 and TC2 are moved forward by one space, and the movement of the front can be confirmed together.

In one embodiment, the server device receives a task contract (TC) of the first device for a first task from a first device, and receives a task contract (TC) of the first device from a second device that matches the first device. , Receive a TC of the second device for the first task, and generate first TC data based on the TC of the first device for the first task and the TC of the second device for the first task. A first TC table including information about a device and an application having an access right to the first TC data may be set.

In one embodiment, the server device receives a request for generating time NFT data from any one electronic device among the plurality of user devices, identifies asset NFT data corresponding to the request for generating time NFT data, Receive information about the asset NFT data from the blockchain network, determine whether the asset NFT data is a first type based on the information about the asset NFT data, and determine whether the asset NFT data is the first type. When it is determined that it is not the 1st type, a first response is transmitted to the electronic device indicating that generation of the time NFT data is impossible, and when it is determined that the asset NFT data is the first type, authentication of the NFT data ) Sends a request for authentication of the asset NFT data to the server for authentication, and when receiving authentication confirmation for the asset NFT data from the server for authentication, receives setting information of the time NFT data from the electronic device, And if authentication confirmation for the asset NFT data is not received from the server for authentication, the first response notifying that generation of the time NFT data is impossible may be transmitted to the electronic device.

In one embodiment, the server device may perform addition of a new aggregator not included in the plurality of aggregators, deletion of at least one aggregator among the plurality of aggregators, and the plurality of aggregators. It may include an aggregator manager for managing information about aggregators of .

In one embodiment, the aggregator manager identifies an additional request of the additional aggregator, determines whether the additional aggregator has been verified by a consortium on the blockchain network through the blockchain network, and , When it is determined that the additional aggregator has been verified, a table related to the additional aggregator is created, the type of TC data to which the additional aggregator has access is identified and stored in the table, and the additional aggregator Information on conditions for calling an aggregator is identified and stored in the table, input values of the additional aggregator, information on a function used by the additional aggregator to generate CV data Can be identified and stored in the table.

In one embodiment, the server device receives a storage request for first TC (task contract) data, and determines whether the first TC data corresponds to a first type that is stored without checking integrity. and if it is determined that the first TC data corresponds to the first type, the first TC data is stored through the blockchain network, and the first TC data does not correspond to the first type. If it is determined that the first TC data has no integrity, it is determined whether the first TC data has integrity indicating that there is no error or unbuffered information, and when it is determined that the first TC data has integrity, the first TC data is stored through the blockchain network, and when it is determined that the first TC data does not have integrity, the first TC data is stored in a first queue, and the first TC data stored in the first queue Recovery may be performed on 1 TC data to generate 2 TC data, and the 2 TC data may be stored in the blockchain network.

A server device according to various embodiments disclosed in this document may be various types of devices. The server device may include, for example, a display device, a portable communication device (eg, a smart phone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. The server device according to the embodiment of this document is not limited to the above-mentioned devices.

A server device according to various embodiments disclosed in this document may be various types of devices. The server device may include, for example, a display device, a portable communication device (eg, a smart phone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. The server device according to the embodiment of this document is not limited to the above-mentioned devices.

Various embodiments of this document and terms used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. For example, a component expressed in the singular number should be understood as a concept including a plurality of components unless the context clearly means only the singular number. It should be understood that the term 'and/or' as used herein encompasses any and all possible combinations of one or more of the listed items. Terms such as 'include,' 'have,' and 'consist of' used in this disclosure are only intended to designate that the features, components, parts, or combinations thereof described in this disclosure exist, and the use of these terms is not intended to exclude the possibility of the presence or addition of one or more other features, components, parts or combinations thereof. In this document, "A or B", "at least one of A and B", "at least one of A or B", "A, B or C", "at least one of A, B and C", and "A Each of the phrases such as "at least one of , B, or C" may include any one of the items listed together in that phrase, or all possible combinations thereof. Terms such as "first", "second", or "first" or "secondary" may simply be used to distinguish a given component from other corresponding components, and may be used to refer to a given component in another aspect (eg, importance or order) is not limited.

The terms "~unit" or "~module" used in various embodiments of this document may include a unit implemented as hardware, software, or firmware, and may include, for example, logic, logic blocks, components, or circuits. The same terms can be used interchangeably. "~unit" or "~module" may be an integrally constituted component or a minimum unit or part of the component that performs one or more functions. For example, according to one embodiment, “~ unit” or “~ module” may be implemented in the form of an application-specific integrated circuit (ASIC).

The term "if" used in various embodiments of this document is interpreted to mean "when" or "when" or "in response to determining" or "in response to detecting" depending on the context. It can be. Similarly, "if it is determined" or "if is detected" is meant to mean "upon determining" or "in response to determining", or "upon detecting" or "in response to detecting", depending on the context. can be interpreted

Programs executed by the server device 200 described in this document may be implemented as hardware components, software components, and/or a combination of hardware components and software components. A program can be executed by any system capable of executing computer readable instructions.

Software may include a computer program, code, instructions, or a combination of one or more of the foregoing, which configures a processing device to operate as desired or processes independently or collectively. The device can be commanded. Software may be implemented as a computer program including instructions stored in computer-readable storage media. Computer-readable storage media include, for example, magnetic storage media (eg, ROM (Read-Only Memory), RAM (Random-Access Memory), floppy disk, hard disk, etc.) and optical reading media (eg, CD-ROM) (CD-ROM) and DVD (Digital Versatile Disc). Computer-readable storage media may be distributed among networked computer systems so that computer-readable codes may be stored and executed in a distributed manner. The computer program may be distributed (eg downloaded or uploaded) online, via an application store (eg Play Store™) or directly between two user devices (eg smart phones). In the case of online distribution, at least part of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium such as a manufacturer's server, an application store server, or a relay server's memory.

According to various embodiments, each component (eg, module or program) of the above-described components may include a single object or a plurality of entities, and some of the plurality of entities may be separately disposed in other components. there is. According to various embodiments, one or more components or operations among the aforementioned corresponding components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (eg modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by a corresponding component of the plurality of components prior to the integration. . According to various embodiments, the actions performed by a module, program, or other component are executed sequentially, in parallel, iteratively, or heuristically, or one or more of the actions are executed in a different order, or omitted. or one or more other actions may be added.

Claims (6)

A plurality of user devices generating and transmitting TC (task contract) data to a server device;
Receiving TC data from the plurality of user devices, generating CV data based thereon, adding a new aggregator not included in the plurality of aggregators, among the plurality of aggregators A server device including an aggregator manager for deleting at least one aggregator and managing information about the plurality of aggregators,
The plurality of user devices include a device corresponding to an employer providing a task, a device corresponding to a worker performing a task provided by the employer,
The server device:
Store the TC data through a blockchain network;
generating CV data based on TC data through the plurality of aggregators;
Transmitting the TC data and the CV data to the user's device through an application programming interface (API) according to the user's request;
The aggregator manager:
identify an additional request from the additional aggregator;
Determining whether the additional aggregator has been verified by the consortium on the blockchain network through the blockchain network;
When determining that the additional aggregator has been verified, create a table relating to the additional aggregator;
Identifying the type of TC data to which the additional aggregator has access authority and storing it in the table;
Identifying and storing information on conditions for calling the additional aggregator in the table;
The system that identifies input values of the additional aggregator and information about a function used by the additional aggregator to generate CV data and stores them in the table. The method of claim 1,
The server device receives a task contract (TC) of the first device for a first task from a first device, and receives the first task from a second device matching the first device. Receive a TC of the second device for the first task, generate first TC data based on the TC of the first device for the first task and the TC of the second device for the first task, and 1 A system for setting a first TC table including information about devices and applications having access to TC data. The method of claim 1,
The server device,
Receiving a request for generating time NFT data from any one of the plurality of user devices,
Identify asset NFT data corresponding to the generation request of the time NFT data,
Receiving information about the asset NFT data from the blockchain network;
Based on the information about the asset NFT data, determining whether the asset NFT data is of a first type,
When it is determined that the asset NFT data is not the first type, a first response is transmitted to the electronic device indicating that generation of the time NFT data is impossible;
When it is determined that the asset NFT data is the first type, a request for authentication of the asset NFT data is transmitted to a server for authentication of NFT data,
When receiving authentication confirmation for the asset NFT data from the server for authentication, receiving setting information of the time NFT data from the electronic device, and
When not receiving authentication confirmation for the asset NFT data from the server for authentication, transmitting the first response indicating that generation of the time NFT data is impossible to the electronic device. delete delete The method of claim 1,
The server device,
Receive a storage request for the first TC data;
determining whether the first TC data corresponds to a first type stored without checking integrity;
When it is determined that the first TC data corresponds to the first type, the first TC data is stored through the blockchain network;
When it is determined that the first TC data does not correspond to the first type, determining whether the first TC data has integrity indicating that there is no error or unbuffered information;
When it is determined that the first TC data has integrity, the first TC data is stored through the blockchain network;
storing the first TC data in a first queue when determining that the first TC data has no integrity;
The system of performing recovery on the first TC data stored in the first queue to generate second TC data, and storing the second TC data in the blockchain network.

Images