System and method for managing digital doppelganger life cycle and computer readable medium

Abstract

A system and method for automatically managing the life cycle of a digital twin based on a smart contract, and a computer-readable recording medium, which, after defining the duration parameters and carrier acceptance rules of the digital twin by using a smart contract, transfers the duration of the digital twin to the accepting subject when the smart contract determines that the duration of the digital twin ends according to the duration parameters and that the corresponding accepting subject exists according to the carrier acceptance rules, and, before the digital twin is used and during the use of the digital twin, performs legality verification to generate a verification result, and, when the verification result does not meet the preset conditions, rejects or suspends the use of the digital twin. The technical means can automatically accept and authorize the digital twin as a personalized asset, and achieve the technical effects of ensuring the legal duration of the digital twin and reducing asset transfer disputes.

Description

Technical Field

[0001] A digital clone lifecycle management system and method, and a computer-readable recording medium, particularly a system and method for automatically managing the lifecycle of a digital clone based on smart contracts, and a computer-readable recording medium. Background Technology

[0002] With the development of technologies related to artificial intelligence, virtual reality, and the metaverse, digital twins (or virtual avatars) are gradually becoming important personalized assets for individuals in the digital world. They are used to represent real people or digital assets for interaction, display, creation, or commercial activities. In current technologies, digital twins are mostly managed by centralized platforms or application systems, and their access permissions, usage periods, and scope of use are usually controlled based on internal platform rules or manual settings.

[0003] However, existing digital avatar management mechanisms generally suffer from the following problems: 1. Existing digital asset management often focuses only on asset storage and single transaction transfers, lacking precise governance over the "entire lifecycle" of digital avatars; 2. The lifecycle of digital avatars is often not clearly defined, lacking verifiable start times, expiration times, or automatic disposal mechanisms after expiration, leading to the possibility of digital avatars continuing to be used after the authorization period expires; 3. When the owner of a digital avatar is unable to continue managing it for any reason, or when the authorization contract expires, resulting in a change in ownership, usage rights, or control of the digital avatar, it often relies on manual intervention or centralized third-party mechanisms. Intervention by institutions (such as courts, lawyers, or platform operators) in determining ownership can easily lead to disputes and delays in enforcement, and is inefficient and costly, resulting in the illegal use or idleness of digital assets in a state of unclear ownership; fourth, existing technologies are unable to maintain the consistency of digital clone status in cross-platform or cross-system environments, and cannot provide tamper-proof usage records for subsequent verification; fifth, existing technologies also lack the technical means to dynamically verify the legality of digital clones during their "use period," and once the authorization is illegally tampered with or the clone is used in unauthorized regions or for unauthorized purposes (such as using non-commercial authorization for commercial advertising), the original rights holder finds it difficult to detect and stop the infringement in a timely manner.

[0004] Furthermore, while some existing technologies incorporate blockchain or smart contracts to manage digital assets or non-fungible tokens (NFTs), they mostly focus only on ownership registration or transaction activities. They fail to provide a comprehensive lifecycle management mechanism that can be automatically executed and verified for determining the continued existence of digital avatars, verifying the immediate legality during use, automatically taking over upon expiration, or revoking rights during disputes. In summary, it is evident that existing technologies have long suffered from inaccurate lifecycle management of digital clones and high levels of inheritance disputes. Therefore, it is necessary to propose improved technical methods to address this issue. Summary of the Invention

[0005] In view of the problems of imprecise lifecycle control and high inheritance disputes in existing technologies for digital clones, this invention discloses a system and method for automatically managing the lifecycle of digital clones based on smart contracts, as well as a computer-readable recording medium, wherein: The system for automatically managing the lifecycle of digital clones based on smart contracts disclosed in this invention includes at least: The cycle management module defines the duration parameters and authorization scope of the digital clone, and selects whether to terminate the digital clone's existence permission based on the duration parameters. The acceptance maintenance module maintains the carrier acceptance rules in the smart contract. The permission transfer module determines whether the corresponding acceptance entity exists based on the carrier acceptance rules when the digital clone meets the trigger conditions. If the acceptance entity exists, the existence permission of the digital clone is transferred to the acceptance entity. The trigger conditions include the cycle management module's selection to terminate the digital clone's existence permission. The usage verification module performs legality verification based on the duration parameters, authorization scope, carrier acceptance rules, and the user identity of the digital clone before and during its use to generate verification results. If the verification results do not meet the preset conditions, the use of the digital clone is rejected or terminated.

[0006] The method for automatically managing the lifecycle of a digital clone based on smart contracts disclosed in this invention includes at least the following steps: defining the lifespan parameters, authorization scope, and carrier acceptance rules of the digital clone using a smart contract; when the smart contract determines that the digital clone meets the triggering conditions and determines that the corresponding accepting entity exists according to the carrier acceptance rules, the smart contract transfers the lifespan permission of the digital clone to the accepting entity, and the triggering conditions include selecting to terminate the lifespan permission of the digital clone according to the lifespan parameters; before the digital clone is used and during the period when the digital clone is used, the smart contract performs legality verification based on the lifespan parameters, authorization scope, carrier acceptance rules, and the user identity of the digital clone to generate a verification result; when the smart contract determines that the verification result does not meet the preset conditions, it refuses or terminates the use of the digital clone.

[0007] The computer-readable recording medium disclosed in this invention stores a computer program thereon. When the computer program is executed by a device in a distributed network environment, the device enables the device to implement the above-mentioned method for automatically managing the lifecycle of digital clones based on smart contracts.

[0008] The system, method, and computer-readable recording medium disclosed in this invention are as described above. The difference between this invention and the prior art is that when the smart contract determines that the digital clone's right of existence has ended and the receiving entity exists, the smart contract transfers the right of existence of the digital clone to the receiving entity. Before the digital clone is used and during the period when the digital clone is used, the legality of the digital clone is verified. When the verification result does not meet the preset conditions, the use of the digital clone is rejected or terminated, thereby solving the problems existing in the prior art and achieving the technical effect of ensuring the legal existence of the digital clone and reducing disputes over asset transfer. Attached Figure Description

[0009] Figure 1A This is a flowchart of the method for automatically managing the lifecycle of digital clones based on smart contracts proposed in this invention.

[0010] Figure 1B This is a flowchart of the method for generating clone recognition data proposed in this invention.

[0011] Figure 1C This is a flowchart of the method for maintaining a digital clone based on behavioral signatures or heartbeat signals proposed in this invention.

[0012] Figure 1D This is a flowchart of the method for selecting and revoking a digital clone based on a dispute-triggered event, as proposed in this invention.

[0013] Figure 1E This is a flowchart of the method for recording the usage status of a digital clone proposed in this invention.

[0014] Figure 2 This is a schematic diagram illustrating the association between the digital clone and the smart contract proposed in an embodiment of the present invention.

[0015] Figure 3 This is a schematic diagram of the modules of the system for automatically managing the lifecycle of digital clones based on smart contracts proposed in this invention.

[0016] Figure 4 This is a schematic diagram of the computer system of the electronic device proposed in this invention.

[0017] Explanation of reference numerals in the attached figures: Step 101: Generate unique clone recognition data based on the digital clone's appearance model, voice model, and / or behavior model, and record the clone recognition data to provide verification of the digital clone. Step 110: Define the duration parameters, authorization scope, and carrier acceptance rules for the digital clone. Step 130: If the digital clone meets the triggering conditions and the corresponding receiving entity exists according to the carrier receiving rules, transfer the survival rights of the digital clone to the receiving entity. Step 150: Before and during the use of the digital clone, perform a legality verification based on the duration parameters, authorization scope, carrier acceptance rules, and the user identity of the digital clone to generate a verification result. Step 160: If the verification result does not meet the preset conditions, refuse or stop the use of the digital clone. Step 170: During the period the digital clone is used, obtain the digital clone's behavioral signature or heartbeat signal to maintain the digital clone's continued existence. Step 181: Obtain the dispute triggering event Step 185: If the dispute status is established based on the dispute triggering event, revoke the digital clone's continued existence permission and save the unalterable usage records. Step 191: Obtain usage event information and behavioral data of the digital clone, as well as a snapshot of the digital clone's state during its use. Step 193: Generate a usage log containing usage event information, corresponding timestamps, behavioral data, and status snapshots. Step 195: Perform specific operations on the log to produce calculated values. Step 197: Anchor the computed value to the blockchain 210: Digital Doppelganger 220: Smart Contracts 240: External Platform 300: System 310: Cloning Detection Module 320: Periodic Management Module 330: Maintenance module 350: Permission Transfer Module 360: Use the verification module 370: Existence Monitoring Module 380: Dispute Resolution Module 390: On-chain anchoring module 400: Computer Systems 401: CPU 402: ROM 403: RAM 404: Bus 405: I / O Interface 406: Input section 407: Output Section 408: Storage Section 409: Communications Section 410: Driver 411: Removable media Detailed Implementation The features and implementation methods of the present invention will be described in detail below with reference to the accompanying drawings and embodiments. The content is sufficient to enable any person skilled in the art to easily and fully understand the technical means used by the present invention to solve the technical problem and to implement it accordingly, thereby achieving the effects that the present invention can achieve.

[0018] It should be noted that the drawings are incorporated into and constitute a part of this specification, illustrating embodiments consistent with the present invention, and are used together with the specification to explain the principles of the present invention. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0019] The diagrams provided in the following embodiments are only schematic representations of the basic concept of the present invention. The diagrams only show the elements related to the present invention and are not drawn according to the actual number, shape and size of the elements in the actual implementation. In the actual implementation, the form, quantity and proportion of each element can be arbitrarily changed, and the layout of the elements may also be more complex.

[0020] In this invention, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0021] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, known structures and devices are shown schematically rather than in detail to avoid obscuring embodiments of the invention.

[0022] This invention can perform legality verification before and / or during the use of digital avatars, and can automatically terminate the authorization of digital avatars and automatically trigger the acceptance of digital avatars through smart contracts. The legality verification proposed in this invention includes at least checking the validity of digital avatars and whether the use of digital avatars complies with regulations. The use of digital avatars includes the image, speech, commercial creation, or derivative works of digital avatars.

[0023] This invention proposes a system for automatically managing the lifecycle of digital clones based on smart contracts, a method for automatically managing the lifecycle of digital clones based on smart contracts, and a computer-readable recording medium, which will be described in detail below.

[0024] The following is a preliminary step. Figure 1AThe flowchart of the method for automatically managing the lifecycle of digital clones based on smart contracts proposed in this invention is used to illustrate the system operation of this invention. Please also refer to... Figure 2 This invention illustrates the relationship between the digital avatar and the smart contract. The method for automatically managing the lifecycle of the digital avatar based on smart contracts, proposed in this invention, is applied in a distributed network environment. It can be accomplished by one or more devices within the distributed network environment executing the smart contract. The detailed steps of this method are as follows: Step 110: Define the duration parameters, authorization scope, and carrier acceptance rules for the digital clone 210. The duration parameters proposed in this invention include, but are not limited to, start time, expiration time, grace period, and renewal conditions. The scope of authorization proposed in this invention includes restrictions on behavior type (including but not limited to display only, responding only to predetermined questions, no derivative creations allowed, no transactions allowed, etc.), contextual restrictions (including but not limited to educational use only, specific platforms only, non-profit scenarios only, and specified time periods only, etc.), and data access restrictions (including but not limited to not using private databases, not using unauthorized training data, and only accessing publicly available model versions, etc.). For example, the digital clone 210 may be allowed to use the metaverse platform, geographical region, or purpose (such as educational use, non-commercial use, etc.). In some embodiments, the normal period and the grace period may have different scopes of authorization; for example, the normal period may have a complete scope of authorization, while the grace period may only have basic authorization, but this invention is not limited thereto. The carrier acceptance rules proposed in this invention include the identification information of the legitimate accepting entity, acceptance priority, acceptance conditions, and the corresponding scope of authorization. In some embodiments, the carrier acceptance rules may use a structured legal carrier graph. The invention uses a graph to record data, but is not limited thereto. It should be noted that in this invention, the carrier acceptance rules are not limited to defining only the accepting entity that accepts the entire scope of the license; multiple accepting entities that accept different scopes of the license can also be defined. In other words, there may be one or multiple legitimate accepting entities.

[0025] For example, through the smart contract 220 associated with the digital clone 210, the expiration date of the authorization for user A to use the digital clone 210 can be set to December 31, 2026. At the same time, the carrier inheritance rules of the digital clone 210 can be defined as follows: if user A does not renew the authorization after it expires, the first priority inheritor is another digital clone B of user A, and digital clone B can obtain the full authorization of digital clone 210. The second priority is a decentralized autonomous organization (DAO), and the centralized autonomous organization (DAO) only obtains the display authorization of digital clone 210, etc.

[0026] In some embodiments, when performing step 110, the expiration disposal behavior of the digital clone 210 can also be defined through the smart contract 220 associated with the digital clone 210. For example, if no one takes over after expiration, the smart contract 220 can perform self-destruction or archive of the digital clone 210.

[0027] Step 130: If the digital clone 210 meets the triggering conditions and the corresponding receiving entity exists according to the carrier receiving rules of the digital clone 210, the survival rights of the digital clone 210 are transferred from the current owner to the receiving entity. If the digital clone 210 meets the triggering conditions, but the corresponding receiving entity does not exist according to the carrier receiving rules, the digital clone 210 can be archived or terminated. The triggering conditions mentioned in step 130 include, but are not limited to, selecting to terminate the lifespan of the digital clone 210 based on the lifespan parameters of the digital clone 210 (such as reaching the expiration date) and / or the life status of the owner of the digital clone 210 (such as the death of the owner), and multiple nodes in the distributed network environment completing consensus signing, etc.; the life status of the owner of the aforementioned digital clone 210 can be obtained through verifiable event sources such as external (third-party) oracles; the termination of the lifespan of the aforementioned digital clone 210 can be authorization, temporary suspension, suspension, or termination of the use rights of the digital clone 210; the aforementioned receiving entity can be a decentralized identifier (DID), or it can be other digital clones.

[0028] For example, if the triggering condition includes choosing to terminate the lifespan permission of digital clone 210 based on the lifespan schedule parameter of digital clone 210, when the smart contract 220 associated with digital clone 210 detects that the current time has exceeded the expiration date in the lifespan schedule parameter of digital clone 210, the triggering condition is met. The smart contract 220 can automatically retrieve the carrier transfer rules of digital clone 210 to confirm that the transferee specified by user A is digital clone B. Then, the smart contract 220 can determine whether the DID of digital clone B is valid. If the DID of digital clone B is valid, the smart contract 220 can transfer the permissions of digital clone to digital clone B.

[0029] In some embodiments, when executing step 130, the smart contract 220 associated with the digital clone 210 can typically employ a recursive search logic. That is, after selecting the highest priority subject to be accepted according to the acceptance priority order in the carrier acceptance rules of the digital clone 210, it is determined whether the currently selected subject to be accepted meets the acceptance conditions in the carrier acceptance rules. If yes, it means that the currently selected subject to be accepted is a subject that meets the carrier acceptance rules; if no, it means that the currently selected subject to be accepted does not meet the carrier acceptance rules (e.g., the subject's DID has been cancelled or it does not have a specific reputation threshold). At this time, another subject to be accepted can be selected again according to the acceptance priority order in the carrier acceptance rules, and it is determined again whether the currently selected subject to be accepted meets the acceptance conditions in the carrier acceptance rules. This process is repeated until the currently selected subject to be accepted is a subject that meets the carrier acceptance rules.

[0030] Step 150: Before and / or during the use of the digital clone 210, a legality verification is performed to generate a verification result. The aforementioned legality verification can be based on the duration parameters, authorization scope, carrier acceptance rules, and user identity of the digital clone 210. For example, the legality verification may include determining whether the digital clone 210 is within the valid period of the duration parameters (start time to expiration time), confirming whether the external platform 240 used by the initiator of the external request complies with the restrictions of the platform and / or specific region, checking whether the external environment (such as the external platform 240) used by the initiator of the external request complies with the usage restrictions, and verifying whether the cumulative usage record of the digital clone 210 within a preset period complies with the quota restrictions of the digital clone 210, etc. However, the legality verification proposed in this invention is not limited to the above. For example, if an advertiser tries to use digital clone 210 for live streaming, the smart contract 220 associated with digital clone 210 can check before digital clone 210 is used: whether digital clone 210 is within its validity period, whether the advertiser has authorization for commercial use, and whether the current frequency or number of uses exceeds the quota set by smart contract 220, etc.

[0031] Step 160: If the verification result generated in step 150 does not meet the preset conditions, the use of the digital clone 210 is rejected or suspended. For example, if the verification result indicates that the digital clone 210 has been marked as being in a grace period or has not obtained commercial authorization, the smart contract 220 associated with the digital clone 210 can refuse to provide the access token for the digital clone 210, preventing the advertiser from obtaining the digital clone 210.

[0032] Thus, through this invention, decentralized management of the lifecycle of digital clones can be achieved, ensuring that digital clones can automatically flow according to preset logic when no one is managing them, reducing disputes, and at the same time, ensuring that digital clones are used in compliance with regulations.

[0033] The method proposed in this invention can also be as follows: Figure 1B As shown in the process, before step 110, step 101 can be executed first, which is to generate unique clone identification data for digital clone 210 based on the appearance model (such as 3D Mesh model), voice model and / or behavior model of digital clone 210, and record the clone identification data in the smart contract 220 associated with digital clone 210 to provide subsequent verification of digital clone, that is, to verify the overall consistency of digital clone 210. The clone recognition data proposed in this invention can be the fingerprint hash value and version tag of the digital clone 210, but this invention is not limited thereto. The voice model of the digital clone 210 includes the voice feature of the digital clone 210, and the behavior model of the digital clone 210 includes the behavior parameter of the digital clone 210. The fingerprint hash value can be generated by performing a hash operation on the appearance model, voice model (voice feature) and / or behavior model (behavior parameter) of the digital clone 210. In some embodiments, the fingerprint hash value can also be generated by performing a hash operation on the appearance model, voice model (voice feature) and / or behavior model (behavior parameter) to generate a first hash value, and then generating a second hash value containing the first hash value according to the combination rules.

[0034] If subsequent verification of the digital clone 210 is required, it can be checked whether the digital clone 210 conforms to the original definition and legal status in multiple dimensions such as fingerprint hash value (unique fingerprint), version status, duration parameters, carrier acceptance rules and authorization scope. When the inspection results returned by multiple inspections meet the preset aggregation rules, the digital clone 210 can be regarded as having passed the overall consistency verification. Among them, the aggregation rules can be that all necessary inspection results pass, some inspection results are allowed to pass under specific conditions, or different passing thresholds are applied to each inspection result according to the life cycle stage. For example, by performing a hash operation on the 3D skeleton data of the appearance model of digital clone 210 and the speech features (such as waveform features) of the speech model, a string of fixed length (such as 0xabc123...) can be generated. The generated string is the fingerprint hash value of digital clone 210. If someone steals the model of digital clone 210 and modifies its appearance, the fingerprint hash value of the digital clone after the appearance modification will definitely change. The smart contract associated with the digital clone after the appearance modification can calculate the fingerprint hash value of the digital clone after the appearance modification and determine that the fingerprint hash value of the digital clone after the appearance modification does not match the recorded fingerprint hash value of digital clone 210. Thus, even if the version status of the digital clone after the appearance modification matches that of digital clone 210, because the fingerprint hash value of the digital clone after the appearance modification does not match that of digital clone 210, the smart contract associated with the digital clone after the appearance modification can determine that the check result does not meet the aggregation rule, and thus determine that the digital clone after the appearance modification is an unauthorized digital clone.

[0035] The method proposed in this invention can also be used as follows: Figure 1CAs shown in the process, after step 130, the activity of the digital clone 210 is continuously monitored. That is, before the digital clone 210 is used, the behavioral signature or heartbeat signal generated by the previous use of the digital clone 210 is obtained, and the existence permission of the digital clone 210 can be maintained when the behavioral signature or heartbeat signal generated by the digital clone 210 is obtained (step 170). Among them, the behavioral signature is a cryptographic digest of the behavioral pattern of the digital clone 210, which is usually generated during use behaviors such as dialogue, to ensure that the digital clone 210 has not been stolen or tampered with. It can include gait trajectory, voice characteristics, word usage habits, and micro-movements. The heartbeat signal is a liveness proof sent by the digital clone 210 at regular intervals, usually generated at fixed intervals (such as every 30 minutes, one hour, etc.), to ensure that the digital clone 210 is still under control. It can include data such as timestamp, DID, current state, and signature value. When the digital clone 210 is used, it can generate behavioral signatures and / or heartbeat signals and publish them on the blockchain. The smart contract 220 associated with the digital clone 210 can obtain the behavioral signatures and / or heartbeat signals from the blockchain as proof that the digital clone 210 is still alive. If the behavioral signatures or heartbeat signals of the digital clone 210 are continuously updated on the blockchain, the smart contract 220 can maintain the existence rights of the digital clone 210.

[0036] The method proposed in this invention can also be used as follows: Figure 1DAs shown in the process, after step 150, a dispute triggering event can be obtained (step 181), and the digital clone's continued existence permission can be revoked when the dispute status is established based on the obtained dispute triggering event, and the unalterable usage record can be saved (step 185). The dispute triggering event proposed in this invention can be generated by the smart contract 220 associated with the digital clone 210, or it can be generated jointly by multiple nodes (devices) in a distributed network environment. The dispute triggering event proposed in this invention can include blockchain events, external events, and abnormal behavior events. Blockchain events include, but are not limited to, reaching the minimum signature threshold (i.e., the number of signatures among multiple authorized entities in a pre-set manner reaches the minimum number of signatures, which can be verified by a mechanism that confirms the signatures of the authorized entities and confirms the number), and succession conflicts (i.e., multiple entities raise conflicting claims to control the digital clone 210, such as two DIDs simultaneously claiming or applying to be the legitimate successor of the digital clone 210, which can be confirmed by a mechanism that verifies the DID of the entity and checks the carrier succession rules). External events include, but are not limited to, confirming the death of the user of the digital clone 210 through a verifiable third party, obtaining data such as legal rulings or arbitration results related to the digital clone 210, which can be verified by a mechanism that verifies the third party's public key and compares the file hash value. Abnormal behavior events include, but are not limited to, continuous failure of heartbeat signal verification (i.e., the digital clone 210's death is confirmed by a verifiable third party, or obtaining data such as legal rulings or arbitration results related to the digital clone 210, which can be verified by a mechanism that verifies the third party's public key and compares the file hash value). If the heartbeat signal generated by digital clone 210 is consistently abnormal, such as digital clone 210 operating continuously but failing to publish the correct heartbeat signal to the blockchain, this can be verified by confirming the DID, timestamp, and signature value contained in the heartbeat signal generated by digital clone 210 on the blockchain; if the proof of existence is invalid (i.e., digital clone 210 does not meet the legal existence conditions of the lifecycle recorded by the existence timeline parameters, this can be verified by checking the clone identification data, existence timeline parameters, and credentials of digital clone 210); or if the usage behavior violates the authorized scope (i.e., the usage behavior violates the predetermined purpose or permissions, such as only authorizing digital clone 210 for non-commercial use, but the smart contract 220 associated with digital clone 210 determines that digital clone 210 is called by a commercial API, causing digital clone 210 to be used in commercial activities, this can be verified by confirming the usage type, context marker, API category, data access permissions, etc. of digital clone 210); the determination of whether the disputed state is valid proposed in this invention can be made using a predetermined condition table or the state machine in smart contract 220, but this invention is not limited thereto.The proposed method for revoking the continued existence rights of a digital clone involves smart contract 220 executing a permission revocation instruction to update the authorized state of digital clone 210. This causes one or more permissions of digital clone 210 to change from an active state to a restricted state such as suspend, read-only, escrow, or deny-execution, thereby preventing unconfirmed use of digital clone 210 during dispute resolution. The aforementioned usage records include the source of the triggering event, timestamp, and state changes, but this invention is not limited to these. The source of the triggering event refers to the event that leads to the execution of the permission revocation instruction by the smart contract and the verification basis, including but not limited to event type, event identification data, timestamp, verification mechanism, block number, and other information. The aforementioned state changes are the process and result of changes to one or more permissions or lifecycle of the digital clone, including but not limited to the original state, new state, affected scope, whether it can be recovered, and its association with the triggering event.

[0037] The method proposed in this invention can also be used as follows: Figure 1E As shown in the process, after step 150, the usage event information of the digital clone 210 during the period of use is obtained, and a usage log containing the usage event information and the corresponding timestamp can be generated. In practice, in addition to obtaining the usage event information of the digital clone 210 during the period of use, the behavior data and status snapshot of the digital clone 210 during the period of use can also be obtained (step 191), and a usage log containing the obtained usage event information, behavior data, status snapshot, and timestamps corresponding to the usage event information can be generated (step 193).

[0038] Then, specific operations can be performed on the generated usage logs to produce operation values ​​(step 195), and the generated operation values ​​can be anchored to the blockchain (step 197) for future auditing.

[0039] Furthermore, the method proposed in this invention can also synchronize or anchor the smart contract 220 to multiple blockchains after step 130. For example, state proofs can be transmitted through a relay communication mechanism among the anchored smart contracts of multiple blockchains, and the anchored smart contracts of each blockchain can use cryptography to verify the state proofs transmitted to the blockchain to synchronize or anchor the smart contract 220 to multiple blockchains, thereby achieving consistency of the state data of the digital clone 210.

[0040] The following continues with Figure 3 The present invention is illustrated by a schematic diagram of the modules of the system for automatically managing the lifecycle of digital clones based on smart contracts. For example... Figure 3The system 300 shown may be contained in a smart contract 220 associated with the digital clone 210, which may be executed by one or more devices in a distributed network environment.

[0041] like Figure 3 As shown, the system 300 of the present invention includes modules such as a cycle management module 320, a maintenance module 330, a permission transfer module 350, and a usage verification module 360. It may also include a clone identification module 310, a survival monitoring module 370, a dispute resolution module 380, and an on-chain anchoring module 390. The cycle management module 320 is connected to the clone identification module 310, the permission transfer module 350, the usage verification module 360, the survival monitoring module 370, the dispute resolution module 380, and the on-chain anchoring module 390. The maintenance module 330 is connected to the permission transfer module 350 and the usage verification module 360.

[0042] The clone recognition module 310 can generate unique clone recognition data specific to the digital clone 210 based on the digital clone's appearance model, voice model (voice features), and / or behavior model (behavioral parameters), and the smart contract 220 records the clone recognition data to provide subsequent verification of the digital clone. For example, when a user uploads a new 3D model, clone recognition data can be generated and recorded.

[0043] The period management module 320 is responsible for defining the duration parameters and authorization scope of the digital clone 210. The period management module 320 is also responsible for choosing whether to terminate the duration permission of the digital clone 210 based on the duration parameters of the digital clone 210.

[0044] The hosting and maintenance module 330 is responsible for maintaining the hosting rules of the digital clone 210. For example, the hosting and maintenance module 330 can maintain a list of hosting topics and record the authorized level of each hosting subject.

[0045] The permission transfer module 350 collaborates with the period management module 320 and the maintenance module 330 to determine whether the digital clone 210 meets the triggering conditions. The permission transfer module 350 is also responsible for determining whether the corresponding receiving entity exists based on the carrier receiving rules of the digital clone 210 when the triggering conditions are met. The permission transfer module 350 is also responsible for transferring the survival rights of the digital clone 210 to the receiving entity when the receiving entity corresponding to the carrier receiving rules exists. The triggering conditions include the period management module 320 selecting to terminate the survival rights of the digital clone based on the survival schedule parameters and / or determining whether to terminate the survival rights of the digital clone 210 based on the physical survival status of the owner of the digital clone 210 obtained through an externally verifiable event source. For example, when it is confirmed through an oracle that the owner of the digital clone 210 has passed away, the commercial authorization of the digital clone 210 can be transferred to receiving entity B, and the image authorization of the digital clone 210 can be transferred to receiving entity C.

[0046] The verification module 360 ​​is responsible for performing legality verification, including identity, time, region, and purpose, before and / or during the use of the digital clone 210, based on the lifespan schedule parameters and authorization scope defined by the period management module 320, the carrier acceptance rules maintained by the acceptance maintenance module 330, and the user identity of the digital clone 210. It is also responsible for refusing or terminating the use of the digital clone 210 by the user if the generated verification result does not meet the preset conditions.

[0047] The persistence monitoring module 370 can obtain the behavioral signatures or heartbeat signals generated by the digital clone 210 during its previous use before the digital clone 210 is used, and determine whether to terminate the persistence permission of the digital clone based on the obtained behavioral signatures or heartbeat signals.

[0048] The dispute resolution module 380 can obtain dispute triggering events and determine whether a dispute status is established based on these events. If a dispute status is established, the module can revoke the continued existence rights of the digital clone 210 and save an immutable usage record. For example, when a dispute status is established based on dispute triggering events related to ownership claims of multiple DIDs, the module can freeze the authorization of the digital clone 210 and save a snapshot of the current state of the digital clone 210 as immutable evidence for arbitration reference.

[0049] The on-chain anchoring module 390 can perform cross-chain synchronization and upload usage logs to the blockchain. In other words, the on-chain anchoring module 390 can synchronize or anchor the smart contract 220 associated with the digital clone 210 to multiple blockchains. The on-chain anchoring module 390 can also obtain usage event information, behavioral data, and state snapshots generated by the digital clone 210 during its use. It can generate usage logs containing the obtained usage event information, behavioral data, state snapshots, and timestamps corresponding to the usage event information. Furthermore, it can perform specific operations on the generated usage logs to produce computational values ​​(summary values) and anchor these computational values ​​to the blockchain. For example, it can synchronize the state on Ethereum to the Solana chain, ensuring the consistency of the digital clone's state in the global metaverse.

[0050] It is understood that the system 300 provided in the above embodiments and the method provided above belong to the same concept, and the specific way in which the method is executed has been described in detail in the above embodiments, and will not be repeated here. In practical applications, the system 300 provided in the above embodiments can be assigned to different functional modules as needed, that is, the modules of the system 300 can be re-divided into different functional modules, and then all or part of the functions of the corresponding functional modules can be implemented by the method described in the above embodiments. The present invention does not impose specific limitations in this regard.

[0051] In summary, the difference between this invention and existing technologies lies in its ability to transfer the lifespan rights of the digital clone to the receiving entity when the digital clone's lifespan rights expire based on the lifespan parameters of a smart contract and the receiving entity exists based on the carrier acceptance rules. Furthermore, before and during the use of the digital clone, the invention verifies the legality of the digital clone based on the lifespan parameters, the scope of authorization, the carrier acceptance rules, and the user's identity. If the verification result does not meet preset conditions, the invention rejects or terminates the use of the digital clone. This technical approach addresses the problems of inaccurate lifespan control and high inheritance disputes inherent in existing technologies, thereby ensuring the legal lifespan of digital clones and reducing disputes over asset transfers.

[0052] Figure 4 This is a schematic diagram of an electronic device provided in one embodiment of the present invention. It should be noted that... Figure 4 The computer system 400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0053] like Figure 4As shown, the computer system 400 includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 402 or programs loaded from storage portion 408 into Random Access Memory (RAM) 403, such as performing the methods described in the above embodiments. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0054] The following components are connected to the input / output interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface controller such as a local area network (LAN) card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to the input / output interface 405 as needed. A removable medium 411, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 410 as needed so that computer programs read from it can be installed into the storage section 408 as needed.

[0055] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable recording medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit 401, it performs various functions defined in the system of the present invention.

[0056] It should be noted that the computer-readable recording medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or element, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a computer disk, a hard disk, random access memory, read-only memory, erasable programmable read-only memory (EPROM), flash memory, optical fiber, compact disc read-only memory (CD-ROM), optical storage, magnetic storage (MRAM), or any suitable combination thereof. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband frequency or as part of a carrier wave, wherein a computer-readable computer program is carried. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable recording medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or element. The computer program contained on the computer-readable recording medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0057] The flowcharts and schematic diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or schematic diagram may represent a module, a program segment, or a portion of program code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than indicated in the figures. For example, two consecutively indicated blocks may actually be executed simultaneously, or sometimes in reverse order, depending on the functions involved. It should also be noted that each block in a schematic diagram or flowchart, and combinations of blocks in a schematic diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0058] The units and modules described in the embodiments of the present invention can be implemented in software or hardware, and can also be located in a processor. The names of these units and modules do not necessarily constitute a limitation on the unit or module itself.

[0059] Another aspect of the present invention provides a computer-readable recording medium storing a computer program thereon, which, when executed by a processor of a device (such as a computer) in a distributed network environment, enables the device to implement the method for automatically managing the lifecycle of digital clones based on smart contracts as described above. This computer-readable recording medium may be included in the electronic device described in the above embodiments, or it may exist independently and not incorporated into the electronic device.

[0060] Another aspect of the present invention provides a computer program product or computer program including computer instructions stored in a computer-readable recording medium. A processor of a computer device reads the computer instructions from the computer-readable recording medium and executes the computer instructions, causing the computer device to perform the method for automatically managing the lifecycle of digital clones based on smart contracts provided in the various embodiments described above.

[0061] While the embodiments disclosed in this invention are as described above, the content is not intended to directly limit the scope of patent protection for this invention. Any modifications or refinements to the form and details of the implementation of this invention made by those skilled in the art, without departing from the spirit and scope disclosed herein, shall fall within the scope of patent protection for this invention. The scope of patent protection for this invention shall still be determined by the scope defined in the appended claims.

Claims

1. A method for automatically managing the lifecycle of digital avatars based on smart contracts, implemented by one or more devices in a distributed network environment, the method comprising at least the following steps: Use smart contracts to define the duration parameters, authorization scope, and carrier acceptance rules of digital clones; When the smart contract determines that the digital clone meets the triggering conditions and determines that the corresponding receiving entity exists according to the carrier receiving rules, the smart contract transfers the survival rights of the digital clone to the receiving entity. The triggering conditions include selecting to terminate the survival rights of the digital clone according to the survival time parameters. The smart contract performs legality verification based on the duration parameters, the scope of authorization, the carrier acceptance rules, and the user identity of the digital clone before and during the use of the digital clone, and generates a verification result; and If the smart contract determines that the verification result does not meet the preset conditions, it will refuse or terminate the use of the digital clone.

2. The method for automatically managing the lifecycle of a digital clone based on a smart contract as described in claim 1, wherein before the step of defining the duration parameters and carrier acceptance rules of the digital clone using the smart contract, the method further includes generating unique clone identification data based on the appearance model, voice model and / or behavior model of the digital clone, and recording the clone identification data by the smart contract to provide a step for verifying the digital clone.

3. The method for automatically managing the lifecycle of a digital clone based on a smart contract as described in claim 1, wherein the method further includes the step of the smart contract obtaining the behavioral signature or heartbeat signal generated during the previous use of the digital clone before the digital clone is used, and determining whether to terminate the lifespan permission of the digital clone based on the behavioral signature or heartbeat signal.

4. The method for automatically managing the lifecycle of a digital clone based on a smart contract as described in claim 1, wherein after the step of the smart contract transferring the life-existence rights of the digital clone to the receiving entity, the method further includes the step of synchronizing or anchoring the smart contract to multiple blockchains.

5. The method for automatically managing the lifecycle of a digital clone based on a smart contract as described in claim 1, wherein after the step of transferring the life-existence permission of the digital clone to the receiving entity, the method further includes the steps of revoking the life-existence permission of the digital clone and saving an immutable usage record when the smart contract obtains a dispute triggering event and determines that a dispute status is established based on the dispute triggering event.

6. The method for automatically managing the lifecycle of a digital clone based on a smart contract as described in claim 1, wherein the step of determining that the digital clone meets the triggering condition further includes obtaining the personal survival status of the owner of the digital clone through an external verifiable event source, and determining whether to terminate the lifespan permission of the digital clone based on the lifespan time parameter and the personal survival status.

7. The method for automatically managing the lifecycle of a digital clone based on a smart contract as described in claim 1, wherein the method further includes the steps of obtaining usage event information, behavior data, and state snapshots generated during the use of the digital clone after the digital clone is used, generating a usage log containing the usage event information, corresponding timestamps, the behavior data, and the state snapshot, performing specific operations on the user log to generate a calculation value, and anchoring the calculation value to the blockchain.

8. A system for automatically managing the lifecycle of digital avatars based on smart contracts, the system comprising at least: The period management module is used to define the duration parameters and authorization scope of the digital clone, and to select whether to terminate the existence permission of the digital clone based on the duration parameters. The maintenance module is used to maintain the carrier acceptance rules for this digital clone; The permission transfer module is used to determine whether the corresponding receiving entity exists according to the carrier receiving rules when the digital clone meets the triggering conditions. When the receiving entity exists, the permission to continue the digital clone is transferred to the receiving entity. The triggering conditions include the period management module's choice to end the permission to continue the digital clone. and The verification module is used to perform legality verification based on the duration parameters, the scope of authorization, the carrier acceptance rules, and the user identity of the digital clone before and during the use of the digital clone, and to generate a verification result. If the verification result does not meet the preset conditions, the use of the digital clone is rejected or terminated.

9. A computer-readable recording medium storing a computer program that includes a smart contract, which, when executed by at least one device in a distributed network environment, causes the at least one device to implement the method for automatically managing the lifecycle of a digital clone based on a smart contract as described in any one of claims 1 to 7.

Images