Document processing method, apparatus, product, and device

Abstract

This application discloses a method, apparatus, product, and device for processing invoices. The method includes: acquiring a chain of invoices generated during business processing, the chain containing N business invoices, where N is a positive integer, and the N business invoices are linked together; performing data trimming on each business invoice in the chain to generate a trimmed invoice corresponding to each business invoice; merging the N trimmed invoices corresponding to the N business invoices based on the linking relationship between the N business invoices to generate a compressed invoice corresponding to the chain; and storing the compressed invoice, which is used to restore the chain. Using this application can improve the utilization rate of storage space for invoices and enhance the reliability of invoice storage.

Description

Technical Field

[0001] This application relates to the technical field of business processing, and more particularly to a method, apparatus, product, and equipment for processing invoices. Background Technology

[0002] In business processing, various documents are typically generated to prove that corresponding operations were performed. However, as business volume increases, the number of documents generated also grows, leading to a larger storage space requirement. Furthermore, storing individual documents separately is disorganized and unreliable. Therefore, improving the utilization rate of storage space and enhancing the reliability of document storage is a key issue. Summary of the Invention

[0003] This application provides a method, apparatus, product, and equipment for processing invoices, which can improve the utilization rate of storage space for invoices and enhance the reliability of invoice storage.

[0004] This application provides a method for processing negotiable instruments, the method comprising:

[0005] Obtain the chain of invoices generated during business processing. The chain of invoices contains N business invoices, and the N business invoices are linked together. N is a positive integer.

[0006] Each business document in the document chain is processed to trim the data, generating a trimmed document corresponding to each business document.

[0007] Based on the chain relationship between N business invoices, the N trimmed invoices corresponding to the N business invoices are merged to generate compressed invoices corresponding to the invoice chain.

[0008] Store compressed tickets; compressed tickets are used to restore the ticket chain.

[0009] This application provides a ticket processing apparatus, which includes:

[0010] The acquisition module is used to acquire the bill chain generated during business processing. The bill chain contains N business bills, and there is a chain relationship between the N business bills, where N is a positive integer.

[0011] The trimming module is used to trim the data of each business document in the document chain and generate a trimmed document corresponding to each business document.

[0012] The generation module is used to merge the N trimmed documents corresponding to the N business documents based on the chain relationship between the N business documents, and generate the compressed document corresponding to the document chain.

[0013] The storage module is used to store compressed tickets, which are then used to restore the ticket chain.

[0014] In one implementation, the generation module, based on the chain relationship between N business documents, merges the N trimmed documents corresponding to the N business documents to generate compressed documents corresponding to the document chain, including:

[0015] According to the order of N business documents in the chain relationship, the N trimmed documents corresponding to the N business documents are merged in sequence to generate the original compressed document.

[0016] The original compressed invoice is supplemented with data to generate a compressed invoice corresponding to the invoice chain.

[0017] In this context, the order of the N cut documents in the original compressed document is consistent with the order of the N business documents in the chain relationship.

[0018] In one implementation, the generation module performs data supplementation processing on the original compressed document to generate compressed documents corresponding to N business documents, including:

[0019] The compression process uses the first private key to sign the original compressed ticket, generating the first signature of the original compressed ticket. The first private key is issued to the compression process by the key management process.

[0020] Obtain the first metadata information related to the first signature;

[0021] The original compressed ticket, the first signature, and the first metadata information are combined and encapsulated to generate a compressed ticket.

[0022] In one implementation, the business processing is carried out according to a business processing flow, which includes M business processing steps and N business tickets generated when the M business processing steps are executed, where M is a positive integer.

[0023] In this system, one business ticket corresponds to one business processing step, and the business ticket corresponding to one business processing step is used to indicate that the business processing step has been successfully executed. The chain relationship between N business tickets is determined according to the order in which the business processing steps corresponding to the N business tickets are executed.

[0024] In one implementation, any one of the N business tickets is the target business ticket, which contains a ticket header, a business dataset, and signature information.

[0025] The document header contains the hash value of the business dataset and the hash value of the previous business document among the N business documents;

[0026] The business dataset contains key business data generated when executing the business processing steps corresponding to the target business ticket.

[0027] The signature information includes a second signature and related second metadata information. The second signature is obtained by the issuer of the target business document by signing the document header and the business dataset.

[0028] In one implementation, the trimming module performs data trimming processing on each business document in the document chain to generate a trimmed document corresponding to each business document, including:

[0029] The header of the target business invoice is trimmed to obtain the intermediate trimmed invoice.

[0030] Identify key metadata from the second metadata information of the intermediate-cut tickets;

[0031] The second signature and other metadata except for key metadata in the signature information of the intermediate clipped ticket are clipped to obtain the clipped ticket corresponding to the target business ticket.

[0032] In one implementation, the storage module stores compressed tickets in the following ways:

[0033] The compressed document is serialized to generate the serialized information corresponding to the compressed document.

[0034] Add compression tags to the serialized information and store the serialized information with compression tags in persistent storage.

[0035] In one embodiment, the above-mentioned ticket processing apparatus further includes a recovery module, which is used for:

[0036] In response to the recovery of the ticket chain, the recovery process is invoked to retrieve serialized information from persistent storage.

[0037] The serialized information is deserialized to obtain a compressed ticket;

[0038] The obtained compressed document is used to restore the document chain.

[0039] In one implementation, the compressed ticket includes an original compressed ticket and a first signature. The first signature is obtained by the compression process signing the original compressed ticket using a first private key. The original compressed ticket is obtained by merging N cropped tickets. The recovery module uses the obtained compressed ticket to recover the ticket chain, including:

[0040] The recovery process is invoked to obtain the first public key corresponding to the first private key. The first public key is issued to the recovery process by the key management process.

[0041] The first signature is verified using the first public key;

[0042] After the first signature is successfully verified, the original compressed document is used to restore the document chain.

[0043] In one implementation, any one of N business tickets is the target business ticket. The original compressed ticket contains the target trimmed ticket corresponding to the target business ticket. The target business ticket contains a ticket header, a business dataset, and signature information. The target trimmed ticket contains the business dataset and key metadata identified from the signature information. The recovery module recovers the ticket chain using the original compressed ticket, including:

[0044] Based on the business dataset in the target cropped invoice, reconstruct the invoice header of the target business invoice;

[0045] Obtain other metadata from the signature information besides the key metadata as supplementary metadata;

[0046] Based on the reconstructed ticket header, supplementary metadata, and target-tailored ticket, the target business ticket is restored;

[0047] Among them, the N recovered business tickets are used to form the recovered ticket chain.

[0048] In one implementation, the recovery module recovers the target business ticket based on the reconstructed ticket header, supplementary metadata, and the target pruned ticket, including:

[0049] The recovery process is invoked to obtain the second private key of the issuer to which the target business ticket belongs. The second private key is issued to the recovery process by the key management process.

[0050] The second private key is used to sign the reconstructed ticket header and the business dataset in the target cropped ticket to generate a reconstructed signature for the target business ticket.

[0051] The reconstructed ticket header, supplementary metadata, reconstructed signature, and target cropped ticket are combined and encapsulated to obtain the recovered target business ticket.

[0052] In one implementation, the recovery module reconstructs the header of the target business document based on the business dataset in the target cropped document, including:

[0053] Perform hash calculation on the business dataset in the target cropped ticket to obtain the hash value of the business dataset;

[0054] If the target business ticket is the first business ticket among N business tickets, then the hash value of the business dataset will be used as the reconstructed ticket header;

[0055] If the target business ticket is not the first business ticket among N business tickets, then obtain the hash value of the previous business ticket of the target business ticket that has been restored before the target business ticket, and use the hash value of the business dataset and the hash value of the previous business ticket as the reconstructed ticket header.

[0056] In one implementation, the recovery module is further configured to:

[0057] The recovery process will report the intermediate data generated during the recovery of the ticket chain to the detection process.

[0058] The detection process is invoked to perform anomaly analysis on the intermediate data and generate analysis results for the intermediate data.

[0059] Visualize intermediate data and analysis results.

[0060] This application provides a computer device, including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the method of this application.

[0061] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the method described in the above-mentioned aspect.

[0062] This application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the methods provided in the various alternative embodiments described above.

[0063] This application can obtain a chain of invoices generated during business processing. This chain of invoices can contain N business invoices, and the N business invoices can have a chain relationship, where N is a positive integer. It can also perform data trimming processing on each business invoice in the chain to generate a trimmed invoice corresponding to each business invoice. Furthermore, based on the chain relationship between the N business invoices, it can merge the N trimmed invoices corresponding to the N business invoices to generate a compressed invoice corresponding to the chain of invoices. Thus, the compressed invoice can be stored, and the compressed invoice can be used to recover the chain of invoices. Therefore, the method proposed in this application can form a bill chain from the various business documents (such as N business documents) generated during business processing. These business documents can have a chain-like relationship, which enables the association between them and provides traceability, thus ensuring the reliability of subsequent document storage. Furthermore, this application can compress the entire bill chain by performing data trimming on each business document to obtain a compressed bill corresponding to the entire bill chain. This compressed bill can then be stored to reduce the storage space occupied by the bills, thereby improving the utilization rate of storage space. Moreover, this compressed bill can be used to reconstruct the complete bill chain; therefore, even if the compressed bill is stored instead of the entire bill chain, it will not affect the subsequent use of the bill chain. Attached Figure Description

[0064] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0065] Figure 1 This is a schematic diagram of the network architecture of a key processing network provided in an embodiment of this application;

[0066] Figure 2 This is a schematic diagram illustrating a scenario where a bill chain is compressed to generate a compressed bill, as provided in an embodiment of this application.

[0067] Figure 3 This is a flowchart illustrating a bill processing method provided in an embodiment of this application;

[0068] Figure 4 This is a schematic diagram of a bill chain structure provided in an embodiment of this application;

[0069] Figure 5 This is a schematic diagram of a compressed document structure provided in an embodiment of this application;

[0070] Figure 6 This is a schematic diagram of a framework for processing a bill chain provided in an embodiment of this application;

[0071] Figure 7 This is a schematic diagram illustrating a process for restoring a chain of bills by compressing bills, as provided in an embodiment of this application.

[0072] Figure 8 This is a schematic diagram illustrating a scenario for restoring a bill chain, provided in an embodiment of this application.

[0073] Figure 9 This is a schematic diagram illustrating a process for compressing and restoring invoices provided in an embodiment of this application;

[0074] Figure 10 This is a schematic diagram of the structure of a ticket processing device provided in an embodiment of this application;

[0075] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0076] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0077] All data collected in this application (such as bill chains, public keys, private keys, and other related data) are collected with the consent and authorization of the data owner (such as a user, institution, or enterprise), and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant regions.

[0078] The relevant technical concepts involved in this application are described and explained here:

[0079] 1. Digital signature (i.e., signature): A technology used to verify the integrity of digital information and the identity of the sender. Based on private key encryption, it ensures that information is not tampered with during transmission and also verifies the sender's identity. Its working principle is as follows:

[0080] ① The sender (i.e. the signer) uses a private key to encrypt (i.e. sign) the information to be transmitted in order to generate a digital signature.

[0081] ②The sender attaches this digital signature to the message and then sends the message and digital signature together to the recipient.

[0082] ③ After receiving the information and digital signature, the recipient can use the sender's public key to decrypt the digital signature (i.e., verify the signature).

[0083] ④ The receiver can compare the decrypted information with the received information. If they match, it proves that the information has not been tampered with during transmission and that the information does indeed come from the claimed sender, i.e., the signature verification is successful. If they do not match, it indicates that the information has been tampered with during transmission and that the information does not come from the claimed sender, i.e., the signature verification fails.

[0084] 2. Hash Algorithm: Used for hash calculations, it is a function that converts input data of arbitrary length into a unique string of fixed length (called a hash value or digest).

[0085] 3. KMS: Key Management Service (or key management system), which can be used to issue the keys required for hash authentication in tickets.

[0086] 4. Issuance of a Business Ticket: This refers to the issuance of a business ticket, which is an authoritative credential generated after logical verification (such as user password verification, SMS verification, facial recognition, etc.) has been completed. It clearly indicates that an operation on specific business data has been effectively executed, serving as evidence that the corresponding business logic verification for that operation has been completed.

[0087] 5. Ticket Verification: This process aims to verify the legality of the voucher and confirm that the business operation it represents has indeed gone through and successfully passed all the necessary logical verification steps, ensuring the legitimacy and validity of the operation.

[0088] 6. Persistent storage: Save data to non-volatile storage media (such as hard drives, SSDs (solid-state drives)) so that the data can be retained and recovered after system restart or program termination.

[0089] Please see Figure 1 , Figure 1 This is a schematic diagram of the network architecture of a key processing network provided in an embodiment of this application. For example... Figure 1 As shown, the network architecture can include a ticketing process, a compression process, a recovery process, and a key management process. Different processes can be configured on the same or different devices, such as servers, terminal devices, or other devices. The processes can interact with each other, and the operations performed by each process can be performed through the device on which it resides.

[0090] Figure 1The servers mentioned can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Figure 1 The terminal devices mentioned can be: smartphones, tablets, laptops, desktop computers, smart TVs, in-vehicle terminals, smart home devices, and other smart terminals.

[0091] The aforementioned ticketing process can be used to generate (i.e., issue) corresponding business tickets during business processing. These tickets indicate that the corresponding business operation (such as the corresponding business processing steps) was successfully executed during the business processing. The generated business tickets can form a ticket chain, and the various business tickets in this chain can have a chain-like relationship (which can be understood as a sequential order). The aforementioned compression process can be used to compress the ticket chain generated during business processing (such as reducing the data volume of the ticket chain) to construct a compressed ticket (also called a compressed ticket) corresponding to the ticket chain, and this compressed ticket can be stored. The recovery process can be used to recover the complete ticket chain using the stored compressed ticket when the ticket chain is needed, thereby using the recovered ticket chain. During the aforementioned processes of generating, compressing, and recovering the ticket chain, corresponding keys (such as private or public keys) are used. These keys can be issued by the key management process to the corresponding processes (such as the ticketing process, compression process, or recovery process). For a detailed description of this process, please refer to the relevant descriptions in the following embodiments.

[0092] Please see also Figure 2 , Figure 2 This is a schematic diagram illustrating a scenario where a chain of bills is compressed to generate a compressed bill, as provided in an embodiment of this application. Figure 2 As shown, the chain of receipts generated during business processing can contain N business receipts, where N can be equal to 5. This chain can sequentially contain business receipts y1, y2, y3, y4, and y5. Here, N is a positive integer; in practical applications, N can also be other values. The fact that N is equal to 5 here is merely illustrative. Figure 1The compression process in the document chain can perform data trimming on each business document to generate trimmed documents corresponding to each business document. For example, data trimming can be performed on business document y1 to generate trimmed document c1, on business document y2 to generate trimmed document c2, on business document y3 to generate trimmed document c3, on business document y4 to generate trimmed document c4, and on business document y5 to generate trimmed document c5. Therefore, by performing data trimming on N business documents, N trimmed documents can be obtained.

[0093] The compression process can merge the N trimmed documents obtained above according to the chain relationship between the various business documents to obtain a compressed document. The N trimmed documents in this compressed document will retain the chain relationship (i.e., the sequence relationship) between the corresponding N business documents. The compression process can persistently store the constructed compressed document, such as persistently storing it to the corresponding database. The persistently stored compressed document can later be used to recover the complete document chain.

[0094] Using the method provided in this application, the bill chain can be compressed and the compressed bills obtained can be stored, thereby reducing the storage space occupied by the bills and improving the utilization rate of the storage space. Furthermore, the various business bills in the business process are stored in the form of a bill chain, and there is a chain relationship between the various business bills. Therefore, the various business bills can be traced, which also improves the reliability of storing business bills.

[0095] Please see Figure 3 , Figure 3 This is a flowchart illustrating a document processing method provided in an embodiment of this application. The executing entity in this embodiment can be a document processing device, which can be a single computer device or a cluster of multiple computer devices. The computer device can be a server or other devices; this application does not impose any limitations on this. Figure 3 As shown, the method may include:

[0096] Step S101: Obtain the bill chain generated during the business processing. The bill chain contains N business bills, and the N business bills have a chain relationship, where N is a positive integer.

[0097] In one implementation, the document processing device can acquire a document chain generated during business processing. This document chain can contain N business documents, where N is a positive integer. The specific value of N can be determined according to the actual application scenario, such as N being 5 or 6. These N business documents can have a chain relationship, meaning they can form a chain structure. This chain relationship can be used to represent the sequential relationship between the N business documents or their positions within the chain structure.

[0098] For example, the N business notes may sequentially include business note 1, business note 2, business note 3, business note 4, and business note 5. The note chain formed by these 5 business notes can be "business note 1 → business note 2 → business note 3 → business note 4 → business note 5", that is, business note 1 is before business note 2, business note 1 is the preceding business note of business note 2, and business note 2 is the following business note of business note 1; similarly, business note 2 is before business note 3, business note 2 is the preceding business note of business note 3, and business note 3 is the following business note of business note 2; and so on.

[0099] The specific business process described above (which can be referred to as the target business) can be determined based on the actual application scenario. That is, the type of target business can be determined based on the actual application scenario, and this application does not impose any restrictions on this. For example, the business process could be a resource withdrawal process, a resource transfer process, or an identity verification process, etc.

[0100] The business processing procedure can be carried out according to a business processing flow, which may include M business processing steps. The aforementioned N business tickets are generated when these M business processing steps are executed, where M can be a positive integer. These M business processing steps can have a sequential order, which is the order in which they are executed.

[0101] In this context, a business ticket can correspond to a business processing step; that is, a business ticket can be generated (i.e., produced) when the corresponding business processing step is executed. Typically, executing a business processing step may generate one corresponding business ticket or not. For example, for a business processing step used to verify business tickets generated by previous business processing steps, executing this step usually does not generate a corresponding business ticket. Alternatively, in some special scenarios, executing a business processing step may generate more than one corresponding business ticket, depending on the specific application scenario.

[0102] A business document corresponding to a business processing step can be used to indicate that the business processing step has been successfully executed. That is, the business document generated after executing a business processing step can serve as proof (or indication) that the business processing step has been successfully executed. The chain relationship between the above N business documents can be determined according to the order in which the business processing steps corresponding to the N business documents are executed. That is, if business processing step t1 corresponding to business document 1 is executed before business processing step t2 corresponding to business document 2, then business document 1 can be placed before business document 2 in the document chain, and business document 2 can have a dependency relationship with the business document that precedes it (such as business document 1).

[0103] For example, if the above M business processing steps, in the order of execution (i.e., the order of execution), include business processing step t1, business processing step t2, business processing step t3, business processing step t4, and business processing step t5 respectively, and no business document is generated after executing business processing step t1, business document 2 is generated after executing business processing step t2, and business document 3 is generated after executing business processing step t5, and no business document is generated after executing business processing steps 3 and t4, then the document chain generated during the business processing of these M business processing steps can be "business document 1 → business document 2 → business document 3", that is, business document 1 is before business document 2, and business document 2 is before business document 3.

[0104] Any one of the above N business tickets can be called the target business ticket. Since the construction of each business ticket and the principle of processing each business ticket are the same, the following uses the target business ticket as an example to specifically describe the construction of the business ticket and the relevant principles of processing the business ticket, as described below.

[0105] The target business ticket may contain a ticket header, a business dataset, and signature information. The ticket header of the target business ticket may contain the hash value of the business dataset and the hash value of the preceding business ticket among N business tickets. Specifically, if the target business ticket is the first (i.e., the first) business ticket among the N business tickets (i.e., the target business ticket has no preceding business ticket), then the ticket header may contain the hash value of the business dataset but not the hash value of the preceding business ticket; if the target business ticket is not the first business ticket among the N business tickets, then the ticket header may contain both the hash value of the business dataset and the hash value of the preceding business ticket.

[0106] The business data set of the target business ticket may include key business data generated during the execution of the business processing steps corresponding to the target business ticket. The type of key business data can be determined according to the type of the target business being processed. This key business data may include business data used to reflect the execution process or result of the business processing steps corresponding to the target business ticket. For example, if the target business is a resource transfer business, and the business processing steps corresponding to the target business ticket are the actual resource transfer steps after verifying the legitimacy of the resource transferor's (e.g., the account transferring the resources) identity information and the adequacy of the account balance, then the key business data may include the amount of resources transferred, the account transferring the resources, the account receiving the resources, and the timestamp of the resource transfer, etc.

[0107] The signature information of the target business ticket may include a second signature and related metadata information. This metadata information can be referred to as the second metadata information. The second signature can be obtained by the issuer of the target business ticket through signing the ticket header and business dataset. The issuer of the target business ticket can be a node that executes the business processing steps corresponding to the target business ticket. This node can be a process within the ticket processing device, referred to as the ticket issuing process or ticket issuing node. In other words, the issuer of the target business ticket can be the ticket issuing process that generated the target business ticket.

[0108] In one implementation, each of the M business processing steps can have its own corresponding business processing node. This business processing node can be a business processing process, or it can be a process configured in the ticket processing system. The business processing processes corresponding to different business processing steps can be the same or different. A business processing process corresponding to a business processing step can be used to execute that business processing step. Therefore, it can be understood that if a business ticket is generated after executing a business processing step, the business ticket can be generated by the business processing process corresponding to that business processing step; that is, the issuer of the business ticket (i.e., the ticket issuing process) can be the business processing process corresponding to that business processing step.

[0109] In addition to the aforementioned business processing process and ticket issuance process (which may be multiple), the ticket processing system in this application may also include a key management process (also known as a key management node). This key management process can be used to issue corresponding keys (such as corresponding private or public keys) to other processes (i.e., other nodes). Therefore, the ticket issuance process can possess the private key issued by the key management process, which can be understood as the private key held by the ticket issuance process itself. Thus, the ticket issuance process can use its own private key to sign the ticket header and business dataset of the target business ticket, thereby generating the aforementioned second signature. The ticket processing system used in this application can be a KMS system (a key escrow system), meaning the method provided in this application can be performed within the framework of this KMS system.

[0110] For example, the aforementioned second metadata information may include metadata such as the signer, issuance time, version number, and ticket scenario identifier of the target business ticket. The signer is the ticket issuing process to which the target business ticket belongs. The signer in the second metadata information may have a mapping relationship with the private key of the ticket issuing process; for example, it may be an identifier (such as a string of identifier characters) generated using the private key of the ticket issuing process. The version number may be a fixed current application version number. The ticket scenario identifier may be used to indicate the business scenario to which the current ticket belongs (such as a resource transfer scenario or an authentication scenario). The issuance time may be the time when the target business ticket was generated.

[0111] Please see Figure 4 , Figure 4 This is a schematic diagram of a bill chain structure provided in an embodiment of this application. For example... Figure 4 As shown, the N business tickets in this ticket chain can sequentially include business ticket a1, business ticket a2, and business ticket a3. Each business ticket has its own ticket header, key element set (i.e., business dataset), and signature information (including the signature of the issuer). The header of a subsequent business ticket contains the hash value of the preceding business ticket; for example, the header of business ticket a2 contains the hash value of business ticket a1, and the header of business ticket a3 contains the hash value of business ticket a2.

[0112] Step S102: Perform data trimming on each business document in the document chain to generate a trimmed document corresponding to each business document.

[0113] In one implementation, the document processing device can perform data trimming on each business document in the aforementioned document chain. For example, it can trim (i.e. remove) the corresponding data in the business document that can be recovered later to generate a trimmed document corresponding to each business document. One business document can correspond to one trimmed document; that is, performing data trimming on a business document yields a trimmed document corresponding to that business document.

[0114] For example, the process by which a bill processing device performs data trimming on a target business bill to generate a trimmed bill corresponding to the target business bill may include: the bill processing device may trim the bill header in the target business bill to obtain an intermediate trimmed bill, which is the bill obtained after removing the bill header from the target business bill.

[0115] The ticket processing device can identify key metadata from the second metadata information of the intermediate cut ticket. The type of key metadata can be pre-set non-general metadata, such as the ticket issuance time, version number and ticket scenario identifier in the second metadata information.

[0116] The document processing equipment can perform trimming (removal) on the second signature and other metadata (excluding key metadata) in the signature information of the intermediate trimmed document to obtain the trimmed document corresponding to the target business document. In other words, the trimmed document corresponding to the target business document is obtained by trimming the document header and other information (including non-key metadata and the second signature) in the signature information of the target business document.

[0117] The document processing equipment can perform data trimming on each business document in accordance with the same principle as the above-mentioned method for obtaining the trimmed document corresponding to the target business document, so as to obtain the trimmed document corresponding to each business document.

[0118] Step S103: Based on the chain relationship between N business tickets, merge the N trimmed tickets corresponding to the N business tickets to generate compressed tickets corresponding to the ticket chain.

[0119] In one implementation, the bill processing device can merge the N trimmed bills corresponding to the N business bills through the chain relationship between the N business bills to generate the same compressed bill corresponding to the entire bill chain, as described below.

[0120] The document processing equipment can sequentially merge the N trimmed documents corresponding to the N business documents according to their order in a chain relationship to generate an original compressed document. This original compressed document contains the N trimmed documents, and the N trimmed documents retain the order of the corresponding N business documents in the document chain. The order among the N trimmed documents in the original compressed document can be consistent with the order of the N business documents in the chain relationship; that is, the trimmed documents in the original compressed document can be sorted according to the order of the corresponding business documents in the chain relationship.

[0121] For example, N business tickets are listed in a chain, sequentially as business ticket 1, business ticket 2, and business ticket 3. Business ticket 1 corresponds to trimmed ticket c1, business ticket 2 corresponds to trimmed ticket c2, and business ticket 3 corresponds to trimmed ticket c3. Therefore, the original compressed ticket could sequentially include trimmed tickets c1, c2, and c3. Alternatively, the original compressed ticket could be represented as an array, where each trimmed ticket is an element of that array, and these elements have a specific order. In this example, the original compressed ticket could be the array [trimmed ticket c1, trimmed ticket c2, trimmed ticket c3].

[0122] The ticket processing device can perform data supplementation processing on the original cropped tickets obtained above to generate compressed tickets corresponding to the ticket chain. This process may include: the ticket processing system may also include a compression process (also called a compression node). This compression process can be used to compress the ticket chain generated during business processing to generate compressed tickets corresponding to the ticket chain. Therefore, the ticket processing device can call this compression process to sign the original compressed ticket using a first private key to generate a signature of the original compressed ticket. This signature of the original compressed ticket can be called the first signature, which can be used to prove that the compressed ticket was generated by the compression process. For example, the first signature can be obtained by encrypting the hash value of the original compressed ticket using the first private key. The hash value of the original compressed ticket can be obtained by the compression process using a hash algorithm to perform hash calculation on the original compressed ticket.

[0123] The first private key can be issued to the compression process by the key management process in the ticket processing system. This first private key can be understood as the compression process's private key, but the compression process may not be issued a corresponding public key (which can be called the first public key), meaning the compression process may not hold the first public key. The first private key and the first public key can form a key pair. Data encrypted with the first private key can be decrypted using the first public key. The first private key and the first public key can be an asymmetric key pair.

[0124] The ticket processing device can also invoke the compression process to obtain metadata information related to the first signature, which can be referred to as the first metadata information. This first metadata information may include metadata such as the signer related to the first signature (which can be the compression process, obtained through the compression process's first private key), the ticket issuance time (such as the time when the compressed ticket was generated), the version number (which can be a fixed setting), and the ticket scenario identifier (such as the business scenario of the target business to which the compressed ticket chain belongs).

[0125] The document processing device can combine and encapsulate the aforementioned original compressed document, first signature, and first metadata information to generate a compressed document corresponding to the document chain. That is, the compressed document encapsulates the original compressed document, first signature, and first metadata information. The first signature and first metadata information can serve as supplementary data to the original compressed document.

[0126] Through the above process, a clipped ticket corresponding to the ticket chain can be constructed by merging the clipped tickets corresponding to each business ticket. Compared with N business tickets, the clipped ticket has removed the ticket header and signature from each business ticket. Generally speaking, a hash value using SHA256 (a hash algorithm) will occupy 32 bytes (a ticket header will contain one or two hash values), and a signature obtained by ECDSA elliptic curve (a signature algorithm) will occupy 64 bytes. Therefore, by using the method provided in this application to perform data clipping on each business ticket, the amount of data contained in each business ticket can be greatly reduced.

[0127] In one exemplary embodiment, the steps for generating compressed bills corresponding to the bill chain in this application embodiment, including data trimming of the bill chain, merging of each trimmed bill, and finally generating compressed bills, as well as the process of storing compressed bills described below, can all be executed by the bill processing device calling the compression process.

[0128] Please see Figure 5 , Figure 5 This is a schematic diagram of a compressed document provided in an embodiment of this application. For example... Figure 5As shown, the compressed ticket can contain multiple fields, including a Chain field, a Version field, an IssuerTime field, an Issuer field, and a Signature field. The compressed ticket can also contain the data types of each field, such as the Chain field being of type "Pb.TicketChain (custom structured data type, such as array type)", the Version field being of type "int32 (32-bit signed integer data type)", the IssuerTime field being of type "int64 (64-bit signed integer data type)", the Issuer field being of type "string (string type)", and the Signature field being of type "[]byte (byte type)".

[0129] The Chain field describes (i.e. records) the compressed and trimmed ticket chain (i.e., the compressed ticket), the Version field describes the version number (which can be a fixed setting), the IssuerTime field describes the issuance time of the compressed ticket (i.e., the issuance time of the compressed ticket, which can be the time when the compressed ticket was generated), the Issuer field describes the issuer of the compressed ticket (i.e., the compression process), and the Signature field describes the signature of the compressed ticket (i.e., the signature generated by the compression process for the compressed ticket, such as the first signature mentioned above).

[0130] Step S104: Store compressed tickets. Compressed tickets are used to restore the ticket chain.

[0131] In one implementation, the document processing device can persistently store the compressed document constructed above, instead of storing the entire complete document chain. That is, the document chain can be omitted, thereby significantly reducing the storage space occupied when storing the document chain. For example, the document processing device can invoke a compression process to store the compressed document constructed above.

[0132] For example, the process of storing compressed tickets may include: serializing the compressed ticket (which may be byte conversion processing) to generate serialized information corresponding to the compressed ticket. This serialized information may be a byte string (also called a string) obtained by converting the compressed ticket. For instance, the serialization process may include: performing binary processing on the compressed ticket using protobuf format (binary serialization format) to obtain a binary string of the compressed ticket, and then encoding this binary string using Base64 (a binary data encoding method based on 64 printable characters) to generate the serialized information, which may be the encoded string. The ticket processing device may add a compression marker to the serialized information. This compression marker may be added as a prefix to the serialized information to identify that the serialized information is information from a compressed ticket. For example, the compression marker may be "zip:". The ticket processing device may store the serialized information with the added compression marker in persistent storage space. This persistent storage space may be a storage space used for persistent data storage, such as a persistent storage database or a persistent storage device.

[0133] Furthermore, the compressed ticket described above can also be used to recover the ticket chain. For example, when the complete ticket chain needs to be used (i.e., applied), it can be recovered from the compressed ticket stored in persistent storage and then used. The specific process of recovering the ticket chain using compressed tickets can be found below. Figure 7 The relevant descriptions in the corresponding embodiments.

[0134] Please see Figure 6 , Figure 6 This is a schematic diagram of a framework for processing a bill chain, provided in an embodiment of this application. For example... Figure 6 As shown, the key system (such as the KMS system, which can be the aforementioned ticket processing system) may contain a private key b1, a public key d1, a private key b2, a public key d2, a private key b3, and a public key d3 private key.

[0135] In this system, private key b1 is the private key of the issuing node J1 (i.e., the issuing process J1), private key b2 is the private key of the issuing node J2 (i.e., the issuing process J2), and private key b3 is the private key of the storage node J3 (i.e., the compression process J3) (as described in the first private key above). Public key d1 and private key b1 can be a key pair; data encrypted (signed) using private key b1 can be decrypted (verified) using public key d1. Similarly, public key d2 and private key b2 can be a key pair; data encrypted (signed) using private key b2 can be decrypted (verified) using public key d2. Likewise, public key d3 and private key b3 can be a key pair; data encrypted (signed) using private key b3 can be decrypted (verified) using public key d3. Public key d3 can be the public key of the recovery node J4 (i.e., the recovery process J4) (as described in the first public key above).

[0136] In a ticket processing system, the system can allocate (issue) keys (including private keys and / or public keys) to each node according to their respective functions (i.e., business permissions). For example, the ticket issuing node J1 can be issued with private key b1; the ticket issuing node J2 can be issued with public key d1 and private key b2; the storage node J3 can be issued with public key d2 and private key b3; and the recovery node J4 can be issued with public key d3 and the private keys (including private keys b1 and b2) of each ticket issuing node (including ticket issuing nodes J1 and J2).

[0137] During business processing, issuing node J1 generates business ticket P1, and issuing node J2 generates business ticket P2. Both business tickets P1 and P2 can contain their own ticket headers, business datasets, and signature information. The signature information in business ticket P1 can include signature e1 obtained by issuing node J1 using its private key b1 to sign the ticket header and business dataset of business ticket P1. The signature information in business ticket P2 can include signature e2 obtained by issuing node J2 using its private key b2 to sign the ticket header and business dataset of business ticket P2. The ticket header of a business ticket can contain a predecessor hash (which can be denoted as Prehash, representing the hash value of the previous business ticket; if this business ticket is the first business ticket in the ticket chain, the predecessor hash can be empty or a fixed string) and a data hash (which can be denoted as Datahash, i.e., the hash value of the ticket header and business dataset in this business ticket).

[0138] Business document P1 precedes business document P2, and the generated document chain consists of business document P1 and business document P2 in sequence. Before issuing node J2 continues to generate business documents based on business document P1 generated by issuing node J1, that is, before appending business documents to business document P1, issuing node J2 can verify (i.e., verify signature) business document P1 generated by issuing node J1. For example, issuing node J2 can use public key d1 to verify signature e1 in business document P1, and can generate business document P2 if signature e1 is successfully verified, and can terminate the generation of business document P2 if signature e1 is not verified. In this case, the document chain generation fails because business document P1 generated by issuing node J1 has a problem and is invalid.

[0139] After the generated ticket chain is given to storage node J3 (e.g., by the issuing node J2 to which the last business ticket in the ticket chain belongs), storage node J3 can use public key d2 to verify the last business ticket in the ticket chain (here, business ticket P2). Similarly, storage node J3 can use public key d2 to verify signature e2 in business ticket P2. If signature e2 is successfully verified, the entire ticket chain is considered to have been successfully verified, and the ticket chain is compressed to generate a compressed ticket (i.e., Zip:Compressed, where "Zip:" is an added compression prefix to identify the compressed ticket). This compressed ticket may contain Tickets (i.e., tickets, here [TP1, TP2], where TP1 is the trimmed ticket corresponding to business ticket P1, and TP2 is the trimmed ticket corresponding to business ticket P2). This compressed ticket may also contain signature e3 obtained by storage node J3 signing the Tickets using private key b3, and related metadata information (including version number, issuance time, and issuer). Storage node J3 can persistently store the constructed compressed tickets, such as storing them in persistent storage space (which can be a database).

[0140] Alternatively, the generated bill chain can be stored in a designated storage space, and storage node J3 can retrieve the generated bill chain from that storage space.

[0141] Subsequently, the recovery node can retrieve the compressed ticket from the persistent storage space. The recovery node can then verify the compressed ticket using the public key d3, such as verifying the signature e3 within the compressed ticket. If verification is successful, the complete ticket chain structure can be recovered from the compressed ticket. If verification fails, it indicates that the currently obtained compressed ticket is untrustworthy and illegitimate, and the process of recovering the ticket chain using the compressed ticket can be terminated. The specific process is detailed below. Figure 7 The relevant descriptions in the corresponding embodiments.

[0142] Through the above process, it can be seen that before a ticket issuing node generates another business ticket based on a previously generated business ticket, it can verify the previous business ticket (through the signature in that previous business ticket). After successful verification, it can continue to generate the next business ticket. Similarly, before a compression node compresses the ticket chain to generate a compressed ticket, it can also verify the last business ticket in the ticket chain (through the signature in that last business ticket). After successful verification, it can compress the ticket chain to generate a compressed ticket.

[0143] This application can be applied to various business scenarios (such as FIT (Payment Infrastructure and Financial Applications)) to implement a data compression and trusted storage solution for various business documents. It balances storage efficiency and data trustworthiness for business documents. By pruning the signatures and document headers in business documents, it significantly reduces the amount of non-business data storage caused by the increase in the number of documents, and greatly reduces the size of the documents. At the same time, the compressed documents retain core business data (i.e., business datasets) and necessary metadata (i.e., key metadata). Based on KMS-managed asymmetric key technology, it can achieve data integrity recovery of the document chain while ensuring the controllability of the recovery node's rights.

[0144] Furthermore, this application stores the tickets generated during the business process in the form of a ticket chain, where the hash value of the previous business ticket is contained in the subsequent business ticket, thereby realizing the correlation between the previous and subsequent business tickets. This allows any business ticket in the ticket chain to perform correlation verification and anti-tampering verification of other business tickets, thus ensuring the traceability and dependency between various business tickets generated in the same business process, and guaranteeing the reliability and effectiveness of verifying and storing each business ticket.

[0145] This application can obtain a chain of invoices generated during business processing. This chain of invoices can contain N business invoices, and the N business invoices can have a chain relationship, where N is a positive integer. It can also perform data trimming processing on each business invoice in the chain to generate a trimmed invoice corresponding to each business invoice. Furthermore, based on the chain relationship between the N business invoices, it can merge the N trimmed invoices corresponding to the N business invoices to generate a compressed invoice corresponding to the chain of invoices. Thus, the compressed invoice can be stored, and the compressed invoice can be used to recover the chain of invoices. Therefore, the method proposed in this application can form a bill chain from the various business documents (such as N business documents) generated during business processing. These business documents can have a chain-like relationship, which enables the association between them and provides traceability, thus ensuring the reliability of subsequent document storage. Furthermore, this application can compress the entire bill chain by performing data trimming on each business document to obtain a compressed bill corresponding to the entire bill chain. This compressed bill can then be stored to reduce the storage space occupied by the bills, thereby improving the utilization rate of storage space. Moreover, this compressed bill can be used to reconstruct the complete bill chain; therefore, even if the compressed bill is stored instead of the entire bill chain, it will not affect the subsequent use of the bill chain.

[0146] Please see Figure 7 , Figure 7 This is a schematic diagram illustrating a process for restoring a chain of documents by compressing documents, as provided in an embodiment of this application. Figure 7 As shown, the process may include:

[0147] In step S201, in response to the triggering of the recovery of the ticket chain, the recovery process is invoked to obtain serialized information from the persistent storage space.

[0148] In one embodiment, the aforementioned ticket processing system may further include a recovery process, which is a process for recovering a complete ticket chain by compressing the ticket. This recovery process may be issued a first public key corresponding to the first private key by the aforementioned key management process; that is, the first public key may be authorized to the recovery process. The ticket processing device can invoke this recovery process to recover the aforementioned ticket chain using the serialized information stored in persistent storage space, as described below.

[0149] The ticket processing device can respond to a recovery trigger on the ticket chain by invoking a recovery process to retrieve the serialized information corresponding to the compressed ticket from persistent storage. This recovery trigger can be triggered when the ticket chain needs to be used (e.g., propagated).

[0150] The compression process (i.e., compression node), key management process (i.e., key management node), recovery process (i.e., recovery node), and ticket issuance process (i.e., ticket issuance node) mentioned above can be configured in the same device (such as a ticket processing device), or different processes can be configured in different devices. For example, each process can be configured in a different device, one process can be configured in a corresponding device, or some processes can be configured in the same device and some processes can be configured in another device. Whether each process is configured in the same or different devices can be determined according to the actual application scenario, and this application does not impose any restrictions on this. The compression process can be configured in the ticket processing device. In one embodiment, if other processes (such as the recovery process, key management process, and ticket issuance process) are not configured in the ticket processing device but in other devices, the ticket processing device can also have the authority to call the other processes configured in the other devices to perform corresponding operations.

[0151] Step S202: Deserialize the serialized information to obtain a compressed ticket.

[0152] In one implementation, the ticket processing device can call a recovery process to deserialize the acquired serialized information to obtain a compressed ticket. For example, the deserialization process may include: decoding the serialized information using Base64 to obtain a binary string, and then converting the binary string back to the original structure using protobuf format, which is the original compressed ticket.

[0153] The ticket processing device can invoke the recovery process to recover the ticket chain by deserializing the compressed ticket, as described below.

[0154] Step S203: Use the obtained compressed document to restore the document chain.

[0155] In one implementation, as described above Figure 3 As described in the corresponding embodiment, the compressed ticket obtained above may include an original compressed ticket and a first signature of the original compressed ticket. The first signature is obtained by the compression process using a first private key to sign the original compressed ticket. The original compressed ticket is obtained by merging N cropped tickets.

[0156] Therefore, the process of recovering the bill chain using the compressed bill obtained through deserialization can include: the bill processing device can call the recovery process to obtain the first public key corresponding to the first private key, which is issued to the recovery process by the key management process. The bill processing device can use the first public key to verify the first signature in the compressed bill. And after the first signature is successfully verified, the bill chain can be recovered using the original compressed bill in the compressed bill.

[0157] For example, the process of verifying the first signature in a compressed document using the first public key may include: decrypting the first signature in the compressed document using the first public key to obtain a decrypted hash value; performing a hash calculation on the original compressed document to obtain a calculated hash value; and then comparing the decrypted hash value with the calculated hash value to obtain the verification result of the first signature. If the decrypted hash value matches the calculated hash value, the first signature verification is considered successful; if the decrypted hash value does not match the calculated hash value, the first signature verification is considered to have failed, and the current compressed document was not signed and generated by the compression process.

[0158] After successful verification of the first signature, the process of restoring the bill chain using the original compressed bill in the compressed bill may include: any one of the aforementioned N business bills can be the target business bill. Since restoring the bill chain requires restoring each business bill in the bill chain, and the principle of restoring each business bill is the same, the following process will be specifically explained using the process of restoring the target business bill as an example. In this application, since the subsequent business bill is generated based on the previous business bill, and the header of the subsequent business bill contains the hash value of the previous business bill, this application can restore the bill chain in the order of the business bills in the chain relationship, and restore each business bill sequentially. For example, the first business bill can be restored first, then the second business bill can be restored using the restored first business bill, then the third business bill can be restored using the restored second business bill, and so on.

[0159] The original compressed document may contain a trimmed document corresponding to the target business document; this trimmed document corresponding to the target business document can be referred to as the target trimmed document. Similarly, based on the above... Figure 3 As can be seen from the description in the corresponding embodiments, the target business ticket may contain a ticket header, a business dataset, and signature information, and the target cropped ticket may contain the business dataset and key metadata identified and retained from the signature information.

[0160] The ticket processing device can reconstruct the ticket header of a target business ticket by analyzing the business dataset in the target cropped ticket. This process can include: the ticket processing device performing a hash calculation (e.g., using a hash algorithm) on the business dataset in the target cropped ticket to obtain the hash value of the business dataset. If the target business ticket is the first business ticket among the aforementioned N business tickets (i.e., the 1st business ticket), it indicates that the target business ticket does not have a preceding business ticket. In this case, the calculated hash value of the business dataset can be directly used as the reconstructed ticket header of the target business ticket, and the reconstructed ticket header will contain the hash value of the business dataset.

[0161] If the target business ticket is not the first of the aforementioned N business tickets, it indicates that a preceding business ticket exists for the target business ticket, and that the preceding business ticket has already been recovered before the target business ticket was recovered. Therefore, the ticket processing device can obtain the hash value of the preceding business ticket. For example, the ticket processing device can perform a hash calculation on the recovered preceding business ticket to calculate its hash value. The ticket processing device can use the hash value of the business dataset and the hash value of the preceding business ticket as the reconstructed ticket header. The reconstructed ticket header contains both the hash value of the business dataset and the hash value of the preceding business ticket.

[0162] The ticket processing device can obtain other metadata not retained in the signature information of the target business ticket during the construction of the aforementioned compressed ticket. This other metadata refers to the metadata in the signature information other than the aforementioned key metadata, and can be used as supplementary metadata. This supplementary metadata can be general metadata, which the recovery process can directly obtain. For example, the supplementary metadata can include the issuer of the target business ticket (which may be the issuer's identity information). The issuer's private key can be issued to the recovery process by the key management process, meaning the recovery process can hold the private keys of the issuers of various business tickets. Therefore, the identity information of the issuer of the target business ticket can be obtained by the recovery process using the issuer's private key. For example, it can be a string of identifier characters calculated using the private key. The method of calculating the identifier character using the private key can be flexibly set according to the actual application scenario.

[0163] The ticket processing device can recover the target business ticket by reconstructing the ticket header, supplementing metadata, and tailoring the target ticket. This process may include: the ticket processing device can call the recovery process to obtain the private key (which may be called the second private key) of the issuer to which the target business ticket belongs. This second private key may be issued to the recovery process by the key management process.

[0164] The ticket processing device can use a second private key to sign the reconstructed ticket header and the business dataset in the target cropped ticket, generating a reconstructed signature for the target business ticket. If the reconstructed signature is correct, it can be consistent with the second signature mentioned above. Alternatively, the reconstructed signature can be obtained by encrypting the hash value of the data after merging (e.g., concatenating) the ticket header and the business dataset.

[0165] The ticket processing device can combine and encapsulate the reconstructed ticket header, supplementary metadata, reconstructed signature, and target cropped ticket to obtain the recovered target business ticket. For example, the ticket processing device can combine the supplementary metadata, the reconstructed signature, and key metadata from the target cropped ticket to obtain the signature information of the target business ticket, and can combine the signature information, the business dataset from the target cropped ticket, and the reconstructed ticket header to obtain the recovered target business ticket.

[0166] The bill processing equipment can restore the above N business bills in sequence according to the same principle as restoring the target business bills. The restored N business bills can constitute the entire restored bill chain, which includes each restored business bill.

[0167] Please see Figure 8 , Figure 8 This is a schematic diagram illustrating a scenario for restoring a bill chain, as provided in an embodiment of this application. For example... Figure 8 As shown, the recovery process can recover the first business ticket in the ticket chain by using the first cropped ticket in the compressed ticket. Then, by using the recovered first business ticket and the second cropped ticket in the compressed ticket, the second business ticket in the ticket chain can be recovered. Similarly, by using the recovered second business ticket and the third cropped ticket in the compressed ticket, the third business ticket in the ticket chain can be recovered, and so on, until the entire ticket chain is finally recovered. The recovered ticket chain can then sequentially include the recovered first business ticket, the recovered second business ticket, the recovered third business ticket, and so on, with each recovered business ticket possessing its own complete ticket header, business dataset, and signature information.

[0168] All operations performed during the aforementioned process of restoring the bill chain by compressing the bill can be executed by the bill processing device calling the recovery process. Furthermore, the bill processing system can also include a detection process to monitor whether the recovery process is successfully restoring the bill chain. The bill processing device can also call the recovery process to report intermediate data generated during the restoration of the bill chain to the detection process. This intermediate data may include relevant data generated by the steps in the restoration process, such as the calculated and decrypted hash values ​​obtained when verifying the first signature, the success or failure result of verifying the first signature, the acquired supplementary metadata, the generated reconstructed signature, the hash value calculated on the business dataset when reconstructing the bill header, and the hash value calculated on the previous business bill of the target business bill, etc.

[0169] The ticket processing device can invoke the detection process to perform anomaly analysis on the intermediate data reported by the recovery process, thereby generating analysis results for the intermediate data. These results can be used as a reference for relevant technical personnel to assess whether there are any anomalies in the recovered ticket chain. The analysis logic for anomaly analysis of the intermediate data can be configured according to the type of intermediate data in practical application scenarios. For example, if the target business ticket does not have a preceding business ticket, but the reconstructed ticket header contains the preceding business ticket, the analysis result for the intermediate data can include the result that the reconstructed ticket header is anomaly. Similarly, if, during the verification of the first signature, the decrypted hash value is inconsistent with the calculated hash value, but the first signature is still considered successfully verified, the analysis result for the intermediate data can include the result that the obtained compressed ticket verification is anomaly (i.e., the verification is invalid, not signed and generated by the compression process); and so on.

[0170] The bill processing equipment can visualize the aforementioned intermediate data and the analysis results based on that data. This allows technical personnel to further analyze and evaluate the recovery process of the bill chain, ensuring its accuracy and reliability. This, in turn, guarantees the reliability and security of the recovered bill chain for subsequent use. For example, the equipment can transmit the intermediate data and analysis results to a connected (wired or wireless) display device for visualization, or it can transmit the data to a configured client for visualization on the client's interface.

[0171] Through the process described above in this application, reliable recovery of the bill chain can be achieved by storing compressed bills. The method provided in this application not only improves the utilization rate of storage space (such as persistent storage space) for bills, but also ensures the reliability and security of applying the bill chain through stored compressed bills.

[0172] Please see Figure 9 , Figure 9 This is a schematic diagram illustrating a process for compressing and restoring a bill, as provided in an embodiment of this application. Steps s11 to s17 represent the process by which the upstream compression node (i.e., the compression process) compresses the bill chain to generate a compressed bill. Steps s21 to s26 represent the process by which the downstream recovery node (i.e., the recovery process) recovers the complete bill chain using the compressed bill. Figure 9 As shown, the compression and recovery processes may include:

[0173] The process by which compression nodes compress the bill chain to generate compressed bills corresponding to the bill chain may include:

[0174] In step s11, the compression node can initiate compression processing on the bill chain. For example, it can trigger (i.e., initiate) compression processing on the bill chain every time a bill chain is generated, that is, every time the compression node acquires a bill chain. Alternatively, in one implementation, when the generated bill chain contains only one business bill, the effect of compressing the bill chain before storing it is not significant, so compression processing on the bill chain can be omitted, and the bill chain can be stored directly. However, when the generated bill chain contains more than one (i.e., more than 1) business bill, compression processing on the bill chain can be initiated to obtain the compressed bill corresponding to the bill chain, and the compressed bill can be stored.

[0175] Step s12: The compression node can verify the bill chain. For example, it can call the bill chain SDK (application component) to verify the last business bill in the bill chain. This can be done by verifying the signature in the last business bill. If the verification is successful, the following step s13 can be executed. If the verification fails, the current bill chain compression process can be terminated. By verifying the bill chain, the verification of each business bill (i.e., each ordinary bill) in the bill chain can be achieved, which is to say, the verification of the script of each ordinary bill can be achieved.

[0176] Step s13: The compression node can prune each business ticket in the ticket chain. For example, it can remove the ticket header and signature from each business ticket one by one, while retaining the business data (i.e., business dataset) and some key metadata in each business ticket, thereby obtaining the pruned ticket corresponding to each business ticket.

[0177] Step s14: The compression node can write the trimmed ordinary ticket (i.e., trimmed ticket) and related metadata into the configured compressed ticket structure to initially build the corresponding compressed ticket.

[0178] Step s15: The compression node can use the private key (such as the first private key) issued by the key system (i.e., the KMS system) to sign the ticket (such as the ticket constructed in step s14 above, such as the original compressed ticket above) to obtain the corresponding signature (such as the first signature above). The first signature can be attached to the end of the compressed ticket initially constructed in step s14 above to obtain the finally constructed compressed ticket, thus completing the compression process of the compressed ticket.

[0179] Step s16: The compression node can serialize the compressed ticket obtained above to encode the compressed ticket into a corresponding string (i.e., serialization information).

[0180] Step s17: The compression node can persistently store the string obtained from the serialization process. This completes the compression process for the ticket chain.

[0181] The process of restoring the ticket chain by restoring nodes through persistently stored serialized information can include:

[0182] Step s21: The recovery node can initiate recovery processing for the ticket chain. For example, it can trigger recovery processing when there is a business need to use the ticket chain. Alternatively, if the required ticket chain contains only one business ticket, the fully stored ticket chain can be obtained directly without performing recovery processing; and if the required ticket chain contains more than one business ticket, the serialization information of the ticket chain can be obtained, and recovery processing can be performed on the ticket chain through this serialization information.

[0183] Step s22: The recovery node can obtain the serialized information of the persistent storage (i.e., the serialized information of the compressed ticket) and can perform deserialization processing on the serialized information to convert it into the original structure of the compressed ticket, that is, to convert it into the compressed ticket.

[0184] Step s23: The recovery node can use the public key (such as the first public key) issued by the key system (such as the KMS system) to verify the signature (such as the first signature) in the compressed ticket. After successful verification, the node can execute the following step s24. If the verification fails, the node can terminate the current process of restoring the ticket chain.

[0185] Step s24: The recovery node can recover the header of a regular ticket (i.e., the header of a regular ticket). For example, it can perform hash calculation on the business data (i.e., the business dataset) of the compressed ticket, and write the calculated hash value into the header of the ticket. It can also perform hash calculation on the previous business ticket to be recovered, and write the calculated hash value into the header of the ticket to recover the header of the current business ticket.

[0186] Step s25: The recovery node can re-sign ordinary tickets. For example, the recovery node can use the private key of the clipped node (i.e., the issuing node to which the clipped ticket belongs) issued by the key system (such as KMS system) to sign the recovered ticket header and the corresponding business dataset to recover the signature in the business ticket.

[0187] Step s26: Through the above process, the recovery of each business bill in the bill chain can be achieved, thereby realizing the recovery of the entire bill chain. The recovery node can return (such as to the relevant business device or business client) the recovered complete bill chain structure.

[0188] Through the above process, the compression node achieves effective compression of the bill chain, and the recovery node achieves reliable recovery of the bill chain when the complete bill chain is needed.

[0189] This application provides a data compression and trusted storage solution based on KMS and bill chain technologies. It uses a bill chain-based compressed bill data structure and relies on an asymmetric key digital signature security mechanism to ensure data integrity and immutability during compression and trimming. Specifically, when compressing the bill chain, the compression node trims the signature and header of the business bill while retaining business data and related marker parameters (i.e., key metadata), thereby reducing the storage burden on the business database. When the bill chain needs to be retrieved and transmitted over the network, the recovery node allows for the reconstruction of the complete bill chain structure. During the complete verification of the restored bill chain, the reconstruction can be completed by obtaining the corresponding public and private key pairs, thus simultaneously ensuring lightweight storage and recovery trustworthiness, effectively reducing the storage burden of non-business fields as the number of bill chains increases. This application uses KMS to manage and distribute asymmetric encryption keys, combined with regulatory and related verification mechanisms, to ensure the key security of the compression and recovery nodes. It also enables traceable recording of the node identity of the compressed bill and the restored bill chain, further ensuring error prevention, tamper resistance, and compliance throughout the entire chain.

[0190] Furthermore, by distinguishing between the ticket issuing node, compression node, recovery node, and key management node, this application can distribute the business processing permissions during the business processing process, enabling each node to work collaboratively to complete the corresponding business processing of the ticket, thereby improving the reliability and security of ticket processing and ensuring the effectiveness of ticket processing.

[0191] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a ticket processing device provided in an embodiment of this application. Figure 10 As shown, the ticket processing device 2000 may include: an acquisition module 2001, a cutting module 2002, a generation module 2003, and a storage module 2004.

[0192] The acquisition module 2001 is used to acquire the bill chain generated during the business processing. The bill chain contains N business bills, and there is a chain relationship between the N business bills, where N is a positive integer.

[0193] The trimming module 2002 is used to trim data for each business document in the document chain and generate a trimmed document corresponding to each business document.

[0194] The generation module 2003 is used to merge the N trimmed tickets corresponding to the N business tickets based on the chain relationship between the N business tickets, and generate the compressed ticket corresponding to the ticket chain.

[0195] Storage module 2004 is used to store compressed tickets, which are used to restore the ticket chain.

[0196] In one implementation, the generation module 2003, based on the chain relationship between N business documents, merges the N trimmed documents corresponding to the N business documents to generate compressed documents corresponding to the document chain, including:

[0197] According to the order of N business documents in the chain relationship, the N trimmed documents corresponding to the N business documents are merged in sequence to generate the original compressed document.

[0198] The original compressed invoice is supplemented with data to generate a compressed invoice corresponding to the invoice chain.

[0199] In this context, the order of the N cut documents in the original compressed document is consistent with the order of the N business documents in the chain relationship.

[0200] In one implementation, the generation module 2003 performs data supplementation processing on the original compressed document to generate compressed documents corresponding to N business documents, including:

[0201] The compression process uses the first private key to sign the original compressed ticket, generating the first signature of the original compressed ticket. The first private key is issued to the compression process by the key management process.

[0202] Obtain the first metadata information related to the first signature;

[0203] The original compressed ticket, the first signature, and the first metadata information are combined and encapsulated to generate a compressed ticket.

[0204] In one implementation, the business processing is carried out according to a business processing flow, which includes M business processing steps and N business tickets generated when the M business processing steps are executed, where M is a positive integer.

[0205] In this system, one business ticket corresponds to one business processing step, and the business ticket corresponding to one business processing step is used to indicate that the business processing step has been successfully executed. The chain relationship between N business tickets is determined according to the order in which the business processing steps corresponding to the N business tickets are executed.

[0206] In one implementation, any one of the N business tickets is the target business ticket, which contains a ticket header, a business dataset, and signature information.

[0207] The document header contains the hash value of the business dataset and the hash value of the previous business document among the N business documents;

[0208] The business dataset contains key business data generated when executing the business processing steps corresponding to the target business ticket.

[0209] The signature information includes a second signature and related second metadata information. The second signature is obtained by the issuer of the target business document by signing the document header and the business dataset.

[0210] In one implementation, the trimming module 2002 performs data trimming processing on each business document in the document chain to generate a trimmed document corresponding to each business document, including:

[0211] The header of the target business invoice is trimmed to obtain the intermediate trimmed invoice.

[0212] Identify key metadata from the second metadata information of the intermediate-cut tickets;

[0213] The second signature and other metadata except for key metadata in the signature information of the intermediate clipped ticket are clipped to obtain the clipped ticket corresponding to the target business ticket.

[0214] In one embodiment, the storage module 2004 stores compressed tickets in the following manner:

[0215] The compressed document is serialized to generate the serialized information corresponding to the compressed document.

[0216] Add compression tags to the serialized information and store the serialized information with compression tags in persistent storage.

[0217] In one embodiment, the above-mentioned ticket processing device 2000 further includes a recovery module 2005, which is used for:

[0218] In response to the recovery of the ticket chain, the recovery process is invoked to retrieve serialized information from persistent storage.

[0219] The serialized information is deserialized to obtain a compressed ticket;

[0220] The obtained compressed document is used to restore the document chain.

[0221] In one implementation, the compressed ticket includes an original compressed ticket and a first signature. The first signature is obtained by the compression process signing the original compressed ticket using a first private key. The original compressed ticket is obtained by merging N cropped tickets. The recovery module 2005 uses the obtained compressed ticket to recover the ticket chain, including:

[0222] The recovery process is invoked to obtain the first public key corresponding to the first private key. The first public key is issued to the recovery process by the key management process.

[0223] The first signature is verified using the first public key;

[0224] After the first signature is successfully verified, the original compressed document is used to restore the document chain.

[0225] In one implementation, any one of N business tickets is the target business ticket. The original compressed ticket contains the target trimmed ticket corresponding to the target business ticket. The target business ticket contains a ticket header, a business dataset, and signature information. The target trimmed ticket contains the business dataset and key metadata identified from the signature information. The recovery module 2005 recovers the ticket chain using the original compressed ticket, including:

[0226] Based on the business dataset in the target cropped invoice, reconstruct the invoice header of the target business invoice;

[0227] Obtain other metadata from the signature information besides the key metadata as supplementary metadata;

[0228] Based on the reconstructed ticket header, supplementary metadata, and target-tailored ticket, the target business ticket is restored;

[0229] Among them, the N recovered business tickets are used to form the recovered ticket chain.

[0230] In one implementation, the recovery module 2005 recovers the target business ticket based on the reconstructed ticket header, supplementary metadata, and the target trimmed ticket, including:

[0231] The recovery process is invoked to obtain the second private key of the issuer to which the target business ticket belongs. The second private key is issued to the recovery process by the key management process.

[0232] The second private key is used to sign the reconstructed ticket header and the business dataset in the target cropped ticket to generate a reconstructed signature for the target business ticket.

[0233] The reconstructed ticket header, supplementary metadata, reconstructed signature, and target cropped ticket are combined and encapsulated to obtain the recovered target business ticket.

[0234] In one implementation, the recovery module 2005 reconstructs the document header of the target business document based on the business dataset in the target cropped document, including:

[0235] Perform hash calculation on the business dataset in the target cropped ticket to obtain the hash value of the business dataset;

[0236] If the target business ticket is the first business ticket among N business tickets, then the hash value of the business dataset will be used as the reconstructed ticket header;

[0237] If the target business ticket is not the first business ticket among N business tickets, then obtain the hash value of the previous business ticket of the target business ticket that has been restored before the target business ticket, and use the hash value of the business dataset and the hash value of the previous business ticket as the reconstructed ticket header.

[0238] In one embodiment, the recovery module 2005 is further configured to:

[0239] The recovery process will report the intermediate data generated during the recovery of the ticket chain to the detection process.

[0240] The detection process is invoked to perform anomaly analysis on the intermediate data and generate analysis results for the intermediate data.

[0241] Visualize intermediate data and analysis results.

[0242] According to one embodiment of this application, Figure 3 The steps involved in the bill processing method shown can be... Figure 10 The various modules in the document processing apparatus 2000 shown are used to perform this operation. For example, Figure 3Step S101 shown can be performed by Figure 10 The acquisition module 2001 in the middle is used to execute, Figure 3 Step S102 shown can be performed by Figure 10 The trimming module 2002 in the middle is used to execute; Figure 3 Step S103 shown can be performed by Figure 10 The generation module 2003 in the middle is used to execute, Figure 3 Step S104 shown can be performed by Figure 10 The storage module 2004 in the middle is used to execute.

[0243] This application can obtain a chain of invoices generated during business processing. This chain of invoices can contain N business invoices, and the N business invoices can have a chain relationship, where N is a positive integer. It can also perform data trimming processing on each business invoice in the chain to generate a trimmed invoice corresponding to each business invoice. Furthermore, based on the chain relationship between the N business invoices, it can merge the N trimmed invoices corresponding to the N business invoices to generate a compressed invoice corresponding to the chain of invoices. Thus, the compressed invoice can be stored, and the compressed invoice can be used to recover the chain of invoices. Therefore, the method proposed in this application can form a bill chain from the various business documents (such as N business documents) generated during business processing. These business documents can have a chain-like relationship, which enables the association between them and provides traceability, thus ensuring the reliability of subsequent document storage. Furthermore, this application can compress the entire bill chain by performing data trimming on each business document to obtain a compressed bill corresponding to the entire bill chain. This compressed bill can then be stored to reduce the storage space occupied by the bills, thereby improving the utilization rate of storage space. Moreover, this compressed bill can be used to reconstruct the complete bill chain; therefore, even if the compressed bill is stored instead of the entire bill chain, it will not affect the subsequent use of the bill chain.

[0244] According to one embodiment of this application, Figure 10 The various modules in the document processing device 2000 shown can be individually or entirely combined into one or more units, or some of the units can be further divided into multiple functionally smaller sub-units to achieve the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can also be implemented by multiple units, or the function of multiple modules can be implemented by one unit. In other embodiments of this application, the document processing device 2000 may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0245] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0246] According to one embodiment of this application, a computer program capable of executing the steps involved in the corresponding methods shown in the various embodiments of this application can be run on a general-purpose computer device (which may include processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM)) to construct a system as described in the embodiments of this application. Figure 10 The document processing apparatus 2000 shown herein. The aforementioned computer program may be recorded on a computer-readable recording medium, and may be loaded into the aforementioned computer device via the computer-readable recording medium and run therein.

[0247] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 11 As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. In some embodiments, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 11 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0248] exist Figure 11In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0249] Obtain the chain of invoices generated during business processing. The chain of invoices contains N business invoices, and the N business invoices are linked together. N is a positive integer.

[0250] Each business document in the document chain is processed to trim the data, generating a trimmed document corresponding to each business document.

[0251] Based on the chain relationship between N business invoices, the N trimmed invoices corresponding to the N business invoices are merged to generate compressed invoices corresponding to the invoice chain.

[0252] Store compressed tickets; compressed tickets are used to restore the ticket chain.

[0253] In one implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0254] According to the order of N business documents in the chain relationship, the N trimmed documents corresponding to the N business documents are merged in sequence to generate the original compressed document.

[0255] The original compressed invoice is supplemented with data to generate a compressed invoice corresponding to the invoice chain.

[0256] In this context, the order of the N cut documents in the original compressed document is consistent with the order of the N business documents in the chain relationship.

[0257] In one implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0258] The compression process uses the first private key to sign the original compressed ticket, generating the first signature of the original compressed ticket. The first private key is issued to the compression process by the key management process.

[0259] Obtain the first metadata information related to the first signature;

[0260] The original compressed ticket, the first signature, and the first metadata information are combined and encapsulated to generate a compressed ticket.

[0261] In one implementation, the business processing is carried out according to a business processing flow, which includes M business processing steps and N business tickets generated when the M business processing steps are executed, where M is a positive integer.

[0262] In this system, one business ticket corresponds to one business processing step, and the business ticket corresponding to one business processing step is used to indicate that the business processing step has been successfully executed. The chain relationship between N business tickets is determined according to the order in which the business processing steps corresponding to the N business tickets are executed.

[0263] In one implementation, any one of the N business tickets is the target business ticket, which contains a ticket header, a business dataset, and signature information.

[0264] The document header contains the hash value of the business dataset and the hash value of the previous business document among the N business documents;

[0265] The business dataset contains key business data generated when executing the business processing steps corresponding to the target business ticket.

[0266] The signature information includes a second signature and related second metadata information. The second signature is obtained by the issuer of the target business document by signing the document header and the business dataset.

[0267] In one implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0268] The header of the target business invoice is trimmed to obtain the intermediate trimmed invoice.

[0269] Identify key metadata from the second metadata information of the intermediate-cut tickets;

[0270] The second signature and other metadata except for key metadata in the signature information of the intermediate clipped ticket are clipped to obtain the clipped ticket corresponding to the target business ticket.

[0271] In one implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0272] The compressed document is serialized to generate the serialized information corresponding to the compressed document.

[0273] Add compression tags to the serialized information and store the serialized information with compression tags in persistent storage.

[0274] In one implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0275] In response to the recovery of the ticket chain, the recovery process is invoked to retrieve serialized information from persistent storage.

[0276] The serialized information is deserialized to obtain a compressed ticket;

[0277] The obtained compressed document is used to restore the document chain.

[0278] In one implementation, the compressed ticket includes an original compressed ticket and a first signature. The first signature is obtained by the compression process signing the original compressed ticket using a first private key. The original compressed ticket is obtained by merging N cropped tickets. The processor 1001 can also be used to call a device control application stored in the memory 1005 to achieve:

[0279] The recovery process is invoked to obtain the first public key corresponding to the first private key. The first public key is issued to the recovery process by the key management process.

[0280] The first signature is verified using the first public key;

[0281] After the first signature is successfully verified, the original compressed document is used to restore the document chain.

[0282] In one implementation, any one of the N service tickets is the target service ticket. The original compressed ticket contains the target trimmed ticket corresponding to the target service ticket. The target service ticket contains a ticket header, a service dataset, and signature information. The target trimmed ticket contains the service dataset and key metadata identified from the signature information. The processor 1001 can also be used to call the device control application stored in the memory 1005 to achieve:

[0283] Based on the business dataset in the target cropped invoice, reconstruct the invoice header of the target business invoice;

[0284] Obtain other metadata from the signature information besides the key metadata as supplementary metadata;

[0285] Based on the reconstructed ticket header, supplementary metadata, and target-tailored ticket, the target business ticket is restored;

[0286] Among them, the N recovered business tickets are used to form the recovered ticket chain.

[0287] In one implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0288] The recovery process is invoked to obtain the second private key of the issuer to which the target business ticket belongs. The second private key is issued to the recovery process by the key management process.

[0289] The second private key is used to sign the reconstructed ticket header and the business dataset in the target cropped ticket to generate a reconstructed signature for the target business ticket.

[0290] The reconstructed ticket header, supplementary metadata, reconstructed signature, and target cropped ticket are combined and encapsulated to obtain the recovered target business ticket.

[0291] In one implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0292] Perform hash calculation on the business dataset in the target cropped ticket to obtain the hash value of the business dataset;

[0293] If the target business ticket is the first business ticket among N business tickets, then the hash value of the business dataset will be used as the reconstructed ticket header;

[0294] If the target business ticket is not the first business ticket among N business tickets, then obtain the hash value of the previous business ticket of the target business ticket that has been restored before the target business ticket, and use the hash value of the business dataset and the hash value of the previous business ticket as the reconstructed ticket header.

[0295] In one implementation, the processor 1001 can also be used to invoke a device control application stored in the memory 1005 to achieve:

[0296] The recovery process will report the intermediate data generated during the recovery of the ticket chain to the detection process.

[0297] The detection process is invoked to perform anomaly analysis on the intermediate data and generate analysis results for the intermediate data.

[0298] Visualize intermediate data and analysis results.

[0299] It should be understood that the computer device 1000 described in the embodiments of this application can execute the above-described ticket processing method in the various embodiments of this application, and can also execute the methods described above. Figure 10 The description of the aforementioned document processing apparatus 2000 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0300] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing a computer program. When a processor executes the computer program, it can perform the descriptions of the ticket processing methods in the various embodiments of this application; therefore, these descriptions will not be repeated here. Additionally, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer storage medium involved in this application, please refer to the descriptions of the method embodiments of this application.

[0301] As an example, the aforementioned computer program can be deployed and executed on a single computer device, or deployed and executed on multiple computer devices located in one location, or executed on multiple computer devices distributed across multiple locations and interconnected via a communication network. These multiple computer devices distributed across multiple locations and interconnected via a communication network can form a blockchain network.

[0302] The aforementioned computer-readable storage medium can be an internal storage unit of the computer device, such as a hard drive or memory. It can also be an external storage device, such as a plug-in hard drive, smart media card (SMC), secure digital card (SD) card, or flash card. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. This computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. It can also be used to temporarily store data that has been output or will be output.

[0303] This application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the document processing methods described in the embodiments of this application; therefore, these descriptions will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application.

[0304] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0305] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0306] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for processing invoices, characterized in that, The method includes: Obtain the chain of invoices generated during business processing, wherein the chain of invoices contains N business invoices, and the N business invoices are linked together, where N is a positive integer; Each business document in the document chain is processed to trim data, generating a trimmed document corresponding to each business document. Based on the chain relationship between the N business tickets, the N trimmed tickets corresponding to the N business tickets are merged to generate the compressed ticket corresponding to the ticket chain; The compressed ticket is stored and used to recover the ticket chain.

2. The method as described in claim 1, characterized in that, The step of merging the N trimmed tickets corresponding to the N business tickets based on the chain relationship between the N business tickets to generate the compressed ticket corresponding to the ticket chain includes: According to the order of the N business documents in the chain relationship, the N trimmed documents corresponding to the N business documents are merged in sequence to generate the original compressed document; The original compressed ticket is supplemented with data to generate the compressed ticket corresponding to the ticket chain; The order of the N trimmed tickets in the original compressed ticket is consistent with the order of the N business tickets in the chain relationship.

3. The method as described in claim 2, characterized in that, The step of performing data supplementation processing on the original compressed invoice to generate the compressed invoices corresponding to the N business invoices includes: The compression process is invoked to sign the original compressed ticket using a first private key, generating a first signature of the original compressed ticket. The first private key is issued to the compression process by the key management process. Obtain the first metadata information related to the first signature; The original compressed ticket, the first signature, and the first metadata information are combined and encapsulated to generate the compressed ticket.

4. The method as described in claim 1, characterized in that, The business processing procedure is carried out according to the business processing flow, which includes M business processing steps. The N business tickets are generated when the M business processing steps are executed, where M is a positive integer. Wherein, one business ticket corresponds to one business processing step, and a business ticket corresponding to one business processing step is used to indicate that the business processing step has been successfully executed. The chain relationship between the N business tickets is determined according to the order in which the business processing steps corresponding to the N business tickets are executed.

5. The method as described in claim 4, characterized in that, Any one of the N business tickets is the target business ticket, and the target business ticket contains a ticket header, a business dataset, and signature information; The ticket header contains the hash value of the business dataset and the hash value of the preceding business ticket of the target business ticket among the N business tickets; The business dataset includes key business data generated when executing the business processing steps corresponding to the target business ticket; The signature information includes a second signature and second metadata information related to the second signature. The second signature is obtained by the issuer of the target business ticket by signing the ticket header and the business dataset.

6. The method as described in claim 5, characterized in that, The step of performing data trimming processing on each business ticket in the ticket chain to generate a trimmed ticket corresponding to each business ticket includes: The header of the target business document is trimmed to obtain an intermediate trimmed document. Identify key metadata from the second metadata information of the intermediate cut-out ticket; The second signature and other metadata except the key metadata in the signature information of the intermediate clipped ticket are clipped to obtain the clipped ticket corresponding to the target business ticket.

7. The method as described in claim 1, characterized in that, The storage of the compressed ticket includes: The compressed ticket is serialized to generate serialized information corresponding to the compressed ticket; A compression tag is added to the serialized information, and the serialized information with the compression tag added is stored in persistent storage space.

8. The method as described in claim 7, characterized in that, The method further includes: In response to the recovery trigger of the ticket chain, the recovery process is invoked to retrieve the serialized information from the persistent storage space; The serialized information is deserialized to obtain the compressed ticket; The obtained compressed ticket is used to recover the ticket chain.

9. The method as described in claim 8, characterized in that, The compressed ticket includes an original compressed ticket and a first signature. The first signature is obtained by the compression process using a first private key to sign the original compressed ticket. The original compressed ticket is obtained by merging the N cropped tickets. The step of recovering the bill chain using the obtained compressed bill includes: The recovery process is invoked to obtain the first public key corresponding to the first private key, which is issued to the recovery process by the key management process. The first signature is verified using the first public key; After the first signature is successfully verified, the original compressed document is used to restore the document chain.

10. The method as described in claim 9, characterized in that, Any one of the N business tickets is a target business ticket. The original compressed ticket contains a target cropped ticket corresponding to the target business ticket. The target business ticket contains a ticket header, a business dataset, and signature information. The target cropped ticket contains the business dataset and key metadata identified from the signature information. The step of recovering the bill chain using the original compressed bill includes: Based on the business dataset in the target cropped ticket, reconstruct the ticket header of the target business ticket; Obtain other metadata from the signature information besides the key metadata as supplementary metadata; Based on the reconstructed ticket header, the supplementary metadata, and the target pruned ticket, the target business ticket is restored; The recovered N business tickets are used to form the recovered ticket chain.

11. The method as described in claim 10, characterized in that, The process of restoring the target business ticket based on the reconstructed ticket header, the supplementary metadata, and the target pruned ticket includes: The recovery process is invoked to obtain the second private key of the issuer to which the target business ticket belongs. The second private key is issued to the recovery process by the key management process. The second private key is used to sign the reconstructed ticket header and the business dataset in the target cropped ticket to generate a reconstructed signature for the target business ticket; The reconstructed ticket header, the supplementary metadata, the reconstructed signature, and the target cropped ticket are combined and encapsulated to obtain the recovered target business ticket.

12. The method as described in claim 10, characterized in that, The step of reconstructing the document header of the target business document based on the business dataset in the target cropped document includes: Perform a hash calculation on the business dataset in the target cropped ticket to obtain the hash value of the business dataset; If the target business ticket is the first business ticket among the N business tickets, then the hash value of the business dataset is used as the reconstructed ticket header; If the target business ticket is not the first business ticket among the N business tickets, then obtain the hash value of the previous business ticket of the target business ticket that has been restored before the target business ticket, and use the hash value of the business dataset and the hash value of the previous business ticket as the reconstructed ticket header.

13. The method as described in claim 8, characterized in that, The method further includes: The recovery process is invoked to report the intermediate data generated during the recovery of the ticket chain to the detection process. The detection process is invoked to perform anomaly analysis on the intermediate data, and analysis results for the intermediate data are generated. The intermediate data and analysis results are visualized.

14. A ticket processing device, characterized in that, The device includes: The acquisition module is used to acquire the bill chain generated during business processing. The bill chain contains N business bills, and the N business bills have a chain relationship, where N is a positive integer. The trimming module is used to perform data trimming processing on each business ticket in the ticket chain to generate a trimmed ticket corresponding to each business ticket. The generation module is used to merge the N trimmed tickets corresponding to the N business tickets based on the chain relationship between the N business tickets, and generate the compressed ticket corresponding to the ticket chain. A storage module is used to store the compressed tickets, which are used to restore the ticket chain.

15. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, the computer program being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-13.

16. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method according to any one of claims 1-13.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the steps of the method according to any one of claims 1-13.

Images