Transaction document determination method, system, electronic device, and non-transitory storage medium

Abstract

The application discloses a transaction document determination method, system, electronic equipment and nonvolatile storage medium. The method comprises the following steps: determining a to-be-encrypted field and a public template in an original transaction document, generating a to-be-encrypted document according to the to-be-encrypted field, and generating a public document according to the public template; encrypting the to-be-encrypted document according to a target public key to obtain an encrypted document; encrypting a target digest corresponding to the original transaction document, the to-be-encrypted document, the public document and the encrypted document according to a target private key corresponding to a digital identity to obtain a digital signature document; and generating a target transaction document according to the public document, the encrypted document and the digital signature document. The application solves the technical problems of the related art, such as easy modification of the text of the electronic transaction document, non-counterfeit, the need to print a paper document for signature and seal to confirm the identity of the trader and the transaction content, poor confidentiality of the electronic transaction document, and no control of the traditional confidential document by the personal customer party.

Description

Technical Field

[0001] This application relates to the field of information security technology, and more specifically, to a method, system, electronic device, and non-volatile storage medium for determining transaction documents. Background Technology

[0002] Traditional electronic transaction documents, such as contracts and agreements, contain the transactor's identity information as part of the text, while the transaction content is in plain text. These documents are easily modified and lack anti-counterfeiting features, requiring the printing of paper documents for signature and stamping to confirm the transactor's identity (to prevent denial) and the transaction content (to prevent tampering). This results in poor confidentiality of electronic transaction documents and a lack of control over information security for individual clients among the transaction participants.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method, system, electronic device, and non-volatile storage medium for determining transaction documents, in order to at least solve the technical problems of electronic transaction documents in related technologies being easily modified and lacking anti-counterfeiting features, requiring the separate printing of paper documents for signing and stamping to confirm the identity of the transactor and the content of the transaction, resulting in poor confidentiality of electronic transaction documents and the lack of control by individual clients over traditional confidential documents.

[0005] According to one aspect of the embodiments of this application, a method for determining a transaction document is provided, comprising: determining a field to be encrypted and a public template in an original transaction document, generating a document to be encrypted based on the field to be encrypted, and generating a public document based on the public template, wherein the original transaction document is a contract document to be signed by the transaction parties for the target transaction; determining a target public key corresponding to the digital identity of the transaction parties, and encrypting the document to be encrypted based on the target public key to obtain an encrypted document; encrypting the original transaction document, the document to be encrypted, the public document, and the target digest corresponding to the encrypted document based on the target private key corresponding to the digital identity to obtain a digital signature document, wherein each target digest corresponds to a uniquely determined document; and generating a target transaction document based on the public document, the encrypted document, and the digital signature document.

[0006] Optionally, generating a document to be encrypted based on the field to be encrypted and generating a public document based on a public template include: determining the field to be encrypted and the field identifier corresponding to the field to be encrypted, wherein each field identifier corresponds to a uniquely determined field to be encrypted; replacing the field to be encrypted in the original transaction document with the corresponding field identifier to obtain a public document; and generating a document to be encrypted based on the field to be encrypted and the field identifier corresponding to the field to be encrypted.

[0007] Optionally, encrypting the document to be encrypted based on the target public key to obtain the encrypted document includes: encrypting the fields to be encrypted in the document to be encrypted based on the target public key to obtain the encrypted fields; generating the encrypted document based on the encrypted fields, the field identifier corresponding to the encrypted fields, and the digital identity of the transaction object, wherein the digital identity includes, but is not limited to, a decentralized digital identity (DID).

[0008] Optionally, the target digest includes: a first digest, a second digest, a third digest, and a fourth digest; based on the target private key corresponding to the digital identity, the target digests corresponding to the original transaction document, the document to be encrypted, the public document, and the encrypted document are encrypted to obtain a digital signature document, including: determining the first digest based on the original transaction document, determining the second digest based on the document to be encrypted, determining the third digest based on the public document, and determining the fourth digest based on the encrypted document; based on the target private key, the first digest, the second digest, the third digest, and the fourth digest are encrypted to obtain a target signature, and a digital signature document is generated based on the target signature, wherein one target private key corresponds to one encryption operation, and each encryption operation generates one target signature.

[0009] Optionally, after generating the target transaction document, when planning to verify the target transaction document, the method further includes: splitting the target transaction document into a public document, an encrypted document, and a digital signature document; decrypting each target signature in the digital signature document according to the target public key corresponding to each transaction object participating in the target transaction to obtain a target digest; comparing whether the target digests corresponding to each transaction object are completely consistent, and determining that the target transaction document is invalid if there are inconsistencies among the target digests.

[0010] Optionally, if all target digests are completely identical, the method further includes: obtaining the third and fourth digests from the decrypted target digests; determining the third and fourth actual digests respectively based on the public and encrypted documents obtained after splitting the target transaction document; comparing whether the third actual digest and the third digest are completely identical, and comparing whether the fourth actual digest and the fourth digest are completely identical; if the third actual digest and the third digest are inconsistent, or if the fourth actual digest and the fourth digest are inconsistent, determining that the target transaction document has been tampered with.

[0011] Optionally, if the third actual digest and the third digest are completely identical, and the fourth actual digest and the fourth digest are completely identical, the method further includes: decrypting the encrypted document based on the target private key corresponding to the digital identity of the transaction object to obtain the document to be encrypted, and determining the second actual digest based on the document to be encrypted; if the second actual digest and the second digest in the target digest obtained after decryption are inconsistent, determining that the target transaction document has been tampered with; if the second actual digest and the second digest are completely identical, restoring the original transaction document based on the document to be encrypted and the public document, and determining the first actual digest based on the original transaction document; if the first actual digest and the first digest in the target digest obtained after decryption are inconsistent, determining that the target transaction document has been tampered with.

[0012] According to another aspect of the embodiments of this application, a transaction document determination system is also provided, comprising: a document segmentation module, configured to determine the fields to be encrypted and the public template in the original transaction document, and generate a document to be encrypted based on the fields to be encrypted, and generate a public document based on the public template, wherein the original transaction document is a contract document to be signed by the transaction parties for the target transaction; a first encryption module, configured to determine the target public key corresponding to the digital identity of the transaction parties, and encrypt the document to be encrypted based on the target public key to obtain an encrypted document; a private key signing module, configured to encrypt the original transaction document, the document to be encrypted, the public document, and the target digest corresponding to the encrypted document based on the target private key corresponding to the digital identity to obtain a digital signature document, wherein each target digest corresponds to a uniquely determined document; and a document generation module, configured to generate a target transaction document based on the public document, the encrypted document, and the digital signature document.

[0013] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes a transaction document determination method during runtime.

[0014] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes a transaction document determination method by running the computer program.

[0015] In this embodiment, the method involves determining the fields to be encrypted and the public template in the original transaction document, generating a document to be encrypted based on the fields to be encrypted, and generating a public document based on the public template. The original transaction document is the contract document required for the transaction parties to conduct the target transaction. The method involves determining the target public key corresponding to the digital identity of the transaction parties, encrypting the document to be encrypted based on the target public key, and obtaining an encrypted document. Then, based on the target private key corresponding to the digital identity, the original transaction document, the document to be encrypted, the public document, and the target digests corresponding to the encrypted documents are encrypted to obtain a digital signature document. Each target digest corresponds to a uniquely identified document. The method of generating the target transaction document based on the public document, the encrypted document, and the digital signature document combines digital identity, digital signature, and information encryption technologies to construct a digital metafile. This achieves the goal of both disclosing some information through templates and supporting the hiding and confidentiality of key information, thus ensuring information security. This solves the problems in related technologies where electronic transaction documents are easily modified, lack anti-counterfeiting features, require separate printing of paper documents for signing and stamping to confirm the transactor's identity and transaction content, and suffer from poor confidentiality of electronic transaction documents and the lack of control over individual clients in traditional confidential documents. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 This is a hardware structure block diagram of a computer terminal (or electronic device) for implementing a method for determining transaction documents, according to an embodiment of this application.

[0018] Figure 2 This is a schematic diagram of a method for determining transaction documents according to an embodiment of this application;

[0019] Figure 3 This is a schematic diagram illustrating the process of creating a digital metafile according to an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of a method for creating a digital contract according to an embodiment of this application;

[0021] Figure 5 This is a schematic diagram of a method flow for third-party verification of digital contracts provided according to an embodiment of this application;

[0022] Figure 6 This is a schematic diagram of a method flow for one party to a transaction to verify a digital contract according to an embodiment of this application;

[0023] Figure 7 This is a schematic diagram of the structure of a transaction document determination system provided according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] In human social activities, legally recognized documents are generated in many scenarios, such as personal declarations and wills in daily life, and transactions in the economic system (represented by transaction receipts, contracts, agreements, etc.). These documents record not only the content of the event itself, but also the time of occurrence, the name / signature of the signatory, and other identifying information; in some scenarios, the content often contains sensitive information or trade secrets that need to be kept confidential from third parties.

[0027] Traditional electronic transaction documents, such as contracts, agreements, receipts, personal statements, and wills, contain the transactor's identity information as part of the text, while the transaction content is in plain text. These documents are easily modified, lack anti-counterfeiting features, and have no legal effect. They require the separate printing of paper documents for signing and stamping to confirm the transactor's identity (to prevent denial) and the transaction content (to prevent tampering). Traditional electronic documents themselves fail to solve the problems of transactor identity verification, content tampering prevention, and information confidentiality.

[0028] In related technologies, although CA-signed electronic documents can implement legally recognized electronic signatures, the public and private keys are issued by the institution to the user, and the user does not have complete control over the private key. In addition, CA certificates are not digital identities, and the certificates have an expiration date and are constantly changing, which cannot effectively solve the requirement of stability of the signer's digital identity.

[0029] To address the aforementioned issues, this application provides relevant solutions, which are detailed below.

[0030] According to an embodiment of this application, a method for determining transaction documents is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal (or electronic device) for implementing a transaction document determination method is shown. Figure 1 As shown, the computer terminal 10 (or electronic device 10) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0032] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or electronic device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0033] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the transaction document determination method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned transaction document determination method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0034] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0035] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or electronic device).

[0036] Under the above operating environment, this application provides a method for determining transaction documents. Figure 2 This is a schematic diagram of a method for determining transaction documents according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0037] Step S202: Determine the fields to be encrypted and the public template in the original transaction document, generate the document to be encrypted based on the fields to be encrypted, and generate the public document based on the public template. The original transaction document is the contract document that the transaction parties need to sign to conduct the target transaction.

[0038] The transaction can involve one or more parties. In this embodiment, we will use a target transaction between Party A and Party B as an example for explanation. Figure 3 This is a schematic diagram illustrating the process of creating a digital metafile according to an embodiment of this application, such as... Figure 3 As shown.

[0039] In some embodiments of this application, generating a document to be encrypted based on a field to be encrypted and generating a public document based on a public template include the following steps: determining a field to be encrypted and a field identifier corresponding to the field to be encrypted, wherein each field identifier corresponds to a uniquely determined field to be encrypted; replacing the field to be encrypted in the original transaction document with the corresponding field identifier to obtain a public document; and generating a document to be encrypted based on the field to be encrypted and the field identifier corresponding to the field to be encrypted.

[0040] Specifically, such as Figure 3 As shown, firstly, the digital identities and related verifiable declarations (VC / VP) lists of both parties to the transaction are verified and added, and a summary is generated for the original transaction document f0. The information fields in the original transaction document f0 that need to be kept confidential (i.e., the fields to be encrypted mentioned above) are identified, while a unique identifier (i.e., the field identifier mentioned above) is retained in the original position of the document. The document f0 is split into the public part ft (i.e., the public document mentioned above) and the confidential part fd (i.e., the document to be encrypted mentioned above), where the data to be encrypted is structured data in the form of "identifier (i.e., the field identifier mentioned above): key information (i.e., the fields to be encrypted mentioned above)," as well as the digital identity list and the VC / VP list.

[0041] The unique identifier (i.e., the field identifier) ​​that is retained in the original position of the document is composed of a string that was not originally present in the text of the original transaction document.

[0042] Step S204: Determine the target public key corresponding to the digital identity of the transaction object, and encrypt the document to be encrypted based on the target public key to obtain the encrypted document;

[0043] In some embodiments of this application, encrypting a document to be encrypted based on a target public key to obtain an encrypted document includes the following steps: encrypting the fields to be encrypted in the document to be encrypted based on the target public key to obtain encrypted fields; generating the encrypted document based on the encrypted fields, the field identifier corresponding to the encrypted fields, and the digital identity of the transaction object, wherein the digital identity includes, but is not limited to, a decentralized digital identity (DID).

[0044] The aforementioned decentralized identity (DID), compared to traditional PKI (Public Key Infrastructure) based identity systems, offers advantages such as ensuring data authenticity and trustworthiness, protecting user privacy and security, and strong portability. Its strengths lie in: Decentralization: Based on blockchain, it avoids identity data being controlled by a single centralized authority; Self-controllable identity: Based on DPKI, each user's identity is not controlled by a trusted third party, but by its owner, allowing individuals to manage their own identities; Trusted data exchange: Identity-related data is anchored on the blockchain, and the authentication process does not rely on the application providing the identity.

[0045] Specifically, the field to be encrypted in the intermediate structured data file fd is replaced with the target public key of the transacting party, and the encrypted data file fs (i.e. the above-mentioned encrypted document) is reconstructed. The data in the encrypted document is structured data in the form of "field identifier: encrypted field", as well as a list of digital identities and a list of VC / VP.

[0046] Step S206: Based on the target private key corresponding to the digital identity, encrypt the target digests corresponding to the original transaction document, the document to be encrypted, the public document, and the encrypted document to obtain a digital signature document, wherein each target digest corresponds to a uniquely identified document;

[0047] In some embodiments of this application, the target digest includes: a first digest, a second digest, a third digest, and a fourth digest; based on the target private key corresponding to the digital identity, the target digests corresponding to the original transaction document, the document to be encrypted, the public document, and the encrypted document are encrypted to obtain a digital signature document, including: determining the first digest based on the original transaction document, determining the second digest based on the document to be encrypted, determining the third digest based on the public document, and determining the fourth digest based on the encrypted document; based on the target private key, the first digest, the second digest, the third digest, and the fourth digest are encrypted to obtain a target signature, and a digital signature document is generated based on the target signature, wherein one target private key corresponds to one encryption operation, and each encryption operation generates one target signature.

[0048] It should be noted that the target private key is under the control of its owner (the transacting party). Therefore, in practical applications, it is usually necessary to send the digest to be signed to each transacting party for signing. Specifically, each transacting party has a digital object instance (digital identity management system / APP) in the digital world; the signing process is a collaborative process between the meta-file construction system / device and the participants' digital identity management system / APP / device / medium.

[0049] Specifically, the original transaction document f0 is digested to obtain the first digest; the document to be encrypted fd is digested to obtain the second digest; the public document ft is digested to obtain the third digest; and the encrypted document fs is digested to obtain the fourth digest.

[0050] The transacting parties electronically sign and confirm each target digest (including the original transaction document f0, the template file ft (i.e. the aforementioned public document), the intermediate data file fd (i.e. the aforementioned document to be encrypted), and the encrypted document fs), that is, they encrypt the digests using the target private key, and then combine the encrypted target signature list with the transacting parties' digital identity list to form a structured data file si (i.e. the aforementioned digital signature document).

[0051] Step S208: Generate the target transaction document based on the public document, the encrypted document, and the digital signature document.

[0052] Specifically, the template ft (i.e. the aforementioned public document), encrypted data fs (i.e. the aforementioned encrypted document), and signature si (i.e. the aforementioned digital signature document) are merged to obtain the digital metafile mf (i.e. the aforementioned target transaction document).

[0053] The template ft (i.e., the aforementioned public document) is plaintext containing no sensitive information, is publicly available, contains a file format, and retains field identifiers (including specific locations). The data fd (i.e., the aforementioned document to be encrypted) is a structured data file in the form of "field identifier: field to be encrypted." Based on ft and fd, the original transaction document f0 can be synthesized from it. The data file fd (i.e., the aforementioned document to be encrypted) is an intermediate state, existing only in memory and not ultimately saved to disk or the network. The data fs (i.e., the aforementioned encrypted document), compared to fd (i.e., the aforementioned document to be encrypted), has its key information (i.e., the fields to be encrypted) encrypted with the public key of the transacting parties, and only the transacting parties can decrypt it; the information is secure. The template ft, encrypted information fs, and electronic signature si (i.e., the aforementioned digital signature document) are ultimately saved to disk and the network as files.

[0054] The method for determining transaction documents in steps S202 to S208 of the embodiments of this application will be further described below.

[0055] Figure 4This is a schematic diagram of a method for creating a digital contract according to an embodiment of this application, such as... Figure 4 As shown, it includes the following steps:

[0056] Step 1: Verify and add the digital identities and relevant verifiable declarations (VC / VP) of both parties to the transaction, and summarize the original transaction document f0;

[0057] Step 2: Identify the information fields that need to be kept confidential in the original transaction document f0 (i.e., the fields to be encrypted mentioned above), and at the same time retain a unique identifier (i.e., the field identifier mentioned above) in the original position of the document.

[0058] Step 3: Split the document f0 = public part ft (i.e., the public document mentioned above) + confidential part fd (i.e., the document to be encrypted mentioned above). The data to be encrypted is structured data in the form of "identifier (i.e., the field identifier mentioned above): key information (i.e., the field to be encrypted mentioned above)," as well as a list of digital identities and a list of VC / VP; or the ft + fd were directly split and passed in from the previous step.

[0059] Step 4: Generate digests for the split encrypted document fd and the public document ft.

[0060] Step 5: For the field to be encrypted in the intermediate structured data file fd, use the target public key of the transacting party to encrypt and replace it, and reassemble to obtain the encrypted data file fs (i.e. the above encrypted document). The data in the encrypted document is structured data in the form of "field identifier: encrypted field", as well as the digital identity list and VC / VP list in step 1.

[0061] Step 6: Digest the encrypted document fs;

[0062] Step 7: The transacting parties confirm the electronic signatures of each target digest (including the original transaction document f0, the template file ft (i.e. the above-mentioned public document), the intermediate state data file fd (i.e. the above-mentioned document to be encrypted), and the encrypted document fs). That is, the digests are encrypted using the target private key, and the encrypted target signature list is combined with the transacting parties' digital identity list to form a structured data file si (i.e. the above-mentioned digital signature document).

[0063] Step 8: Merge the template ft (i.e. the aforementioned public document), the encrypted data fs (i.e. the aforementioned encrypted document), and the signature si (i.e. the aforementioned digital signature document) to obtain the digital metafile mf (i.e. the aforementioned target transaction document).

[0064] After the digital metafile mf (i.e., the target transaction document mentioned above) is generated, the target transaction document can be verified by a third party or the parties involved in the target transaction.

[0065] This application's solution, based on digital identity-constructed digital metafiles, simultaneously addresses issues of verifiable identity (non-repudiation), verifiable content (tamper-proof), and critical information security. Introducing digital identity ensures the stability of participant identities within the digital metafile and grants participants the option to choose which digital identity to use in different scenarios. Leveraging the characteristics of digital identity, while ensuring information security, the digital metafile is also applicable to both anonymous and real-name registration scenarios, as well as certain complex scenarios (e.g., buyers of cigarettes must be at least 18 years old), enabling business oversight and providing a tool for enforcing certain laws.

[0066] In some embodiments of this application, after generating the target transaction document, when it is planned to verify the target transaction document, the method further includes: splitting the target transaction document into a public document, an encrypted document, and a digital signature document; decrypting each target signature in the digital signature document according to the target public key corresponding to each transaction object participating in the target transaction to obtain a target digest; comparing whether the target digests corresponding to each transaction object are completely consistent, and determining that the target transaction document is invalid if there is an inconsistency between the target digests.

[0067] In some embodiments of this application, when the target digests are completely identical, the method further includes: obtaining the third digest and the fourth digest from the decrypted target digests; determining the third actual digest and the fourth actual digest respectively based on the public document and the encrypted document obtained after splitting the target transaction document; comparing whether the third actual digest and the third digest are completely identical, and comparing whether the fourth actual digest and the fourth digest are completely identical; and determining that the target transaction document has been tampered with if the third actual digest and the third digest are inconsistent, or if the fourth actual digest and the fourth digest are inconsistent.

[0068] In some embodiments of this application, when the third actual digest and the third digest are completely identical, and the fourth actual digest and the fourth digest are completely identical, the method further includes: decrypting the encrypted document based on the target private key corresponding to the digital identity of the transaction object to obtain the document to be encrypted, and determining the second actual digest based on the document to be encrypted; if the second actual digest and the second digest in the target digest obtained after decryption are inconsistent, determining that the target transaction document has been tampered with; if the second actual digest and the second digest are completely identical, restoring the original transaction document based on the document to be encrypted and the public document, and determining the first actual digest based on the original transaction document; if the first actual digest and the first digest in the target digest obtained after decryption are inconsistent, determining that the target transaction document has been tampered with.

[0069] The following sections will further introduce the verification methods for two scenarios: verification of the target transaction document by a third party and verification of the target transaction document by the parties involved in the target transaction.

[0070] Figure 5 This is a schematic diagram of a method flow for third-party verification of digital contracts provided in an embodiment of this application, as shown below. Figure 5 As shown, the method includes the following steps:

[0071] Step 1: Based on the digital metafile mf (i.e. the target transaction document mentioned above), decompose it into template ft (i.e. the public document mentioned above), encrypted data fs (i.e. the encrypted document mentioned above), and signature si (i.e. the digital signature document mentioned above).

[0072] Step 2: Perform a data digest on the ft and fs parts to obtain the actual file values ​​d2(ft) (i.e., the third actual digest mentioned above) and d2(fs) (i.e., the fourth actual digest mentioned above);

[0073] Step 3: Parse the public key list of signers from the signature si part, and parse the corresponding signatures accordingly to obtain the target digest (should value) of various documents within the signature;

[0074] Step 4: Compare the target digest values ​​of the four files f0, fd, ft, and fs of Party A and Party B. If they are inconsistent, it can be concluded that the signature of this contract (target transaction document) is invalid, the contract is invalid, and the verification ends.

[0075] Step 5: Verify the expected values ​​(third digest and fourth digest) and actual values ​​(third actual digest and fourth actual digest) of files ft and fs. If they are inconsistent, it indicates that the data in ft or fs in the current target transaction document mf has been tampered with; if they are consistent, it proves that the content of this document mf is true, valid and has not been tampered with, and the signer of the contract is the holder of the private key corresponding to the public key.

[0076] In this embodiment, the authenticity of the target transaction document mf and the signatory are verifiable. The electronic signature portion of the document can be decrypted to obtain the document digest (the expected value) at the time of contract signing, and the signatory is also verified using the public key; the document content (public / template + confidential / data) can be used to calculate the document digest (actual value) in real time, and compared with the expected value to complete the document integrity verification.

[0077] In two verification scenarios where the parties involved in the target transaction verify the target transaction document, either party can use their private key to restore the plaintext of the contract. Based on the digest value of the original text in the signature, it can be verified whether the document has been tampered with during storage.

[0078] Figure 6This is a schematic diagram of a method flow for one party to a transaction to verify a digital contract according to an embodiment of this application, as shown below. Figure 6 As shown, it includes the following steps:

[0079] Step 1: Based on the digital metafile mf (i.e. the target transaction document mentioned above), decompose it into template ft (i.e. the public document mentioned above), encrypted data fs (i.e. the encrypted document mentioned above), and signature si (i.e. the digital signature document mentioned above).

[0080] Step 2: Perform a data digest on the ft and fs parts to obtain the actual file values ​​d2(ft) (i.e., the third actual digest mentioned above) and d2(fs) (i.e., the fourth actual digest mentioned above);

[0081] Step 3: Parse the public key list of signers from the signature si part, and parse the corresponding signatures accordingly to obtain the target digest (should value) of various documents within the signature;

[0082] Step 4: Compare the target digest values ​​of the four files f0, fd, ft, and fs of Party A and Party B. If they are inconsistent, it can be concluded that the signature of this contract (target transaction document) is invalid, the contract is invalid, and the verification ends.

[0083] Step 5: Verify the expected values ​​(third digest and fourth digest) and actual values ​​(third actual digest and fourth actual digest) of files ft and fs. If they are inconsistent, it indicates that the data in ft or fs in the current target transaction document mf has been tampered with; if they are consistent, it proves that the content of this document mf is true, valid and has not been tampered with, and the signer of the contract is the holder of the private key corresponding to the public key.

[0084] Step 6: The transacting party uses the target private key to decrypt the encrypted document fs, obtain the document to be encrypted fd, and performs a data digest on fd to obtain the actual file value d2(fd) (i.e. the second actual digest mentioned above);

[0085] Step 7: Verify the expected value (second digest) and actual value (second actual digest) of file fd. If they are inconsistent, it indicates that the data in the encrypted information of the current target transaction document mf has been tampered with, and the verification ends. If they are consistent, it proves that the encrypted information in this document mf is true, valid and has not been tampered with.

[0086] Step 8: Based on the document to be encrypted fd and the public document ft, restore the original transaction document f0, and perform a data digest on f0 to obtain the actual file value d2(f0) (i.e. the first actual digest mentioned above);

[0087] Step 9: Verify the expected value (first digest) and actual value (first actual digest) of file f0. If they are inconsistent, it indicates that the key information in the current target transaction document mf has been tampered with, and the verification ends. If they are consistent, it proves that the key information in this document mf is true, valid and has not been tampered with.

[0088] This application's solution organically combines digital identity, digital signature, and information encryption technologies. It introduces digital identity, thereby hiding the plaintext information of the participants' identities within the digital metadata, while ensuring the authenticity of the identity is verifiable. Furthermore, the private key is created by the user, giving them complete control; in contrast, traditional CA certificates, besides the public key, also publicly display the certificate holder's name and other identity information, failing to achieve complete hiding of sensitive information. Additionally, in traditional PKI systems, the CA generates public-private key pairs and then distributes them to users; both the user and the CA center possess the private key, leaving the holder without complete control. Thirdly, digital identity, compared to CA certificates, has a stable binding relationship with the individual, while CA certificates have an expiration date. Compared to CA certificate signing in related technologies, this solution aims to achieve simpler operation, more stable digital identity, and effectively meet the needs of various application scenarios, including anonymity, real-name authentication, and differentiated conditions (such as requiring cigarette buyers to be over 18 years old). The existing electronic signature mode for documents has been optimized to ensure that the identity information of signers is kept confidential and that they are verified with their real names. At the same time, it supports the confidentiality of key transaction information. The information can be jointly owned by the contracting parties (the information can only be unlocked with the consent of both parties) or individually owned by each party (the information can be unlocked with the consent of only one party).

[0089] Compared to other electronic document patents with electronic signatures, this application can both disclose some information through templates and support the concealment and confidentiality of key information, ensuring information security. Furthermore, unlike traditional anonymized documents, which are unrecoverable, the information in the encrypted data of this invention is recoverable with the consent of the participants. The key information in this application is encrypted, and regardless of where the data is stored or transmitted, the data encryptor retains permanent ownership of the data, which can only be decrypted with their private key. Based on digital identity, digital proof of the preconditions for participants creating documents (real-name authentication and related qualification authentication, etc.) can be introduced into the digital meta-file; for example, the signing of certain agreements requires verification of the participants' age.

[0090] This application's solution achieves identity and qualification verification for transacting parties using digital identity: In the digital world, the public-private key mechanism of digital identity can not only solve the problem of signer identity in anonymous scenarios; it can also use third-party issued VC / VP (verifiable assertions / vouchers) to achieve real-name verification or other related qualification verification; in the event of legal disputes, the real identity of the transacting party can be extracted from the third-party issuer through legal means in the real world. Digital signatures for transactions based on digital identity: Using the private key of digital identity, the transaction text is digested and electronically signed, and the integrity of the text content can be verified at any time, solving the problem of tamper-proofing of transaction content and meeting the requirements of the Electronic Signature Law. Confidentiality of key transaction information based on digital identity: The content of the digital meta-file can be divided into two parts according to the transacting parties' wishes: a public template and a non-public structured confidential information block. The confidential information is encrypted using the transacting party's public key, and the information is directly controlled by the transacting party. Any third party unrelated to the transaction (any data storage party, transmitter, etc.) cannot decrypt the encrypted information, achieving information security.

[0091] This application solution applies to all types of legally binding digital documents that require the signature of individuals, organizations, etc., including but not limited to the following scenarios:

[0092] 1. Applications for signing digital documents with a single signature, such as personal statements and wills.

[0093] 2. Signing digital contracts, digital agreements, digital business receipts, and other digital economy applications.

[0094] 3. It can be applied to the creation of business receipts (in terms of confidentiality, sensitive information such as customer information, phone number, and installation address can be hidden; in addition, the customer's private key signature can replace the current electronic signature mode which has no legal effect); secondly, it can be applied to the signing of government and enterprise contracts.

[0095] 4. Re-application of digital metafiles created based on this invention:

[0096] 1) Reapplication of digital contracts: When bidding, companies can provide digital contracts as proof of performance, which can reduce the leakage of the client's privacy and trade secrets in traditional paper contract scans or photocopies (in traditional bidding, the contractor provides too much information to the bidding party and process participants because of the plain text contract).

[0097] 2) Reapplication of digital contracts: When such digital contracts are applied to bidding, the trading parties or a trusted third party may issue a verifiable statement about the contract. This statement can be used to calculate and verify the relevant evaluation items (contract signing date, contract amount range standard). On the one hand, it can realize the automatic calculation of objective scores and eliminate human error. On the other hand, it can effectively reduce the workload of manual evaluation by review experts.

[0098] To better understand this application, the following example illustrates the signing and use of a digital contract (rental agreement).

[0099] Example: A rental agreement (f0, text file) contains sensitive information such as the names and ID numbers of both parties, the detailed address of the property, and the rent, as shown below.

[0100] "Lessor (Party A), Zhang XX, male, ID number _3XXXXXXXXXXYYYY_"

[0101] Lessee (Party B) Li XX, male, ID number _3XXXXXXAABBCCCC_

[0102] Based on the principles of equality, voluntariness, and mutual agreement, Party A and Party B have reached the following agreement regarding the lease of the following premises:

[0103] Party A will lease its property located at Room XX, No. XX, XXX Community, XX Street, XX City to Party B for use.

[0104] The lease term is 12 months. Party A will deliver the leased premises to Party B for use from [Date] to [Date].

[0105] The monthly rent for this property is RMB XXXX, payable quarterly. Party B shall pay the full quarterly rent to Party A within 5 days of the beginning of each quarter.

[0106] Examples of digital contracts using the scheme of this application include a public content portion ft, an encrypted data portion fs, and a digital signature portion si, as shown below.

[0107] The first part is the publicly available portion of the contract (public document ft) (the document format is consistent with f0), where fields to be kept confidential are replaced by field identifiers. An example of ft is as follows:

[0108] "ft: Lessor (Party A) _$lessor$, male, ID number $cidA$"

[0109] Lessee (Party B), male, ID number: _$lessee$_

[0110] Based on the principles of equality, voluntariness, and mutual agreement, Party A and Party B have reached the following agreement regarding the lease of the following premises:

[0111] Party A will lease its property located at $addr$ to Party B for use.

[0112] The lease term is 12 months. Party A will deliver the leased premises to Party B for use from [Date] to [Date].

[0113] The monthly rent for this property is RMB $rentM$, payable quarterly. Party B shall pay the full quarterly rent to Party A within 5 days of the beginning of each quarter.

[0114] The extracted file descriptor (fd) of the document to be encrypted (intermediate state, not ultimately saved, structured data, JSON text file format) is as follows:

[0115] "fd":{

[0116] "$lessor$":"Zhang XX",

[0117] "$lessee$":"Li XX",

[0118] "$cidA$":"3XXXXXXXXXXYYYY",

[0119] "$cidB$":"3XXXXXXAABBCCCC",

[0120] "$addr$":"Room XX, No. XX, XXX Community, XX Street, XX City",

[0121] "$rentM$":"XXXX yuan"}"

[0122] The encrypted data block (encrypted document) fs (structured data, in JSON text format) is as follows:

[0123] The signature data block (i.e., the digital signature document si) (structured data, in JSON text format) is as follows:

[0124]

[0125]

[0126] The final target transaction document, mf.json, is shown below:

[0127] {"ft":"ft.XXX",

[0128] "fs":"fs.json",

[0129] "si":"si.json"}

[0130] The digital metafile (target transaction document) consists of a public content component (ft), an encrypted data component (fs), and a signature component (si); the JSON format is as follows: {"ft":{},"fs":{},"si":{}}, and the expression of the three components is not limited to JSON format;

[0131] The JSON format is as follows: ("ft":{public content or attachment}). This expression is not limited to JSON format. The description of public content can be included directly or as an attachment. The JSON format is as follows: {"content":“content text itself”} or {"file":“attachment file name”}. The file format of the attachment storage includes, but is not limited to, txt, word, PDF, HTML, markdown, and binary files. Among them, to adapt to some applications where the content is completely public, the encrypted data component fs is optional and can be empty.

[0132] In this embodiment, fs can be encrypted by a single person (in scenarios such as personal declarations and wills) or by multiple people (in scenarios such as contracts and agreements involving multiple parties). When multiple people encrypt, they can encrypt separately (each person has a copy of the encryption result, and any party can decrypt it individually) or they can encrypt collaboratively (the encryption result is one copy, and all encryptors need to be present when decrypting).

[0133] As an optional implementation, based on the characteristics of public information security of digital metadata, participating entities can choose whether to upload digital metadata to the platform for unified storage and provide subsequent public access, according to their own wishes.

[0134] The digital metadata generated by this application is secure, verifiable, and can be stored on public networks and transmitted over networks without fear of information leakage. It balances data openness and information security, fully meeting the requirements of the digital economy. Any electronic copy of the data metadata, as long as the signature is legally verified, is the original. Compared to the scarcity of verifiable original documents in the real world, this demonstrates the efficiency of the digital twin world. The security of encrypted digital metadata relies on the security and reliability of the public-private key system and the security of the private key held by the information encryptor; rather than on the security control measures and processes of a company's IT system. This effectively reduces the investment pressure related to the construction of business application systems.

[0135] Compared to files signed with traditional CA certificates, which cannot be effectively categorized as belonging to individuals with the same identity (e.g., CA certificates issued by different banks require identification cards for association, and ID cards are sensitive information), digital identities can be used across different government and enterprise organizations without relying on sensitive information like ID cards. Furthermore, customers retain the right to choose how their digital identities are used, which can help counter joint data mining of privacy data between enterprises.

[0136] Through the above steps, by combining technologies such as digital identity, digital signature, and information encryption, a digital metafile is constructed. This achieves the goal of both disclosing some information through templates and supporting the concealment and confidentiality of key information, thus ensuring information security. This solves the problems in related technologies, such as the ease of modification and lack of anti-counterfeiting features of electronic transaction documents, the need to print paper documents for signature and seal to confirm the identity of the transactor and the transaction content, the poor confidentiality of electronic transaction documents, and the lack of control over individual clients by traditional confidential documents.

[0137] According to an embodiment of this application, an embodiment of a transaction document determination system is also provided. Figure 7 This is a schematic diagram of the structure of a transaction document determination system provided according to an embodiment of this application. For example... Figure 7 As shown, the system includes:

[0138] The document segmentation module 70 is used to determine the fields to be encrypted and the public template in the original transaction document, and to generate the document to be encrypted based on the fields to be encrypted, and to generate the public document based on the public template. The original transaction document is the contract document that the transaction parties need to sign to carry out the target transaction.

[0139] The first encryption module 72 is used to determine the target public key corresponding to the digital identity of the transaction object, and encrypt the document to be encrypted according to the target public key to obtain the encrypted document;

[0140] The private key signing module 74 is used to encrypt the target digests corresponding to the original transaction document, the document to be encrypted, the public document, and the encrypted document based on the target private key corresponding to the digital identity, so as to obtain a digital signature document. Each target digest corresponds to a unique document.

[0141] It should be noted that the target private key is under the control of its owner (the transacting party). Therefore, in practical applications, it is usually necessary to send the target digest to be signed to each transacting party for signing. Specifically, each transacting party has a digital object instance (digital identity management system / APP) in the digital world; the signing process is a collaborative process between the meta-file construction system / device and the participants' digital identity management system / APP / device / medium.

[0142] The document generation module 76 is used to generate target transaction documents based on public documents, encrypted documents, and digitally signed documents.

[0143] The digital metadata created by this application scheme balances data openness and information security, can be transmitted and stored on public networks, can eliminate information silos, and can fully meet the requirements of the digital economy. In the digital metadata, the security of encrypted information depends on the security and reliability of the public-private key system and the security of the information encryptor's own safekeeping of the private key, rather than on the security internal control measures and processes of a certain enterprise's IT system, which can effectively reduce the investment pressure related to the construction of business application systems.

[0144] It should be noted that the modules in the aforementioned transaction document determination device can be program modules (e.g., a set of program instructions that implement a specific function) or hardware modules. For the latter, they can take the following forms, but are not limited to them: each of the aforementioned modules is represented by a processor, or the functions of each of the aforementioned modules are implemented by a processor.

[0145] It should be noted that the transaction document determination device provided in this embodiment can be used to perform... Figure 2 The transaction document determination method shown above is also applicable to the embodiments of this application, and will not be repeated here.

[0146] This application embodiment also provides a non-volatile storage medium, which includes a stored computer program. The device containing the non-volatile storage medium executes the following transaction document determination method by running the computer program: determining the fields to be encrypted and the public template in the original transaction document, generating a document to be encrypted based on the fields to be encrypted, and generating a public document based on the public template, wherein the original transaction document is a contract document required for the transaction parties to conduct the target transaction; determining the target public key corresponding to the digital identity of the transaction parties, and encrypting the document to be encrypted based on the target public key to obtain an encrypted document; encrypting the target digests corresponding to the original transaction document, the document to be encrypted, the public document, and the encrypted document based on the target private key corresponding to the digital identity to obtain a digital signature document, wherein each target digest corresponds to a uniquely determined document; and generating a target transaction document based on the public document, the encrypted document, and the digital signature document.

[0147] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0148] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0149] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0150] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0151] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0152] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0153] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for determining transaction documents, characterized in that, include: The process involves identifying the fields to be encrypted and the public template in the original transaction document, generating an encrypted document based on the fields to be encrypted, and generating a public document based on the public template, wherein the original transaction document is a contract document that the transaction parties need to sign to conduct the target transaction; Determine the target public key corresponding to the digital identity of the transaction object, and encrypt the document to be encrypted based on the target public key to obtain the encrypted document; Based on the target private key corresponding to the digital identity, the target digests corresponding to the original transaction document, the document to be encrypted, the public document, and the encrypted document are encrypted to obtain a digital signature document, wherein each target digest corresponds to a uniquely identified document; A target transaction document is generated based on the publicly available document, the encrypted document, and the digitally signed document.

2. The method for determining transaction documents according to claim 1, characterized in that, Generating a document to be encrypted based on the fields to be encrypted, and generating a public document based on the public template, include: The field to be encrypted and the field identifier corresponding to the field to be encrypted are determined, wherein each field identifier corresponds to a uniquely determined field to be encrypted; The field to be encrypted in the original transaction document is replaced with the corresponding field identifier to obtain the public document; The document to be encrypted is generated based on the field to be encrypted and the field identifier corresponding to the field to be encrypted.

3. The method for determining transaction documents according to claim 2, characterized in that, The document to be encrypted is encrypted using the target public key to obtain the encrypted document, which includes: Based on the target public key, the field to be encrypted in the document to be encrypted is encrypted to obtain the encrypted field; The encrypted document is generated based on the encrypted field, the field identifier corresponding to the encrypted field, and the digital identity of the transaction object, wherein the digital identity includes, but is not limited to, a decentralized digital identity (DID).

4. The method for determining transaction documents according to claim 1, characterized in that, The target digest includes: a first digest, a second digest, a third digest, and a fourth digest; based on the target private key corresponding to the digital identity, the target digests corresponding to the original transaction document, the document to be encrypted, the public document, and the encrypted document are encrypted to obtain a digital signature document including: The first digest is determined based on the original transaction document, the second digest is determined based on the document to be encrypted, the third digest is determined based on the public document, and the fourth digest is determined based on the encrypted document; Based on the target private key, the first digest, the second digest, the third digest, and the fourth digest are encrypted to obtain the target signature, and the digital signature document is generated based on the target signature. Each target private key corresponds to one encryption operation, and each encryption operation generates one target signature.

5. The method for determining transaction documents according to claim 4, characterized in that, After generating the target transaction document, when planning to verify the target transaction document, the method further includes: The target transaction document is split into the public document, the encrypted document, and the digitally signed document; Based on the target public key corresponding to each of the transaction objects participating in the target transaction, each of the target signatures in the digital signature document is decrypted to obtain the target digest; The target transaction document is determined to be invalid if the target digests corresponding to each of the transaction objects are completely identical and there are inconsistencies among the target digests.

6. The method for determining transaction documents according to claim 5, characterized in that, If the target summaries are completely identical, the method further includes: Obtain the third and fourth digests from the target digest obtained after decryption; Based on the public document and the encrypted document obtained after splitting the target transaction document, a third actual digest and a fourth actual digest are determined respectively; Compare whether the third actual digest and the third digest are completely identical, and compare whether the fourth actual digest and the fourth digest are completely identical; If the third actual summary is inconsistent with the third summary, or if the fourth actual summary is inconsistent with the fourth summary, it is determined that the target transaction document has been tampered with.

7. The method for determining transaction documents according to claim 6, characterized in that, If the third actual digest is completely identical to the third actual digest, and the fourth actual digest is completely identical to the fourth actual digest, the method further includes: Based on the target private key corresponding to the digital identity of the transaction object, the encrypted document is decrypted to obtain the document to be encrypted, and based on the document to be encrypted, a second actual digest is determined; If the second actual digest and the second digest obtained after decryption are inconsistent, it is determined that the target transaction document has been tampered with; If the second actual digest and the second digest are completely identical, the original transaction document is restored based on the document to be encrypted and the public document, and the first actual digest is determined based on the original transaction document; If the first digest in the first actual digest and the first digest obtained after decryption are inconsistent, it is determined that the target transaction document has been tampered with.

8. A transaction document verification system, characterized in that, include: The document segmentation module is used to determine the fields to be encrypted and the public template in the original transaction document, and to generate a document to be encrypted based on the fields to be encrypted, and to generate a public document based on the public template, wherein the original transaction document is a contract document that the transaction parties need to sign to conduct the target transaction; The first encryption module is used to determine the target public key corresponding to the digital identity of the transaction object, and encrypt the document to be encrypted according to the target public key to obtain the encrypted document; The private key signing module is used to encrypt the target digests corresponding to the original transaction document, the document to be encrypted, the public document, and the encrypted document based on the target private key corresponding to the digital identity, so as to obtain a digital signature document, wherein each target digest corresponds to a uniquely determined document; The document generation module is used to generate a target transaction document based on the public document, the encrypted document, and the digital signature document.

9. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, performs the transaction document determination method according to any one of claims 1 to 7.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the transaction document determination method according to any one of claims 1 to 7 by running the computer program.

Images