HK40008495B - Method and related apparatus for processing information in inheritance transfer of digital asset certificate - Google Patents

Description

Information processing method and related device in digital asset certificate inheritance transfer

Technical Field

The present disclosure relates to the field of user identity information technology, and in particular to an information processing method, a judicial institution node, and a computer program medium in the inheritance and transfer of digital asset certificates.

Background Art

In real life, asset transfers are often based on physical asset certificates. With the increasing popularity of the internet, an increasing number of digital asset certificates are circulating online at an ever-increasing rate. For example, when people purchase financial products, exchanges no longer provide physical certificates by default due to the high real-time nature of transactions. Saving and transferring assets often requires logging into various asset issuance or trading websites, making it difficult for individual users to centrally manage a growing number of digital asset certificates. Furthermore, these digital asset certificates can be easily lost at the end of a user's lifecycle (e.g., through death). For example, after a user's death, their assets become unknown, making it impossible for heirs to inherit or recover the certificates according to law. A typical example is the unexpected illness of the founder of the QuadrigaCX exchange, which resulted in the inability to withdraw approximately $147 million worth of digital currency.

The existing technology lacks an information processing technology that can uniformly manage users' digital asset certificates, so that even at the end of the user's life cycle, the relevant digital asset certificates related to their identity can still be smoothly transferred.

Summary of the Invention

One purpose of the present disclosure is to propose an information processing technology that can uniformly maintain a user's digital asset credentials so that even at the end of the user's life cycle, the relevant digital asset credentials can still be automatically and securely transferred to the heir.

According to one aspect of an embodiment of the present disclosure, a method for processing information in the inheritance and transfer of digital asset certificates is disclosed. The method is executed by a judicial institution node, and the method includes:

Determine the end of the user's lifecycle;

Obtaining the user's will, which includes the identifier of the user's personal security kernel node, the identifier of each heir's personal security kernel node, the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the public key of the judicial institution's node;

If the will is signed with the public key of the judicial institution node and the signature verification is successful with the private key of the judicial institution node, it triggers the heir's personal security kernel node identified by each heir in the will to send the signature of each digital asset certificate in the will with the public key of the corresponding heir's personal security kernel node, so that the heir's personal security kernel node decrypts the signature with the private key of the heir's personal security kernel node to obtain the summary of the digital asset certificate, and obtains the inherited digital asset certificate based on the obtained summary of the digital asset certificate.

According to one aspect of an embodiment of the present disclosure, a judicial institution node is disclosed, including:

A lifecycle end determination unit, used to determine the end of a user's lifecycle;

A will acquisition unit, configured to acquire a user's will, the will including the identifier of the user's personal security kernel node, the identifier of each heir's personal security kernel node, the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the public key of the judicial institution's node;

The digital asset certificate signature sending unit is used to trigger the heir's personal security kernel node identified by each heir's personal security kernel node in the will to send the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node if the signature of the will using the public key of the judicial institution node is successfully verified using the private key of the judicial institution node, so that the heir's personal security kernel node can decrypt the signature using the private key of the heir's personal security kernel node to obtain the summary of the digital asset certificate, and obtain the inherited digital asset certificate based on the obtained summary of the digital asset certificate.

According to one aspect of an embodiment of the present disclosure, a judicial institution node is disclosed, including: a memory storing computer-readable instructions; and a processor reading the computer-readable instructions stored in the memory to execute the method described above.

According to one aspect of an embodiment of the present disclosure, a computer program medium is disclosed, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor of a computer, the computer is caused to execute the method described above.

In the disclosed embodiment, a user's digital asset certificates are maintained in their personal security kernel node. Heirs also have their own personal security kernel node, which maintains their digital asset certificates. During their lifecycle, users may create a will. The will includes the identifier of each heir's personal security kernel node, as well as a signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the public key of the judicial authority node. When the judicial authority node determines that the user's lifecycle has ended, it obtains the user's will and verifies the signature in the will using the judicial authority node's public key using its own private key. If the verification is successful, it indicates that it is the judicial authority node designated by the user to execute the inheritance. The judicial authority node then triggers the transmission of the signatures of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node to the corresponding heir's personal security kernel node. Only the true heir's personal security kernel node, using the heir's personal security kernel node's private key, can decrypt the signatures and obtain the inherited digital asset certificates. The entire inheritance process is automatically executed by the machine, and the reliability of the third-party judicial institution node that executes the inheritance procedures is guaranteed by signing the will with the public key of the judicial institution node. By signing the digital asset certificate with the public key of the heir's personal security kernel node, it is ensured that only the real heir can decrypt the signature, ensuring the security of the digital asset certificate during the inheritance process. Even at the end of the user's life cycle, the relevant digital asset certificate can still be automatically and securely transferred to the heir.

Other features and advantages of the present disclosure will become apparent from the following detailed description, or may be learned in part by practice of the present disclosure.

It should be understood that the foregoing general description and the following detailed description are exemplary only and are not restrictive of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail example embodiments thereof with reference to the attached drawings.

Figures 1A-B show a system architecture diagram of the application of the information processing method in the inheritance and transfer of digital asset certificates according to an embodiment of the present disclosure, wherein Figure 1A is a simplified system architecture diagram, and Figure 1B is a system architecture diagram after refining the personal security kernel node based on Figure 1A.

2A-K illustrate interface diagrams of an information processing method for digital asset certificate inheritance and transfer according to an embodiment of the present disclosure, applied in an application scenario of digital asset certificate inheritance after a user passes away.

FIG3 shows a flowchart of a method for processing information in the inheritance and transfer of digital asset certificates according to an embodiment of the present disclosure.

FIG4 shows a specific flow chart of verifying the signature of a will using the public key of a judicial institution node according to an embodiment of the present disclosure.

FIG5 shows a flowchart of a method for processing information in inheritance and transfer of digital asset certificates according to an embodiment of the present disclosure.

FIG6 shows a flow chart of a process for generating a will according to an embodiment of the present disclosure.

FIG7 shows a flow chart of a will updating process according to an embodiment of the present disclosure.

FIG8 shows a flow chart of a will update process according to an embodiment of the present disclosure.

FIG9 shows a block diagram of a judicial institution node according to one embodiment of the present disclosure.

FIG10 shows a hardware diagram of a judicial institution node according to one embodiment of the present disclosure.

DETAILED DESCRIPTION

Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that the description of this disclosure will be more comprehensive and complete, and will fully convey the concepts of the example embodiments to those skilled in the art. The accompanying drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. Identical reference numerals in the figures indicate identical or similar parts, and thus repeated descriptions thereof will be omitted.

In addition, the described features, structures or characteristics can be combined in any suitable manner in one or more example embodiments. In the following description, many specific details are provided to provide a full understanding of the example embodiments of the present disclosure. However, those skilled in the art will appreciate that the technical solutions of the present disclosure can be practiced while omitting one or more of the specific details, or other methods, components, steps, etc. can be adopted. In other cases, well-known structures, methods, implementations or operations are not shown or described in detail to avoid obscuring various aspects of the present disclosure.

Some of the blocks shown in the accompanying drawings are functional entities that do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The following first describes the system architecture used in the information processing method for digital asset certificate inheritance and transfer in an embodiment of the present disclosure with reference to Figures 1A-1B.

The system architecture shown in FIG1A includes a personal security kernel node 107, a relying party node 109, a relying party qualification certifier node 100, a business-level user identity credential certifier node 104, a legal user identity credential certifier node 105, a social operating system-level user identity credential certifier node 106, a relying party business operator terminal 108, a judicial institution node 145, and an investigation node 146. All of the above nodes are blockchain nodes in the blockchain network, and various data generated by them during the process of the embodiments of the present disclosure can be recorded in the blockchain, and data can also be obtained from the blockchain.

The personal security kernel node 107 is a secure core that stores a user's digital asset credentials. Each user has a corresponding personal security kernel node 107. It is the core node for managing the user's digital asset credentials. Digital asset credentials are assets that exist in the form of digital evidence, such as electronically stored financial products. Digital asset credentials often represent obligations owed by the relying party node 109 to the user after the user and the relying party node 109 have completed a transaction. For example, an electronic financial product represents the obligation of the relying party node 109, acting as a financial company, to pay interest and return principal after the user has fulfilled the purchase.

As shown in Figure 1B, the personal security kernel node 107 may include a personal security kernel node client 115 and a personal security kernel node server 116. The personal security kernel node client 115 is a client installed on the user terminal for user identity asset management, and the personal security kernel node server 116 is a server that cooperates with the personal security kernel node client 115 to perform user identity asset management.

The relying party node 109 is the node of the party that the user relies on to fulfill the service, and is generally the server node of the relying party. For example, when purchasing a financial product, the user relies on the financial company to complete the purchase. The server of the financial company is the relying party node 109 in the financial product purchase service.

The relying party salesperson terminal 108 refers to the terminal used by the salesperson performing specific business operations with the user during the transaction. For example, in the financial product purchase business, the terminal used by the counter staff who specifically interacts with the user to purchase the financial product is the relying party salesperson terminal 108. The legal user identity credential certifier node 105 is the node for registering the user's legal identity. It is used to verify the user's identity before the transaction is performed. Only then can the transaction be performed, thereby obtaining the digital asset certificate generated by the transaction with the relying party node. The business-level user identity credential certifier node 104 refers to a platform server that has previously performed business with the user. Because this platform has previously performed business with the user, the user's identity has been verified. If the identity authentication assurance level requirement is not too high, such a platform can serve as an indirect verification of the user's identity. The social operating system-level user identity credential certifier node 191 is a social operating system-level platform server that provides identity verification for users. These platforms have strong data security protection capabilities and provide universal service capabilities, such as WeChat platform servers and Facebook platform servers. It can be considered that such a service provider provides a social operating system that is widely used in the industry. Given that this type of operating system-level identity authentication is not based solely on a centralized, pre-issued static legal identity credential as the basis for identity verification, but rather incorporates a multi-dimensional, decentralized identity verification system based on social circles and user activity status confirmation to avoid the risk of identity fraud after the loss of the centralized, static identity verification component. Therefore, the user's identity verification confidence level before the service is performed is higher. The confidence level evaluation used by the social operating system for identity verification is related to the number of users, applications (such as mini-program applications), and content hosted by the social operating system. Since this part is not the focus of this disclosure, it will not be discussed in detail here. The relying party qualification certifier node 100 refers to the terminal that authenticates whether the relying party has the authority to request the user to provide user identity credentials. Before the service is performed, the user's identity needs to be verified by the legal user identity credential certifier node 105, or the service-level user identity credential certifier node 104, or the social operating system-level user identity credential certifier node 191, and the relying party's qualifications need to be verified by the relying party qualification certifier node 100. They are all nodes used before performing business to form digital asset certificates such as electronic financial products. They are not directly related to the embodiments of this disclosure and will not be described in detail.

The judicial institution node 145 is a terminal used by a judicial institution (such as a court) to execute a will, such as a server used by the court to handle will business.

The investigation node 146 is a processing terminal of a unit entrusted by a judicial institution (eg, a court) to investigate the information in inheritance, such as a terminal of an investigation committee of the court.

2A-K , the following describes the interface diagrams of the information processing method in the inheritance and transfer of digital asset certificates according to the embodiments of the present disclosure applied in the digital asset certificate inheritance application scenario after the user's death.

FIG2A shows a function selection interface diagram displayed by a user terminal associated with a personal security kernel node (Persk) 116. As previously mentioned, the personal security kernel node 116 is a device that maintains a user's digital asset credentials and can be embodied as a client in the user terminal, or a chip in the user terminal, or a metal patch, chip, or other unit with storage and computing capabilities implanted in the human body or attached to the skin surface. When the personal security kernel node 116 is a client in the user terminal, or a chip in the user terminal, or other unit with storage and computing capabilities, the user terminal associated with the personal security kernel node 116 refers to the user terminal on which it is installed. When the personal security kernel node 116 is a metal patch, chip, or other unit with storage and computing capabilities implanted in the human body or attached to the skin surface, the user terminal associated with the personal security kernel node 116 refers to the terminal that communicates with the metal patch, chip, or other unit with storage and computing capabilities and displays the digital asset credentials stored therein.

Before the end of the user's life cycle, the user can select the "Create a Will" function option in the interface shown in FIG2A to enter the interface shown in FIG2B.

The interface in Figure 2B lists all of the user's digital asset certificates or various types of digital asset certificates, allowing the user to enter the desired heirs for each digital asset certificate or each type of digital asset certificate, as well as the judicial authority for will execution. The role of the judicial authority for will execution is to initiate and witness the transfer of the digital asset certificate to the designated heir after the user's lifecycle, thus providing a public trust.

After the user completes the heir and witnessing judicial institution for each digital asset certificate on the interface shown in Figure 2B, the public keys of the heir and designated judicial institution will be retrieved, as shown in Figure 2C. The heir's public key ensures the security of the digital asset certificate issued to the heir after the user's lifecycle. The judicial institution's public key verifies that the third-party judicial institution executing the will is the one the user intended, enhancing the confidentiality of the will. Since the user's will is signed with the judicial institution's public key, only the authentic judicial institution can decrypt the signature, verify it, and proceed with subsequent procedures.

After obtaining the heir's public key, the corresponding digital asset certificate is signed with the heir's public key. The user's Persk ID, the heir's Persk ID, and the signature of the digital asset certificate using the heir's public key are placed in the will. After obtaining the judicial institution's public key, the current will content is signed with the judicial institution's public key and this signature is also placed in the will. The contents of the will at this point are shown in Figure 2D, including the user's Persk ID, the heir's Persk ID, the signature of the corresponding digital asset certificate using each heir's public key, and the will signature generated using the judicial institution's public key. The signature of the corresponding digital asset certificate using each heir's public key can only be decrypted by the heir's private key, ensuring the security of the digital asset certificate transmission during inheritance. The will signature generated using the judicial institution's public key can only be verified using the judicial institution's private key specified by the user, ensuring the credibility of the inheritance process.

Then, as shown in Figure 2E, the generated will is recorded on the blockchain.

Figures 2F-K are no longer user terminal interfaces, but rather interfaces for judicial institutions. Before a user passes away, they sign a smart contract with the blockchain network operator when joining the network. Each node in Figures 1A-B acts as a blockchain network node and has access to this smart contract. In this smart contract, the user designates the initiator and witness of the post-death inheritance process.

When a request is received from a friend or relative of user A, B, to confirm that user A has passed away, the interface shown in Figure 2F is displayed. If B is the designated successor in the user's smart contract, the succession verification process begins. This involves the designated witnesses, C, D, and E, in the smart contract sending a request to confirm that user A has passed away, as shown in Figure 2G.

If responses are received from witnesses C, D, and E indicating that user A has passed away, it is determined that user A has passed away, and the inheritance procedure begins, as shown in FIG2H .

After the judicial authority node staff selects "Confirm" on the interface shown in Figure 2H, they enter the interface shown in Figure 2I and find the will on the blockchain that contains User A's Persk ID. Because the will on the blockchain includes the user's Persk ID, the heir's Persk ID, the signature of the corresponding digital asset certificate using each heir's public key, and the will signature generated using the judicial authority's public key, the will can be found. The judicial authority then verifies the signature generated using the judicial authority's public key, as shown in Figure 2J.

If the signature verification is successful, the signature of the corresponding digital asset certificate using each heir's public key in the will is extracted and sent to the Persk identified by the heir Persk in the will, as shown in Figure 2K. After receiving it, the heir Persk uses the heir's private key to decrypt the signature and obtain the summary of the digital asset certificate. With this summary, the digital asset certificate is obtained. If the heir is not the true heir and does not have the heir's private key, it cannot be used to decrypt the signature and the inherited digital asset certificate cannot be obtained.

The above only describes the application scenario of digital asset certificate inheritance after the user's death. The process is similar in other application scenarios such as user disappearance.

According to one embodiment of the present disclosure, a method for processing information during the inheritance and transfer of digital asset certificates is provided. A digital asset certificate is an asset certificate in digitized form, such as an electronic financial product certificate. This inheritance and transfer refers to the transfer of a user's digital asset certificate to a corresponding heir after the end of the user's lifecycle. A lifecycle refers to the period from birth to death or declaration of disappearance, with the end of the lifecycle including death and declaration of disappearance. The method is executed by a judicial institution node.

As shown in FIG3 , the method includes:

Step 210: Determine that the user's life cycle has ended;

Step 220: Obtain the user's will, which includes the identifier of the user's personal security kernel node, the identifier of each heir's personal security kernel node, the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the public key of the judicial institution's node.

Step 230: If the will is signed with the public key of the judicial institution node and the signature verification is successful with the private key of the judicial institution node, the heir's personal security kernel node identified by each heir in the will is triggered to send the signature of each digital asset certificate in the will with the public key of the corresponding heir's personal security kernel node, so that the heir's personal security kernel node decrypts the signature with the private key of the heir's personal security kernel node to obtain the summary of the digital asset certificate, and obtains the inherited digital asset certificate based on the summary of the obtained digital asset certificate.

The above steps are described in detail below.

In step 210, it is determined that the user's life cycle has ended.

The end of a user's life cycle can be determined through official initiation, private initiation, or a method of joint official and private confirmation.

In the officially initiated approach, step 210 includes:

In response to the lifecycle end notification from the investigation node 146 , it is determined that the user's lifecycle has ended.

The investigation node is the terminal of an institution commissioned by the judicial authority to investigate various circumstances surrounding wills and inheritances. For example, if the judicial authority is a court, investigation node 146 is the terminal of the court's investigation committee. When a user's death or disappearance is reported to the court, the court commissions personnel from the investigation committee to investigate the user's social relationships and determine whether the user is truly deceased or should be declared missing. Based on this determination, the personnel at investigation node 146 generate an end-of-life notification and send it to judicial authority node 145. This end-of-life notification declares the user's death or disappearance.

The advantage of this embodiment is that the lifecycle end notification is obtained by the relevant personnel of the investigation node 146 after actual investigation, which is relatively comprehensive and has a small error.

In the civilian-initiated approach, step 210 includes:

Receive a startup request from a startup node;

Send a user lifecycle end confirmation message to multiple proving nodes via the social operating system platform;

If the responses of the plurality of prover nodes satisfy a predetermined condition, it is determined that the lifecycle of the user's personal security kernel node ends.

The startup node is the terminal that starts the testamentary inheritance procedure.

In one embodiment, the initiating node user is any terminal (including a court terminal, etc.), that is, the inheritance process is started as long as someone starts it.

In another embodiment, the initiating node is a user terminal in the user's address book. This means that only people known to the user can initiate the inheritance process, preventing false reports and irrelevant harassment. Since the user's personal security kernel node client may be lost after death or disappearance, the user's address book can be stored on a personal security kernel node server and retrieved from the server.

In another embodiment, the startup node is the startup node specified by the user in the smart contract during the life cycle. For example, during the life cycle, the user can specify a startup node identifier in the smart contract, such as a friend's terminal identifier. The smart contract can correspond to the user's personal security kernel node identifier and be stored in all blockchain nodes or on the blockchain. The startup request contains the user's personal security kernel node identifier. The judicial agency node 145 can obtain the user's personal security kernel node identifier from the startup request, find the smart contract corresponding to the user's personal security kernel node identifier locally or on the blockchain, and thus obtain the startup node identifier therein. If the identifier is the identifier of the issuer of the startup request, the inheritance process is started. This embodiment improves the security of enabling inheritance.

In one embodiment, a smart contract is generated through the following process:

Display the list of smart contract templates;

In response to a user selecting a smart contract template from the smart contract template list and filling in content in the selected smart contract template, the filled-in content is integrated into the smart contract template to generate a smart contract for the user.

In other words, the system provides users with multiple smart contract templates, each of which requires users to fill in certain fields. Users can select a smart contract template from a list, for example by checking a box, and then fill in the required fields within the template. The user's fields are then integrated into the selected smart contract template to generate the smart contract.

Social operating system platforms, such as WeChat and Facebook platforms, provide user identity verification and offer stronger data security and universal service capabilities than standard application service platforms. Due to the large number of registered users on these platforms, they can send succession procedure confirmation requests to multiple proving nodes. A succession procedure confirmation request is a request to confirm whether a user has passed away or is missing, in order to determine whether to initiate the succession procedure.

In one embodiment, the multiple proving nodes are randomly selected from the user's address book. As described above, the user's address book can be obtained from the personal security kernel node server. The advantage of this embodiment is that since the address book contains people the user knows, the random selection reduces the risk of the user colluding with some friends to cheat.

In one embodiment, the multiple proving node identifiers are specified by the user during their lifecycle and, like the initiation node described above, are recorded in a smart contract. The smart contract corresponds to the user's personal secure kernel node identifier and is stored on each blockchain node or on the blockchain itself. The judicial authority node obtains the user's personal secure kernel node identifier from the initiation request, locates the corresponding smart contract locally or on the blockchain, retrieves the multiple proving node identifiers from the smart contract, and sends a user lifecycle end confirmation message to the multiple proving node identifiers via the social operating system platform. This embodiment increases the flexibility of the user's choice of the will execution process.

The predetermined condition here refers to a pre-set condition that must be satisfied by the responses of the multiple proving nodes. In one embodiment, the predetermined condition is that all responses from the multiple proving nodes confirm the end of the user lifecycle. In another embodiment, the predetermined condition is that at least a predetermined proportion of the responses from the multiple proving nodes confirm the end of the user lifecycle.

The advantage of this privately initiated approach is that it is automatically executed through machine nodes, has a high degree of automation, and avoids lengthy and time-consuming government approval and investigation.

In the official and private joint confirmation method, if the responses of the multiple proving nodes meet a predetermined condition, determining that the lifecycle of the user's personal security kernel node has ended includes:

If the responses of the plurality of prover nodes satisfy predetermined conditions and a lifecycle end notification is received from the investigation node, it is determined that the lifecycle of the user's personal security kernel node has ended.

In other words, it's not enough for multiple proving node responses to meet the predefined conditions. Officials must also provide an end-of-lifecycle notification. Only when both conditions are met can the end of the lifecycle of a user's personal secure kernel node be determined. This embodiment improves the security of determining the end of the lifecycle of a user's personal secure kernel node.

In step 220, the user's will is obtained, which includes the identifier of the user's personal security kernel node, the identifier of each heir's personal security kernel node, the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the public key of the judicial institution node.

In one embodiment, obtaining the user's will includes obtaining the user's will corresponding to the identifier of the user's personal security kernel node. In other words, the corresponding user's will can be obtained according to the identifier of the user's personal security kernel node.

The identifier of a user's personal secure kernel node distinguishes it from other personal secure kernel nodes. It can be represented by letters, numbers, symbols, or a combination thereof. The identifier of a user's personal secure kernel node is recorded in a will so that after the user's lifecycle ends, the corresponding will (the will containing the identifier) can be found based on the identifier.

Each heir's personal secure kernel node identifier is specific to the user's digital asset certificate. The identifier of the individual designated by the user distinguishes that individual's secure kernel node from that of others. In a will, each digital asset certificate can have a different identifier for the individual's secure kernel node.

Each digital asset certificate is signed using the public key of the corresponding heir's personal secure kernel node. This involves generating a digest for each user's digital asset certificate using a predetermined digest algorithm and encrypting the digest using the public key of the corresponding heir's personal secure kernel node. Directly transmitting a digital asset certificate can be easily intercepted by a third party, allowing them to easily steal the digital asset certificate. Because the signature is generated by first generating a digest and then encrypting it using the public key of the corresponding heir's personal secure kernel node, it cannot be decrypted without the public key of the heir's personal secure kernel node, enhancing the security of digital asset certificate transfer during inheritance.

The signature of a will using the judicial institution node's public key refers to the signing of the will's current contents using the judicial institution node's public key. This involves generating a digest of the will's current contents using a predetermined digest algorithm and encrypting the digest using the judicial institution node's public key. This function verifies that the judicial institution node executing the will is the user-specified judicial institution node. If the executing judicial institution node is not the user-specified judicial institution node, it lacks the judicial institution node's private key and cannot successfully verify the signature. This ensures the credibility of the judicial institution node during inheritance and enhances the security of the inheritance process.

After a will is created, it can be recorded on the blockchain or stored on the user's personal secure kernel node server. This is because after the user's lifecycle ends, it is likely that the personal secure kernel node client will also be lost along with the user's terminal, and the will may also disappear. Storing it on the blockchain or on the personal secure kernel node server allows the will to be retrieved after the user's lifecycle ends.

In an embodiment of chain storage of a will, step 220 includes: obtaining a will containing the identifier of the user's personal security kernel node from the blockchain as the user's will corresponding to the identifier of the user's personal security kernel node, wherein the will is recorded on the blockchain after generation.

As described above, the will includes the identifier of the user's personal secure kernel node, the identifiers of each heir's personal secure kernel node, signatures of each digital asset certificate using the public key of the heir's personal secure kernel node, and the signature of the will using the public key of the judicial authority node. Because the activation request includes the identifier of the user's personal secure kernel node, the judicial authority node can search the blockchain for a will containing this identifier, and this will be the will of the user corresponding to the identifier of the user's personal secure kernel node.

In one embodiment, the will also includes header information. The header information includes the will signature and the will length. The will containing the identifier of the user's personal security kernel node is obtained from the blockchain, including:

After identifying the header information with the will signature in the blockchain, the data block associated with the will is identified according to the will length in the header information;

In the identified data block, it is determined whether the identifier of the user's personal security kernel node is contained. If so, the identified data block constitutes a will containing the identifier of the user's personal security kernel node.

Header information refers to the block header information of each data block after the will is recorded as a data block on the blockchain. Each data block also has a block body, which records the contents of the will. A will may include multiple data blocks. As mentioned above, a will includes the identifier of the user's personal secure kernel node, the identifiers of each heir's personal secure kernel node, the signature of each digital asset certificate using the public key of the corresponding heir's personal secure kernel node, and the signature of the will using the public key of the judicial authority node. The identifiers of different heirs' personal secure kernel nodes and the signatures of different digital asset certificates using the public keys of their corresponding heirs' personal secure kernel nodes may be recorded in different data blocks.

The Will keyword is a flag that indicates a data block on the blockchain is a will. If the Will keyword is absent, the data block does not record a will. If the Will keyword is present, it indicates that the data block does record a will. Because the blockchain records a variety of data blocks, some of which have nothing to do with wills, to narrow the search scope, the Will keyword is set in the block header of data blocks containing wills. If the Will keyword is found on the blockchain, the data block containing the Will keyword is considered a will data block.

The will length is a symbol that indicates the number of consecutive data blocks on the blockchain that the will occupies. For example, a will length of 7 means that on the blockchain, 7 data blocks, counting from the current data block, are all data blocks associated with the will.

Therefore, after identifying the header information containing the will signature in the blockchain, the data blocks associated with the will can be identified based on the will length in the header information. Then, the identification of the user's personal secure kernel node identifier can be determined within these data blocks. The advantage of this is that compared to searching the entire blockchain for data blocks containing the user's personal secure kernel node identifier, the search scope is greatly reduced, improving search efficiency.

If it is determined that the identifier of the user's personal security kernel node is contained within these continuous data block ranges, the continuous data block ranges (the number of continuous data blocks indicated by the will length) constitute a will containing the identifier of the user's personal security kernel node.

In an embodiment where the will is stored on a personal security kernel node server, the personal security kernel node includes a personal security kernel node client and a personal security kernel node server. Step 220 includes: obtaining the will from the personal security kernel node server corresponding to the identifier of the user's personal security kernel node as the will of the user corresponding to the identifier of the user's personal security kernel node, wherein the will is generated by the personal security kernel node client and stored on the personal security kernel node server.

After the personal security kernel node client generates a will, it stores it on the personal security kernel node server. The personal security kernel node client and the personal security kernel node server have the same personal security kernel node identifier. The startup request contains the identifier of the user's personal security kernel node. This allows the personal security kernel node server corresponding to this identifier to be found and the will retrieved from it.

In step 230, if the will is signed with the public key of the judicial institution node and the signature verification is successful with the private key of the judicial institution node, the heir's personal security kernel node identified by each heir in the will is triggered to send the signature of each digital asset certificate in the will with the public key of the corresponding heir's personal security kernel node, so that the heir's personal security kernel node decrypts the signature with the private key of the heir's personal security kernel node to obtain the summary of the digital asset certificate, and obtains the inherited digital asset certificate based on the obtained summary of the digital asset certificate.

After receiving a will, the Judicial Authority Node should not immediately initiate the inheritance process. This is because if it is not the user-designated Judicial Authority Node, it is not authorized to execute the subsequent inheritance procedures. Therefore, the will must be signed with the Judicial Authority Node's public key and the signature verified with the Judicial Authority Node's private key.

In one embodiment, the will also includes a node identifier of a designated judicial institution for executing the will. As shown in FIG2B , the user specifies the node identifier of the judicial institution for executing the will on the interface, thereby including the identifier in the will of FIG2D .

In this embodiment, as shown in FIG4 , the signature of the will using the public key of the judicial institution node and the successful signature verification using the private key of the judicial institution node include:

Step 310: Obtain the node identifier of the judicial institution designated in the will to execute the will;

Step 320: If the identifier of the judicial institution node designated in the will to execute the will is the identifier of the judicial institution node currently executing the method, the signature of the will using the judicial institution node public key is successfully verified using the judicial institution node private key.

Because the will contains the identifier of the judicial institution node designated to execute it, this identifier can be obtained from the will. Since the judicial institution node locally stores its own identifier, it compares the obtained identifier with its own locally stored identifier. If they match, it uses the judicial institution node's private key to verify the signature in the will, which was signed with the judicial institution node's public key.

The advantage of this embodiment is that it performs authority verification of the judicial agency node by integrating the judicial agency node identification and comparison and the verification of the signature generated by the judicial agency node public key, which can improve the accuracy of judicial agency node authority verification more than simply checking the signature.

In one embodiment, step 320 includes:

If the identifier of the judicial institution node designated in the will for executing the will is the identifier of the judicial institution node currently executing the method, the will signed with the judicial institution node's public key is decrypted with the judicial institution node's private key to obtain a decrypted will summary;

Produce an abstract of said will;

If the will summary produced after decryption is consistent with the summary of the generated will, it is determined that the signature of the will using the public key of the judicial institution node and the signature verification using the private key of the judicial institution node are successful.

Since generating a will signature involves generating a digest of the will content using a predetermined digest algorithm (e.g., a hash algorithm) and encrypting the digest using the public key of the judicial authority node, the reverse process is followed when verifying the signature. First, the signature is decrypted using the private key of the judicial authority node to obtain a digest of the will content. Then, the digest of the will is generated using the same digest algorithm used when generating the signature. Since the will has not yet been signed when the will signature is generated, the generation of the will signature is based on the content of the will other than the will signature. Therefore, in one embodiment, generating the digest of the will includes:

Remove the signature of the will from the will using the public key of the judicial authority node;

The same predetermined digest algorithm as that used when generating the will is applied to the will after the signature is removed to generate a digest of the will.

In other words, it follows the same digest generation process as when generating the signature of a will. First, the signature of the will, signed with the judicial authority node's public key, is removed. This is because when generating the signature of the will, the digest of the will containing the signature is not generated and then encrypted. Instead, the digest of the will's contents is generated and then encrypted before the signature is included. Furthermore, the judicial authority node must store the same predetermined digest algorithm as that in the user's personal security kernel node. This way, when the predetermined digest algorithm is applied to the will after the signature is removed, the generated digest is consistent with the digest generated when the signature was generated.

After applying the predetermined digest algorithm to the will after the signature has been removed, the decrypted digest of the will is compared with the digest of the generated will. If the two are consistent, the signature verification is successful, and the judicial institution node currently executing the will is deemed to be the judicial institution node specified by the user. At this point, the signature of each digital asset certificate in the will, signed using the public key of the corresponding heir's personal security kernel node, can be triggered to be sent to the heir's personal security kernel node identified by the heir's personal security kernel node in the will.

The meaning of triggering is that the judicial institution node can complete it by itself, or another node can be designated to complete it, or a smart contract in the blockchain network can be initiated and automatically assigned a node to complete it.

In the above process, what is sent is the signature of each digital asset certificate rather than the digital asset certificate itself. This is because even if a third-party node intercepts it, it does not have the private key of the heir's personal security kernel node and cannot decrypt the signature, and therefore cannot obtain the inherited digital asset certificate, thereby improving the security of the inherited digital asset certificate.

Because signing a digital asset certificate with the public key of the heir's personal security kernel node involves generating a digest of the digital asset certificate using a predetermined digest algorithm and encrypting the digest with the public key of the heir's personal security kernel node, the decryption process is also a two-step process. First, the heir's personal security kernel node decrypts the signature using its private key to obtain the digest of the digital asset certificate. Then, based on the obtained digest of the digital asset certificate, the inherited digital asset certificate is obtained.

There are multiple implementation methods for obtaining the inherited digital asset certificate based on the digest of the obtained digital asset certificate.

In one embodiment, obtaining the inherited digital asset certificate based on the obtained summary of the digital asset certificate includes: obtaining a digital asset certificate corresponding to the summary of the obtained digital asset certificate from the blockchain, wherein, after the digital asset certificate is generated, it is stored on the blockchain corresponding to the summary of the digital asset certificate.

This embodiment follows a model where digital asset certificates are uploaded to the blockchain immediately after generation. After the user's personal security kernel node and the business-relying party node (e.g., a financial company terminal) perform a transaction (e.g., sign a contract to purchase a financial product), a digital asset certificate (e.g., a financial product order) is generated between the user and the business-relying party node. Immediately after the digital asset certificate is generated, a digest of the digital asset certificate is generated according to a predetermined digest algorithm. This digest is then stored on the blockchain in correspondence with the digital asset certificate. This allows direct querying of the digital asset certificate corresponding to the digest of the obtained digital asset certificate from the blockchain.

In one embodiment, a personal security kernel node includes a personal security kernel node client and a personal security kernel node server. Obtaining an inherited digital asset certificate based on a digest of the obtained digital asset certificate includes: obtaining, from the personal security kernel node server, a digital asset certificate corresponding to the digest of the obtained digital asset certificate, wherein the digital asset certificate, after being generated by the personal security kernel node client, is stored on the personal security kernel node server in correspondence with the digest of the digital asset certificate.

In this embodiment, after the personal security kernel node client and the service-relying party node generate a digital asset certificate, they generate a digest of the digital asset certificate using a predetermined digest algorithm. This digest, along with the digital asset certificate, is stored on the personal security kernel node server. This allows the personal security kernel node server to directly query the digital asset certificate corresponding to the generated digital asset certificate digest.

In one embodiment, the will also includes the business dependent node identifier of each digital asset certificate. The triggering of sending the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node to the heir's personal security kernel node identifier of each heir in the will includes: triggering the sending of the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node and the business dependent node identifier of each digital asset certificate to the heir's personal security kernel node identifier of each heir in the will. The obtaining of the inherited digital asset certificate based on the obtained summary of the digital asset certificate includes:

Sending the obtained summary of the digital asset certificate to the business relying party node identified by the business relying party node of the digital asset certificate;

A digital asset certificate corresponding to the digest of the digital asset certificate is received from the business relying party node.

Digital asset certificates are generated by the user's personal security kernel node and a business-relying party node during the execution of a business transaction. After the digital asset certificate is generated, the digital asset certificate and its summary are backed up and stored at the business-relying party node. Therefore, the corresponding digital asset certificate can be retrieved from the business-relying party node using the summary of the digital asset certificate. To request the business-relying party node, the will must include the business-relying party node's identifier. This identifier can be generated based on the business-relying party node identifier contained in the digital asset certificate when the will is generated (the business-relying party node identifier is a key field in the digital asset certificate; without it, the digital asset cannot be redeemed). When the digital asset certificate, signed with the public key of the heir's personal security kernel node, is sent to the heir's personal security kernel node, the business-relying party node identifier is also sent simultaneously. The heir's personal security kernel node can then send the obtained digital asset certificate summary to the business-relying party node identified by the digital asset certificate. The business-relying party node stores the digital asset certificate and its summary in correspondence, allowing the business-relying party node to receive the digital asset certificate corresponding to the summary of the digital asset certificate.

In one embodiment, the inherited digital asset certificate includes the business-relying party node identifier on which the digital asset certificate depends, so that the heir's personal security kernel node and the business-relying party node identified by the business-relying party node generate an updated digital asset certificate between the heir node and the business-relying party node based on the inherited digital asset certificate.

That is to say, although in step 230, the heir's personal security kernel node obtains the inherited digital asset certificate, the digital asset certificate is only formed by the user's personal security kernel node and the relying party node, not by the heir's personal security kernel node and the relying party node. Therefore, the heir's personal security kernel node must form an updated digital asset certificate with the relying party node.

In one embodiment, the business relying party node identified by the business relying party node generates, based on the inherited digital asset certificate, an updated digital asset certificate between the successor node and the business relying party node, including the following process performed by the successor's personal security kernel node:

Sending the inherited digital asset certificate and the heir's personal security kernel node identifier to the business relying party node identified by the business relying party node, so that the business relying party node generates an updated digital asset certificate based on the inherited digital asset certificate and the heir's personal security kernel node identifier;

Receive the updated digital asset certificate sent by the business relying party node.

Since the obligations of the relying party node in the updated digital asset certificate are exactly the same as those of the inherited digital asset certificate, except that the parties have changed from the user's personal security kernel node and the business relying party node to the relying party's personal security kernel node and the business relying party node, it is possible to change only the party information in the inherited digital asset certificate content from the user's personal security kernel node identifier and the business relying party node identifier to the relying party's personal security kernel node identifier and the business relying party node identifier, obtain the updated digital asset certificate, and send it to the heir's personal security kernel node.

The benefit of this embodiment is that it converts inherited digital asset certificates through a convenient procedure, thereby improving the efficiency of updating digital asset certificates.

Furthermore, after the above process completes the entire inheritance process, the user's personal security kernel node can be set to a terminated state. Setting the user's personal security kernel node to a terminated state can be performed automatically by the smart contract allocation node. Furthermore, the user's personal security kernel node can be set to a terminated state at some point in time after the above process completes. Besides being used in inheritance, the user's personal security kernel node may also be used in other programs. Therefore, in addition to inheritance, it may be necessary to wait until other related programs are completed before the user's personal security kernel node is set to a terminated state.

A user's personal security kernel node has several states: inactive, active, suspended, and terminated. Before the user is born, the user's personal security kernel node is inactive. After the user is born, upon parental approval, the node is enabled. During this time, in the event of a loss, the node may need to be reset to a suspended state. Operations on the node are prohibited until it is restored. At the end of the user's lifecycle, after completing the aforementioned process and any other processes that may require the node, the node can be reset to a terminated state. In the terminated state, the node is deactivated and permanently inaccessible.

Furthermore, sometimes simply specifying the heirs in a will is insufficient. The effects of inheritance can vary significantly depending on the laws governing inheritance. For example, the laws of some countries require inheritance to be subject to inheritance tax, while the laws of other countries do not. In one embodiment, in the interface of FIG2B , the user not only specifies the heir's personal security kernel node identifier corresponding to each digital asset certificate and the identifier of the judicial authority node that will execute the will, but also specifies the applicable laws governing inheritance. Thus, the will shown in FIG2D may also include the applicable laws governing inheritance.

In this embodiment, in step 230, the triggering of sending the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node to the heir's personal security kernel node identified by each heir in the will includes:

Trigger the heir's personal security kernel node identified by each heir in the will, and send the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node and the inheritance applicable law of the will, so that after the heir's personal security kernel node obtains the inherited digital asset certificate, it executes the process corresponding to the inheritance applicable law.

That is to say, since the will also contains the applicable law of inheritance, what triggers the sending of the heir's personal security kernel node identified by the heir's personal security kernel node corresponding to the digital asset certificate in the will is not only the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node, but also the applicable law of inheritance of the will.

The inheritance process corresponding to each applicable inheritance law can be pre-written in program code and stored on a public server or in each user's personal secure kernel node. Thus, in one embodiment, executing the process corresponding to the applicable inheritance law includes the following process performed by the heir's personal secure kernel node: based on the received applicable inheritance law, the program code corresponding to the applicable inheritance law is retrieved from the public server or the heir's personal secure kernel node, and the inherited digital asset certificate is input into the program code, thereby executing the process corresponding to the applicable inheritance law.

The benefit of this embodiment is that inheritance can be carried out in accordance with the applicable inheritance law specified by the user, thereby improving the precision of inheritance.

Furthermore, not all users create a will before their lifecycle ends. When a user doesn't create a will before their lifecycle ends, it's equivalent to a statutory inheritance scenario. In addition to testamentary inheritance, one embodiment also automates the data processing for statutory inheritance, enabling automated default testamentary inheritance.

As shown in FIG5 , in one embodiment, after step 210, the method further includes:

Step 225: If the user's will cannot be obtained, determine the law corresponding to the identity based on the identity of the user's personal security kernel node;

Step 235: Obtain the user's kinship relationship;

Step 245: Obtain the user's digital asset certificates;

Step 255: For each digital asset certificate of the user obtained, determine the personal security kernel node identifier of the heir corresponding to each digital asset certificate according to the determined law and the kinship relationship;

Step 265: Obtain the public key of the heir's personal security kernel node of the determined heir's personal security kernel node identifier;

Step 275: Sign each digital asset certificate of the user with the public key of the corresponding heir's personal security kernel node and send it to the corresponding heir's personal security kernel node, so that the heir's personal security kernel node can decrypt the signature with the private key of the heir's personal security kernel node to obtain the summary of the digital asset certificate. Based on the obtained summary of the digital asset certificate, the inherited digital asset certificate is obtained.

These steps are described in detail below.

In step 225, if the user's will cannot be obtained, the law corresponding to the identity is determined based on the identity of the user's personal security kernel node.

If the user's will cannot be obtained from the blockchain or the user's personal security kernel node server, it is likely that the user's life cycle has ended before he or she has had time to establish a will. At this time, statutory inheritance needs to be initiated and the law corresponding to the identity of the user's personal security kernel node needs to be determined.

Since the user's personal security kernel node client may not be found after the user's lifecycle ends, in one embodiment, the identity of the user's personal security kernel node is stored in advance on the personal security kernel node server. Based on the identity of the user's personal security kernel node, the corresponding law is determined, including:

Send an identity request to the personal security kernel node server corresponding to the personal security kernel node identifier of the user in the startup request;

Receiving the identity of the user's personal security kernel node from the personal security kernel node server;

Search the identity-law correspondence table to determine the law corresponding to the identity.

Since the startup request contains the user's personal security kernel node identifier, which corresponds to a unique set of personal security kernel node clients and servers, an identity request can be sent to the personal security kernel node server corresponding to the user's personal security kernel node identifier in the startup request.

The identity of a user's personal security kernel node refers to the user's nationality, registration region, etc. For example, if the user is Chinese, Chinese law may apply to inheritance. If the user is an individual, US law may apply to inheritance.

A table of correspondences between the identity of a user's personal security kernel node and the applicable laws for inheritance, i.e., an identity-law correspondence table, is stored in a predetermined server or in each personal security kernel node. From this correspondence table, the law corresponding to the identity of the user's personal security kernel node can be determined based on the identity of the user's personal security kernel node.

In step 235, the user's kinship relationship is obtained.

In one embodiment, the user's kinship list is stored in the user's personal security kernel node server. Therefore, the user's kinship list in the user's personal security kernel node server can be used to obtain the user's kinship relationship.

In step 245, the user's digital asset certificates are obtained.

In one embodiment, a user's digital asset credentials are stored not only on the user's personal secure kernel node client but also on the user's personal secure kernel node server. Although the user's personal secure kernel node client may become unavailable after the user's lifecycle ends, the corresponding personal secure kernel node server can be found based on the user's personal secure kernel node in the startup request, from which the user's digital asset credentials can be retrieved.

In step 255, for each digital asset certificate of the user obtained, the personal security kernel node identifier of the heir corresponding to each digital asset certificate is determined according to the determined law and the kinship relationship.

In one embodiment, program code corresponding to each applicable law is installed on a dedicated server or in each personal security kernel node. The user's digital asset credentials and the kinship relationship are input into the program code corresponding to the determined law, and the heir's personal security kernel node identifier corresponding to each digital asset credential is obtained according to the law.

In step 265 , the public key of the heir's personal security kernel node of the determined heir's personal security kernel node identifier is obtained.

In one embodiment, obtaining the public key of the heir's personal security kernel node, which identifies the heir's personal security kernel node, can be achieved by requesting a dedicated authentication center (CA) server in the blockchain. Since the authentication center (CA) server is the node that issues the public and private keys of blockchain nodes, the public key of any blockchain node can be requested from it.

In another embodiment, obtaining the public key of the heir's personal security kernel node with the determined heir's personal security kernel node identifier includes: obtaining the public key of the heir's personal security kernel node corresponding to the determined heir's personal security kernel node identifier from the blockchain, wherein the public key of the heir's personal security kernel node is generated by the heir's personal security kernel node and recorded on the blockchain corresponding to the public key identifier of the heir's personal security kernel node.

In this embodiment, the public key is not generated and stored by the authentication center server, but by each individual security kernel node and published on the blockchain. Since the corresponding record of the individual security kernel node identifier is recorded on the blockchain, the individual security kernel node identifier can be used to search on the blockchain when needed.

In another embodiment, obtaining the public key of the heir's personal security kernel node of the determined heir's personal security kernel node identifier includes:

Sending a public key acquisition request to the personal security kernel node of the heir's friend via the social operating system platform, wherein the public key acquisition request includes the determined personal security kernel node identifier of the heir;

Receive the public key of the heir's personal security kernel node identified by the heir's personal security kernel node from the heir's friend's personal security kernel node.

On a social operating system platform (such as WeChat), when two users add each other as friends, the public key of one user is sent to the other user's personal security kernel node for storage. The social operating system platform stores the friendship relationships between all users who have added each other as friends. In this way, through the social operating system platform, a list of all heir personal security kernel node identifiers that have a friendship relationship with the heir's personal security kernel node identifier can be obtained, and a public key acquisition request is sent to the personal security kernel node of any personal security kernel node identifier in the list, the public key acquisition request including the determined heir personal security kernel node identifier. The personal security kernel node returns the public key of the heir personal security kernel node identified by the heir personal security kernel node identifier.

In step 275, each digital asset certificate of the user is signed with the public key of the corresponding heir's personal security kernel node and sent to the corresponding heir's personal security kernel node, so that the heir's personal security kernel node decrypts the signature with the private key of the heir's personal security kernel node to obtain the summary of the digital asset certificate, and obtains the inherited digital asset certificate based on the obtained summary of the digital asset certificate.

The only difference between this step and step 230 is that, whereas in step 230, the heir's security kernel node corresponding to the digital asset certificate in the will sends a signature using the public key of the heir's personal security kernel node, in step 275, the heir's security kernel node corresponding to the legally derived digital asset certificate sends a signature using the public key of the heir's personal security kernel node. The general process is the same, so I won't repeat it here.

The advantage of this embodiment is that it realizes the automation of legal inheritance and ensures the security of inheritance.

As shown in FIG6 , in one embodiment, the will is generated by the user's personal security kernel node through the following process:

Step 410: For the digital asset certificate in the user's personal security kernel node, receive the user's designation of the personal security kernel node identifier of the successor of the digital asset certificate;

Step 420: Obtain the public key of the heir's personal security kernel node of the designated heir's personal security kernel node identifier;

Step 430: Sign each digital asset certificate with the public key of the heir's personal security kernel node corresponding to the designated heir's personal security kernel node identifier, thereby obtaining a signature of each digital asset certificate with the public key of the corresponding heir's personal security kernel node.

Step 440: Place the user's personal security kernel node identifier, the identifiers of each heir's personal security kernel node, and the signatures of each digital asset certificate using the public key of the corresponding heir's personal security kernel node into the will;

Step 450: Receive the user's designation of the node identifier of the judicial institution that will execute the will;

Step 460: Obtain the public key of the judicial institution node identified by the judicial institution node;

Step 470: Sign the current content of the will with the obtained public key of the judicial institution node and put it into the will.

The above process is described in detail below.

In step 410 , for the digital asset certificate in the user's personal security kernel node, the user's designation of the personal security kernel node identifier of the heir of the digital asset certificate is received.

FIG2B shows an interface for a user to specify the identity of an heir's personal security kernel node for a digital asset certificate in a personal security kernel node. In practice, step 410 can be implemented by category designation or item designation. FIG2B is an example interface for item designation.

In the embodiment specified in the sub-item, step 410 includes:

Displays a list of digital asset certificates in the user's personal secure kernel node;

For each digital asset certificate in the digital asset certificate list, a designation of a personal security kernel node identifier of an heir of the digital asset certificate by a user is received.

In this embodiment, the interface of FIG2B displays a list of digital asset certificates containing all digital asset certificates in the user's personal security kernel node. Below each digital asset certificate in the list, a drop-down box is displayed for specifying the personal security kernel node identifier of the heir to that digital asset certificate. Clicking the arrow on the right side of the drop-down box causes a drop-down menu to pop up, displaying all candidate heir personal security kernel node identifiers. All candidate heir personal security kernel node identifiers can be directly derived from the user's address book stored in the user's personal security kernel node, or directly derived from the kinship list stored in the user's personal security kernel node. When the user selects a candidate personal security kernel node identifier in the drop-down menu, the heir personal security kernel node identifier for that digital asset certificate is considered to have been specified.

The advantage of this embodiment is that it is convenient for users to specify the corresponding heir's personal security kernel node identifier for each digital asset certificate, thereby improving the precision of will generation.

In a classification-specified embodiment, step 410 includes:

Displays a list of digital asset certificate types in the user's personal security kernel node;

For each digital asset certificate type in the digital asset certificate list, a user designation of an heir personal security kernel node identifier for the digital asset certificate type is received, wherein the designated heir personal security kernel node identifier is used for each digital asset certificate of the digital asset certificate type.

The interface of this embodiment differs from that of FIG. 2B in that the interface of FIG. 2B displays a list of all digital asset certificates, while the interface of this embodiment displays a list of all digital asset certificate types (such as financial product orders, insurance product orders, and stock trading orders). This is because users typically wish to designate the same heir to inherit the same type of digital asset certificate (financial product order). Then, for each digital asset certificate type in the digital asset certificate list, the user designates the heir's personal security kernel node identifier for that digital asset certificate type. After designation, all digital asset certificates of this type are inherited by the designated heir's personal security kernel node upon inheritance.

The advantage of this embodiment is that it improves the efficiency of will generation in view of the fact that users usually want to designate the same heir to inherit the same type of digital asset certificate (financial product certificate).

In step 420 , the public key of the heir's personal security kernel node of the designated heir's personal security kernel node identifier is obtained.

As previously mentioned, obtaining the public key of the heir's personal secure kernel node, which identifies the designated heir's personal secure kernel node, can be accomplished by requesting it from a dedicated certification authority (CA), obtaining it from the blockchain, or obtaining it from the heir's friends' personal secure kernel nodes through a social operating system platform. Since the specific implementation has been described previously, it will not be repeated here to save space.

In step 430, each digital asset certificate is signed with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node, so that each digital asset certificate is signed with the public key of the corresponding heir's personal security kernel node.

As described above, the process of signing a digital asset certificate with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node includes generating a digest for the digital asset certificate based on a predetermined digest algorithm, and encrypting the digest with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node.

In step 440, the identifier of the user's personal security kernel node, the identifier of each heir's personal security kernel node, and the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node are placed in the will.

The user's personal secure kernel node identifier is included in the will because it is needed to retrieve the will during the inheritance process. The identifiers of each heir's personal secure kernel node and the signatures of each digital asset certificate using the public key of the corresponding heir's personal secure kernel node are included in the will because the inheritance process requires sending the digital asset certificate signed with the public key of the corresponding heir's personal secure kernel node to the heir's personal secure kernel node corresponding to these identifiers.

In step 450, the user's designation of the node identifier of the judicial institution that will execute the will is received.

As shown in Figure 2B, the user can specify the judicial authority node ID for executing the will in the drop-down box on the interface. Clicking the arrow to the right of the drop-down box will pop up a drop-down menu displaying all candidate judicial authority node IDs. These candidate judicial authority node IDs are pre-imported. Once the user selects a candidate judicial authority node ID in the drop-down menu, the judicial authority node ID for executing the will is designated.

In step 460, the public key of the judicial institution node identified by the judicial institution node is obtained.

Similar to step 420, this step can also be implemented by requesting a dedicated certification center server (CA), or obtained from the blockchain, or obtained from the personal security kernel node of the heir's friend through the social operating system platform, so it will not be repeated here.

In step 470, the current content in the will is signed with the obtained public key of the judicial institution node and placed into the will.

The significance of this signature in the will is as previously mentioned. It can be used during the inheritance process to verify whether the judicial authority node executing the inheritance process is the one the user intended. If the judicial authority node executing the inheritance process is not the one specified by the user, signature verification will fail without the judicial authority node's private key.

The advantage of this embodiment is that a will is generated in a quick manner, thereby improving the efficiency of will generation.

As previously described, in addition to including the identifier of the user's personal security kernel node, the identifiers of each heir's personal security kernel node, the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the judicial institution's node public key, the will may also include a designated judicial institution node identifier. In this embodiment, before step 470, the method for generating a will further includes: inserting the designated judicial institution node identifier into the will (not shown).

Since the user's designation of the node ID of the judicial institution that will execute the will has been received in step 450, the ID can be placed in the will in this step.

After a will is generated, it can be configured in various locations. As previously mentioned, in step 220, when obtaining the user's will, it can be obtained from the blockchain or from the user's personal secure kernel node server. In practice, it can also be obtained using the user's personal secure kernel node client, but the user's personal secure kernel node client is very easy to lose as the user's lifecycle ends. Therefore, obtaining it from the blockchain or the user's personal secure kernel node server is more secure. In one embodiment, based on the security requirements of the will configuration, it can be divided into multiple security modes, each with different security levels.

In one embodiment, the will is configured through the following process after it is generated:

Display a security mode list, which includes a first security mode, a second security mode, and a third security mode. In the first security mode, the will is stored in the user's personal security kernel node client; in the second security mode, the will is stored in the user's personal security kernel node client and server; in the third security mode, the will is stored in the user's personal security kernel node server and published on the blockchain;

In response to the user selecting a first security mode in the security mode list, storing the will in the user's personal security kernel node client;

In response to the user selecting a second security mode in the security mode list, storing the will in the user's personal security kernel node client and server;

In response to the user selecting the third security mode in the security mode list, the will is stored in the user's personal security kernel node server and published on the blockchain.

Will configuration refers to the storage and maintenance of a will after it's created. Security modes refer to different ways of storing a will, corresponding to different levels of security. In the first security mode, the will is stored on the user's personal secure kernel node client. This prevents the user from retrieving their digital asset certificates if their phone is lost, resulting in the lowest level of security. In the second security mode, the will is stored on both the user's personal secure kernel node client and the server. This allows for asset recovery even if the user's phone is lost, providing the second highest level of security. In the third security mode, the will is stored on both the user's personal secure kernel node client and the server, and published on the blockchain. This allows for easy retrieval if the will is lost in one location, providing the highest level of security.

In addition, after a user generates a will during their lifecycle, they may continue to generate digital asset certificates, such as forming new digital asset certificates with a relying party node (e.g., purchasing a new financial product and generating a new financial product order). For these new digital asset certificates, no corresponding heir's personal secure kernel node identifier is specified. Therefore, after the user's lifecycle ends, these new digital asset certificates cannot be inherited according to the will. Therefore, if a user generates a will and additional digital asset certificates are added to the user's personal secure kernel node, two implementation methods can be used: allowing the user to additionally specify the heir's personal secure kernel node identifier for the digital asset certificate, or automatically specifying the heir's personal secure kernel node identifier for the digital asset certificate for the user.

In an embodiment where the user is asked to specify the personal security kernel node identifier of the heir of the digital asset certificate, as shown in FIG7 , the will is updated by the user's personal security kernel node through the following process:

Step 510: When a digital asset certificate is added to the user's personal security kernel node, an interface for specifying the personal security kernel node identifier of the heir of the digital asset certificate is displayed to the user;

Step 520: receiving, on the interface, a user's designation of a personal security kernel node identifier for an heir of the digital asset certificate;

Step 530: Obtain the public key of the heir's personal security kernel node of the designated heir's personal security kernel node identifier;

Step 540: Sign the added digital asset certificate with the public key of the heir's personal security kernel node corresponding to the designated heir's personal security kernel node identifier, thereby obtaining a signature of the added digital asset certificate with the public key of the corresponding heir's personal security kernel node.

Step 550: Add the heir's personal security kernel node identifier specified for the added digital asset certificate and the signature of the added digital asset certificate using the public key of the corresponding heir's personal security kernel node to the will;

Step 560: Remove the current signature in the will using the obtained public key of the judicial institution node;

Step 570: Sign the current content in the will with the obtained public key of the judicial institution node and put it into the will.

Steps 510-570 are described in detail below.

In step 510, when a digital asset certificate is added to the user's personal security kernel node, an interface for specifying the personal security kernel node identifier of the heir of the digital asset certificate is displayed to the user.

In one embodiment, a user's personal security kernel node includes a detection module. When a new digital asset credential is written to the personal security kernel node (i.e., the user's personal security kernel node and the relying party node perform business and generate a credential, i.e., a digital asset credential, which is written to the personal asset safe of the personal security kernel node), the detection module detects this and displays an interface similar to FIG2B , which lists the added digital asset credential and a drop-down box below for specifying the heir's personal security kernel node. Clicking the arrow on the right displays a drop-down menu containing a list of all candidate heir personal security kernel node identifiers, allowing the user to select.

In step 520, the user's designation of a personal security kernel node identifier of the heir of the digital asset certificate is received on the interface.

When the user selects an heir's personal security kernel node identifier in the drop-down menu, it is considered that the user's designation of the heir's personal security kernel node identifier for the digital asset certificate has been received.

In step 530 , the public key of the heir's personal security kernel node of the designated heir's personal security kernel node identifier is obtained.

Similar to step 420, this step can also be implemented by requesting a dedicated certification center server (CA), or obtained from the blockchain, or obtained from the personal security kernel node of the heir's friend through the social operating system platform, so it will not be repeated here.

In step 540, the added digital asset certificate is signed with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node, and the added digital asset certificate is signed with the public key of the corresponding heir's personal security kernel node.

This step is similar to step 430, and includes generating a digest of the added digital asset certificate according to a predetermined digest algorithm, and encrypting the digest with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node.

In step 550, the heir's personal security kernel node identifier specified for the added digital asset certificate and the signature of the added digital asset certificate using the public key of the corresponding heir's personal security kernel node are added to the will.

This step is similar to step 440, except that step 550 is only for the added digital asset certificate, and the heir's personal security kernel node identifier and corresponding signature are added to the will, so it is not repeated here.

In step 560, the current signature in the will using the obtained public key of the judicial institution node is removed.

When the will was signed with the judicial institution node's public key in step 470, the signature was applied to the current contents of the will at the time of creation. Since the content added in step 550 has been added to the current contents of the will, the signature inheritance has changed, and therefore a new signature is required. However, this signature in the will itself is not part of the signature basis. When signing the new will with the judicial institution node's public key, this signature must first be removed. Then, the current contents of the will are signed with the acquired judicial institution node's public key. At this point, the current contents include the content added in step 550.

In step 570, the current content in the will is signed with the obtained public key of the judicial institution node and placed into the will.

The above process provides a simple and easy way to update a will when the user's digital asset certificates increase after the will is generated, avoiding the problem that some newly added digital asset certificates in the will may have no heirs in the future.

In the case of automatically adding the personal security kernel node identifier of the heir of the newly added digital asset certificate to the digital asset certificate, in one embodiment, as shown in FIG8 , the will is updated by the user's personal security kernel node through the following process:

Step 510': When a digital asset certificate is added to the user's personal security kernel node, the heir's personal security kernel node identifier corresponding to the added digital asset certificate is determined based on the heir's personal security kernel node identifier specified for the existing digital asset certificate in the will;

Step 520': Obtain the public key of the heir's personal security kernel node corresponding to the added digital asset certificate.

Step 530': Sign the added digital asset certificate with the public key of the heir's personal security kernel node corresponding to the designated heir's personal security kernel node identifier, thereby obtaining a signature of the added digital asset certificate with the public key of the corresponding heir's personal security kernel node.

Step 540': add the heir's personal security kernel node identifier specified for the added digital asset certificate and the signature of the added digital asset certificate using the public key of the corresponding heir's personal security kernel node to the will;

Step 550': remove the current signature in the will using the obtained public key of the judicial institution node;

Step 560': Sign the current content in the will with the obtained public key of the judicial institution node and put it into the will.

The above steps are described in detail below.

In step 510', when a digital asset certificate is added to the user's personal security kernel node, the heir's personal security kernel node identifier corresponding to the added digital asset certificate is determined based on the heir's personal security kernel node identifier specified for the existing digital asset certificate in the will.

The method for determining whether to add a digital asset certificate to the user's personal security kernel node is the same as step 510.

In one embodiment, determining the heir's personal security kernel node identifier corresponding to the added digital asset certificate based on the heir's personal security kernel node identifier specified in the will for the existing digital asset certificate includes:

Get the type of added digital asset certificate;

Find the personal security kernel node identifier of the heir designated in the will for the same type of digital asset certificate;

If the personal security kernel node identifiers of the heirs specified in the will for the same type of digital asset certificates are consistent, the personal security kernel node identifiers of the heirs specified in the will for the same type of digital asset certificates will be determined as the personal security kernel node identifiers of the heirs corresponding to the added digital asset certificates.

Since the digital asset certificate contains a digital asset certificate type field, the type of the added digital asset certificate can be obtained from the type field of the digital asset certificate.

For example, if the added digital asset certificate is a financial product, the heir's personal security kernel node identifier specified for the digital asset certificate of the financial product type in the will is searched. If the will previously contained five digital asset certificates of the financial product type, there would be five heir's personal security kernel node identifiers specified for these digital asset certificates. However, these five heir's personal security kernel node identifiers may be identical. In other words, the heir's personal security kernel node identifiers specified for the same type of digital asset certificates in the will are identical. In this case, the user likely wishes to specify the same heir's personal security kernel node for the newly added digital asset certificate. Therefore, the heir's personal security kernel node identifier specified for the same type of digital asset certificate in the will is determined as the heir's personal security kernel node identifier corresponding to the added digital asset certificate.

In one embodiment, determining the heir's personal security kernel node identifier corresponding to the added digital asset certificate based on the heir's personal security kernel node identifier specified for the existing digital asset certificate in the will further includes:

If the personal security kernel node identifiers of the heirs specified in the will for the same type of digital asset certificates are inconsistent, the personal security kernel node identifier of the heir with the largest number of personal security kernel node identifiers among the multiple personal security kernel node identifiers of the heirs specified in the will for the same type of digital asset certificates shall be determined as the personal security kernel node identifier of the heir corresponding to the added digital asset certificate.

For example, if there are 5 digital asset certificates of the financial product type in the will, there are 5 personal security kernel node identifiers of the heirs specified for these digital asset certificates, 3 of which are the identifiers of the heir's personal security kernel node A and 2 are the identifiers of the heir's personal security kernel node B. At this time, the one with more of the two may be the one the user prefers to specify. Therefore, the heir's personal security kernel node identifier with the most of the 5 heir's personal security kernel node identifiers specified for the same type of digital asset certificates in the will, that is, the identifier of the heir's personal security kernel node A, is automatically determined as the heir's personal security kernel node identifier corresponding to the added digital asset certificate.

This embodiment determines the heir personal security kernel node identifier specified for the newly added digital asset certificate based on the heir personal security kernel node identifier previously specified for the same type of digital asset certificate. Since users tend to specify the same heir personal security kernel node for the same type of digital asset certificate, this embodiment improves the accuracy of automatically specifying the heir personal security kernel node identifier.

In addition, if the same type of digital asset certificate is not found in the will, the user can manually select the heir's personal security kernel node identifier corresponding to the digital asset certificate that he wishes to add in a manner similar to steps 510-520.

In one embodiment, determining the heir's personal security kernel node identifier corresponding to the added digital asset certificate based on the heir's personal security kernel node identifier specified in the will for the existing digital asset certificate includes:

Obtain the business relying party node identifier of the added digital asset certificate;

Find the personal security kernel node ID of the heir specified in the will for the digital asset certificate with the same business relying party node ID;

If the personal security kernel node identifier of the heir specified in the will for the digital asset certificate with the same business dependent party node identifier is consistent, the personal security kernel node identifier of the heir specified in the will for the digital asset certificate with the same business dependent party node identifier shall be determined as the personal security kernel node identifier of the heir corresponding to the added digital asset certificate.

Since the digital asset certificate also contains a business relying party node identification field, the business relying party node identification of the added digital asset certificate can be obtained from the relying party node identification field.

For example, the added digital asset certificate is a financial product purchased from Financial Management Company A. Therefore, the business relying party node identifier is the terminal identifier of Financial Management Company A. Find five heir personal security kernel node identifiers specified in the will for digital asset certificates (such as financial products) generated from Financial Management Company A's terminal. However, these five heir personal security kernel node identifiers may be the same. In this case, the same heir personal security kernel node identifier is used as the heir personal security kernel node identifier corresponding to the added digital asset certificate.

In one embodiment, determining the heir's personal security kernel node identifier corresponding to the added digital asset certificate based on the heir's personal security kernel node identifier specified for the existing digital asset certificate in the will further includes:

If the personal security kernel node identifiers of the heirs specified in the will for the digital asset certificates with the same business dependent party node identifier are inconsistent, the personal security kernel node identifier of the heir with the largest number of personal security kernel node identifiers among the multiple personal security kernel node identifiers of the heirs specified in the will for the digital asset certificates with the same business dependent party node identifier shall be determined as the personal security kernel node identifier of the heir corresponding to the added digital asset certificate.

For example, if there are 5 financial products purchased from financial management company A in the will, there are 5 heir personal security kernel node identifiers specified for these digital asset certificates, 3 of which are the identifiers of the heir personal security kernel node A and 2 are the identifiers of the heir personal security kernel node B. At this time, the one with more of the two may be the one the user prefers to specify. Therefore, the heir personal security kernel node identifier with the most of the 5 heir personal security kernel node identifiers specified for the digital asset certificates with the same business dependent party node identifier in the will, that is, the identifier of the heir personal security kernel node A, is automatically determined as the heir personal security kernel node identifier corresponding to the added digital asset certificate.

This embodiment determines the heir's personal security kernel node identifier specified for the newly added digital asset certificate based on the heir's personal security kernel node identifier previously specified for the digital asset certificate of the same business dependent party node identifier. Since users tend to specify the same heir's personal security kernel node for digital asset certificates of the same business dependent party node, this embodiment improves the accuracy of automatically specifying the heir's personal security kernel node identifier.

In step 520', the public key of the heir's personal security kernel node corresponding to the added digital asset certificate is obtained.

Similar to step 530, this step can also be implemented by requesting a dedicated certification center server (CA), or obtained from the blockchain, or obtained from the personal security kernel node of the heir's friend through the social operating system platform, so it will not be repeated here.

In step 530', the added digital asset certificate is signed with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node, and the added digital asset certificate is signed with the public key of the corresponding heir's personal security kernel node.

This step is similar to step 540 and will not be described in detail.

In step 540', the heir's personal security kernel node identifier specified for the added digital asset certificate and the signature of the added digital asset certificate using the public key of the corresponding heir's personal security kernel node are added to the will.

This step is similar to step 550 and will not be described in detail.

In step 550', the current signature in the will using the obtained public key of the judicial institution node is removed.

This step is similar to step 560 and will not be described in detail.

In step 560', the current content in the will is signed with the obtained public key of the judicial institution node and placed into the will.

This step is similar to step 570 and will not be described in detail.

This embodiment automatically allocates the heir's personal security kernel node identifier to the newly added digital asset certificate based on the existing digital asset certificate in the user's personal security kernel node, thereby improving the automation level of will updates.

In addition, if the digital asset certificate with the same business dependent party node identifier is not found in the will, the user can manually select the heir's personal security kernel node identifier corresponding to the digital asset certificate that he wishes to add in a manner similar to steps 510-520.

As shown in FIG9 , according to one embodiment, a judicial institution node is further provided, including:

A lifecycle end determination unit 610 is used to determine the end of a user's lifecycle;

A will acquisition unit 620 is configured to acquire a user's will, which includes the identifier of the user's personal security kernel node, the identifiers of each heir's personal security kernel node, the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the public key of the judicial institution's node.

The first digital asset certificate signature sending unit 630 is used to trigger the heir's personal security kernel node identified by each heir's personal security kernel node in the will to send the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node if the signature of the will using the public key of the judicial institution node is successfully verified using the private key of the judicial institution node, so that the heir's personal security kernel node can decrypt the signature using the private key of the heir's personal security kernel node to obtain the summary of the digital asset certificate, and obtain the inherited digital asset certificate based on the obtained summary of the digital asset certificate.

In one embodiment, the lifecycle end determination unit 610 is further configured to:

In response to the lifecycle end notification from the investigation node, it is determined that the lifecycle of the user has ended.

In one embodiment, the lifecycle end determination unit 610 is further configured to:

Receive a startup request from a startup node;

Sending a confirmation request for starting the inheritance program to multiple proving party nodes via the social operating system platform;

If the responses of the plurality of prover nodes satisfy a predetermined condition, it is determined that the lifecycle of the user is ended.

In one embodiment, if the responses of the plurality of proving nodes satisfy a predetermined condition, determining that the user lifecycle has ended includes:

If the responses of the plurality of prover nodes satisfy predetermined conditions and a lifecycle end notification is received from the investigating node, it is determined that the user's lifecycle has ended.

In one embodiment, the will also includes an identifier of a designated judicial institution node for executing the will. The signature of the will using the judicial institution node public key and the successful signature verification using the judicial institution node private key include:

Obtain the node ID of the judicial institution designated in the will to execute the will;

If the identifier of the judicial institution node designated in the will to execute the will is the identifier of the judicial institution node currently executing the method, the signature of the will using the public key of the judicial institution node is successfully verified using the private key of the judicial institution node.

In one embodiment, if the identifier of the judicial institution node designated in the will to execute the will is the identifier of the judicial institution node currently executing the method, the signature of the will using the judicial institution node public key is successfully verified using the judicial institution node private key, including:

If the identifier of the judicial institution node designated in the will for executing the will is the identifier of the judicial institution node currently executing the method, the will signed with the judicial institution node's public key is decrypted with the judicial institution node's private key to obtain a decrypted will summary;

Produce an abstract of said will;

If the will summary produced after decryption is consistent with the summary of the generated will, it is determined that the signature of the will using the public key of the judicial institution node and the signature verification using the private key of the judicial institution node are successful.

In one embodiment, the inherited digital asset certificate includes the business-relying party node identifier on which the digital asset certificate depends, so that the heir's personal security kernel node and the business-relying party node identified by the business-relying party node generate an updated digital asset certificate between the heir node and the business-relying party node based on the inherited digital asset certificate.

In one embodiment, the will further includes the applicable law of inheritance of the will, and the triggering of sending each digital asset certificate in the will, signed by the public key of the corresponding heir's personal security kernel node, to the heir's personal security kernel node identified by each heir in the will, includes:

Trigger the heir's personal security kernel node identified by each heir in the will, and send the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node and the inheritance applicable law of the will, so that after the heir's personal security kernel node obtains the inherited digital asset certificate, it executes the process corresponding to the inheritance applicable law.

In one embodiment, the judicial institution node further includes:

An identity-corresponding law determination unit, configured to determine the law corresponding to the identity based on the identity of the user's personal security kernel node if the user's will cannot be obtained;

a kinship acquisition unit, configured to acquire the kinship of the user;

A digital asset certificate acquisition unit, used to acquire each digital asset certificate of the user;

An heir personal security kernel node identification determination unit is used to determine the heir personal security kernel node identification corresponding to each digital asset certificate obtained from the user in accordance with the determined law and the kinship relationship;

The heir personal security kernel node public key acquisition unit is used to obtain the public key of the heir personal security kernel node of the determined heir personal security kernel node identifier;

The second digital asset certificate signature sending unit is used to sign each digital asset certificate of the user with the public key of the corresponding heir's personal security kernel node and send it to the corresponding heir's personal security kernel node, so that the heir's personal security kernel node can decrypt the signature with the private key of the heir's personal security kernel node to obtain the summary of the digital asset certificate, and obtain the inherited digital asset certificate based on the obtained summary of the digital asset certificate.

In one embodiment, the will is generated by the user's personal security kernel node through the following process:

For a digital asset certificate in a user's personal secure kernel node, receiving the user's designation of a personal secure kernel node identifier for the successor of the digital asset certificate;

Obtain the public key of the heir's personal security kernel node for the specified heir's personal security kernel node identifier;

Sign each digital asset certificate with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node, to obtain a signature of each digital asset certificate with the public key of the corresponding heir's personal security kernel node;

Place the user's personal security kernel node identifier, each heir's personal security kernel node identifier, and each digital asset certificate signed with the public key of the corresponding heir's personal security kernel node into the will;

receiving the user's designation of a node identifier of a judicial institution for executing the will;

Obtaining a public key of the judicial institution node identified by the judicial institution node;

The current content in the will is signed with the obtained public key of the judicial institution node and placed in the will.

In one embodiment, before signing the will with the obtained public key of the judicial institution node and inserting it into the will, the will generation process further includes:

Place the designated judicial authority node ID into the will.

In one embodiment, the will is configured through the following process after it is generated:

Display a security mode list, which includes a first security mode, a second security mode, and a third security mode. In the first security mode, the will is stored in the user's personal security kernel node client; in the second security mode, the will is stored in the user's personal security kernel node client and server; in the third security mode, the will is stored in the user's personal security kernel node server and published on the blockchain;

In response to the user selecting a first security mode in the security mode list, storing the will in the user's personal security kernel node client;

In response to the user selecting a second security mode in the security mode list, storing the will in the user's personal security kernel node client and server;

In response to the user selecting the third security mode in the security mode list, the will is stored in the user's personal security kernel node server and published on the blockchain.

In one embodiment, the will is updated by the user's personal secure kernel node through the following process:

When a digital asset certificate is added to the user's personal security kernel node, an interface for specifying the personal security kernel node identifier of the heir of the digital asset certificate is displayed to the user;

Receiving, on the interface, a user's designation of a personal security kernel node identifier for an heir of the digital asset certificate;

Obtain the public key of the heir's personal security kernel node for the specified heir's personal security kernel node identifier;

Sign the added digital asset certificate with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node, to obtain the signature of the added digital asset certificate with the public key of the corresponding heir's personal security kernel node;

Add the heir's personal security kernel node identifier specified for the added digital asset certificate and the signature of the added digital asset certificate using the public key of the corresponding heir's personal security kernel node to the will;

Remove the current signature in the will using the obtained judicial authority node's public key;

The current content in the will is signed with the obtained public key of the judicial institution node and placed in the will.

In one embodiment, the will is updated by the user's personal secure kernel node through the following process:

When a digital asset certificate is added to the user's personal security kernel node, the personal security kernel node identifier of the heir corresponding to the added digital asset certificate is determined based on the personal security kernel node identifier of the heir specified for the existing digital asset certificate in the will;

Obtain the public key of the heir's personal security kernel node corresponding to the added digital asset certificate;

Sign the added digital asset certificate with the public key of the heir's personal security kernel node identified by the corresponding designated heir's personal security kernel node, to obtain the signature of the added digital asset certificate with the public key of the corresponding heir's personal security kernel node;

Add the heir's personal security kernel node identifier specified for the added digital asset certificate and the signature of the added digital asset certificate using the public key of the corresponding heir's personal security kernel node to the will;

Remove the current signature in the will using the obtained judicial authority node's public key;

The current content in the will is signed with the obtained public key of the judicial institution node and placed in the will.

The information processing method in the inheritance transfer of digital asset certificates according to the embodiment of the present disclosure can be implemented by the judicial institution node 145 of Figure 10.

As shown in Figure 10, judicial institution node 145 is implemented as a general-purpose computing device. Components of judicial institution node 145 may include, but are not limited to, the at least one processing unit 810 described above, the at least one storage unit 820 described above, and a bus 830 connecting various system components (including storage unit 820 and processing unit 810).

The storage unit stores program code that can be executed by the processing unit 810, causing the processing unit 810 to perform the steps according to various exemplary embodiments of the present invention described in the description of the exemplary method above. For example, the processing unit 810 can perform the steps shown in Figure 3.

The storage unit 820 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 8201 and/or a cache memory unit 8202 , and may further include a read-only memory unit (ROM) 8203 .

The storage unit 820 may also include a program/utility 8204 having a set (at least one) of program modules 8205, such program modules 8205 including but not limited to: a social operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

Bus 830 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The judicial authority node 145 can also communicate with one or more external devices 700 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the judicial authority node 145, and/or any device that enables the judicial authority node 145 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication can occur via an input/output (I/O) interface 650. Furthermore, the judicial authority node 145 can communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and/or a public network such as the Internet) via a network adapter 860. As shown, the network adapter 860 communicates with other modules of the judicial authority node 145 via a bus 830. It should be understood that, although not shown, other hardware and/or software modules can be used in conjunction with the judicial authority node 145, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, a computer program medium is further provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor of a computer, the computer is caused to execute the method described in the above method embodiment.

According to one embodiment of the present disclosure, a program product for implementing the method in the above method embodiment is also provided. The program product may be a portable compact disc read-only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

The program product may be implemented in any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, and the like, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a stand-alone software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

It should be noted that although several modules or units of the device for action execution are mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

Furthermore, although the steps of the method of the present disclosure are described in a particular order in the accompanying drawings, this does not require or imply that the steps must be performed in this particular order, or that all steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and/or one step may be decomposed into multiple steps.

Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the appended claims.

Claims (15)

1. A method for information processing in the inheritance and transfer of digital asset certificates, characterized in that the method is executed by a judicial institution node, and the method includes: Determine the end of the user's lifecycle; Obtain the user's will, which includes the identifier of the user's personal security kernel node, the identifiers of each heir's personal security kernel node, the signatures of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the public key of the judicial institution's node. If the signature of the will made using the public key of the judicial institution node is successfully verified using the private key of the judicial institution node, it triggers the sending of the signatures of each digital asset certificate in the will made using the public key of the corresponding heir's personal security kernel node to the personal security kernel node identified by the heir's personal security kernel node in the will. This allows the heir's personal security kernel node to decrypt the signature using its private key, obtaining a digest of the digital asset certificate. Based on the obtained digest of the digital asset certificate, the inherited digital asset certificate is obtained. 2. The method according to claim 1, wherein determining the end of the user's lifecycle includes: In response to a lifecycle end notification from the survey node, determine the end of the user's lifecycle. 3. The method according to claim 1, wherein determining the end of the user's lifecycle includes: A startup request has been received from the startup node; Through the social operating system platform, a confirmation request to initiate the inheritance procedure is sent to multiple proof-party nodes. If the responses from the multiple provider nodes meet predetermined conditions, then the user's lifecycle is determined to have ended. 4. The method according to claim 3, characterized in that, determining the end of the user's lifecycle if the responses of the plurality of certifying nodes meet predetermined conditions includes: If the responses of the plurality of certifying nodes meet the predetermined conditions and a lifecycle end notification is received from the investigating node, then the user's lifecycle is determined to have ended. 5. The method according to claim 1, characterized in that the will further includes a designated judicial institution node identifier for executing the will, and the signing of the will using the public key of the judicial institution node, and the successful verification of the signature using the private key of the judicial institution node, includes: Obtain the node identifier of the judicial body designated in the will to execute the will; If the judicial authority node identifier specified in the will to execute the will is the identifier of the judicial authority node currently executing the method, the will is signed using the judicial authority node's public key, and the signature verification is successful using the judicial authority node's private key. 6. The method according to claim 5, characterized in that, if the identifier of the judicial institution node that executes the will specified in the will is the identifier of the judicial institution node currently executing the method, signing the will with the public key of the judicial institution node and verifying the successful signature with the private key of the judicial institution node includes: If the judicial authority node identifier specified in the will to execute the will is the identifier of the judicial authority node currently executing the method, the will is signed with the public key of the judicial authority node and decrypted with the private key of the judicial authority node to obtain the decrypted will digest; Generate a summary of the will; If the decrypted will digest matches the generated will digest, then the signature of the will using the judicial authority node's public key is confirmed, and the signature verification using the judicial authority node's private key is successful. 7. The method according to claim 1, wherein the inherited digital asset certificate includes a business dependency node identifier on which the digital asset certificate depends, so that the inheritor's personal security kernel node and the business dependency node identified by the business dependency node identifier can generate an updated digital asset certificate between the inheritor node and the business dependency node based on the inherited digital asset certificate. 8. The method according to claim 1, characterized in that the will further includes the applicable law for the inheritance of the will, and the step of triggering the sending of the signature of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node to the personal security kernel node identified by the personal security kernel node of each heir in the will includes: The system triggers the sending of the signatures of each heir's personal security kernel node (identified by the heir's personal security kernel node in the will) to the heir's personal security kernel node, along with the signatures of each digital asset certificate in the will using the public key of the corresponding heir's personal security kernel node, and the applicable inheritance law of the will. This allows the heir's personal security kernel node to execute the process corresponding to the applicable inheritance law after receiving the inherited digital asset certificates. 9. The method according to claim 1, characterized in that, after determining that the user's lifecycle has ended, the method further includes: If the user's will cannot be obtained, determine the legal basis corresponding to the user's personal security kernel node identity. Obtain the user's kinship; Obtain the user's digital asset credentials; For each digital asset certificate obtained from a user, the personal security kernel node identifier of the heir corresponding to each digital asset certificate is determined in accordance with the established laws and the stated kinship. Obtain the public key of the heir's personal security kernel node, which is the identifier of the heir's personal security kernel node; Each user's digital asset certificate is signed using the public key of the corresponding heir's personal security kernel node and sent to the corresponding heir's personal security kernel node. The heir's personal security kernel node then decrypts the signature using its private key to obtain a digest of the digital asset certificate. Based on the digest of the digital asset certificate, the inherited digital asset certificate is obtained. 10. The method according to claim 1, wherein the will is generated by the user's personal security kernel node through the following process: For digital asset credentials in a user's personal security kernel node, receive the user's designation of the personal security kernel node identifier of the successor of the digital asset credentials; Retrieve the public key of the heir's personal security kernel node, which is the identifier of the specified heir's personal security kernel node; Each digital asset certificate is signed using the public key of the corresponding heir's personal security kernel node, which is identified by the designated heir's personal security kernel node. This results in each digital asset certificate being signed using the public key of the corresponding heir's personal security kernel node. The will should include the identifier of the user's personal security kernel node, the identifier of each heir's personal security kernel node, and the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node. Receive the user's designation of the judicial authority node identifier for executing the will; Obtain the public key of the judicial institution node that identifies the judicial institution node; The current contents of the will are signed with the public key of the obtained judicial authority node and then placed into the will. 11. The method according to claim 10, characterized in that the will is configured through the following process after it is generated: The list of security modes is displayed, including a first security mode, a second security mode, and a third security mode. In the first security mode, the will is stored in the user's personal security kernel node client; in the second security mode, the will is stored in both the user's personal security kernel node client and the server; and in the third security mode, the will is stored in the user's personal security kernel node server and published on the blockchain. In response to the user selecting the first security mode from the security mode list, the will is stored in the user's personal security kernel node client; In response to the user selecting the second security mode from the list of security modes, the will is stored on the user's personal security kernel node client and server; In response to the user selecting the third security mode from the list of security modes, the will is stored in the user's personal security kernel node server and published on the blockchain. 12. The method according to claim 10, wherein the will is updated by the user's personal security kernel node through the following process: When a digital asset certificate is added to the user's personal security kernel node, the personal security kernel node identifier of the heir corresponding to the added digital asset certificate is determined according to the personal security kernel node identifier of the heir specified for the existing digital asset certificate in the will. Obtain the public key of the heir's personal security kernel node, which is the identifier of the heir's personal security kernel node corresponding to the added digital asset certificate; For the added digital asset certificate, sign it with the public key of the corresponding heir's personal security kernel node, which is identified by the designated heir's personal security kernel node, to obtain the added digital asset certificate signed with the public key of the corresponding heir's personal security kernel node. The personal security kernel node identifier of the heir designated for the added digital asset certificate, and the signature of the added digital asset certificate using the public key of the corresponding heir's personal security kernel node, are added to the will; Remove the signature from the will using the public key obtained from the judicial authority node; The current contents of the will are signed with the public key of the obtained judicial authority node and then placed into the will. 13. A judicial institution node, characterized in that it comprises: The lifecycle end determination unit is used to determine the end of a user's lifecycle. The will retrieval unit is used to retrieve the user's will, which includes the identifier of the user's personal security kernel node, the identifier of each heir's personal security kernel node, the signature of each digital asset certificate using the public key of the corresponding heir's personal security kernel node, and the signature of the will using the public key of the judicial institution's node. The first digital asset certificate signing and sending unit is configured to, if the signature of the will made using the public key of the judicial institution node is successfully verified using the private key of the judicial institution node, trigger the sending of the signatures of each digital asset certificate in the will made using the public key of the corresponding heir's personal security kernel node to the personal security kernel node identified by the personal security kernel node of each heir in the will. This allows the personal security kernel node of the heir to decrypt the signature using its private key to obtain a digest of the digital asset certificate. Based on the digest of the digital asset certificate, the inherited digital asset certificate is obtained. 14. A judicial institution node, characterized in that it comprises: Memory, which stores computer-readable instructions; The processor reads computer-readable instructions stored in memory to perform the method described in any one of claims 1-12. 15. A computer program medium having stored computer-readable instructions thereon, which, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 1-12.