Dual nft-based medical data management method and apparatus

Abstract

A Dual NFT-based medical data management method performed by an electronic device is disclosed. The Dual NFT-based medical data management method comprises the steps of: issuing a first token containing ownership information for medical data on a blockchain network; issuing a second token containing usage right information for medical data on a blockchain network; connecting the first token and the second token as a single contract session unit based on an identifier commonly assigned to the first token and the second token; determining the next state of the first token and the second token according to a state transition rule stored in an electronic device based on current state information of the first token and the second token connected as a contract session unit; synchronizing and updating the state of the first token and the second token using the determined next state as a reference state; and managing the relationship between ownership and usage rights for medical data by performing control logic linked to the contract session based on the updated state information of the first token and the second token.

Description

Technology Field

[0001] The present disclosure relates to a dual NFT-based medical data management method and apparatus. Background Technology

[0002] With the advancement of medical information systems, hospitals, medical institutions, and research institutes manage various medical data, such as patient treatment records, medical images, test results, and prescription information, in electronic form. Medical data can be stored and managed through medical information systems such as Electronic Medical Record (EMR) systems, Picture Archiving and Communication Systems (PACS), and Hospital Information Systems (HIS). Medical institutions utilize these systems to store and manage medical data and can leverage this data in the process of providing medical services.

[0003] Medical data can be data containing information regarding a patient's health status and treatment process. It can be used by medical professionals in the process of diagnosis and treatment decision-making, and can also be utilized in medical research and the formulation of health policies. Recently, the scope of medical data utilization has been expanding for data sharing between medical institutions, medical artificial intelligence training, and medical big data analysis. Medical data can be managed in a structure where it is stored on data servers or central data repositories.

[0004] In a data management structure based on a central repository, difficulties may arise in clearly managing the rights and relationships regarding medical data. When the owner of medical data differs from the user, it may be difficult to systematically manage the scope and duration of data usage. If management procedures, such as data usage contracts, approval, and termination, are handled through separate management systems or manual processes, the efficiency of managing data usage history may be reduced. Furthermore, if the relationship between medical data usage rights and data ownership is not clearly documented, the transparency of the data usage process may be compromised. The problem to be solved

[0005] One embodiment aims to provide a Dual NFT-based medical data management method and apparatus capable of managing ownership and usage rights of medical data separately.

[0006] One embodiment aims to provide a Dual NFT-based medical data management method and apparatus capable of systematically managing the rights relationship of medical data based on a token representing ownership information of medical data and a token representing usage rights information of medical data.

[0007] One embodiment aims to provide a Dual NFT-based medical data management method and apparatus capable of automatically managing the medical data usage status by processing state changes occurring during the medical data usage contract process based on rules.

[0008] One embodiment aims to provide a Dual NFT-based medical data management method and apparatus that can improve the control of medical data usage and security by automatically allowing or blocking access to data depending on the usage status of the medical data.

[0009] One embodiment aims to provide a Dual NFT-based medical data management method and apparatus that can improve the transparency and reliability of the medical data usage process by managing the history of status changes regarding the ownership and usage rights of medical data.

[0010] However, the problems that the present invention aims to solve are not limited to those mentioned above, and may include problems that are not mentioned but can be clearly understood by those skilled in the art from the description below. means of solving the problem

[0011] A Dual NFT-based medical data management method performed by an electronic device according to one or more embodiments of the present disclosure comprises: issuing a first token containing ownership information for medical data on a blockchain network; issuing a second token containing usage right information for medical data on a blockchain network; connecting the first token and the second token in a single contract session unit based on an identifier commonly assigned to the first token and the second token; determining the next state of the first token and the second token according to a state transition rule stored in an electronic device based on current state information of the first token and the second token connected in a contract session unit; synchronizing and updating the state of the first token and the second token with the determined next state as a reference state; and managing the relationship between ownership and usage rights for medical data by performing control logic linked to the contract session based on the updated state information of the first token and the second token.

[0012] An electronic device according to one or more embodiments of the present disclosure comprises a processor and a memory connected to the processor, wherein the memory is configured to store a program and the processor is configured to execute the program, and when the program is executed, a Dual NFT-based medical data management method is implemented. Effects of the invention

[0013] One embodiment allows for clear management of the rights relationship of medical data by separating and managing the ownership and usage rights of medical data into different token structures.

[0014] One embodiment allows for the systematic management of rights relationships arising during the use of medical data by linking and managing ownership tokens and usage rights tokens for medical data on a contract session basis.

[0015] One embodiment can automatically change the state of a token according to state transition rules, so the usage status of medical data can be managed based on rules.

[0016] One embodiment can automatically allow or block access to data based on the medical data usage status, thereby improving security during the medical data usage process.

[0017] One embodiment can improve the traceability of medical data usage history by recording changes in the ownership and usage rights status of medical data. Brief explanation of the drawing

[0018] FIG. 1 is a diagram illustrating a Dual NFT-based medical data management process according to one or more embodiments. FIG. 2 is a flowchart illustrating a Dual NFT-based medical data management method according to one or more embodiments. FIG. 3 is a flowchart for explaining a first token issuance method according to one or more embodiments. FIG. 4 is a flowchart for explaining a second token issuance method according to one or more embodiments. FIG. 5 is a flowchart illustrating a method for connecting a contract session according to one or more embodiments. FIG. 6 is a flowchart illustrating a method for configuring session mapping information according to one or more embodiments. FIG. 7 is a flowchart illustrating a method for setting rights dependency relationships and state synchronization rules according to one or more embodiments. FIG. 8 is a flowchart illustrating a method for determining the following state according to one or more embodiments. FIG. 9 is a flowchart illustrating a method for determining whether a state transition condition is satisfied according to one or more embodiments. FIG. 10 is a drawing for explaining a first token state determination method according to one or more embodiments. FIG. 11 is a flowchart illustrating a method for state synchronization and state information update according to one or more embodiments. FIG. 12 is a flowchart illustrating a method for allowing access to medical data according to one or more embodiments. FIG. 13 is a flowchart illustrating a method for blocking access to medical data and restoring the state according to one or more embodiments. FIG. 14 is a block diagram illustrating the configuration of an electronic device according to one or more embodiments. Specific details for implementing the invention

[0019] The various embodiments described in this specification are illustrative for the purpose of clearly explaining the technical concept of this disclosure and are not intended to limit it to specific embodiments. The technical concept of this disclosure includes various modifications, equivalents, alternatives, and embodiments optionally combined from all or part of each embodiment described in this specification. Furthermore, the scope of the technical concept of this disclosure is not limited to the various embodiments presented below or the specific descriptions thereof.

[0020] Terms used in this specification, including technical or scientific terms, may have the meaning generally understood by those skilled in the art to which this disclosure pertains, unless otherwise defined.

[0021] Expressions used herein such as “comprising,” “may compose,” “possessing,” “possessing,” “having,” and “possessing” imply the existence of the subject feature (e.g., function, operation, or component, etc.) and do not exclude the existence of other additional features. That is, such expressions should be understood as open-ended terms implying the possibility of including a second embodiment.

[0022] In this specification, singular expressions include plural expressions unless the context clearly specifies them as singular. Additionally, plural expressions include singular expressions unless the context clearly specifies them as plural. Throughout the specification, when a part is described as including a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components.

[0023] Additionally, the terms 'module' or 'part' as used in the specification refer to software or hardware components, and the 'module' or 'part' performs certain roles. However, the meaning of 'module' or 'part' is not limited to software or hardware. The 'module' or 'part' may be configured to reside in an addressable storage medium or configured to run on one or more processors. Thus, as an example, the 'module' or 'part' may include components such as software components, object-oriented software components, class components, and task components, and at least one of processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, or variables. The components and the functions provided within the 'module' or 'part' may be combined into a smaller number of components and 'modules' or 'parts', or further separated into additional components and 'modules' or 'parts'.

[0024] According to one embodiment of the present disclosure, a ‘module’ or ‘part’ may be implemented as a processor and memory. The term ‘processor’ should be broadly interpreted to include a general-purpose processor, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a controller, a microcontroller, a state machine, etc. In some environments, the term ‘processor’ may refer to an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), etc. The term ‘processor’ may also refer to a combination of processing devices, such as, for example, a combination of a DSP and a microprocessor, a combination of multiple microprocessors, a combination of one or more microprocessors combined with a DSP core, or any other combination of such configurations. Additionally, the term ‘memory’ should be broadly interpreted to include any electronic component capable of storing electronic information. 'Memory' may refer to various types of processor-readable media, such as Random Access Memory (RAM), Read-Only Memory (ROM), Non-Volatile Random Access Memory (NVRAM), Programmable Read-Only Memory (PROM), Erasable-Programmable Read-Only Memory (EPROM), Electrically Erasable PROM (EEPROM), Flash Memory, Magnetic or Optical Data Storage Devices, Registers, etc. If a processor can read information from memory and / or write information to memory, the memory is said to be in an electronic communication state with the processor. Memory integrated into a processor is in an electronic communication state with the processor.

[0025] Expressions such as "first," "second," or "first," "second" as used in this specification are used to distinguish one object from another when referring to a plurality of objects of the same kind, unless otherwise indicated in the context, and do not limit the order or importance of said objects.

[0026] Expressions used herein such as “A, B, and C,” “A, B, or C,” “A, B, and / or C,” or “at least one of A, B, and C,” “at least one of A, B, or C,” “at least one of A, B, and / or C,” “at least one selected from A, B, and C,” “at least one selected from A, B, or C,” “at least one selected from A, B, and / or C,” etc., may mean each of the listed items or all possible combinations of the listed items. For example, “at least one selected from A and B” may refer to (1) A, (2) at least one of A, (3) B, (4) at least one of B, (5) at least one of A and at least one of B, (6) at least one of A and B, (7) at least one of B and A, and (8) all of A and B.

[0027] As used herein, the expression “based on” is used to describe one or more factors affecting an act or action of a decision or judgment described in the phrase or sentence containing such expression, and such expression does not exclude additional factors affecting said act or action of a decision or judgment.

[0028] As used in this specification, the expression that a certain component (e.g., a first component) is "connected" or "connected" to another component (e.g., a second component) may mean that the said certain component is not only directly connected or connected to the said other component, but is also connected or connected through a new other component (e.g., a third component).

[0029] As used herein, the expression "configured to" may have meanings such as "set to," "capable of," "modified to," "made to," or "capable of." Such expression is not limited to the meaning of "specifically designed in hardware," and, for example, a processor configured to perform a specific operation may mean a generic-purpose processor capable of performing that specific operation by executing software.

[0030] Various embodiments of the present disclosure will be described below with reference to the accompanying drawings. In the accompanying drawings and the description thereof, identical or substantially equivalent components may be given the same reference numerals. Furthermore, in the description of the various embodiments below, the description of identical or corresponding components may be omitted, but this does not mean that such components are not included in the embodiments.

[0031] FIG. 1 is a diagram illustrating a Dual NFT-based medical data management process according to one or more embodiments.

[0032] Referring to FIG. 1, an electronic device according to one embodiment can manage the rights relationship of medical data by issuing ownership and usage rights for medical data as a provider NFT (Non-Fungible Token) (10) and a user NFT (20), respectively, and by connecting the provider NFT (10) and the user NFT (20) into a single contract session and synchronizing the state of the NFTs according to state transition rules. Here, the electronic device can be implemented as various types of electronic devices such as a mobile phone, a smartphone, a personal computer (PC), a tablet PC, a wearable device, an artificial intelligence (AI) device, etc.

[0033] A provider NFT (10) is a token representing ownership information for medical data and may be a digital rights object for identifying the rights holder of medical data and expressing rights information for medical data. A provider NFT (10) may be a non-fungible token created and recorded on a blockchain network. A provider NFT (10) may be a unique identification token created to correspond to a single piece of medical data or a set of medical data to represent ownership of specific medical data.

[0034] The provider NFT (10) may include a metadata structure that includes data identification information for identifying medical data, owner identification information for identifying the owner of the medical data, and a hash value for verifying the integrity of the medical data. The provider NFT (10) may be a rights information object that expresses the corresponding relationship between the rights holder of the medical data and the medical data through the metadata.

[0035] For example, a provider NFT (10) may include metadata including data identification information for a specific patient's diagnostic image data, owner identification information for identifying the patient or medical data provider, and a hash value generated from the diagnostic image data.

[0036] A user NFT (20) is a token representing information on the right to use medical data, and may be a digital right object for identifying the subject who can use the medical data and expressing information on the right to use the medical data. A user NFT (20) may be a non-fungible token created and recorded on a blockchain network. A user NFT (20) may be a unique identification token created to correspond to a single piece of medical data or a set of medical data to represent the right to use specific medical data.

[0037] The user NFT (20) may include a metadata structure that includes user identification information to identify the user who requested the use of medical data, data identification information to identify the medical data to be used, and usage information indicating the conditions for using the medical data. The user NFT (20) may be a right information object that expresses the usage relationship between the subject using the medical data and the medical data through the metadata.

[0038] For example, a user NFT (20) may be created in response to a request to use a specific patient's diagnostic image data for research purposes for a certain period. The user NFT (20) may include metadata including user identification information to identify a research institution, data identification information to identify the diagnostic image data to be used, and usage condition information indicating the purpose and duration of use of the medical data.

[0039] According to one embodiment, the electronic device can connect a supplier NFT (10) and a demander NFT (20) into a single contract session (30) using a smart contract.

[0040] A smart contract can be execution logic that defines relationships between tokens and applies state transition rules. A smart contract can be contract execution logic in the form of program code executed on a blockchain network. A smart contract can be configured to automatically perform specific actions according to predefined conditions and rules.

[0041] For example, a smart contract may be configured to perform processing operations such as the creation of a supplier NFT (10) and a demander NFT (20), the formation of a contract session, token state transitions, and state synchronization. The smart contract may determine whether conditions are met by referring to state information and contract session information recorded on the blockchain network, and execute logic to change the state of the token or control rights relationships based on the result of the determination.

[0042] According to one embodiment, the electronic device can automatically perform a transaction for medical data based on a contract session (30) structure. The electronic device can perform transaction execution, transaction settlement, and transaction termination operations in response to changes in the state of the provider NFT (10) and the demander NFT (20). For example, the electronic device can control the execution of a transaction regarding the use of medical data or the settlement of said transaction when transaction conditions are met according to a state transition rule.

[0043] According to one embodiment, an electronic device can manage the ownership and usage rights of medical data separately using a token-based rights structure. In conventional medical data management methods, there was a problem in that it was difficult to clearly distinguish the relationship of rights because data ownership and usage rights were processed collectively within the same system.

[0044] According to one example, the electronic device can systematically manage medical data rights relationships by creating a supplier NFT (10) and a consumer NFT (20) separately and linking the states of the supplier NFT (10) and the consumer NFT (20) through a smart contract (40). For convenience of explanation, the supplier NFT (10) will be referred to as the first token and the consumer NFT (20) as the second token.

[0045] Below, with reference to the drawings, the process by which an electronic device performs a Dual NFT-based medical data management method will be explained in detail.

[0046] FIG. 2 is a flowchart illustrating a Dual NFT-based medical data management method according to one or more embodiments.

[0047] Referring to FIG. 2, an electronic device according to one embodiment issues a first token containing ownership information for medical data and a second token containing usage rights information for medical data, and then connects the first token and the second token into a single contract session to manage rights relationships according to state transitions.

[0048] According to one embodiment, the electronic device may issue a first token containing ownership information for medical data on a blockchain network (S210).

[0049] The electronic device can acquire data identification information corresponding to medical data and owner identification information for the medical data. Based on the acquired data identification information and owner identification information, the electronic device can verify whether it holds ownership of the medical data. If ownership is verified, the electronic device can generate a hash value from the medical data for integrity verification. The electronic device can configure the metadata of the first token to include the result of verifying ownership and the hash value. The electronic device can transmit and record the first token containing the metadata on a blockchain network.

[0050] According to one example, an electronic device may generate a first token as a digital rights token representing ownership information regarding medical data. The first token may be a non-fungible token representing a correspondence between the subject of rights to the medical data and the medical data. The first token may include metadata including data identification information for identifying the medical data, owner identification information for identifying the owner, and a hash value for verifying integrity. However, not limited thereto, the first token may be referred to as an ownership token or a rights standard token.

[0051] For example, an electronic device may generate a first token that includes data identification information corresponding to the diagnostic image data of a specific patient, owner identification information for identifying the patient, and a hash value generated from the diagnostic image data.

[0052] According to one embodiment, the electronic device may issue a second token containing information on the right to use medical data on a blockchain network (S220).

[0053] The electronic device can obtain information regarding a request for use of medical data. The electronic device can identify information regarding the purpose of use and the period of use included in the request for use information. The electronic device can determine whether the information regarding the purpose of use and the period of use falls under the conditions set in the first token. If it falls under the conditions set in the first token, the electronic device can configure the metadata of the second token to include the information regarding the purpose of use and the period of use. The electronic device can transmit and record the second token along with the metadata to a blockchain network.

[0054] According to one example, an electronic device may generate a second token as a digital rights token representing information regarding the right to use medical data. The second token may be a non-substitutable token representing the subject who can use specific medical data, the purpose of use, the period of use, and the scope of use. The second token may be a rights-dependent token generated within the scope of conditions set by the first token. However, not limited thereto, the second token may be referred to as a right token or an access token. For example, the electronic device may generate a second token containing information that allows a research institution to use the diagnostic imaging data of a specific patient for a certain period.

[0055] According to one embodiment, the electronic device can connect the first token and the second token as a single contract session unit based on an identifier commonly assigned to the first token and the second token (S230).

[0056] An identifier may be unique identification information assigned to link a first token and a second token to the same contract session. An identifier may be a reference value for establishing a correspondence between an ownership token and a usage token for specific medical data. An identifier may be a reference value for managing the connection relationships between tokens recorded on a blockchain network. An identifier may be composed in the form of a string, a hash value, or a unique identification code.

[0057] For example, the electronic device can generate an identifier based on data identification information of specific medical data and contract creation time information. By assigning the identifier to both the first token and the second token in common, the electronic device can configure the two tokens to be included in the same contract session.

[0058] A contract session may be a logical management unit established to manage the rights relationship between a first token and a second token. A contract session may be a session information structure for linking an ownership token and a usage right token corresponding to the same medical data into a single transaction unit.

[0059] A contract session may be a set of management information including a common identifier, a token identification value, state information, and state transition rules. A contract session may be a management structure for tracking state changes of the first token and the second token and applying state transition rules.

[0060] For example, when a first token and a second token are generated for specific medical data, the electronic device may assign a common identifier to the first token and the second token and create a contract session based on the assigned identifier. Through the contract session, the electronic device may synchronize the status of the first token and the second token and manage transaction conditions related to the use of medical data. However, not limited thereto, the contract session may be referred to as a rights session, a token linkage session, or a transaction session.

[0061] According to one embodiment, the electronic device can determine the next state of the first token and the second token based on the current state information of the first token and the second token connected in a contract session unit, according to the state transition rule stored in the electronic device (S240).

[0062] Current status information may be status data representing the current rights status of the first token and the second token. Current status information may consist of predefined status values ​​to express the rights status of the tokens. Current status information may be set to one of the status values ​​such as available status, usage commencement status, usage termination status, or usage restriction status.

[0063] For example, the electronic device may determine that medical data usage is in progress if the current status information of the second token is set to a usage start state. The electronic device may determine that medical data usage has ended if the current status information of the second token is changed to a usage end state.

[0064] A state transition rule may be rule information that defines whether the state of the first token and the second token changes to a specific state under specific conditions. A state transition rule may be a set of rules for determining the next state based on the token's current state and whether a condition occurs within a contract session. A state transition rule may be rule information stored in an electronic device and serve as a management standard for controlling the state change process of the first token and the second token.

[0065] A state transition rule may be a rule structure including a current state, a transition condition, and a corresponding state. A state transition rule may be rule information defined to transition to the next state when a condition corresponding to the current state is satisfied. A state transition rule may include transition conditions such as event occurrence conditions, usage period expiration conditions, or usage restriction violation conditions. A state transition rule may be defined to change the states of the first token and the second token depending on whether the transition conditions are satisfied.

[0066] For example, the electronic device may set a state transition rule to transition the state of the second token to a usage termination state when the current state of the second token is a usage commencement state and the usage period expiration condition is satisfied. The electronic device may set a state transition rule to change the state of the first token to a lock state when the state of the second token transitions to a usage restriction state. By synchronizing and updating the states of the first token and the second token according to the state transition rule, the electronic device can manage the relationship between ownership and usage rights for medical data according to consistent rules.

[0067] According to one embodiment, the electronic device can synchronize and update the states of the first token and the second token with the determined next state as the reference state (S250).

[0068] The electronic device can identify the next state of the first token and the next state of the second token, respectively, determined according to state transition rules. The electronic device can update the current state information of the first token based on the identified next state of the first token. The electronic device can update the current state information of the second token based on the identified next state of the second token. The electronic device can record the updated current state information of the first token and the updated current state information of the second token on a blockchain network.

[0069] According to one example, the electronic device may perform state synchronization as an update process to maintain the rights relationship between the first token and the second token consistent within the same contract session. State synchronization may be a process that adjusts the state to correspond to the progress of the same contract session, even if the two tokens have different rights contents. State synchronization may be a process that updates the state of the first token to a maintenance state, a locked state, or a terminated state in response to a change in the state of the second token. For example, if the second token changes to a restricted use state, the electronic device may update the first token to a locked state, and if the second token changes to a terminated use state, the first token may update to a terminated state or a state prior to the start of use.

[0070] According to one embodiment, the electronic device can manage the relationship between ownership and usage rights for medical data by performing control logic linked to a contract session based on the status information of the updated first token and second token (S260).

[0071] The electronic device can determine whether the state of the first token is in a valid ownership state based on the updated state information of the first token. The electronic device can determine whether the state of the second token is in an available state based on the updated state information of the second token.

[0072] The electronic device may allow access to medical data if the status of the first token is a valid ownership state and the status of the second token is an available state. The electronic device may block access to medical data if the status of the second token corresponds to either a terminated use state or a restricted use state. If the status of the second token is a terminated use state, the electronic device may block access to medical data and restore the status of the first token to the state prior to the commencement of use.

[0073] According to one example, the electronic device may execute control logic linked to a contract session as a control rule to perform at least one of allowing access to medical data, restricting access, maintaining rights, terminating rights, and restoring the state. The control logic may be execution logic that reflects the rights relationship regarding medical data in actual operation according to updated token state information. The control logic may be executed by being included in a smart contract or implemented as a control program executed by the processor of the electronic device. However, not limited thereto, the control logic may be referred to as rights control logic, session control logic, or access control logic. For example, the electronic device may allow viewing of medical data when the first token is in a valid ownership state and the second token is in an available state, and may block the replication or transmission of medical data when the second token is in a restricted use state.

[0074] FIG. 3 is a flowchart for explaining a first token issuance method according to one or more embodiments.

[0075] Referring to FIG. 3, an electronic device according to one embodiment can obtain data identification information corresponding to medical data and owner identification information for medical data, verify whether ownership is held, and then configure metadata including a hash value to record a first token on a blockchain network.

[0076] According to one embodiment, the electronic device can obtain data identification information corresponding to medical data and owner identification information for medical data (S310).

[0077] The electronic device can acquire identification items for identifying medical data. The electronic device can acquire identification items for identifying the rights holder of the medical data. The electronic device can store data identification information and owner identification information as basic information for issuing the first token.

[0078] According to one example, an electronic device may acquire data identification information as identification information to identify the medical data itself. The data identification information may be information including at least one of a data identification value, creation time information, data type information, or storage location information. The data identification information may be unique information distinguished by medical data unit. For example, the electronic device may acquire a data number, creation time, and image type information corresponding to the diagnostic image data of a specific patient as data identification information.

[0079] According to one example, an electronic device may acquire owner identification information as information for identifying the subject of rights to medical data. Owner identification information may be information including at least one of a patient identification value, user account information, a distributed identifier, or institutional registration information. Owner identification information may be reference information for identifying the subject to whom rights to medical data belong. However, not limited thereto, owner identification information may be referred to as rights holder identification information, provider identification information, or user identification information. For example, the electronic device may acquire a distributed identifier corresponding to a specific patient and medical data provider registration information as owner identification information.

[0080] According to one embodiment, the electronic device can verify whether it holds ownership of medical data based on data identification information and owner identification information (S320).

[0081] The electronic device can verify the correspondence between data identification information and owner identification information. The electronic device can determine whether it holds ownership of medical data by referring to stored rights information or registration information. The electronic device can use the result of verifying ownership as reference information for determining whether to issue the first token.

[0082] According to one example, an electronic device may perform a verification of ownership as a procedure to determine whether the correspondence between medical data and the rights holder is valid. The result of the verification of ownership may be expressed as a result value among confirmed, unconfirmed, or restricted confirmation. The result of the verification of ownership may be rights confirmation information included in the metadata of the first token. For example, the electronic device may determine that ownership is confirmed if the data identification information of specific image data matches the owner identification information corresponding to a specific patient.

[0083] According to one embodiment, if ownership is confirmed, the electronic device can generate a hash value for integrity verification from medical data (S330).

[0084] The electronic device can generate a fixed-length hash value by applying a hash function to medical data. The electronic device can use the generated hash value as a reference value to verify the identity of the medical data. The electronic device can store the hash value in a temporary storage area before including it in the metadata of the first token.

[0085] For example, an electronic device may generate a hash value as integrity verification information generated in correspondence with the content of medical data. The hash value may be a fixed-length data value generated to verify the integrity of medical data. The hash value may be verification information produced by applying a hash function to medical data. The hash value may be generated as the same value for the same medical data, or as a different value if the content of the medical data is changed. The hash value may be a verification criterion value to check whether the medical data has been altered. For example, the electronic device may generate a hash value by applying a SHA-family hash algorithm to a specific diagnostic image file. However, not limited thereto, the hash value may be referred to as an integrity verification value, a data verification value, or an original verification value.

[0086] According to one embodiment, the electronic device may configure the metadata of the first token to include a result of verifying ownership and a hash value (S340).

[0087] The electronic device may place the result of ownership verification in the rights information item of the metadata. The electronic device may place the hash value in the integrity information item of the metadata. The electronic device may configure the metadata to include data identification information and owner identification information together.

[0088] According to one example, the electronic device may configure metadata as a set of supplementary information included in a first token. The metadata may be an information structure including rights information, data identification information, owner identification information, and integrity verification information. The metadata may be descriptive information indicating which medical data the first token corresponds to, who the rights holder is, and whether the said medical data has not been altered. However, not limited thereto, the metadata may be referred to as token descriptive information, rights descriptive information, or supplementary information. For example, the electronic device may configure a data number, patient identifier, ownership verification result, and hash value for a specific patient's diagnostic image data as a single set of metadata.

[0089] According to one embodiment, the electronic device can transmit and record a first token containing metadata to a blockchain network (S350).

[0090] The electronic device can generate a first token combined with metadata as data to be recorded on a blockchain network. The electronic device can transmit the first token to the blockchain network and process it to be recorded on a distributed ledger. The electronic device can use the recorded first token as a right reference token representing ownership information for medical data.

[0091] According to one example, the electronic device may record the first token as a non-fungible token uniquely identified on a blockchain network. For example, the electronic device may record the first token, which includes a result of verifying ownership of diagnostic image data of a specific patient and a hash value, on a blockchain network, and use the first token as a reference token for subsequent usage right verification.

[0092] FIG. 4 is a flowchart for explaining a second token issuance method according to one or more embodiments.

[0093] Referring to FIG. 4, an electronic device according to one embodiment receives information on a request for use of medical data, configures metadata of a second token based on information on the purpose of use and period of use included in the request for use information, and then records the second token on a blockchain network.

[0094] According to one embodiment, the electronic device can receive information regarding a request for use of medical data (S410).

[0095] The electronic device may receive request data requesting the use of medical data from an external terminal or institutional system. The electronic device may store the received request data as input information for determining whether to issue a second token.

[0096] According to one example, an electronic device may process use request information as request information transmitted by a subject who wishes to use medical data. The use request information may be request information that includes at least one of information on the user, information on the target of use, information on the purpose of use, and information on the period of use. The use request information may be reference information for determining whether specific medical data is available for use. However, not limited thereto, the use request information may be referred to as use application information, access request information, or usage request information. For example, the electronic device may receive research use request information regarding diagnostic imaging data of a specific patient from a research institution server.

[0097] According to one embodiment, the electronic device can identify the purpose of use and the period of use information included in the request for use information (S420).

[0098] The electronic device can obtain purpose and period items by distinguishing them from the usage request information. The electronic device can store the identified usage purpose and usage period information as condition information for use in configuring the metadata of the second token.

[0099] According to one example, an electronic device may identify information regarding the purpose of use as information indicating the use of medical data. The information regarding the purpose of use may be information indicating at least one of research, insurance review, clinical analysis, or service provision. The information regarding the period of use may be information indicating the start time, end time, or period during which the use of medical data is permitted. For example, the electronic device may identify information regarding the purpose of research and the period of use from January 1, 2026, to March 31, 2026, from the information regarding the request for use.

[0100] According to one embodiment, the electronic device can determine whether information regarding the purpose of use and the period of use is included in the conditions set in the first token (S430).

[0101] The electronic device may refer to condition information stored in the first token. The electronic device may determine whether the purpose of use and the period of use correspond to the condition information stored in the first token. The electronic device may use the result of the determination as a criterion for whether to allow the issuance of the second token.

[0102] According to one example, the electronic device may process the conditions set in the first token as reference information indicating the permitted scope of use of medical data. The conditions set in the first token may be rights conditions including at least one of a permitted purpose, a permitted period, a scope of use, or restrictions on use. The conditions set in the first token may be reference conditions for restricting the scope of issuance of the second token based on ownership of the medical data. For example, if the electronic device has conditions set in the first token for research purposes and use within three months, it may determine that use request information including a research purpose and a two-month usage period is included in the conditions.

[0103] According to one embodiment, the electronic device may configure the metadata of the second token to include information on the purpose of use and the period of use when the conditions are included (S440).

[0104] The electronic device may place identified usage purpose and usage period information in the usage condition item of the metadata. If information regarding the user subject and the target of use exists, the electronic device may configure the metadata to include such information as well. The electronic device may combine the configured metadata with a second token.

[0105] According to one example, the electronic device may configure metadata as a set of descriptive information attached to a second token. The metadata may be an information structure including at least one of information on the purpose of use, information on the period of use, information on the subject of use, and information on the target of use. The metadata may be descriptive information indicating to whom and to what extent the second token grants usage rights for certain medical data. For example, the electronic device may combine metadata including a research institution identifier, a research purpose, a start date of use, and a end date of use with the second token.

[0106] According to one embodiment, the electronic device can record the second token along with metadata by transmitting it to a blockchain network (S450).

[0107] The electronic device can generate a second token combined with metadata as data to be recorded on a blockchain network. The electronic device can transmit the second token to the blockchain network and process it to be recorded on a distributed ledger. The electronic device can use the recorded second token as a right token representing information on the right to use medical data.

[0108] According to one example, an electronic device may use a second token recorded on a blockchain network as reference information for usage rights linked to a first token. The second token recorded on the blockchain network may be token information referenced in the creation of contract sessions and state management. The second token recorded on the blockchain network may be information subject to state management that can transition to an available state, a restricted state, or a terminated state. For example, after recording a second token containing research purposes and a two-month usage period on the blockchain network, the electronic device may use the second token as a reference token for usage rights verification and access control.

[0109] FIG. 5 is a flowchart illustrating a method for connecting a contract session according to one or more embodiments.

[0110] Referring to FIG. 5, an electronic device according to one embodiment can connect a first token and a second token as a single contract session unit based on an identifier commonly assigned to the first token and the second token.

[0111] According to one embodiment, the electronic device can obtain a first token identification value for specifying a first token and a second token identification value for specifying a second token (S510).

[0112] The electronic device can obtain an identification value for distinguishing each token from the first token and the second token recorded on the blockchain network. The electronic device can store the obtained first token identification value and the second token identification value as basic information for establishing a contract session.

[0113] According to one example, an electronic device may acquire a first token identification value as unique information for individually identifying the first token. The first token identification value may be identification information for distinguishing the first token, which includes ownership information, from other tokens. The first token identification value may be a value including at least one of a token number, a token address, a token hash, or a token registration code. For example, the electronic device may acquire the registration number of the first token corresponding to the diagnostic image data of a specific patient as the first token identification value.

[0114] According to one example, an electronic device may acquire a second token identification value as unique information for individually identifying the second token. The second token identification value may be identification information for distinguishing the second token, which includes usage rights information, from other tokens. The second token identification value may be a value including at least one of a token number, a token address, a token hash, or a token registration code. For example, the electronic device may acquire the registration number of the second token issued in correspondence with a research institution as the second token identification value.

[0115] According to one embodiment, the electronic device may set an identifier commonly assigned to the first token and the second token as a reference value for distinguishing contract sessions (S520).

[0116] The electronic device can identify an identifier commonly included in the first token and the second token. The electronic device can set the identified identifier as a reference value used for the creation and differentiation of contract sessions. The electronic device can use the set reference value to determine whether the first token and the second token correspond to the same medical data transaction.

[0117] According to one example, an electronic device may set an identifier as common reference information to link a first token and a second token into a single contract session. For example, the electronic device may generate an identifier by combining data identification information of specific medical data and contract creation time information, and assign the generated identifier to both the first token and the second token.

[0118] According to one embodiment, the electronic device may generate session mapping information including a state transition rule for controlling the state transition of the first token and the second token in correspondence with a reference value (S530).

[0119] Session mapping information may be an information structure for connecting a first token and a second token as a single contract session unit and managing the state and relationship information of said tokens. Session mapping information may be management information that stores the correspondence relationship between two tokens, including a first token identification value, a second token identification value, and a common identifier. Session mapping information may be management data for managing state changes of tokens at the contract session unit, including current state information, a state management area, and state transition rules of the first token and the second token.

[0120] For example, an electronic device may register a first token identification value and a second token identification value in a single session mapping information based on a common identifier corresponding to specific medical data, and may store state transition rules corresponding to a usage initiation state, a usage termination state, and a usage restriction state together in the session mapping information. However, not limited thereto, the session mapping information may be referred to as session management information, token mapping information, or rights linkage information.

[0121] According to one embodiment, the electronic device can be configured so that the first token and the second token are included in the same contract session by registering the first token identification value and the second token identification value in the session mapping information (S540).

[0122] The electronic device can input a first token identification value and a second token identification value into the registration items of the session mapping information. The electronic device can assign the registered first token identification value and the second token identification value to a single contract session by associating them with a reference value. Accordingly, the electronic device can be configured so that the first token and the second token are treated as linked tokens belonging to the same contract session.

[0123] For example, an electronic device may establish a "same contract session" as a logical session to manage ownership and usage rights relationships for specific medical data as a single transaction unit. A same contract session may be a session unit to which state transition and control logic are applied, where a first token and a second token are bound together by a single rights relationship even if they exist independently. A same contract session may be a management unit that includes dependency relationships, state synchronization relationships, and control rule application relationships between tokens. For example, the electronic device may register a first token for a specific patient's diagnostic imaging data and a second token corresponding to a research institution's usage request into a single contract session, thereby configuring the device so that the state of the first token is updated together with changes in the state of the second token.

[0124] According to one example, the electronic device may additionally establish a right dependency relationship between a first token and a second token in the session mapping information. The right dependency relationship may be relationship information that causes the second token to be treated as a usage right corresponding to the first token. The right dependency relationship may be state synchronization reference information that causes the state of the first token to transition to a pre-configured corresponding state when the state of the second token changes. For example, the electronic device may establish a right dependency relationship such that the first token transitions to a locked state when the second token changes to a restricted usage state.

[0125] FIG. 6 is a flowchart illustrating a method for configuring session mapping information according to one or more embodiments.

[0126] Referring to FIG. 6, an electronic device according to one embodiment may configure session mapping information to include a state management area for storing state information of a first token and a second token corresponding to a reference value, and may store a state transition rule for controlling the state transition of the first token and the second token in the state management area.

[0127] According to one embodiment, the electronic device may configure session mapping information to include a state management area for storing state information of a first token and a second token corresponding to a reference value (S610).

[0128] The electronic device can generate session mapping information linked to a reference value. The electronic device can be configured to include a state management area within the session mapping information to separately store state information of the first token and the second token. The electronic device can manage the current state and change history of the first token and the second token using the state management area.

[0129] According to one example, the electronic device may configure session mapping information as management information to maintain corresponding relationships between tokens and state management information together at the contract session unit. For example, the electronic device may set a common identifier corresponding to specific medical data as a reference value and configure session mapping information including a state item of a first token and a state item of a second token corresponding to the reference value.

[0130] According to one example, the electronic device may configure a state management area as a storage area for managing the mutual correspondence relationship while storing the states of a first token and a second token separately. The state management area may be an area that includes a first state item in which the state value of the first token is stored and a second state item in which the state value of the second token is stored. The state management area may be an area that further includes information on the state update time or the state change sequence information in addition to the current state value. For example, the electronic device may store the state of the first token as an ownership-valid state and the state of the second token as an available state in the state management area.

[0131] According to one embodiment, the electronic device may store a state transition rule for controlling the state transition of the first token and the second token in a state management area (S620).

[0132] The electronic device can set transition conditions corresponding to the state of the first token and the state of the second token. The electronic device can store state transition rules in a state management area so that the next state is determined according to the transition conditions. The electronic device can synchronize and update the states of the first token and the second token at the contract session level by referring to the state transition rules.

[0133] According to one example, an electronic device may store a state transition rule as rule information including a current state, a transition condition, and a corresponding state. The state transition rule may be rule information for determining the next state of the first token and the second token based on whether an event has occurred, whether the usage period has expired, or whether a usage restriction has been violated. The state transition rule may be synchronization reference information that causes the state of the first token to change together in response to a change in the state of the second token. However, not limited thereto, the state transition rule may be referred to as a state control rule or a transition control rule. For example, the electronic device may store a state transition rule such that when the second token changes to a usage termination state, the first token changes to a termination state or a state prior to the start of use.

[0134] For example, the electronic device may set state transition rules stored in the state management area differently for each contract session. The electronic device may store different state transition rules depending on the type of medical data, the purpose of use, or the period of use. Using state transition rules, the electronic device may perform different state transition processing depending on the usage conditions of the connected second token, even if the first token is the same. For example, the electronic device may store a rule to transition the first token to a restored state after use ends in a contract session corresponding to use for research purposes, and may store a rule to transition the first token to a locked state in a contract session where a restriction violation has occurred.

[0135] For example, the electronic device may store a state transition rule that sets the state of the first token to a maintenance state when the usage period expires in a contract session corresponding to the use of medical data for educational purposes. The electronic device may control the first token to remain in a maintenance state without changing its state when the usage period of the second token expires.

[0136] For example, in a contract session corresponding to the use of medical data for commercial research purposes, the electronic device may store a state transition rule that transitions the state of the first token to a transaction completed state simultaneously with the end of the usage period. When the state of the second token changes to a usage terminated state, the electronic device may transition the state of the first token to a transaction completed state and process the transaction for the medical data as terminated.

[0137] For example, in a contract session corresponding to the use of data analysis for a limited period, the electronic device may store a state transition rule such that the state of the first token transitions to a restored state after a certain waiting period following the expiration of the usage period. The electronic device may process the transition of the state of the first token to a restored state after a certain period has elapsed following the change of the second token's state to a usage termination state, thereby enabling a new usage contract for the same medical data.

[0138] For example, in a contract session where a usage limit condition is set, the electronic device may store a state transition rule that transitions the state of the first token to a usage-restricted state when the usage count of the second token reaches the set maximum usage count. If the usage count of the second token exceeds a reference value, the electronic device may control the state of the first token to prevent additional usage requests for the relevant medical data from being performed by changing the state of the first token to a usage-restricted state.

[0139] FIG. 7 is a flowchart illustrating a method for setting rights dependency relationships and state synchronization rules according to one or more embodiments.

[0140] Referring to FIG. 7, an electronic device according to one embodiment may set rights dependency relationship information between a first token and a second token in session mapping information, and set a state transition rule of the first token corresponding to a state change of the second token based on the rights dependency relationship information.

[0141] According to one embodiment, when a first token identification value and a second token identification value are registered in the session mapping information, the electronic device may set information on the right dependency relationship between the first token and the second token in the session mapping information so that the second token is treated as a right corresponding to the first token (S710).

[0142] The electronic device can verify whether the first token identification value and the second token identification value are included in the same contract session. Based on the verification result, the electronic device can register the second token in the session mapping information so that it has a rights relationship dependent on the first token. The electronic device can manage the rights correspondence relationship between the first token and the second token using the rights dependency relationship information.

[0143] According to one example, the electronic device may set the rights dependency information as relationship information indicating that the second token is not an independent right object but a usage right object issued based on the first token. The rights dependency information may be relationship information indicating a hierarchical relationship, a correspondence relationship, and a control relationship between the first token and the second token. The rights dependency information may be reference information that restricts the valid scope of the second token to within the scope of rights set in the first token.

[0144] For example, if a first token containing ownership of specific medical data and a second token for using the medical data for research purposes are registered in the same contract session, the electronic device may set up rights dependency relationship information so that the second token is treated as a usage right dependent on the first token.

[0145] For example, an electronic device may store information on rights dependency relationships in a relationship setting item within session mapping information. The electronic device may store a relationship in the relationship setting item such that the first token is a base right and the second token is a derivative right. The electronic device may refer to the relationship setting item to process changes in the state of the second token so that they are reflected in the determination of the state of the first token. For example, if the second token is invalidated, the electronic device may refer to the information on rights dependency relationships as a criterion for determining whether to transition the state of the first token to a locked state or a restored state.

[0146] According to one embodiment, the electronic device may set a state synchronization rule so that when the state of the second token changes based on the right dependency relationship information, the state of the first token is transitioned to a pre-set corresponding state (S720).

[0147] The electronic device can determine the target state of the first token corresponding to a change in the state of the second token. The electronic device can set a state synchronization rule so that the determined target state is stored in session mapping information. By referring to the state synchronization rule, the electronic device can consistently manage the states of the first token and the second token at the contract session level.

[0148] The rights dependency information may be relationship information indicating that the second token is a usage right corresponding to the first token, and may be rights relationship definition information configured such that a change in the state of the second token affects the state of the first token. When the state of the second token changes according to the rights dependency information, the electronic device may change the state of the first token to a corresponding state by referring to a state synchronization rule.

[0149] For example, if the second token changes from a usage start state to a usage end state, the electronic device may update the state of the first token to a termination state or a restoration state according to a state synchronization rule. Additionally, if the second token changes from a usage restricted state, the electronic device may be configured to update the state of the first token to a locked state according to a state synchronization rule.

[0150] According to one example, the electronic device may set a state synchronization rule as rule information that defines a state transition relationship of the first token corresponding to a state change of the second token. The state synchronization rule may be rule information that defines a state linkage between the first token and the second token based on right dependency relationship information. The state synchronization rule may be rule information that defines a maintenance state, a termination state, or a lock state of the first token corresponding to the usage start state, usage termination state, or usage restriction state of the second token, respectively.

[0151] A state synchronization rule may be rule information that causes the state of the first token to be updated together according to a pre-established correspondence relationship when the state of the second token changes, even if the state of the first token is not determined separately. However, the state synchronization rule is not limited thereto and may be referred to as a state linkage rule, a synchronization control rule, or a corresponding state rule.

[0152] For example, the electronic device may set a state synchronization rule so that when the second token changes to a usage termination state, the first token transitions to a termination state. For example, the electronic device may set a state synchronization rule so that when the second token changes to a usage restriction state, the first token transitions to a locked state.

[0153] For example, the electronic device may set state synchronization rules differently for each contract session. The electronic device may set the corresponding state of the first token differently depending on the type of medical data, the purpose of use, or the conditions for restriction of use. The electronic device may control the transition to a different state depending on the state of the connected second token, even if it is the same first token, according to the state synchronization rules.

[0154] For example, the electronic device may set a state synchronization rule to transition the first token to a restored state upon the termination of the second token in a contract session for research purposes, and to transition the first token to a locked state in a contract session involving a violation.

[0155] FIG. 8 is a flowchart illustrating a method for determining the following state according to one or more embodiments.

[0156] Referring to FIG. 8, an electronic device according to one embodiment can identify the current state of a first token and a second token, determine whether a state transition condition corresponding to the current state is satisfied, and then determine a corresponding state defined in a state transition rule as the next state of the first token and the second token.

[0157] According to one embodiment, the electronic device can identify the current state of the first token and the second token (S810).

[0158] The electronic device can verify the current state of the first token and the second token by referring to state information stored in a contract session or state information recorded on a blockchain network. The electronic device can store the identified current state as reference information for determining the next state.

[0159] According to one example, the electronic device may identify the current state as state information indicating which right stage each token is currently located in. The current state may be at least one state value among a use initiation state, use termination state, use restriction state, lock state, or retention state. The current state may be input state information for applying state transition rules. For example, the electronic device may identify the current state of the second token as a use initiation state and the current state of the first token as an ownership valid state or retention state.

[0160] According to one embodiment, the electronic device can search for a state transition condition corresponding to the current state from a state transition rule stored in the electronic device (S820).

[0161] The electronic device can search for a rule item corresponding to the identified current state in the state transition rules. The electronic device can obtain a state transition condition from the searched rule item. The electronic device can use the obtained state transition condition as reference information for determining whether the condition is satisfied.

[0162] According to one example, an electronic device may process a state transition condition as condition information that must be satisfied to transition from a current state to another state. The state transition condition may be condition information including at least one of an event occurrence condition, a usage period expiration condition, a usage restriction violation condition, or an approval completion condition. The state transition condition may be set differently for each current state. However, not limited thereto, the state transition condition may be referred to as a transition criterion condition, a state change condition, or a rule condition. For example, if the current state of the second token is the usage start state, the electronic device may search for a state transition condition including a usage period expiration condition and a usage restriction violation condition.

[0163] State transition conditions may be condition information for determining when the state of a token should be changed, and may be criterion information for determining whether to perform a state transition based on whether conditions such as event occurrence conditions, usage period expiration conditions, or usage restriction violation conditions occur.

[0164] On the other hand, the state synchronization rule described in Fig. 7 may be rule information that defines how to link and change the state of another token after the state of a specific token has changed when a state transition condition is satisfied. That is, the state transition condition is a rule for determining whether a state change has occurred, and the state synchronization rule may be a linkage rule applied to maintain the state relationship between multiple tokens after a state change has occurred.

[0165] For example, the electronic device may perform a process to transition the state of the second token to a usage termination state when the usage period expiration condition is satisfied, and subsequently, according to a state synchronization rule, process to update the state of the first token to a termination state or a restoration state in response to the state change of the second token.

[0166] According to one embodiment, the electronic device can determine whether the state transition condition is satisfied based on whether at least one of the conditions included in the state transition condition—an event occurrence condition, a usage period expiration condition, and a usage restriction violation condition—occurs (S830).

[0167] The electronic device may check whether a condition has occurred by referring to the event records, usage period information, or access control history of the contract session. The electronic device may determine that a state transition condition is satisfied if one or more conditions are met. If the occurrence of a condition is not confirmed, the electronic device may determine to maintain the current state.

[0168] For example, an electronic device may determine the conditions for an event to occur as conditions corresponding to state-changing events such as contract conclusion, approval completion, settlement completion, or a request for termination of use.

[0169] The usage period expiration condition may be a condition indicating whether the usage termination time set in the second token has arrived.

[0170] Conditions for violations of usage restrictions may be conditions corresponding to violation situations such as use for unauthorized purposes, access outside the permitted scope, or exceeding the number of uses.

[0171] For example, the electronic device may determine that the condition for the expiration of the usage period is satisfied when the time for the termination of use of the second token arrives. For example, the electronic device may determine that the condition for a violation of the usage restriction is satisfied when an unauthorized external transmission attempt occurs.

[0172] According to one example, an electronic device may determine whether a state transition condition is satisfied based on a combination of multiple conditions. The electronic device may be configured to perform a state transition when a single condition is satisfied. The electronic device may be configured to perform a state transition corresponding to the condition with the highest priority when multiple conditions are satisfied simultaneously.

[0173] For example, if the usage period expiration condition and the usage restriction violation condition are simultaneously satisfied, the electronic device may determine the second token to be in a usage restriction state by applying a state transition rule that prioritizes the usage restriction violation condition.

[0174] According to one embodiment, when a state transition condition is satisfied, the electronic device can determine the corresponding state defined in the state transition rule as the next state of the first token and the second token (S840).

[0175] The electronic device can determine the next state of the first token by referring to a rule item corresponding to a satisfied state transition condition. The electronic device can determine the next state of the second token by referring to the same rule item. The electronic device can store the determined next state as a reference state for state synchronization and updating.

[0176] According to one example, an electronic device may determine a corresponding state as a target state value predefined in a state transition rule. The corresponding state may be defined individually for each of the first token and the second token. The corresponding states may be configured to be interconnected based on rights dependency relationships and state synchronization rules.

[0177] For example, if the usage period expiration condition is satisfied, the electronic device may determine the next state of the second token as a usage termination state and the next state of the first token as a termination state or a restoration state. For example, if the usage restriction violation condition is satisfied, the electronic device may determine the next state of the second token as a usage restriction state and the next state of the first token as a lock state.

[0178] For example, an electronic device may determine a corresponding state defined in a state transition rule differently for each contract session. Even if the current state is the same, the electronic device may determine a different next state depending on the type of medical data, the purpose of use, or the conditions of use.

[0179] The electronic device can utilize the result of determining the corresponding state to process the subsequent state synchronization process so that the rights relationship between the first token and the second token is consistently maintained. For example, the electronic device may determine the first token to be in a restored state after the termination of use in a research purpose contract session, and may determine the first token to be in a transaction completed state after the termination of use in a commercial analysis contract session.

[0180] FIG. 9 is a flowchart illustrating a method for determining whether a state transition condition is satisfied according to one or more embodiments.

[0181] Referring to FIG. 9, an electronic device according to one embodiment can perform a state transition by extracting transition condition information corresponding to the current state of the second token from a state transition rule and checking whether the conditions included in the transition condition information are satisfied.

[0182] According to one embodiment, the electronic device can determine whether the current state of the second token corresponds to a state of initiation of use, a state of termination of use, and a state of restriction of use (S910).

[0183] The electronic device can verify the current state of the second token by referring to state information stored in a contract session or state information recorded on a blockchain network. The electronic device can store the verified current state as reference information for extracting transition condition information.

[0184] According to one example, the electronic device may determine the current state of the second token as a state value indicating what right stage the usage right granted to the second token is currently in. The current state of the second token may be state information indicating whether the use of medical data is in progress, terminated, or restricted. The current state of the second token may be reference state information for specifying the subject of application of a state transition rule.

[0185] For example, the electronic device may determine that the use of medical data is permitted if the second token corresponds to a state of initiation of use. For example, the electronic device may determine that access to medical data is restricted if the second token corresponds to a state of restricted use.

[0186] According to one embodiment, the electronic device can extract transition condition information from a state transition rule in response to the current state of the determined second token (S920).

[0187] The electronic device can search for a rule item corresponding to the current state of the second token in the state transition rules. The electronic device can obtain one or more transition condition information from the searched rule item. The electronic device can use the obtained transition condition information as reference information for verifying whether the condition is satisfied.

[0188] According to one example, the electronic device may extract transition condition information as condition information that must be verified to transition from a specific state to another state. The transition condition information may be information including at least one of an event occurrence condition, a usage period expiration condition, a usage restriction violation condition, or an approval status condition. The transition condition information may be condition information that is set differently depending on the current state of the second token. However, not limited thereto, the transition condition information may be referred to as state condition information, transition criterion information, or state change condition information.

[0189] For example, if the second token is in a usage initiation state, the electronic device may extract transition condition information including conditions for the expiration of the usage period and conditions for violating usage restrictions. For example, if the second token is in a usage restriction state, the electronic device may extract transition condition information including conditions for lifting restrictions or conditions for administrative approval.

[0190] According to one embodiment, the electronic device can check whether at least one of the event occurrence condition, usage period expiration condition, and usage restriction violation condition included in the transition condition information is satisfied (S930).

[0191] The electronic device may check whether each condition is satisfied by referring to event information, usage period information, or access history information recorded in the contract session. The electronic device may determine that a state transition condition is satisfied if at least one condition is satisfied. If none of the conditions are satisfied, the electronic device may decide to maintain the current state.

[0192] For example, the electronic device may confirm that the usage period expiration condition is satisfied if the usage end time of the second token has passed the current time. For example, the electronic device may confirm that the usage restriction violation condition is satisfied if an external transmission request occurs regarding medical data that is prohibited from being taken out.

[0193] According to one example, an electronic device may check whether multiple conditions included in transition condition information are satisfied by setting priorities for them. If multiple conditions are satisfied simultaneously, the electronic device may decide to apply a state transition corresponding to the condition with the highest priority. Based on the priority information, the electronic device may be configured to apply a violation of the usage restriction before the expiration of the usage period.

[0194] For example, if the expiration of the usage period and a violation of the usage restriction are confirmed simultaneously, the electronic device may decide to transition the second token to a usage restriction state by applying the usage restriction violation condition first.

[0195] According to one embodiment, the electronic device can perform a state transition if the transition condition is satisfied based on the verification result (S940).

[0196] The electronic device can determine the next state of the second token by referring to a state transition rule corresponding to the satisfied transition condition. The electronic device can update the state information of the second token according to the determined next state. The electronic device can process the state of the first token linked to the contract session to be updated together in response to the state change of the second token.

[0197] According to one example, the electronic device may perform a state transition as a process that changes the current state of the second token to the next state. The state transition may be a state change process performed based on a state transition rule stored in the contract session. The state transition may be a process that changes only the state of the second token, or a linked process that changes the corresponding state of the first token together. However, not limited thereto, the state transition may be referred to as a state update, a state change process, or a transition execution.

[0198] For example, if the condition for the expiration of the usage period is satisfied, the electronic device may transition the second token to a usage termination state and transition the first token to a termination state or a restoration state. For example, if the condition for a usage restriction violation is satisfied, the electronic device may transition the second token to a usage restriction state and transition the first token to a locked state.

[0199] For example, the electronic device may reflect the results of a state transition in the state information of the contract session. The electronic device may record the time of the state transition, applied condition information, and the changed state value together. The electronic device may track ownership and usage rights relationships of medical data using the recorded state transition history. For example, the electronic device may record in the contract session the history of a specific second token changing to a terminated usage status due to the expiration of the usage period while being used for research purposes.

[0200] FIG. 10 is a drawing for explaining a first token state determination method according to one or more embodiments.

[0201] Referring to FIG. 10, an electronic device according to one embodiment may determine the state of the first token (1020) as one of the maintained state, locked state, and terminated state in a corresponding state defined in a state transition rule (1030) in correspondence with the current state of the second token (1010). The electronic device may use the current state of the second token (1010) as a reference state. The electronic device may determine the corresponding state of the first token (1020) by referring to the state transition rule (1030).

[0202] The second token (1010) may be a right object having a state value of a usage start state, a usage end state, and a usage restriction state. For example, if the second token (1010) is in a usage start state, the electronic device may determine that the use of medical data is permitted.

[0203] The first token (1020) may be a reference right object whose state is determined in conjunction with the state change of the second token (1010). For example, when the use of the second token (1010) is terminated, the electronic device may determine the state of the first token (1020) to be a terminated state.

[0204] According to one example, the electronic device may use a state transition rule (1030) as rule information that defines the relationship between the state of the second token (1010) and the corresponding state of the first token (1020). The state transition rule (1030) may be a set of rules that specify the state to be applied to the first token (1020) according to the current state of the second token (1010). For example, the electronic device may set the state transition rule (1030) to determine the first token (1020) to a locked state when the second token (1010) is in a restricted state.

[0205] According to one example, the electronic device may determine the maintenance state as a state in which the ownership of the first token (1020) remains valid. The maintenance state may be a state value applied when the state of the second token (1010) does not cause a restriction of rights of the first token (1020). For example, the electronic device may determine the first token (1020) to be in the maintenance state when the second token (1010) is in the use initiation state.

[0206] According to one example, the electronic device may determine the lock state as a state in which further use or further connection to the first token (1020) is restricted. The lock state may be a protection state value applied when a violation or usage restriction situation occurs in the second token (1010). For example, the electronic device may determine the first token (1020) as a lock state if the second token (1010) is in a usage restriction state.

[0207] According to one example, the electronic device may determine the termination state as the contract session corresponding to the first token (1020) has ended. The termination state may be a state value applied when the use of the second token (1010) has expired or ended. For example, the electronic device may determine the first token (1020) as the termination state if the second token (1010) is in the termination state.

[0208] According to one example, the electronic device may manage the current state of the second token (1010) and the determined state of the first token (1020) as a single correspondence. The electronic device may determine different states for the same first token (1020) depending on the state of the connected second token (1010) according to the state transition rule (1030). For example, for the same first token (1020), the electronic device may determine a maintenance state in one contract session and a lock state or a termination state in another contract session.

[0209] For example, when the state of the second token (1010) changes, the electronic device may apply a state transition rule (1030) to determine the state of the first token (1020) to one of the maintenance state, the lock state, and the termination state.

[0210] FIG. 11 is a flowchart illustrating a method for state synchronization and state information update according to one or more embodiments.

[0211] Referring to FIG. 11, an electronic device according to one embodiment can identify the next state of a first token and the next state of a second token determined according to a state transition rule, respectively, update the current state information of the first token and the second token based on the identified next state, and then record the updated state information on a blockchain network.

[0212] According to one embodiment, the electronic device can identify the next state of the first token and the next state of the second token, respectively, determined according to a state transition rule (S1110).

[0213] The electronic device can refer to state transition rules stored in the contract session. The electronic device can obtain the next state value corresponding to the first token and the second token, respectively. The electronic device can store the obtained next state value as reference information for updating state information.

[0214] According to one example, an electronic device may identify the next state as a target state to be transitioned from the current state. The next state may be a result state calculated according to a state transition rule. The next state may be a state value set individually for each of the first token and the second token. However, not limited thereto, the next state may be referred to as a corresponding state, a target state, or a transition state.

[0215] For example, if the current state of the second token is a usage start state and the usage period expiration condition is satisfied, the electronic device can identify the next state of the second token as a usage end state.

[0216] According to one example, an electronic device may use a state transition rule as rule information that defines the state correspondence relationship between a first token and a second token. For example, the electronic device may apply a state transition rule to identify the next state of the first token as a locked state when the second token transitions to a restricted state.

[0217] According to one embodiment, the electronic device can update the current state information of the first token based on the next state of the identified first token (S1120).

[0218] The electronic device can check the current state value stored in the first token. The electronic device can change the checked current state value to the identified next state value. The electronic device can reflect the changed state value as the current state information of the first token.

[0219] According to one example, the electronic device may manage the current status information of the first token as status information indicating the current rights status of the ownership token for medical data. The current status information of the first token may include at least one status value among a maintenance state, a lock state, a termination state, or a restoration state. The current status information of the first token may be rights status information that is updated in conjunction with a change in the status of the second token. For example, the electronic device may update the current status information of the first token to a lock state if a violation of the usage restriction of the second token is confirmed.

[0220] According to one example, when an electronic device updates the current state information of a first token, it may also record information regarding the time of the state change. The electronic device may also store information regarding the cause of the change in the current state information of the first token. The electronic device may use the cause information to track the history of state changes of the first token. For example, if the first token is updated from a maintenance state to a termination state, the electronic device may also record the time of change and information regarding the applied state transition rule.

[0221] According to one embodiment, the electronic device can update the current state information of the second token based on the next state of the identified second token (S1130).

[0222] The electronic device can check the current state value stored in the second token. The electronic device can change the checked current state value to the identified next state value. The electronic device can reflect the changed state value as the current state information of the second token.

[0223] According to one example, the electronic device may manage the current status information of the second token as status information indicating the current usage status of the usage right token for medical data. The current status information of the second token may include at least one status value among a usage start status, a usage end status, and a usage restriction status. The current status information of the second token may be reference status information for determining whether usage is available and whether usage is restricted. For example, the electronic device may update the current status information of the second token to a usage end status when the time for usage end arrives. For example, the electronic device may update the current status information of the second token to a usage restriction status when an unauthorized attempt to take data out externally occurs.

[0224] For example, when updating the current status information of the second token, the electronic device may also reflect usage period information or violation occurrence information. The electronic device may also store the reason for the status change related to the current status information of the second token. The electronic device may manage the state transition history of the second token at the contract session level using the usage period information or violation occurrence information. For example, if the second token is updated from the usage start state to the usage end state, the electronic device may also record the expiration time information.

[0225] According to one embodiment, the electronic device can record the current state information of the updated first token and the current state information of the updated second token on a blockchain network (S1140).

[0226] The electronic device can organize updated state information to fit the record format of the blockchain network. The electronic device can transmit the updated state information to the blockchain network. The electronic device can verify the rights relationship between the first token and the second token by referring to the state information recorded in the distributed ledger.

[0227] According to one example, an electronic device may manage records on a blockchain network as immutable historical information regarding the results of state updates. The state information recorded on the blockchain network may serve as reference information for tracking state changes per contract session. The state information recorded on the blockchain network may serve as reference record information used for subsequent state determination, access control, or rights verification. For example, the electronic device may record the lock status update information of a first token and the usage restriction status update information of a second token together on the blockchain network.

[0228] FIG. 12 is a flowchart illustrating a method for allowing access to medical data according to one or more embodiments.

[0229] Referring to FIG. 12, an electronic device according to one embodiment determines whether the state of the first token is in a valid ownership state and whether the state of the second token is in an available state based on the state information of the updated first token and the state information of the updated second token, and may allow access to medical data according to the result of the determination.

[0230] According to one embodiment, the electronic device can determine whether the state of the first token is in a valid ownership state based on the updated state information of the first token (S1210).

[0231] The electronic device can check the current status information stored in the first token. The electronic device can determine whether the checked status information corresponds to a valid ownership status. The electronic device can use the result of the determination as reference information for deciding whether to allow access to medical data.

[0232] According to one example, the electronic device may manage the status information of the first token as status information indicating the validity of ownership of medical data. The status information of the first token may include at least one status value among a maintenance state, a lock state, a termination state, or a restoration state. The status information of the first token may be right status information that is updated in conjunction with the status change of the second token within a contract session.

[0233] For example, the electronic device may determine that the ownership is in a valid state if the state of the first token is in a maintained state or a restored state. For example, the electronic device may determine that the ownership is not in a valid state if the state of the first token is in a locked state or a terminated state.

[0234] According to one example, an electronic device may determine the ownership valid state as a state in which the basic rights relationship regarding medical data remains valid. The ownership valid state may be a state value in which the first token has not transitioned to a rights restricted state due to the restriction of use of the second token or the termination of the contract. The ownership valid state may be a state value used as a first reference state in determining whether access to medical data is permitted. For example, the electronic device may determine the state of the first token as the ownership valid state if the usage period of the second token has not expired and no violation state has occurred.

[0235] According to one embodiment, the electronic device can determine whether the state of the second token is available based on the updated state information of the second token (S1220).

[0236] The electronic device can check the current status information stored in the second token. The electronic device can determine whether the checked status information corresponds to an available state. The electronic device can use the result of this determination as reference information for deciding whether to allow access to medical data.

[0237] According to one example, the electronic device may manage the status information of the second token as status information indicating the current availability of the medical data usage right. The status information of the second token may include at least one status value among a usage start status, a usage end status, and a usage restriction status. The status information of the second token may be usage status information that is updated within the contract session based on the usage period, usage conditions, and whether a violation has occurred.

[0238] For example, the electronic device may determine that the second token corresponds to an available state if its state is a usage start state. For example, the electronic device may determine that the second token is not in an available state if its state is a usage end state or a usage restriction state.

[0239] According to one example, the electronic device may determine the availability status as a state in which the authority to actually view, analyze, or process medical data is valid. The availability status may indicate a state value in which the purpose of use and the period of use set in the second token are still valid. The availability status may be a state value used as a second reference state in determining whether access to medical data is permitted.

[0240] For example, the electronic device may determine the status of the second token to be available if the usage end time set on the second token has not arrived and no violation of usage restrictions is confirmed.

[0241] According to one embodiment, the electronic device may allow access to medical data when the state of the first token is an ownership valid state and the state of the second token is an available state (S1230).

[0242] The electronic device may refer to the status determination result of the first token and the status determination result of the second token together. The electronic device may approve a medical data access request if both determination results satisfy the permission conditions. The electronic device may control at least one operation among viewing, analyzing, or transmitting medical data in accordance with the approved access request.

[0243] According to one example, an electronic device may process the permission to access medical data as the result of executing control logic linked to a contract session. The permission to access medical data may be an access control process performed when the validity of ownership indicated by the first token and the availability indicated by the second token are simultaneously recognized. The permission to access medical data may be a control result including at least one of allowing viewing, downloading, analysis execution, or API calls to the medical data.

[0244] For example, the electronic device may allow a research institution to view diagnostic image data if the second token corresponding to the research institution is in an inactive state and the first token corresponding to the patient is in a maintained state. For example, the electronic device may allow the relevant review system to query necessary medical data if the second token for insurance review purposes is valid and the status of the first token is in a restored state.

[0245] For example, an electronic device may record access history along with permission to access medical data. The electronic device may store the time of access permission, information on the accessing party, and information on the access target corresponding to the contract session. The electronic device may verify the history of exercising rights to medical data using the stored access history. For example, if permission to access is granted based on a specific second token, the electronic device may reflect the time of access, purpose of use, and information on the requesting party in the contract session record.

[0246] FIG. 13 is a flowchart illustrating a method for blocking access to medical data and restoring the state according to one or more embodiments.

[0247] Referring to FIG. 13, an electronic device according to one embodiment can determine the state of the second token based on updated state information of the second token, and block access to medical data or restore the state of the first token according to the determined state.

[0248] According to one embodiment, the electronic device can determine whether the state of the second token corresponds to either a state of termination of use or a state of restricted use based on the state information of the updated second token (S1310).

[0249] The electronic device can check the current status information recorded in the second token. The electronic device can determine whether the checked current status information is in a terminated usage state or a restricted usage state. The electronic device can use the result of the determination as reference information for medical data access control.

[0250] For example, the electronic device may determine the status of a second token whose usage period has expired as a usage termination state. For example, the electronic device may determine the status of a second token in which unauthorized usage activity has been confirmed as a usage restriction state.

[0251] For example, the electronic device may determine the usage termination status as a state where the authorization based on the usage period or purpose of use corresponding to the second token has ended. The usage termination status may be a state value where medical data can no longer be used. The usage termination status may be a state value associated with the termination of a contract session or the expiration of a usage period. For example, the electronic device may determine the second token as being in the usage termination status when the termination time set for use for research purposes has arrived.

[0252] For example, the electronic device may determine that the usage restriction state is a state in which the exercise of usage rights is blocked due to a violation or a reason for restriction. The usage restriction state may be a status value associated with use for purposes other than those permitted, access beyond the permitted scope, or attempts to export externally. The usage restriction state may be a protection status value intended to suspend the use of the second token. For example, the electronic device may determine that the usage restriction state occurs if a data request exceeding the allowed analysis scope for the second token is made.

[0253] According to one embodiment, the electronic device may block access to medical data when the state of the second token is in a restricted state (S1320).

[0254] The electronic device may refuse requests for access to medical data based on the results of determining the usage restriction status. The electronic device may control the suspension of viewing, downloading, analysis execution, or transmission of medical data. The electronic device may record the results of the access blocking in correspondence with the contract session.

[0255] According to one example, the electronic device may block access to medical data through an access control process performed when the status of the second token is not available. The blocking of access to medical data may be a control result including at least one of suspending data viewing, restricting file export, terminating an analysis task, or rejecting an API request.

[0256] Blocking access to medical data may be a control process that ensures changes in the state of the second token are reflected in actual data usage behavior. For example, an electronic device may block both viewing and downloading of diagnostic image data if the second token issued to the research institution is changed to a restricted usage state.

[0257] For example, an electronic device may store information regarding the reason for restriction along with access blocking corresponding to a usage restriction status. The electronic device may record information regarding the reason for restriction on a contract session or a blockchain network. The electronic device may verify the history of usage restriction occurrences using the recorded information. For example, if access blocking is performed due to an external transmission violation, the electronic device may record information regarding the time of violation and the type of violation.

[0258] According to one embodiment, if the state of the second token is a state of termination of use, the electronic device can block access to medical data and restore the state of the first token to a state prior to the start of use (S1330).

[0259] The electronic device may suspend current access to medical data based on the result of determining the termination of use status. The electronic device may update the current status information recorded in the first token to the status value prior to the start of use. The electronic device may use the updated status of the first token as the reference state for setting up a subsequent contract session.

[0260] According to one example, the electronic device may restore the state prior to the commencement of use to the reference state that the first token had before the second token was activated. The state prior to the commencement of use may be any one of the state values ​​of a maintenance state, a standby state, or an initial active state. The state prior to the commencement of use may be a restoration state value intended to enable the setting of a new usage right after the existing usage contract has ended. However, it is not limited thereto, and the state prior to the commencement of use may be referred to as a restoration state, an initial state, or a standby state. For example, if the usage period of the second token expires, the electronic device may restore the state of the first token to a maintenance state.

[0261] For example, the electronic device may restore the state of the first token by processing the release of the state linkage according to the existing usage contract. After restoring the state, the electronic device may configure the first token to be reconnected with a new second token. The electronic device may store the result of the state restoration along with the contract session termination history. For example, if the second token used for insurance underwriting purposes becomes a terminated usage state, the electronic device may restore the first token to an initial standby state and configure it to respond to usage requests from other institutions thereafter.

[0262] FIG. 14 is a block diagram illustrating the configuration of an electronic device according to one or more embodiments.

[0263] Referring to FIG. 14, the electronic device (100) includes a memory (1410) and a processor (1420) connected to the memory (1410). However, it is not limited thereto, and the electronic device (100) may be implemented with some components excluded or with other components included.

[0264] The memory (1410) can store at least one instruction, data, program, etc. required for the operation of the electronic device (100). Depending on the purpose of data storage, the memory (1410) may be implemented in the form of a memory embedded in the electronic device (100) or in the form of a memory that is detachable from the electronic device (100). For example, data for operating the electronic device (100) may be stored in a memory embedded in the electronic device (100), and data for the expansion function of the electronic device (100) may be stored in a memory that is detachable from the electronic device (100).

[0265] The processor (1420) controls the overall operation of the electronic device (100). Specifically, the processor (1420) is connected to each component of the electronic device (100) to control the overall operation of the electronic device (100). The processor (1420) may be configured to execute a program stored in memory (1410). When the program is executed, a Dual NFT-based medical data management method according to the embodiments may be implemented.

[0266] According to one embodiment, when a program stored in memory (1410) is executed, the electronic device (100) issues a first token containing ownership information for medical data on a blockchain network and issues a second token containing usage right information for medical data on a blockchain network, connects the first token and the second token in a contract session unit based on an identifier commonly assigned to the first token and the second token, determines the next state of the first token and the second token according to a state transition rule stored in the electronic device based on the current state information of the first token and the second token connected in a contract session unit, synchronizes and updates the state of the first token and the second token using the determined next state as a reference state, and manages the relationship between ownership and usage rights for medical data by performing control logic linked to the contract session based on the updated state information of the first token and the second token. This enables the implementation of a Dual NFT-based medical data management method.

[0267] The electronic device according to the present invention manages a first token representing ownership of medical data and a second token representing the right to use medical data by distinguishing between them, and can systematically control the right to use medical data based on the state linkage between the first token and the second token. By managing the relationship of rights by mapping the first token and the second token at the contract session level, the electronic device can control the ownership and right to use of medical data to be clearly separated while ensuring mutual interoperability. Since the electronic device can automatically transition the token state based on usage conditions, usage periods, and violations of usage restrictions using state transition rules, it can reduce the management burden that may arise during the process of managing rights to medical data and improve the consistency of rights processing.

[0268] The electronic device according to the present invention can ensure transparency and traceability in the process of using medical data by recording state information of a first token and a second token on a blockchain network and managing the history of state changes. The electronic device determines whether to allow access to medical data based on the state of the second token and can automatically block access to medical data if a state of termination of use or restriction of use occurs. Since the electronic device can perform access control by reflecting the usage status of medical data in real time, it can prevent unauthorized use of medical data and improve security and reliability in the process of utilizing data.

[0269] It is obvious that each step or operation of the method according to the embodiments of the present disclosure may be performed by a computer comprising one or more processors in accordance with the execution of a computer program stored in a computer-readable recording medium.

[0270] The computer-executable instructions stored on the aforementioned recording medium can be implemented through a computer program programmed to perform each corresponding step, and such a computer program can be stored on a computer-readable recording medium and executed by a processor. The computer-readable recording medium may be a non-transitory readable medium. In this case, a non-transitory readable medium refers to a medium that stores data semi-permanently and is readable by a device, rather than a medium that stores data for a short moment, such as a register, cache, or memory. Specifically, programs for performing the various methods described above may be provided by being stored on a non-transitory readable medium, such as semiconductor memory devices including erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; optical-magnetic disks; and non-volatile memory including CD-ROMs and DVD-ROMs.

[0271] Methods according to the various examples disclosed in this document may be provided by being included in a computer program product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)) or online through an application store (e.g., Play Store™). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0272] As explained above, a person skilled in the art to which this disclosure pertains will understand that this disclosure may be implemented in other specific forms without altering its technical concept or essential features. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive. The scope of this disclosure is defined by the claims set forth below rather than by the detailed description, and all modifications or variations derived from the meaning and scope of the claims and equivalent concepts should be interpreted as being included within the scope of this disclosure.

[0273] The features and advantages described herein are not all included, and in particular, many additional features and advantages will become apparent to those skilled in the art by considering the drawings, the specification, and the claims. Furthermore, it should be noted that the language used in this specification has been chosen primarily for readability and instructional purposes and may not be chosen to describe or limit the subject matter of this disclosure.

[0274] The foregoing description of the embodiments of the present disclosure is provided for illustrative purposes only. It is not intended to limit the present disclosure to the exact form disclosed or to make it incomplete. Those skilled in the art will understand that many modifications and variations are possible in light of the foregoing disclosure.

[0275] Therefore, the scope of the present disclosure is not limited by the detailed description but by any of the claims of the application based thereon. Accordingly, the disclosure of embodiments of the present disclosure is illustrative and does not limit the scope of the present disclosure as set forth in the following claims.

Claims

Claim 1 A Dual NFT-based medical data management method performed by an electronic device, comprising: a step of issuing a first token containing ownership information for medical data on a blockchain network; a step of issuing a second token containing usage right information for medical data on the blockchain network; a step of connecting the first token and the second token as a single contract session unit based on an identifier commonly assigned to the first token and the second token; a step of determining the next state of the first token and the second token according to a state transition rule stored in the electronic device based on current state information of the first token and the second token connected as a contract session unit; and a step of synchronizing and updating the states of the first token and the second token using the determined next state as a reference state. A method for managing medical data, comprising the step of managing the relationship between ownership and usage rights of the medical data by performing control logic linked to the contract session based on the updated status information of the first token and the second token, wherein the step of managing the relationship between ownership and usage rights of the medical data by performing control logic linked to the contract session based on the updated status information of the first token and the second token comprises: a step of determining whether the state of the first token is an ownership valid state based on the updated status information of the first token; a step of determining whether the state of the second token is an availability state based on the updated status information of the second token; and a step of allowing access to the medical data when the state of the first token is an ownership valid state and the state of the second token is an availability state. Claim 2 A method for managing medical data according to claim 1, wherein the step of issuing a first token containing ownership information for the medical data on a blockchain network comprises: a step of obtaining data identification information corresponding to the medical data and owner identification information for the medical data; a step of verifying whether ownership of the medical data is held based on the data identification information and the owner identification information; a step of generating a hash value for integrity verification from the medical data if ownership is confirmed; a step of configuring metadata of the first token to include the result of verifying ownership and the hash value; and a step of transmitting and recording the first token containing the metadata on the blockchain network. Claim 3 A method for managing medical data according to claim 1, wherein the step of issuing a second token containing information on a right to use the medical data on the blockchain network comprises: receiving information on a request for use of the medical data; identifying information on the purpose of use and the period of use included in the request for use information; determining whether the information on the purpose of use and the period of use is included in a condition set in the first token; if it is included in the condition, configuring the metadata of the second token to include the information on the purpose of use and the period of use; and transmitting and recording the second token together with the metadata on the blockchain network. Claim 4 A method for managing medical data according to claim 1, wherein the step of connecting the first token and the second token as a single contract session unit based on an identifier commonly assigned to the first token and the second token comprises: obtaining a first token identification value for specifying the first token and a second token identification value for specifying the second token; setting the identifier commonly assigned to the first token and the second token as a reference value for distinguishing the contract session; generating session mapping information including a state transition rule for controlling the state transition of the first token and the second token in correspondence with the reference value; and setting the first token and the second token to be included in the same contract session by registering the first token identification value and the second token identification value in the session mapping information. Claim 5 In claim 4, the step of generating session mapping information including state transition rules for controlling state transitions of the first token and the second token in correspondence with the reference value comprises: configuring the session mapping information to include a state management area for storing state information of the first token and the second token in correspondence with the reference value; and storing the state transition rules for controlling state transitions of the first token and the second token in the state management area; a medical data management method. Claim 6 A medical data management method according to claim 4, further comprising: a step of setting information on a right dependency relationship between the first token and the second token in the session mapping information so that when the first token identification value and the second token identification value are registered in the session mapping information, the second token is treated as a right corresponding to the first token; and a step of setting a state synchronization rule so that when the state of the second token changes based on the right dependency relationship information, the state of the first token is transitioned to a pre-set corresponding state. Claim 7 A method for managing medical data according to claim 1, wherein the step of determining the next state of the first token and the second token comprises: identifying the current state of the first token and the second token; searching for a state transition condition corresponding to the current state from a state transition rule stored in the electronic device; determining whether the state transition condition is satisfied based on whether at least one of an event occurrence condition, a usage period expiration condition, and a usage restriction violation condition included in the state transition condition occurs; and, if the state transition condition is satisfied, determining the corresponding state defined in the state transition rule as the next state of the first token and the second token. Claim 8 In claim 7, the step of determining whether the state transition condition is satisfied comprises: determining whether the current state of the second token corresponds to a state of initiation of use, a state of termination of use, and a state of restriction of use; extracting transition condition information from the state transition rule in correspondence with the determined current state of the second token; verifying whether at least one of an event occurrence condition, a usage period expiration condition, and a usage restriction violation condition included in the transition condition information is satisfied; and performing the state transition if the transition condition is satisfied based on the verification result; a medical data management method. Claim 9 In claim 7, the step of determining the next state of the first token and the second token in the corresponding state defined in the state transition rule when the state transition condition is satisfied comprises: determining the state of the first token in the corresponding state defined in the state transition rule in the current state of the second token as one of the state of maintenance, lock, and termination; a medical data management method. Claim 10 A medical data management method according to claim 1, wherein the step of synchronizing and updating the states of the first token and the second token with the determined next state as a reference state comprises: identifying the next state of the first token and the next state of the second token, respectively, determined according to the state transition rule; updating the current state information of the first token based on the identified next state of the first token; updating the current state information of the second token based on the identified next state of the second token; and recording the updated current state information of the first token and the updated current state information of the second token on the blockchain network. Claim 11 delete Claim 12 A method for managing medical data according to claim 1, wherein the step of managing the relationship between ownership and usage rights for the medical data by performing control logic linked to the contract session based on the updated status information of the first token and the second token comprises: a step of determining whether the state of the second token corresponds to either a usage termination state or a usage restriction state based on the updated status information of the second token; a step of blocking access to the medical data if the state of the second token is a usage restriction state; and a step of blocking access to the medical data and restoring the state of the first token to a state prior to the start of use if the state of the second token is a usage termination state. Claim 13 An electronic device comprising a processor and a memory connected to the processor, wherein the memory is configured to store a program and the processor is configured to execute the program, and when the program is executed, any one of the methods of claims 1 to 10 and 12 is implemented.

Images