Methods, systems, devices, equipment, storage media, and program products for processing invoices.

Abstract

This application discloses a method, system, apparatus, device, storage medium, and program product for processing invoices, relating to the field of data processing technology. In response to a business activity, the method obtains element information of the business activity and verification logic from a verification node through a ticket issuing node; based on the element information and verification logic, a business invoice corresponding to the business activity is constructed through the ticket issuing node; the business invoice is signed by the ticket issuing node to obtain first signature data, and the business invoice and the first signature data are transmitted to the verification node; the first signature data is verified by the verification node, and upon successful verification, input verification parameters are obtained according to the verification logic; based on the verification parameters and verification logic, the element information is verified by the verification node to obtain a first verification result. This application can improve the flexibility and security of invoice verification.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a bill processing method, bill processing system, bill processing device, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] A bill is a certificate reflecting a business transaction, containing essential information about that transaction. This transaction can be of various types, such as a consumption transaction, in which case the essential information might include the identifier of the consumer and the amount spent. Bill verification aims to confirm that the business transaction represented by the bill has indeed occurred and successfully passed the verification logic, ensuring the validity of the transaction. In current verification technology, the issuer submits the essential information and verification logic to the blockchain virtual machine in the form of a smart contract. The verifier then calls the smart contract interface, passing in the verification parameters. However, in this verification method, the verification logic of the smart contract is immutable after deployment. Updating the verification logic requires redeploying a new smart contract, resulting in high overall verification costs. Summary of the Invention

[0003] This application provides a bill processing method, bill processing system, bill processing device, electronic device, computer-readable storage medium, and computer product, which can improve the flexibility and security of bill verification.

[0004] Firstly, the bill processing method provided in this application includes:

[0005] In response to the business actions that occur, obtain the element information of the business actions through the ticket issuing node, as well as the ticket verification logic from the ticket verification node;

[0006] Based on the element information and ticket verification logic, business tickets corresponding to business behaviors are constructed through the ticket issuance node;

[0007] The business ticket is signed by the ticket issuing node to obtain the first signature data, and the business ticket and the first signature data are then transmitted to the ticket verification node.

[0008] The first signature data is verified by the ticket verification node, and the input verification parameters are obtained according to the ticket verification logic after the verification is successful.

[0009] Based on the ticket verification parameters and logic, the ticket verification nodes verify the element information to obtain the first ticket verification result.

[0010] Secondly, the bill processing method provided in this application may also include:

[0011] Obtain the ticket verification logic and pass it to the ticket issuing node;

[0012] The business document and first signature data of the business behavior transmitted by the issuing node are obtained. The business document is constructed by the issuing node based on the element information of the business behavior and the verification logic. The first signature data is obtained by the issuing node signing the business document.

[0013] Verify the first signature data, and when the first signature data is successfully verified, obtain the input verification parameters according to the verification logic;

[0014] Based on the ticket verification parameters and logic, the element information is verified to obtain the first ticket verification result.

[0015] Thirdly, the bill processing system provided in this application includes a bill issuing node and a bill verification node, wherein,

[0016] The ticket issuing node is used to respond to the business behavior that occurs, obtain the element information of the business behavior, and obtain the ticket verification logic from the ticket verification node.

[0017] The ticket issuance node is also used to construct business tickets corresponding to business activities based on element information and ticket verification logic;

[0018] The ticket issuing node is also used to sign business tickets to obtain the first signature data, and to transmit the business ticket and the first signature data to the ticket verification node.

[0019] The ticket verification node is used to verify the first signature data and obtain the input verification parameters according to the ticket verification logic after successful verification.

[0020] The ticket verification node is also used to verify the element information according to the ticket verification parameters and ticket verification logic to obtain the first ticket verification result.

[0021] Optionally, in one embodiment, the ticket verification logic includes ticket verification logic text;

[0022] The ticket issuance node is used to convert the ticket verification logic text into a calculation expression, which includes operators, a first placeholder corresponding to the element information, and a second placeholder corresponding to the ticket verification parameters; and to construct a business ticket corresponding to the business behavior based on the element information and the calculation expression.

[0023] Optionally, in one embodiment, the ticket verification node is used to replace the first placeholder with element information, replace the second placeholder with ticket verification parameters, and perform calculations on the element information and ticket verification parameters according to the operator to obtain the calculation result; and obtain the first ticket verification result corresponding to the element information according to the calculation result.

[0024] Optionally, in one embodiment, the ticket verification node is used to call a pre-encapsulated ticket verification function with ticket verification parameters and element information as calling parameters, so as to replace the first placeholder with element information, replace the second placeholder with ticket verification parameters, and perform calculations on the element information and ticket verification parameters according to the operator to obtain the calculation result.

[0025] Optionally, in one embodiment, the ticket issuing node is used to determine the format verification strategy corresponding to the operation expression based on the expression type of the operation expression; to verify the format of the operation expression according to the format verification strategy; and if the format verification of the operation expression is successful, to construct a business ticket corresponding to the business behavior based on the element information and the operation expression.

[0026] Optionally, in one embodiment, the ticket processing system provided in this application further includes a downstream ticket verification node;

[0027] If the first verification result indicates that the verification of the element information is successful, the verification node is also used to obtain additional element information of the business behavior, as well as additional verification logic from the downstream verification node.

[0028] The ticket verification node is also used to construct additional business tickets corresponding to business activities based on additional element information and additional ticket verification logic;

[0029] The ticket verification node is also used to sign additional business tickets to obtain second signature data;

[0030] The ticket verification node is also used to transmit business tickets, supplementary business tickets, first signature data, and second signature data to downstream ticket verification nodes;

[0031] Downstream verification nodes are used to verify the first signature data and the second signature data, and when the verification is successful, they obtain the input verification parameters according to the verification logic, and obtain the input additional verification parameters according to the additional verification logic.

[0032] Downstream ticket verification nodes are also used to verify the element information based on the verification parameters and verification logic to obtain a second verification result.

[0033] Downstream ticket verification nodes are also used to verify additional element information based on additional ticket verification parameters and additional ticket verification logic to obtain a third ticket verification result.

[0034] Optionally, in one embodiment, the business behavior includes transaction behavior. If the second verification result indicates that the verification of the element information is successful, and the third verification result indicates that the verification of the additional element information is successful, the downstream verification node is also used to perform the account operation corresponding to the transaction behavior.

[0035] Optionally, in one embodiment, the ticket verification node is used to merge business tickets and supplementary business tickets to obtain a merged business ticket; and to attach the first signature data and the second signature data to the merged business ticket and transmit them together to the downstream ticket verification node.

[0036] Optionally, in one embodiment, the ticket verification node is further configured to provide a logical configuration interface, which includes a text input interface; acquiring natural language text received by the text input interface, and performing semantic recognition on the natural language text to obtain the ticket verification logical text; and transmitting the ticket verification logical text to the ticket issuing node.

[0037] Fourthly, the bill processing apparatus provided in this application includes:

[0038] The logic acquisition module is used to acquire the ticket verification logic and pass it to the ticket issuing node.

[0039] The bill acquisition module is used to acquire the business bill and first signature data of the business behavior transmitted by the bill issuing node. The business bill is constructed by the bill issuing node based on the element information of the business behavior and the bill verification logic, and the first signature data is obtained by the bill issuing node signing the business bill.

[0040] The parameter acquisition module is used to verify the first signature data and, when the first signature data is successfully verified, to acquire the input verification parameters according to the verification logic.

[0041] The ticket verification module is used to verify the element information according to the verification parameters and verification logic, and obtain the first verification result.

[0042] Optionally, in one embodiment, the business ticket includes an operational expression derived from the ticket verification logic. The operational expression includes an operator, a first placeholder corresponding to the element information, and a second placeholder corresponding to the ticket verification parameters. The ticket verification module is used to replace the first placeholder with the element information, replace the second placeholder with the ticket verification parameters, and perform operations on the element information and ticket verification parameters according to the operator to obtain the operation result; and obtain the first ticket verification result corresponding to the element information according to the operation result.

[0043] Optionally, in one embodiment, the ticket verification module is used to call a pre-encapsulated ticket verification function with the ticket verification parameters and element information as calling parameters, so as to replace the first placeholder with the element information, replace the second placeholder with the ticket verification parameters, and perform calculations on the element information and ticket verification parameters according to the operators to obtain the calculation results.

[0044] Optionally, in one embodiment, the bill processing apparatus provided by this application further includes:

[0045] The second data acquisition module is used to acquire additional element information of business behavior if the first ticket verification result indicates that the ticket verification of element information is successful; and to acquire additional ticket verification logic from downstream ticket verification nodes.

[0046] The second bill construction module is used to construct additional business bills corresponding to business activities based on additional element information and additional bill verification logic.

[0047] The second document signature module is used to sign additional business documents to obtain second signature data;

[0048] The second document transmission module is used to transmit business documents, supplementary business documents, first signature data, and second signature data to downstream document verification nodes. After the downstream document verification node successfully verifies the first signature data, it uses the document verification logic to provide verification parameters to verify the element information and obtain the second verification result. After the downstream document verification node successfully verifies the second signature data, it uses the supplementary verification logic to provide supplementary verification parameters to verify the supplementary element information and obtain the third verification result.

[0049] Optionally, in one embodiment, the second ticket construction module is used to convert the additional ticket verification logic into an additional operation expression, the additional operation expression including an additional operator, a third placeholder corresponding to the additional element information, and a fourth placeholder corresponding to the additional ticket verification parameters; and to construct an additional business ticket corresponding to the business behavior based on the additional element information and the additional operation expression; wherein, the additional operation expression is used by the downstream ticket verification node to obtain the third ticket verification result based on the operation result obtained by the additional operator after replacing the third placeholder with the additional element information and the fourth placeholder with the additional ticket verification parameters.

[0050] Optionally, in one embodiment, the second ticket transmission module is used to merge business tickets and supplementary business tickets to obtain a merged business ticket; and to attach the first signature data and the second signature data to the merged business ticket and transmit them together to the downstream ticket verification node.

[0051] Optionally, in one embodiment, the ticket processing device provided in this application further includes a logic configuration module for providing a logic configuration interface, the logic configuration interface including a text input interface; acquiring natural language text received by the text input interface, and performing semantic recognition on the natural language text to obtain ticket verification logic text.

[0052] Fifthly, the electronic device provided in this application includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program in the memory when the electronic device is configured as a ticket issuing node to implement the steps in the ticket processing method suitable for a ticket verification node provided in this application.

[0053] Sixthly, the computer-readable storage medium provided in this application stores a computer program adapted for processor execution to implement the steps in the ticket processing method suitable for ticket verification nodes provided in this application.

[0054] Seventhly, the computer program product provided in this application includes a computer program adapted for processor execution to implement the steps in the ticket processing method suitable for ticket verification nodes provided in this application.

[0055] The bill processing solution provided in this application, on the one hand, obtains the element information of the business behavior and the verification logic from the verification node through the bill issuing node. Based on the obtained element information and verification logic, a business bill corresponding to the business behavior is constructed, and the business bill is signed to obtain first signature data. Finally, the business bill and the first signature data are transmitted to the verification node. On the other hand, the verification node verifies the first signature data. If the verification is successful, it determines that the business bill has not been tampered with. Further verification is performed on the element information based on the verification parameters provided by the verification logic to obtain the first verification result. Thus, by directly carrying the verification logic into the business bill, the verification logic can be flexibly designed according to verification requirements. When the verification logic needs to be changed, only the modified verification logic needs to be carried into the business bill, without any additional operations. Furthermore, signature verification is performed on the business bill carrying the verification logic, which can prevent the verification logic from being tampered with during the transmission of the business bill. In summary, the bill processing solution provided in this application can improve the flexibility and security of bill verification. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0057] Figure 1 This is a schematic diagram illustrating an application scenario of the invoice processing method provided in the embodiments of this application;

[0058] Figure 2 This is a schematic diagram of a bill processing method provided in an embodiment of this application;

[0059] Figure 3 This is a structural example diagram of a business document in an embodiment of this application;

[0060] Figure 4 This is an example diagram illustrating the verification of a transaction and the execution of an account update in this application embodiment;

[0061] Figure 5 This is an example diagram of the logical configuration interface in the embodiments of this application;

[0062] Figure 6 This is another schematic diagram of the bill processing method provided in the embodiments of this application;

[0063] Figure 7 This is an example diagram of the parameter input interface in an embodiment of this application;

[0064] Figure 8 This is a schematic diagram of the structure of the invoice processing system provided in the embodiments of this application;

[0065] Figure 9 This is a schematic diagram of the structure of the bill processing device provided in the embodiments of this application;

[0066] Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0067] It should be noted that the principles of this application are illustrated by example in a suitable computing environment. The following description is based on the specific embodiments of this application that are illustrated, and should not be regarded as limiting other specific embodiments not detailed herein.

[0068] In the following description of this application, "some embodiments" are referred to, which describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subset of all possible embodiments, and may be combined with each other without conflict.

[0069] In the following description of this application, the terms "first, second, third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0070] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0071] Considering the high cost of ticket verification in related technologies, this application provides a ticket processing method, a ticket processing device, an electronic device, a computer-readable storage medium, and a computer program product to reduce the cost of ticket verification. The ticket processing method can be executed by the ticket processing device or by an electronic device integrating the ticket processing device.

[0072] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below 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.

[0073] Please refer to Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of the bill processing method provided in this application. In a pair of verification relationships, there are an issuing node and a verification node. The issuing node is the party that generates the bill, and the verification node is the party that verifies the bill generated by the issuing node. In practical applications, the issuing node and the verification node can be business nodes with business relationships within a business system. For example, the issuing node can be a node in a transaction system used for billing transaction behavior, and the verification node can be a node in a transaction system that performs accounting operations. On one hand, the verification node obtains the element information of the occurring transaction behavior (business behavior) (such as the object identifier of the transaction behavior, i.e., the object identifier of the transaction object executing the transaction behavior, the transaction amount, etc.) and the verification logic from the verification node. Then, based on the obtained element information and verification logic, it constructs a business bill corresponding to the transaction behavior. Next, it signs the business bill using the first private key of the issuing node to obtain first signature data. Finally, it transmits the business bill and the first signature data to the verification node; for example, the first signature data can be appended to the business bill and transmitted together to the verification node. On the other hand, after receiving the business ticket and the first signature data from the ticket issuing node, the ticket verification node uses the first public key of the ticket issuing node to verify the first signature data. If the verification is successful, the node provides verification parameters according to the verification logic to verify the element information and obtain the first verification result. The node then determines the validity of the transaction based on the first verification result. If the transaction is determined to be valid, the corresponding transaction operation can be executed. The first public key and the first private key can be generated and maintained by the key management system.

[0074] It should be noted that the application scenarios described above are merely examples to more clearly illustrate the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of application scenarios and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0075] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating the bill processing method provided in this application, such as... Figure 2As shown, the flow of this invoice processing method can be as follows:

[0076] In 110, in response to the business behavior that occurs, the element information of the business behavior is obtained through the ticket issuing node, as well as the ticket verification logic from the ticket verification node.

[0077] A business system is a software system used to support and manage various business activities. Common business systems include transaction systems (such as e-commerce platforms, stock trading systems, etc.), customer relationship management systems, enterprise resource planning systems, and so on.

[0078] Element information refers to the core data or key information necessary for completing business activities within a business system. This element information is typically used to support the execution of business logic, data validation, decision-making, and interaction with other systems or modules. Depending on the business system, element information can include the following types:

[0079] Identity information, such as the object identifier, object name, contact information, etc. of the object of the action;

[0080] Transaction information, such as transaction amount, transaction date, transaction type (e.g., purchase, sale, transfer), etc.;

[0081] Product information, such as product name, product number, product description, etc.;

[0082] Geographic location information, such as address, postal code, etc.;

[0083] Status information, such as order status (e.g., pending shipment, shipped, completed), payment status (e.g., unpaid, paid, payment failed), etc.

[0084] In this embodiment of the application, the ticket issuing node and the ticket verification node can be business nodes that have business relationships in the business system. For example, the ticket issuing node can be a node in the transaction system used for the invoicing of transaction behavior, and the ticket verification node can be a node in the transaction system that performs the accounting operation.

[0085] The issuing node can respond to business actions occurring in the business system and obtain the essential information of those actions. For example, the issuing node can access an access service via remote invocation. When it finds a business action occurring in the business system through the access service, it can further obtain the essential information of that business action through the access service.

[0086] For example, taking a certain transaction system as an example, when a transaction object (i.e., a behavior object) places an order to purchase a product in the transaction system, a transaction behavior (i.e., a business behavior) is generated. The issuing node can access the access service of the transaction system through remote calls, query the transaction behavior that occurred in the transaction system through the access service, and further obtain the object identifier and transaction amount of the transaction behavior as the element information of the transaction behavior through the access service.

[0087] In this application embodiment, the data format of the acquired element information is not specifically limited, and can be configured by those skilled in the art according to actual needs. For example, please refer to Table 1 below, which is a schematic diagram of the data structure of element information:

[0088]

[0089] Table 1

[0090] As shown in Table 1 above, element information can be in the form of key-value pairs [Key→Value]. For example, the element information obtained by the ticket issuing node includes [Object Identifier→1] and [Transaction Amount→100], where [Object Identifier→1] indicates that the object identifier is 1, and [Transaction Amount→100] indicates that the transaction amount is 100.

[0091] It should be noted that after obtaining the element information of the business behavior that has occurred, the ticket issuing node verifies the format of the obtained element information, that is, verifies whether the format of the element information meets the format requirements. Only after the format verification of the element information is successful will subsequent processing be carried out to ensure the normal execution of subsequent processing.

[0092] In addition, the issuing node also receives the verification logic from the verification node. This verification logic can be generated by the verification node based on actual verification needs. Verification logic consists of a series of conditions and rules used to verify whether a ticket conforms to business rules. For example, taking a transaction in a transaction system as an example, verification logic can be used to verify whether the object identifier of the transaction exists and is valid, whether the transaction amount is within the allowed range, whether the transaction date is within the valid range, whether the transaction type is allowed (e.g., only purchases are allowed, refunds are not allowed), whether the account balance is sufficient, whether the order status is valid, and so on.

[0093] It should be noted that the form of the ticket verification logic in this application embodiment is not limited. For example, it can be in the form of natural language text. Natural language is the language used by humans in daily life. It is different from artificially designed programming languages ​​or formal languages. Natural language has the characteristics of complexity, variability and context dependence. For example, the ticket verification logic obtained from the ticket verification node is in the form of natural language text: Is the object identifier of the transaction behavior ?, is the transaction amount greater than ?, and is the transaction date earlier than ?, where ? are placeholders for the ticket verification parameters, and the specific parameter content is provided by the ticket verification node during ticket verification.

[0094] In 120, based on the element information and ticket verification logic, business tickets corresponding to business behaviors are constructed through the ticket issuance node.

[0095] As mentioned above, after obtaining the element information of the business behavior that occurred and the verification logic from the verification node, the issuing node constructs a business ticket corresponding to the business behavior according to the obtained element information and verification logic and the configured ticket format. There are no specific restrictions on the configuration of the ticket format here.

[0096] For example, please refer to Figure 3 Business invoices can include basic information fields, element information fields, verification logic fields, and supplementary information fields. The basic information fields are used to populate the invoice's identifier (generated by an identifier generator to uniquely identify the business invoice), creation date (the date the business invoice was created), and expiration date (the date determined based on the creation date and validity period of the business invoice, where the validity period is determined according to actual needs). The element information fields are used to populate element information. The verification logic fields are used to populate verification logic. The supplementary information fields are used to populate supplementary information (such as remarks, attachments (such as transaction orders for the transaction), etc.). Supplementary information is filled in as needed, or it can be omitted. Figure 3 The document format shown illustrates that when constructing a business document, the issuing node generates a unique identifier as the document identifier using an identifier generator, determines the current date of the construction operation as the document construction date, and determines the expiration date based on the configured document validity period. The document identifier, construction date, and expiration date are then filled into the basic information field of the business document. The issuing node then fills the obtained element information into the element information field of the business document. Finally, the issuing node fills the obtained verification logic into the verification logic field of the business document. The issuing node leaves the additional information field blank. Thus, the issuing node constructs the business document corresponding to the business activity based on the obtained element information and verification logic.

[0097] In step 130, the business ticket is signed by the ticket issuing node to obtain the first signature data, and the business ticket and the first signature data are transmitted to the ticket verification node.

[0098] In this embodiment of the application, a first public-private key pair corresponding to the issuing node is pre-generated. This first public-private key pair includes a first private key and a first public key. The first public-private key pair can be generated by the issuing node using a configured key generation algorithm, or it can be generated by a third-party key management system.

[0099] For example, the issuing node uses a configured key generation algorithm to generate the first public-private key pair, stores the first private key in the first public-private key pair locally (it can be stored in ciphertext or plaintext), and transmits the first public key in the first public-private key pair to the verification node; or, for another example, the issuing node can generate the first public-private key pair through a third-party key management system, and query the first private key in the first public-private key pair from the key management system when needed, while the verification node can query the first public key in the first public-private key pair from the key management system.

[0100] As shown above, after constructing the business ticket corresponding to the business behavior based on the obtained element information and ticket verification logic, the ticket issuing node further signs the business ticket using its own first private key and records the obtained signature data as the first signature data.

[0101] For example, the issuing node can use a configured hash algorithm (also known as a hashing algorithm, such as SHA-256) to perform a hash operation on the business ticket, obtaining a fixed-length hash value. The hash value ensures the integrity of the business ticket; any modification to the business ticket will result in a change to the hash value. The issuing node then uses its own first private key to encrypt the previously obtained hash value, using the resulting ciphertext hash value as signature data, which is the first signature data. The first private key is owned by the issuing node, ensuring the uniqueness and security of the first signature data.

[0102] After obtaining the first signature data by signing the business ticket, the ticket issuing node further transmits the business ticket and the first signature data to the ticket verification node according to the configured data transmission strategy. There are no specific restrictions on the configuration of the data transmission strategy here.

[0103] For example, the data transmission strategy can be configured as follows: the business ticket and the first signature data are transmitted to the ticket verification node separately. Alternatively, the data transmission strategy can be configured as follows: the first signature data is appended to the business ticket and transmitted together to the ticket verification node.

[0104] It should be noted that, to improve the transmission efficiency of business documents, they can be serialized before transmission. Serialization refers to the process of converting the data structure of a business document into a format that can be transmitted or stored over a network (such as byte streams, JSON, XML, Protocol Buffers, etc.).

[0105] In step 140, the first signature data is verified by the ticket verification node, and the input verification parameters are obtained according to the ticket verification logic after successful verification.

[0106] After receiving the business ticket and first signature data from the issuing node, the verification node uses the first public key corresponding to the issuing node to verify the first signature data. If the verification is successful, it means that the business ticket has not been tampered with. The verification node then provides verification parameters based on the verification logic in the business ticket to verify the element information in the business ticket. If the verification fails, it means that the business ticket has been tampered with during transmission. In this case, the tampered business ticket can be discarded directly, and the issuing node can be requested to retransmit the business ticket.

[0107] In one example, taking the first signature data obtained by the issuing node using a hash algorithm to perform a hash operation on the business ticket to obtain a hash value, and then encrypting it using the first private key, the verification node can complete the verification of the first signature data in the following manner:

[0108] The verification node uses the first public key corresponding to the issuing node to decrypt the first signature data, and decrypts the hash value obtained by the issuing node using a hash algorithm. In addition, the same hash algorithm as the issuing node is used to perform a hash operation on the business ticket. If the hash value obtained at this time is the same as the hash value obtained by the issuing node, the signature verification is successful; otherwise, the signature verification fails.

[0109] In step 150, based on the ticket verification parameters and logic, the element information is verified through the ticket verification node to obtain the first ticket verification result.

[0110] Ticket verification involves substituting the element information and verification parameters into the ticket verification logic to check if the logic is valid. For example, taking a business transaction as an example, the ticket verification logic, expressed in natural language text, is: Is the object identifier of the transaction a ?, where "?" represents a placeholder for the verification parameter, which is the expected object identifier of the transaction. Assuming the verification parameter provided by the verification node is [object identifier → 1], if the value of the object identifier in the element information carried in the business ticket is 1, the ticket verification logic is valid, and the verification of this element information is successful, resulting in the first verification result indicating successful verification. If the value of the object identifier in the element information carried in the business ticket is not 1, the ticket verification logic is invalid, and the verification of this element information fails, resulting in the first verification result indicating failed verification. As another example, continuing to use a business transaction as an example, the ticket verification logic, expressed in natural language text, is: Is the transaction amount of the transaction greater than ? In this context, "?" represents a placeholder for the verification parameter, which is the expected transaction amount. Assuming the verification parameter provided by the verification node is [transaction amount → 200], if the transaction amount in the element information carried in the business ticket is greater than 200, the verification logic is valid, and the verification of this element information is successful, resulting in the first verification result indicating successful verification. If the transaction amount in the element information carried in the business ticket is less than or equal to 200, the verification logic is invalid, and the verification of this element information fails, resulting in the first verification result indicating failed verification.

[0111] In this embodiment, after verifying the business documents from the issuing node and obtaining the first verification result, the verification node can further execute business operations corresponding to the business behavior as needed. For example, taking the verification node as the transaction processing node in the transaction system, once the verification node has completed the verification of the business documents for the transaction behavior generated by the issuing node, and the first verification result indicates successful verification, it can then execute the transaction processing operation corresponding to that transaction behavior.

[0112] Optionally, in one embodiment, to improve the efficiency of business ticket verification, the verification logic is expressed as a computational expression for constructing the business ticket. The verification logic includes verification logic text. Based on the element information and the verification logic, a business ticket corresponding to the business behavior is constructed through the ticket issuing node, including:

[0113] The ticket verification logic text is converted into a computational expression through the ticket issuance node. The computational expression includes operators, a first placeholder corresponding to the element information, and a second placeholder corresponding to the ticket verification parameters.

[0114] Based on the element information and calculation expression, business tickets corresponding to business behaviors are constructed through the ticket issuance node.

[0115] An operational expression is a fundamental concept in mathematics and computer science, used to represent a sequence of symbols that perform various operations on data. Operational expressions can include elements such as constants, variables, operators, and function calls. Through operational expressions, data can be calculated, compared, and subjected to logical processing.

[0116] In this embodiment of the application, the ticket verification logic is in the form of natural language text, including ticket verification logic text. When constructing a business ticket, the ticket issuing node first converts the ticket verification logic into a corresponding operation expression, and then constructs a business ticket corresponding to the business behavior based on the element information and the operation expression. The operation expression includes an operator, a placeholder corresponding to the element information (denoted as the first placeholder), and a placeholder corresponding to the ticket verification parameters (denoted as the second placeholder).

[0117] Please refer to Table 2 below. Table 2 is an example table of operators in the embodiments of this application, in which operators are divided into arithmetic operators, relational operators, set operators, and logical operators, and the uses of some operators are shown:

[0118]

[0119]

[0120] Table 2

[0121] It should be noted that the embodiments of this application do not impose specific restrictions on the conversion method for transforming ticket verification logic into corresponding operational expressions. It can be rule-based or AI-based. For example, supervised model training can be performed based on ticket verification logic samples in natural language text form and corresponding operational expression labels. For instance, a transformer network can be used as the base network to build a regression model. Supervised model training can then be performed on the constructed regression model to obtain a logic conversion model for converting ticket verification logic in natural language text form into corresponding operational expressions. This logic conversion model can then be used to implement the conversion from ticket verification logic to operational expressions.

[0122] For example, assuming the ticket verification logic text is: Is the object identifier of the transaction behavior ?, the ticket issuing node can convert this ticket verification logic into the corresponding operation expression: [Key] == ?, where Key is the first placeholder corresponding to the element information "object identifier", and ? is the second placeholder corresponding to the ticket verification parameter (in this case, the expected object identifier).

[0123] For example, suppose the ticket verification logic text is: The transaction amount of the transaction behavior is greater than?, then the ticket issuing node can convert the ticket verification logic into the corresponding operation expression: [Key]>?, where Key is the first placeholder corresponding to the element information "transaction amount", and ? is the second placeholder corresponding to the ticket verification parameter (in this case, the expected transaction amount).

[0124] Understandably, computational expressions are more suitable for computer processing than natural language text, and can therefore complete ticket verification more efficiently.

[0125] In this embodiment of the application, based on the ticket verification parameters and ticket verification logic, the element information is verified through the ticket verification node to obtain the first ticket verification result, including:

[0126] The first placeholder is replaced with element information and the second placeholder is replaced with ticket verification parameters through the ticket verification node. The element information and ticket verification parameters are then processed according to the operators to obtain the calculation results.

[0127] Based on the calculation results, the first ticket verification result corresponding to the element information is obtained through the ticket verification node.

[0128] In this embodiment of the application, for business tickets whose ticket verification logic adopts the form of an arithmetic expression, when the business ticket is verified by the ticket verification node, the element information encapsulated in the business ticket and the arithmetic expression used to represent the ticket verification logic are parsed out. Then, the first placeholder of the arithmetic expression is replaced with the element information, the second placeholder of the arithmetic expression is replaced with the input ticket verification parameters, and the element information and ticket verification parameters are calculated according to the operators of the arithmetic expression to obtain the calculation result. Finally, the first ticket verification result corresponding to the element information is obtained based on the calculation result.

[0129] For example, when the operator in the expression is an arithmetic operator, the result of the arithmetic operation performed according to the arithmetic operator is the first ticket verification result, and the ticket verification is considered successful.

[0130] When the operators in the operation expression are relational operators, set operators, or logical operators, after replacing the first placeholder of the operation expression with element information and the second placeholder of the operation expression with the ticket verification parameter, if the operation result of the operation expression on the element information and the ticket verification parameter indicates that the operation expression is true, then the first ticket verification result indicating successful ticket verification is obtained; if the operation result of the operation expression on the element information and the ticket verification parameter indicates that the operation expression is false, then the first ticket verification result indicating failed ticket verification is obtained.

[0131] For example, suppose the expression representing the ticket verification logic is: [Key] == ?, where Key is the first placeholder corresponding to the element information "object identifier", and ? is the second placeholder corresponding to the verification parameter (in this case, the expected object identifier). If the value of the object identifier in the element information is 1, and the value of the input verification parameter—that is, the expected object identifier—is also 1, then the ticket verification node substitutes the element information and the verification parameter into the expression: 1 == 1. Obviously, this expression is true, and the ticket verification node successfully verifies the element information. Suppose the value of the input verification parameter—that is, the expected object identifier—is not 1, for example, it is 2. The ticket verification node substitutes the element information and the verification parameter into the expression: 1 == 2. Obviously, this expression is false, and the ticket verification node fails to verify the element information.

[0132] For example, suppose the expression representing the ticket verification logic is: [Key]>?, where Key is the first placeholder corresponding to the element information "transaction amount", and ? is the second placeholder corresponding to the verification parameter (in this case, the expected transaction amount). If the transaction amount in the element information is 100, and the input verification parameter—that is, the expected transaction amount—is 50, the ticket verification node substitutes the element information and the verification parameter into the expression: 100>50. Obviously, this expression is true, and the ticket verification node successfully verifies the element information. Suppose the input verification parameter—that is, the expected transaction amount—is greater than or equal to 100, for example, 200. The ticket verification node substitutes the element information and the verification parameter into the expression: 100>200. Obviously, this expression is false, and the ticket verification node fails to verify the element information.

[0133] Optionally, in one embodiment, the process of replacing the first placeholder with element information and the second placeholder with ticket verification parameters through the ticket verification node, and performing calculations on the element information and ticket verification parameters according to operators to obtain the calculation result includes:

[0134] The ticket verification node calls the pre-encapsulated ticket verification function using ticket verification parameters and feature information as calling parameters. The ticket verification function replaces the first placeholder with feature information, the second placeholder with ticket verification parameters, and performs calculations on the feature information and ticket verification parameters according to operators to obtain the calculation results.

[0135] In this embodiment, a ticket verification function for executing arithmetic expressions is pre-encapsulated. No restrictions are placed on the coding language or specific code content of this ticket verification function; those skilled in the art can determine its suitability based on actual needs.

[0136] When the ticket verification node calls the ticket verification function using the input ticket verification parameters and the element information in the business ticket as calling parameters, the ticket verification function performs the following operations:

[0137] The first placeholder in the operational expression is replaced with element information, and the second placeholder is replaced with ticket verification parameters. The operational expressions are then used to perform calculations on the element information and ticket verification parameters to obtain the result. Accordingly, based on the calculation result obtained by the ticket verification function, the ticket verification node can obtain the first ticket verification result corresponding to the element information. For details on how to obtain the first ticket verification result from the operational expression, please refer to the relevant descriptions in the above embodiments; they will not be repeated here.

[0138] As shown above, by encapsulating the ticket verification operation based on computational expressions into a ticket verification function for ticket verification nodes to call and execute, ticket verification efficiency can be further improved.

[0139] Optionally, in one embodiment, based on element information and computational expressions, a business ticket corresponding to the business behavior is constructed through the ticket issuing node, including:

[0140] Based on the expression type of the operation expression, the format verification strategy corresponding to the operation expression is determined by the ticket issuing node;

[0141] According to the format validation strategy, the format of the operation expression is validated by the ticket issuing node;

[0142] If the format of the operation expression is successfully validated, a business ticket corresponding to the business behavior is constructed through the ticket issuing node based on the element information and the operation expression.

[0143] It is understandable that, depending on the type of the operational expression, the operational expression should conform to a specific expression format. To ensure that the converted operational expression conforms to the required expression format, thereby enabling the constructed business invoice to perform the verification function correctly, this application embodiment sets corresponding format verification strategies for different expression types. For an expression type, the format verification strategy corresponding to that expression type describes the expression format that the expression type should conform to. For example, taking the operators shown in Table 2 as an example, the expression types are divided as follows: unary expression (an expression containing only one operator, such as [Key]>?), multivariate expression (containing at least two operators, such as [Key1]+[Key2]=?), set expression (an expression that determines whether an element is in an unordered and non-repeating set of elements, such as ?in([Key1]、[Key2]……[KeyN]))), and logical expression (an expression that performs Boolean operations based on logical operators, such as [Key1]>?and[Key2]<?). Correspondingly, format verification strategies are set for unary expressions, multivariate expressions, set expressions, and logical expressions.

[0144] In this embodiment, after the ticket issuing node converts the ticket verification logic into an operational expression, it does not directly construct the business ticket based on the element information and the operational expression. Instead, it first identifies the expression type of the converted operational expression, then determines the format verification strategy corresponding to the expression type, and further verifies the format of the converted operational expression according to the determined format verification strategy to verify whether the format of the operational expression conforms to the expression format that its expression type should conform to. If the format verification of the operational expression is successful, the business ticket corresponding to the business behavior is constructed based on the element information and the operational expression, that is, the corresponding basic information is generated, the basic information is filled into the basic information field, the element information is filled into the element information field, and the operational expression is filled into the ticket verification logic field. For details, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0145] Optionally, in one embodiment, after verifying the element information through the ticket verification node according to the ticket verification parameters and ticket verification logic to obtain the first ticket verification result, the method further includes:

[0146] If the first ticket verification result indicates that the verification of the element information is successful, then the additional element information of the business behavior is obtained through the ticket verification node, as well as the additional ticket verification logic from the downstream ticket verification node.

[0147] Based on the additional information and additional verification logic, additional business tickets corresponding to business behaviors are constructed through verification nodes.

[0148] The additional business tickets are signed by the ticket verification node to obtain the second signature data;

[0149] The business ticket, supplementary business ticket, first signature data, and second signature data are transmitted to the downstream ticket verification node through the ticket verification node.

[0150] As mentioned above, in different verification relationships, the verification node can be the issuing node, and the issuing node can also be the verification node. In this embodiment, the verification node can also construct additional business tickets according to the verification requirements of downstream verification nodes.

[0151] In this embodiment, if the first verification result indicates successful verification of the element information, the verification node obtains additional element information of the business behavior corresponding to the above business ticket. Here, the additional element information is relative to the original element information. For example, taking a certain transaction behavior as an example, the verification of this transaction behavior can be divided into two verification stages. In the first verification stage, the issuing node obtains the object identifier of the behavior object of the transaction behavior as element information to construct a business ticket, and then verifies the object identifier. In the second verification stage, when the verification node successfully verifies the business ticket, it obtains the transaction amount of the transaction behavior. Since this transaction amount is additional compared to the original element information - object identifier, the transaction amount obtained at this time is used as additional element information to construct a new business ticket, and then the transaction amount is verified. It can be understood that, according to actual needs, the verification of a business behavior can be divided into more than two verification stages.

[0152] The ticket verification node also obtains the verification logic corresponding to the additional element information from the downstream ticket verification node, denoted as the additional ticket verification logic. This additional ticket verification logic can be generated by the downstream ticket verification node according to the actual ticket verification needs. There are no restrictions on the form of the additional ticket verification logic here; for example, it can be in the form of natural language text.

[0153] After obtaining additional information about the business activity and the verification logic from the downstream verification nodes, the verification node constructs a new business document corresponding to the business activity according to the same document format as the above business documents, based on the obtained additional information and additional verification logic. This document is called an additional business document.

[0154] In this embodiment, a second public-private key pair corresponding to the ticket verification node is pre-generated. This second public-private key pair includes a second private key and a second public key. The second public-private key pair can be generated by the ticket verification node using a configured key generation algorithm, or it can be generated by a third-party key management system. As described above, after constructing an additional business ticket corresponding to the occurred business behavior based on the obtained additional element information and additional ticket verification logic, the ticket verification node further signs the additional business ticket using its second private key and records the resulting signature data as the second signature data.

[0155] For example, a ticket verification node uses a configured key generation algorithm to generate a second public-private key pair, stores the second private key locally (either in encrypted or plaintext), and transmits the second public key to downstream ticket verification nodes. Alternatively, a ticket verification node can generate a second public-private key pair through a third-party key management system and retrieve the second private key from the system when needed, while downstream ticket verification nodes can retrieve the second public key from the same system.

[0156] According to the configured data transmission strategy, the ticket verification node transmits the business ticket, the supplementary business ticket, the first signature data and the second signature data to the downstream ticket verification node. There are no specific restrictions on the configuration of the data transmission strategy here.

[0157] It is understandable that for the above business invoices, the verification node is the node that verifies the invoice, while for additional business invoices, the verification node is the node that issues the invoice.

[0158] Optionally, in one embodiment, after the ticket verification node transmits the business ticket, supplementary business ticket, first signature data, and second signature data to the downstream ticket verification node, the method further includes:

[0159] The first signature data and the second signature data are verified by the downstream verification nodes. When the verification is successful, the input verification parameters are obtained according to the verification logic, and the input additional verification parameters are obtained according to the additional verification logic.

[0160] Based on the ticket verification parameters and logic, the element information is verified through the downstream ticket verification nodes to obtain the second ticket verification result.

[0161] Based on the additional ticket verification parameters and logic, the additional element information is verified by the downstream ticket verification nodes to obtain the third ticket verification result.

[0162] After obtaining the business ticket, the appended business ticket, the first signature data, and the second signature data, the downstream verification node uses the first public key corresponding to the issuing node to verify the first signature data. If the verification is successful, it indicates that the business ticket has not been tampered with. Further verification parameters are provided based on the verification logic in the business ticket to verify the element information in the business ticket, resulting in a second verification result. If the verification fails, it indicates that the business ticket has been tampered with during transmission. In this case, the tampered business ticket can be discarded directly, and the verification node is requested to retransmit the business ticket, the appended business ticket, the first signature data, and the second signature data. The specific verification process performed by the downstream verification node is not detailed here; please refer to the verification process of the verification node in the above embodiment for details.

[0163] For the supplementary business ticket and second signature data, the downstream verification node uses the second public key corresponding to the verification node to verify the second signature data. If the verification is successful, it indicates that the supplementary business ticket has not been tampered with. Further, based on the supplementary verification logic in the supplementary business ticket, supplementary verification parameters are provided to verify the supplementary element information in the supplementary business ticket, resulting in a third verification result. If the verification fails, it indicates that the supplementary business ticket has been tampered with during transmission. In this case, the tampered supplementary business ticket can be discarded directly, and the verification node is requested to retransmit the business ticket, supplementary business ticket, first signature data, and second signature data. The specific verification process performed by the downstream verification node is not detailed here; please refer to the verification process of the verification node in the above embodiment for implementation details.

[0164] Optionally, in one embodiment, the business activity includes a transaction activity. After verifying the additional ticket verification information through downstream ticket verification nodes based on the additional ticket verification parameters and logic, and obtaining the third ticket verification result, the activity further includes:

[0165] If the second verification result indicates that the verification of the element information is successful, and the third verification result indicates that the verification of the additional element information is successful, then the corresponding transaction operation will be executed through the downstream verification node.

[0166] In this embodiment, after verifying the business tickets and additional business tickets from the verification node, the downstream verification node can further execute business operations corresponding to the business behavior as needed. For example, taking a transaction occurring in a business behavior transaction system, where the downstream verification node is the transaction processing node, after verifying the business tickets and additional business tickets corresponding to the transaction behavior from the verification node, if the second verification result indicates successful verification of the business tickets and the third verification result indicates successful verification of the additional business tickets, then the transaction behavior occurring in the transaction system is legal, and the transaction processing operation corresponding to that transaction behavior can be executed.

[0167] Optionally, in one embodiment, transmitting the business ticket, supplementary business ticket, first signature data, and second signature data to the downstream ticket verification node through the ticket verification node includes:

[0168] By merging business tickets and adding business tickets through ticket verification nodes, a merged business ticket is obtained;

[0169] The first and second signature data are attached to the merged business ticket and transmitted together to the downstream ticket verification node through the ticket verification node.

[0170] This application embodiment further provides an optional data transmission strategy. For the ticket verification node, according to the configured ticket merging strategy, the business ticket from the upstream ticket issuing node and its own generated supplementary business ticket are merged into a single ticket, denoted as a merged business ticket. The first signature data and the second signature data are added as supplementary information to the merged business ticket and transmitted together with it to the downstream ticket verification node. The configuration of the ticket merging strategy is not specifically limited here and can be configured according to actual needs.

[0171] For example, please refer to Figure 4 A transaction (i.e., business transaction) occurred in the transaction system (i.e., business system) with object identifier 1 and consumption amount of 1000. The issuing node obtains the object identifier as element information and, combined with the verification logic of the verification node, generates a business ticket corresponding to this transaction, represented as:

[0172] {

[0173] "TID":"T1",

[0174] "date":"2024-12-31",

[0175] "Key":"UID=1",

[0176] "verificationLogic":"KEY=='?'",

[0177] "signature":"First signature data"

[0178] }

[0179] Wherein, "TID":"T1" indicates that the ticket identifier of this business ticket is T1, "date":"2024-12-31" indicates that the creation date of this business ticket is 2024-12-31, "Key":"UID=1" indicates that the element information of this business ticket is an object identifier and the value of the object identifier is 1, "verificationLogic":"KEY=='?"" indicates the ticket verification logic in the form of an operation expression, which is to verify whether the object identifier is the expected object identifier, and "signature":"first signature data" indicates the attached first signature data.

[0180] After successfully verifying the first signature data, the verification node obtains the input verification parameter - the expected object identifier is 1, indicating successful verification of the business invoice. It then obtains the transaction amount of the above transaction as additional element information. Combined with the additional verification logic of the downstream verification node, it generates an additional business invoice corresponding to the above transaction, represented as:

[0181] {

[0182] "TID":"T1-Addendum",

[0183] "originalTID":"T1",

[0184] "date":"2024-12-31",

[0185] "Key":"amount=1000",

[0186] "verificationLogic":"Key==?",

[0187] "signature": "Second signature data"

[0188] }

[0189] In this document, "TID":T1-Addendum indicates that the additional business document's document identifier is T1-Addendum, which is the original business document's document identifier with "Addendum" added for distinction. "originalTID":"T1" indicates that the original business document's document identifier is T1, used to associate it with the original document. "date":"2024-12-31" indicates that the additional business document was created on 2024-12-31. "Key":"amount=1000" indicates that the additional business document's element information is the transaction amount, and the transaction amount value is 1000. "verificationLogic":"KEY=='?" indicates the additional document verification logic in the form of an expression, used to verify whether the transaction amount is the expected transaction amount. "signature":"Second signature data" indicates the additional second signature data.

[0190] The ticket verification node further merges the above business tickets and the above additional business tickets to obtain a merged business ticket, represented as follows:

[0191] {

[0192] "TID":"T2",

[0193] "date":"2024-12-31",

[0194] "Key1":"UID=1"

[0195] "Key2":"amount=1000",

[0196] "verificationLogic":"Key1==?"AND"Key2==?"

[0197] "signature": "First signature data, second signature data"

[0198] }

[0199] Wherein, "TID":T2" indicates that the ticket identifier of the merging business ticket is T2, "date":"2024-12-31" indicates that the construction date of the merging business ticket is 2024-12-31, "Key1":"UID=1" indicates that the value of the object identifier in the element information of the merging business ticket is 1, "Key2":"amount=1000" indicates that the value of the transaction amount in the element information of the merging business ticket is 1000, "verificationLogic":"Key1==? "AND"Key2==? " represents the verification logic and additional verification logic after merging in the form of an arithmetic expression, which verifies whether the object identifier is the expected object identifier and whether the transaction amount is the expected transaction amount, and "signature":"first signature data, second signature data" represents the additional first signature data and second signature data.

[0200] The downstream verification node is the transaction node in the transaction system. After obtaining the above-mentioned integrated business ticket, it first verifies the first signature data and the second signature data respectively. If the verification of the first signature data and the second signature data is successful, it further obtains the input verification parameter - the expected object identifier is 1, and the input additional verification parameter - the expected transaction amount is 1000. At this time, the above calculation expression is true, and the integrated business ticket is successfully verified. Then, the transaction operation corresponding to the above transaction behavior is executed.

[0201] As described above, in this embodiment of the application, when additional business tickets are generated, the additional business tickets are not independently transmitted to the downstream. Instead, the additional business tickets and their corresponding business tickets are merged to obtain a fused business ticket before being transmitted downstream. This enables the business tickets generated by multiple "ticket issuing nodes" to form a "ticket chain", thereby achieving anti-tampering of tickets across the entire chain and further improving the security of ticket verification.

[0202] Optionally, in one embodiment, before obtaining the element information of the business behavior through the ticket issuing node and the ticket verification logic from the ticket verification node in response to the occurring business behavior, the method further includes:

[0203] The ticket verification node provides a logical configuration interface, which includes a text input interface.

[0204] The ticket verification logic text is obtained by acquiring the natural language text received by the text input interface through the ticket verification node and performing semantic recognition on the natural speech text.

[0205] The verification logic text is transmitted from the verification node to the ticket issuing node.

[0206] In this embodiment of the application, an optional configuration scheme for ticket verification logic is also provided to improve the configuration efficiency of ticket verification logic.

[0207] Please refer to Figure 5 The ticket verification node provides a logic configuration interface, which includes a text input interface for receiving input text. Additionally, the interface includes a prompt message asking for natural language input: "Please use natural language to input the desired ticket verification logic." Through the text input interface, the ticket verification node receives the input natural language text and further performs semantic recognition on it according to the configured semantic recognition strategy to obtain the corresponding semantic recognition result. The configuration of the semantic recognition strategy is not specifically limited here; for example, it can be configured as follows: using an artificial intelligence-based semantic recognition model to perform semantic recognition on the received natural language text, thereby obtaining the semantic recognition result of the natural language text.

[0208] As described above, after recognizing the semantic recognition result of the received natural language text, the ticket verification node further formats the recognized semantic recognition result to obtain the ticket verification logic text that conforms to natural language. The formatting process converts the format of the semantic recognition result into the format of the ticket verification logic text, thereby generating the ticket verification logic text. For example, the semantic recognition result obtained from the received natural language text describes the ticket verification logic as: whether the value of the object identifier of the transaction behavior object is the expected input value. This semantic recognition result is then formatted into the ticket verification logic text: Is the object identifier ?.

[0209] Optionally, in one embodiment, before the ticket issuing node transmits the business ticket and the first signature data to the ticket verification node, the method further includes:

[0210] The business ticket is set with a verification password by the ticket issuing node. The business ticket is used by the verification node to verify the first signature data. After the verification is successful according to the verification password, the verification node provides verification parameters according to the verification logic to verify the element information and obtain the first verification result.

[0211] To further enhance the security of ticket verification, this embodiment of the application also performs password verification on business tickets.

[0212] Before transmitting the business ticket and first signature data to the ticket verification node, the ticket issuing node sets a verification password for the business ticket. For example, the ticket issuing node can set the verification password in the key management system. When the ticket verification node triggers the verification, it provides a password input interface to receive the entered password, records it as the input password, and provides the received input password to the password management system. The password management system compares the input password with the verification password. If they match, it returns a verification success indication to the ticket verification node; otherwise, it returns a verification failure indication to the ticket verification node. For example, the issuing node can set the verification password in the business ticket. For instance, the issuing node can encrypt the verification password using a symmetric key agreed upon with the verification node to obtain the ciphertext, and then fill the additional information field of the business ticket with the ciphertext as additional information. When the verification node triggers the verification, it provides a password input interface to receive the input password, which is recorded as the input password. The verification node then decrypts the ciphertext using the symmetric key agreed upon with the issuing node to obtain the verification password, and then compares the input password with the verification password. If they match, the verification is successful; otherwise, the verification fails.

[0213] It should be noted that the ticket verification node can perform the security verification operation after successful signature verification, or vice versa. The order of the security verification and signature verification operations can be set according to actual needs. Regardless of whether the signature verification or security verification is performed first, the ticket verification node must verify the element information according to the ticket verification logic and the provided verification parameters after both signature and security verification are successful. The process of verifying the element information according to the provided verification parameters is not detailed here; please refer to the relevant descriptions in the above embodiments.

[0214] Understandably, in different verification relationships, a verification node can also be a ticket-issuing node, and vice versa; that is, the roles of ticket-issuing node and ticket-verifying node can be interchangeable. For example, in one verification relationship, business node A constructs a business ticket, and business node B verifies the business ticket constructed by business node A. In this verification relationship, business node A is the ticket-issuing node, and business node B is the ticket-verifying node. Similarly, in another verification relationship, business node B constructs a business ticket, and business node A verifies the business ticket constructed by business node B. In this verification relationship, business node B is the ticket-issuing node, and business node A is the ticket-verifying node.

[0215] In this embodiment, taking a business ticket as a reference, the upstream is the ticket issuing node and the downstream is the ticket verification node. By encapsulating the ticket verification logic and element information in the same business ticket, the loose coupling between the ticket verification logic and the ticket issuing business is achieved. For the downstream, the ticket verification can be achieved through the ticket verification logic encapsulated in the business ticket, without the need for additional business reverse lookup or other coupling logic.

[0216] As described above, this application provides a bill processing solution. On one hand, it obtains the element information of the business activity and the verification logic from the verification node through the bill issuing node. Based on the obtained element information and verification logic, it constructs a business bill corresponding to the business activity, signs the business bill to obtain first signature data, and finally transmits the business bill and the first signature data to the verification node. On the other hand, the verification node verifies the first signature data. If the verification is successful, it determines that the business bill has not been tampered with. It further verifies the element information based on the verification parameters provided by the verification logic to obtain the first verification result. Thus, by directly carrying the verification logic into the business bill, the verification logic can be flexibly designed according to verification requirements. When the verification logic needs to be changed, only the modified verification logic needs to be carried into the business bill, without any additional operations. Furthermore, signature verification is performed on the business bill carrying the verification logic, which can prevent the verification logic from being tampered with during the transmission of the business bill. In summary, the bill processing solution provided by this application can improve the flexibility and security of bill verification.

[0217] Please refer to Figure 6 , Figure 6 This is another flowchart illustrating the bill processing method provided in this application, such as... Figure 6 As shown, the flow of this invoice processing method can be as follows:

[0218] In step 210, the ticket verification logic is obtained and then passed to the ticket issuing node.

[0219] In this embodiment, the verification node provides the issuing node with verification logic for constructing business invoices in advance. This verification logic can be generated by the verification node according to actual verification needs. Verification logic is a series of conditions and rules used to verify whether an invoice conforms to business rules. For example, taking a transaction in a transaction system as an example, verification logic can be used to verify whether the object identifier of the transaction exists and is valid, whether the transaction amount is within the allowed range, whether the transaction date is within the valid range, whether the transaction type is allowed (e.g., only purchase allowed, no refund allowed), whether the account balance is sufficient, whether the order status is valid, and so on. The form of the verification logic is not limited here; for example, it can be in the form of natural language text. Natural language is the language used by humans in daily life, distinct from artificially designed programming languages ​​or formal languages. Natural language is characterized by complexity, variability, and context dependence. For example, the verification logic obtained from the verification node is in natural language text: Is the object identifier of the transaction a ?, is the transaction amount greater than ?, and is the transaction date earlier than ?, where ? is a placeholder for the verification parameters, and the specific parameter content is provided by the verification node during verification.

[0220] In step 220, the business ticket and first signature data of the business behavior transmitted by the ticket issuing node are obtained. The business ticket is constructed by the ticket issuing node based on the element information of the business behavior and the ticket verification logic, and the first signature data is obtained by the ticket issuing node signing the business ticket.

[0221] The ticket issuing node can respond to business actions occurring in the business system, obtaining the element information of that business action and the ticket verification logic from the ticket verification node. For example, the ticket issuing node can access an access service via remote call. When it finds a business action occurring in the business system through the access service, it can further obtain the element information of that business action through the access service. After obtaining the element information, the ticket issuing node verifies the format of the obtained element information, that is, it verifies whether the format of the element information meets the requirements. Only after the format verification of the element information is successful will subsequent processing be performed to ensure the normal execution of subsequent processing procedures.

[0222] For example, taking a certain transaction system as an example, when a transaction object (i.e., a behavior object) places an order to purchase a product in the transaction system, a transaction behavior (i.e., a business behavior) is generated. The issuing node can access the access service of the transaction system through remote calls, query the transaction behavior that occurred in the transaction system through the access service, and further obtain the object identifier and transaction amount of the transaction behavior as the element information of the transaction behavior through the access service.

[0223] After obtaining the element information of the business behavior that occurred, as well as the verification logic from the verification node, the issuing node constructs a business ticket corresponding to the business behavior according to the obtained element information and verification logic and the configured ticket format. There are no specific restrictions on the configuration of the ticket format here.

[0224] For example, a business invoice may include basic information fields, element information fields, verification logic fields, and supplementary information fields. The basic information fields are used to fill in basic information such as the invoice identifier (which can be generated by an identifier generator and is used to uniquely identify the business invoice), the creation date (i.e., the date on which the business invoice is created), and the expiry date (i.e., the date determined based on the creation date and the validity period of the business invoice, where the validity period is determined according to actual needs). The element information fields are used to fill in element information. The verification logic fields are used to fill in verification logic. The supplementary information fields are used to fill in supplementary information (such as remarks, attachments (such as transaction orders for the transaction behavior), etc.). Supplementary information is filled in according to actual needs, or it can be left blank. When constructing a business invoice, the issuing node generates a unique identifier as the invoice identifier using an identifier generator, determines the current date of the construction operation as the construction date of the business invoice, and determines the expiration date of the business invoice based on the configured invoice validity period. The invoice identifier, construction date, and expiration date are then filled into the basic information field of the business invoice. The acquired element information is filled into the element information field of the business invoice; the acquired verification logic is filled into the verification logic field of the business invoice; and the additional information field is left blank. At this point, the issuing node has constructed the business invoice corresponding to the business behavior based on the acquired element information and verification logic.

[0225] In this embodiment, a first public-private key pair corresponding to the issuing node is pre-generated. This first public-private key pair includes a first private key and a first public key. The first public-private key pair can be generated by the issuing node using a configured key generation algorithm, or it can be generated by a third-party key management system. As described above, after constructing a business ticket corresponding to the occurring business behavior based on the obtained element information and ticket verification logic, the issuing node further signs the business ticket using its own first private key and records the resulting signature data as the first signature data.

[0226] For example, the issuing node uses a configured key generation algorithm to generate the first public-private key pair, stores the first private key in the first public-private key pair locally (it can be stored in ciphertext or plaintext), and transmits the first public key in the first public-private key pair to the verification node; or, for another example, the issuing node can generate the first public-private key pair through a third-party key management system, and query the first private key in the first public-private key pair from the key management system when needed, while the verification node can query the first public key in the first public-private key pair from the key management system.

[0227] The issuing node transmits the business ticket and the first signature data to the verification node according to the configured data transmission strategy. There are no specific restrictions on the configuration of the data transmission strategy here. For example, the data transmission strategy can be configured to transmit the business ticket and the first signature data to the verification node separately, or the data transmission strategy can be configured to append the first signature data to the business ticket and transmit them together to the verification node.

[0228] On the other hand, the verification node will receive the business ticket and first signature data of the business behavior transmitted by the ticket issuing node.

[0229] In step 230, the first signature data is verified, and when the first signature data is successfully verified, the input verification parameters are obtained according to the verification logic.

[0230] After receiving the business ticket and first signature data from the issuing node, the verification node uses the first public key corresponding to the issuing node to verify the first signature data. If the verification is successful, it means that the business ticket has not been tampered with. The verification node then provides verification parameters based on the verification logic in the business ticket to verify the element information in the business ticket. If the verification fails, it means that the business ticket has been tampered with during transmission. In this case, the tampered business ticket can be discarded directly, and the issuing node can be requested to retransmit the business ticket.

[0231] In one example, taking the first signature data obtained by the issuing node using a hash algorithm to perform a hash operation on the business ticket to obtain a hash value, and then encrypting it using the first private key, the verification node can complete the verification of the first signature data in the following manner:

[0232] The verification node uses the first public key corresponding to the issuing node to decrypt the first signature data, and decrypts the hash value obtained by the issuing node using a hash algorithm. In addition, the same hash algorithm as the issuing node is used to perform a hash operation on the business ticket. If the hash value obtained at this time is the same as the hash value obtained by the issuing node, the signature verification is successful; otherwise, the signature verification fails.

[0233] In response to the successful verification of the first signature data, the verification node can provide a parameter input interface to receive the input verification parameters.

[0234] For example, please refer to Figure 7 The diagram shows an example of a parameter input interface, which includes an input interface for receiving ticket verification parameters. Figure 7 The input interface shown in the figure is in the form of an input box, and the prompt message for entering the ticket verification parameters is as follows. For example, if the ticket verification logic is: the transaction amount of the transaction is greater than ?, then the ticket verification parameter is the expected transaction amount, and the corresponding prompt message can be: Please enter the expected transaction amount.

[0235] In step 240, the element information is verified according to the verification parameters and verification logic to obtain the first verification result.

[0236] Ticket verification involves substituting the element information and verification parameters into the ticket verification logic to check if the logic is valid. For example, taking a business transaction as an example, the ticket verification logic, expressed in natural language text, is: Is the object identifier of the transaction a ?, where "?" represents a placeholder for the verification parameter, which is the expected object identifier of the transaction. Assuming the ticket verification node receives the input verification parameter [object identifier → 1], if the value of the object identifier in the element information carried in the business ticket is 1, the ticket verification logic is valid, and the verification of this element information is successful, resulting in a first verification result indicating successful verification. If the value of the object identifier in the element information carried in the business ticket is not 1, the ticket verification logic is invalid, and the verification of this element information fails, resulting in a first verification result indicating failed verification. As another example, continuing to use a business transaction as an example, the ticket verification logic, expressed in natural language text, is: Is the transaction amount of the transaction greater than ? In this context, "?" represents a placeholder for the verification parameter, which is the expected transaction amount. Assuming the verification node receives the input verification parameter as [transaction amount → 200], if the transaction amount in the element information carried in the business ticket is greater than 200, the verification logic is valid, and the verification of this element information is successful, resulting in the first verification result indicating successful verification. If the transaction amount in the element information carried in the business ticket is less than or equal to 200, the verification logic is invalid, and the verification of this element information fails, resulting in the first verification result indicating failed verification.

[0237] Understandably, in different verification relationships, a verification node can also be a ticket-issuing node, and vice versa; that is, the roles of ticket-issuing node and ticket-verifying node can be interchangeable. For example, in one verification relationship, business node A constructs a business ticket, and business node B verifies the business ticket constructed by business node A. In this verification relationship, business node A is the ticket-issuing node, and business node B is the ticket-verifying node. Similarly, in another verification relationship, business node B constructs a business ticket, and business node A verifies the business ticket constructed by business node B. In this verification relationship, business node B is the ticket-issuing node, and business node A is the ticket-verifying node.

[0238] Optionally, in one embodiment, the business ticket includes an operational expression derived from the ticket verification logic. The operational expression includes operators, a first placeholder corresponding to element information, and a second placeholder corresponding to verification parameters. Based on the verification parameters and the ticket verification logic, the element information is verified to obtain a first verification result, including:

[0239] Replace the first placeholder with the element information, replace the second placeholder with the ticket verification parameter, and perform calculations on the element information and ticket verification parameter according to the operator to obtain the calculation result;

[0240] Based on the calculation results, obtain the first ticket verification result corresponding to the element information.

[0241] In this embodiment of the application, for business tickets whose ticket verification logic adopts the form of an arithmetic expression, when the business ticket is verified by the ticket verification node, the element information encapsulated in the business ticket and the arithmetic expression used to represent the ticket verification logic are parsed out. Then, the first placeholder of the arithmetic expression is replaced with the element information, the second placeholder of the arithmetic expression is replaced with the input ticket verification parameters, and the element information and ticket verification parameters are calculated according to the operators of the arithmetic expression to obtain the calculation result. Finally, the first ticket verification result corresponding to the element information is obtained based on the calculation result.

[0242] For example, when the operator in the expression is an arithmetic operator, the result of the arithmetic operation performed according to the arithmetic operator is the first ticket verification result, and the ticket verification is considered successful.

[0243] When the operators in the operation expression are relational operators, set operators, or logical operators, after replacing the first placeholder of the operation expression with element information and the second placeholder of the operation expression with the ticket verification parameter, if the operation result of the operation expression on the element information and the ticket verification parameter indicates that the operation expression is true, then the first ticket verification result indicating successful ticket verification is obtained; if the operation result of the operation expression on the element information and the ticket verification parameter indicates that the operation expression is false, then the first ticket verification result indicating failed ticket verification is obtained.

[0244] For example, suppose the expression representing the ticket verification logic is: [Key] == ?, where Key is the first placeholder corresponding to the element information "object identifier", and ? is the second placeholder corresponding to the verification parameter (in this case, the expected object identifier). If the value of the object identifier in the element information is 1, and the value of the input verification parameter—that is, the expected object identifier—is also 1, then the ticket verification node substitutes the element information and the verification parameter into the expression: 1 == 1. Obviously, this expression is true, and the ticket verification node successfully verifies the element information. Suppose the value of the input verification parameter—that is, the expected object identifier—is not 1, for example, it is 2. The ticket verification node substitutes the element information and the verification parameter into the expression: 1 == 2. Obviously, this expression is false, and the ticket verification node fails to verify the element information.

[0245] For example, suppose the expression representing the ticket verification logic is: [Key]>?, where Key is the first placeholder corresponding to the element information "transaction amount", and ? is the second placeholder corresponding to the verification parameter (in this case, the expected transaction amount). If the transaction amount in the element information is 100, and the input verification parameter—that is, the expected transaction amount—is 50, the ticket verification node substitutes the element information and the verification parameter into the expression: 100>50. Obviously, this expression is true, and the ticket verification node successfully verifies the element information. Suppose the input verification parameter—that is, the expected transaction amount—is greater than or equal to 100, for example, 200. The ticket verification node substitutes the element information and the verification parameter into the expression: 100>200. Obviously, this expression is false, and the ticket verification node fails to verify the element information.

[0246] Optionally, in one embodiment, the first placeholder is replaced with element information, the second placeholder is replaced with ticket verification parameters, and operations are performed on the element information and ticket verification parameters according to operators to obtain the calculation result, including:

[0247] The pre-encapsulated ticket verification function is called using the ticket verification parameters and feature information as calling parameters. The ticket verification function replaces the first placeholder with feature information, the second placeholder with ticket verification parameters, and performs calculations on the feature information and ticket verification parameters according to the operators to obtain the calculation results.

[0248] In this embodiment, a ticket verification function for executing arithmetic expressions is pre-encapsulated. No restrictions are placed on the coding language or specific code content of this ticket verification function; those skilled in the art can determine its suitability based on actual needs.

[0249] When the ticket verification node calls the ticket verification function using the input ticket verification parameters and the element information in the business ticket as calling parameters, the ticket verification function performs the following operations:

[0250] The first placeholder in the operational expression is replaced with element information, and the second placeholder is replaced with ticket verification parameters. The operational expressions are then used to perform calculations on the element information and ticket verification parameters to obtain the result. Accordingly, based on the calculation result obtained by the ticket verification function, the ticket verification node can obtain the first ticket verification result corresponding to the element information. For details on how to obtain the first ticket verification result from the operational expression, please refer to the relevant descriptions in the above embodiments; they will not be repeated here.

[0251] As shown above, by encapsulating the ticket verification operation based on computational expressions into a ticket verification function for ticket verification nodes to call and execute, ticket verification efficiency can be further improved.

[0252] Optionally, in one embodiment, after verifying the element information according to the ticket verification parameters and ticket verification logic to obtain the first ticket verification result, the method further includes:

[0253] If the first ticket verification result indicates that the element information has been successfully verified, then the additional element information of the business behavior is obtained, as well as the additional ticket verification logic from the downstream ticket verification node is obtained.

[0254] Based on the additional information and additional verification logic, construct additional business tickets corresponding to the business activities;

[0255] Sign the additional business invoice to obtain the second signature data;

[0256] The business ticket, supplementary business ticket, first signature data, and second signature data are transmitted to the downstream verification node. The business ticket is used by the downstream verification node to verify the element information according to the verification logic after the first signature data is successfully verified, and a second verification result is obtained. The supplementary business ticket is used by the downstream verification node to verify the supplementary element information according to the supplementary verification logic after the second signature data is successfully verified, and a third verification result is obtained.

[0257] As mentioned above, in different verification relationships, the verification node can also be the issuing node, and vice versa. In this embodiment, the verification node can also construct additional business tickets based on the verification requirements of downstream verification nodes.

[0258] In this embodiment, if the first verification result indicates successful verification of the element information, the verification node obtains additional element information of the business behavior corresponding to the above business ticket. Here, the additional element information is relative to the original element information. For example, taking a certain transaction behavior as an example, the verification of the transaction behavior can be divided into two verification stages. In the first verification stage, the issuing node obtains the object identifier of the behavior object of the transaction behavior as element information to construct a business ticket, and then verifies the object identifier. In the second verification stage, when the verification node successfully verifies the business ticket, it obtains the transaction amount of the transaction behavior. Since the transaction amount is additional compared to the original element information - object identifier, the transaction amount obtained at this time is used as additional element information to construct a new business ticket, and then the transaction amount is verified.

[0259] The ticket verification node also obtains the verification logic corresponding to the additional element information from the downstream ticket verification node, denoted as the additional ticket verification logic. This additional ticket verification logic can be generated by the downstream ticket verification node according to the actual ticket verification needs. There are no restrictions on the form of the additional ticket verification logic here; for example, it can be in the form of natural language text.

[0260] After obtaining additional information about the business activity and the verification logic from the downstream verification nodes, the verification node constructs a new business document corresponding to the business activity according to the same document format as the above business documents, based on the obtained additional information and additional verification logic. This document is called an additional business document.

[0261] In this embodiment, a second public-private key pair corresponding to the ticket verification node is pre-generated. This second public-private key pair includes a second private key and a second public key. The second public-private key pair can be generated by the ticket verification node using a configured key generation algorithm, or it can be generated by a third-party key management system. As described above, after constructing an additional business ticket corresponding to the occurred business behavior based on the obtained additional element information and additional ticket verification logic, the ticket verification node further signs the additional business ticket using its second private key and records the resulting signature data as the second signature data.

[0262] For example, a ticket verification node uses a configured key generation algorithm to generate a second public-private key pair, stores the second private key locally (either in encrypted or plaintext), and transmits the second public key to downstream ticket verification nodes. Alternatively, a ticket verification node can generate a second public-private key pair through a third-party key management system and retrieve the second private key from the system when needed, while downstream ticket verification nodes can retrieve the second public key from the same system.

[0263] According to the configured data transmission strategy, the ticket verification node transmits the business ticket, the supplementary business ticket, the first signature data and the second signature data to the downstream ticket verification node. There are no specific restrictions on the configuration of the data transmission strategy here.

[0264] Understandably, for the above-mentioned business invoices, the verification node is the verification node, while for additional business invoices, the verification node is the issuance node.

[0265] On the other hand, after obtaining the business ticket, the supplementary business ticket, the first signature data, and the second signature data, the downstream verification node uses the first public key corresponding to the issuing node to verify the first signature data. If the verification is successful, it indicates that the business ticket has not been tampered with. Further verification parameters are provided based on the verification logic in the business ticket to verify the element information in the business ticket, resulting in a second verification result. If the verification fails, it indicates that the business ticket has been tampered with during transmission. In this case, the tampered business ticket can be discarded directly, and the verification node is requested to retransmit the business ticket, the supplementary business ticket, the first signature data, and the second signature data. The specific implementation of the downstream verification node's verification process is not detailed here; please refer to the verification process of the verification node in the above embodiment.

[0266] For the supplementary business ticket and second signature data, the downstream verification node uses the second public key corresponding to the verification node to verify the second signature data. If the verification is successful, it indicates that the supplementary business ticket has not been tampered with. Further, based on the supplementary verification logic in the supplementary business ticket, supplementary verification parameters are provided to verify the supplementary element information in the supplementary business ticket, resulting in a third verification result. If the verification fails, it indicates that the supplementary business ticket has been tampered with during transmission. In this case, the tampered supplementary business ticket can be discarded directly, and the verification node is requested to retransmit the business ticket, supplementary business ticket, first signature data, and second signature data. The specific verification process performed by the downstream verification node is not detailed here; please refer to the verification process of the verification node in the above embodiment for implementation details.

[0267] In this embodiment, after verifying the business tickets and additional business tickets from the verification node, the downstream verification node can further execute business operations corresponding to the business behavior as needed. For example, if the downstream verification node is an account activity node in the transaction system, after verifying the business tickets and additional business tickets corresponding to the transaction behavior from the verification node, the downstream verification node can execute the account activity corresponding to that transaction behavior.

[0268] Optionally, in one embodiment, based on the additional element information and the additional ticket verification logic, an additional business ticket corresponding to the business behavior is constructed, including:

[0269] The additional ticket verification logic is converted into an additional operation expression, which includes an additional operator, a third placeholder corresponding to the additional element information, and a fourth placeholder corresponding to the additional ticket verification parameters.

[0270] Based on the additional element information and the additional operation expression, construct the additional business ticket corresponding to the business behavior;

[0271] The append operation expression is used by the downstream ticket verification node to obtain the third ticket verification result based on the second operation result obtained by the append operator after replacing the third placeholder with the append element information and the fourth placeholder with the append verification parameter.

[0272] In this embodiment of the application, if the additional ticket verification logic is in the form of natural language text, the ticket verification node converts the additional ticket verification logic text into a corresponding operation expression, which is denoted as the additional operation expression. Then, based on the additional element information and the additional operation expression, an additional business ticket corresponding to the business behavior is constructed. The additional operation expression includes an additional operator, a placeholder corresponding to the additional element information, which is denoted as the third placeholder, and a placeholder corresponding to the additional ticket verification parameters, which is denoted as the fourth placeholder.

[0273] For example, if the additional verification logic text is: "The transaction amount of the transaction is greater than ?", then the verification node can convert this additional verification logic text into the corresponding additional operation expression: [Key]>?, where Key is the third placeholder corresponding to the additional element information "transaction amount", and ? is the fourth placeholder corresponding to the additional verification parameter (in this case, the expected transaction amount). Assuming the transaction amount in the additional information is 100, and the downstream verification node receives the additional verification parameter—the expected transaction amount—of 50, the downstream verification node substitutes the additional information and the additional verification parameter into the addition operation expression: 100 > 50. Obviously, the result of this addition operation expression is true, and the downstream verification node will successfully verify the additional information. However, assuming the downstream verification node receives the additional verification parameter—the expected transaction amount—greater than or equal to 100, for example, 200, the downstream verification node substitutes the additional information and the additional verification parameter into the addition operation expression: 100 > 200. Obviously, the result of this addition operation expression is false, and the downstream verification node will fail to verify the additional information.

[0274] It should be noted that the embodiments of this application do not impose specific restrictions on the conversion method for converting the additional ticket verification logic into the corresponding additional operation expression. It can be a rule-based conversion or an artificial intelligence-based conversion.

[0275] Optionally, in one embodiment, transmitting the business ticket, supplementary business ticket, first signature data, and second signature data to the downstream ticket verification node includes:

[0276] Merge business invoices and additional business invoices to obtain integrated business invoices;

[0277] The first and second signature data are appended to the aforementioned fused business ticket and transmitted together to the downstream ticket verification node.

[0278] This application embodiment further provides an optional data transmission strategy. For the ticket verification node, according to the configured ticket merging strategy, the business ticket from the upstream ticket issuing node and its own generated supplementary business ticket are merged into a single ticket, denoted as a merged business ticket. The first signature data and the second signature data are added as supplementary information to the merged business ticket and transmitted together with it to the downstream ticket verification node. The configuration of the ticket merging strategy is not specifically limited here and can be configured according to actual needs.

[0279] For example, please refer to Figure 4 A transaction (i.e., business transaction) occurred in the transaction system (i.e., business system) with object identifier 1 and consumption amount of 1000. The issuing node obtains the object identifier as element information and, combined with the verification logic of the verification node, generates a business ticket corresponding to this transaction, represented as:

[0280] {

[0281] "TID":"T1",

[0282] "date":"2024-12-31",

[0283] "Key":"UID=1",

[0284] "verificationLogic":"KEY=='?'",

[0285] "signature":"First signature data"

[0286] }

[0287] Wherein, "TID":"T1" indicates that the ticket identifier of this business ticket is T1, "date":"2024-12-31" indicates that the creation date of this business ticket is 2024-12-31, "Key":"UID=1" indicates that the element information of this business ticket is an object identifier and the value of the object identifier is 1, "verificationLogic":"KEY=='?"" indicates the ticket verification logic in the form of an operation expression, which is to verify whether the object identifier is the expected object identifier, and "signature":"first signature data" indicates the attached first signature data.

[0288] After successfully verifying the first signature data, the verification node obtains the input verification parameter - the expected object identifier is 1, indicating successful verification of the business invoice. It then obtains the transaction amount of the above transaction as additional element information. Combined with the additional verification logic of the downstream verification node, it generates an additional business invoice corresponding to the above transaction, represented as:

[0289] {

[0290] "TID":"T1-Addendum",

[0291] "originalTID":"T1",

[0292] "date":"2024-12-31",

[0293] "Key":"amount=1000",

[0294] "verificationLogic":"Key==?",

[0295] "signature": "Second signature data"

[0296] }

[0297] In this document, "TID":T1-Addendum indicates that the additional business document's document identifier is T1-Addendum, which is the original business document's document identifier with "Addendum" added for distinction. "originalTID":"T1" indicates that the original business document's document identifier is T1, used to associate it with the original document. "date":"2024-12-31" indicates that the additional business document was created on 2024-12-31. "Key":"amount=1000" indicates that the additional business document's element information is the transaction amount, and the transaction amount value is 1000. "verificationLogic":"KEY=='?" indicates the additional document verification logic in the form of an expression, used to verify whether the transaction amount is the expected transaction amount. "signature":"Second signature data" indicates the additional second signature data.

[0298] The ticket verification node further merges the above business tickets and the above additional business tickets to obtain a merged business ticket, represented as follows:

[0299] {

[0300] "TID":"T2",

[0301] "date":"2024-12-31",

[0302] "Key1":"UID=1"

[0303] "Key2":"amount=1000",

[0304] "verificationLogic":"Key1==?"AND"Key2==?"

[0305] "signature": "First signature data, second signature data"

[0306] }

[0307] Wherein, "TID":T2" indicates that the ticket identifier of the merging business ticket is T2, "date":"2024-12-31" indicates that the construction date of the merging business ticket is 2024-12-31, "Key1":"UID=1" indicates that the value of the object identifier in the element information of the merging business ticket is 1, "Key2":"amount=1000" indicates that the value of the transaction amount in the element information of the merging business ticket is 1000, "verificationLogic":"Key1==? "AND"Key2==? " represents the verification logic and additional verification logic after merging in the form of an arithmetic expression, which verifies whether the object identifier is the expected object identifier and whether the transaction amount is the expected transaction amount, and "signature":"first signature data, second signature data" represents the additional first signature data and second signature data.

[0308] The downstream verification node is the transaction node in the transaction system. After obtaining the above-mentioned integrated business ticket, it first verifies the first signature data and the second signature data respectively. If the verification of the first signature data and the second signature data is successful, it further obtains the input verification parameter - the expected object identifier is 1, and the input additional verification parameter - the expected transaction amount is 1000. At this time, the above calculation expression is true, and the integrated business ticket is successfully verified. Then, the transaction operation corresponding to the above transaction behavior is executed.

[0309] As described above, in this embodiment of the application, when additional business tickets are generated, the additional business tickets are not independently transmitted to the downstream. Instead, the additional business tickets and their corresponding business tickets are merged to obtain a fused business ticket before being transmitted downstream. This enables the business tickets generated by multiple "ticket issuing nodes" to form a "ticket chain", thereby achieving anti-tampering of tickets across the entire chain and further improving the security of ticket verification.

[0310] Optionally, in one embodiment, obtaining the ticket verification logic includes:

[0311] Provides a logic configuration interface, which includes a text input interface;

[0312] The system receives natural language text from the text input interface, performs semantic recognition on the natural language text, and obtains the ticket verification logic text.

[0313] In this embodiment of the application, an optional configuration scheme for ticket verification logic is also provided to improve the configuration efficiency of ticket verification logic.

[0314] Please refer to Figure 5 The ticket verification node provides a logic configuration interface, which includes a text input interface for receiving input text. Additionally, the interface includes a prompt message asking for natural language input: "Please use natural language to input the desired ticket verification logic." Through the text input interface, the ticket verification node receives the input natural language text and further performs semantic recognition on it according to the configured semantic recognition strategy to obtain the corresponding semantic recognition result. The configuration of the semantic recognition strategy is not specifically limited here; for example, it can be configured as follows: using an artificial intelligence-based semantic recognition model to perform semantic recognition on the received natural language text, thereby obtaining the semantic recognition result of the natural language text.

[0315] As described above, after recognizing the semantic recognition result of the received natural language text, the ticket verification node further formats the recognized semantic recognition result to obtain the ticket verification logic text that conforms to natural language. The formatting process converts the format of the semantic recognition result into the format of the ticket verification logic text, thereby generating the ticket verification logic text. For example, the semantic recognition result obtained from the received natural language text describes the ticket verification logic as: whether the value of the object identifier of the transaction behavior object is the expected input value. This semantic recognition result is then formatted into the ticket verification logic text: Is the object identifier ?.

[0316] This application also provides a ticket processing system; please refer to... Figure 8 The ticket processing system may include a ticket issuing node and a ticket verification node. In this embodiment, the above-mentioned procedures can be performed through data interaction between the ticket issuing node and the ticket verification node. Figure 2 The corresponding embodiment provides a bill processing method, wherein,

[0317] The ticket issuing node is used to respond to the business behavior that occurs, obtain the element information of the business behavior, and obtain the ticket verification logic from the ticket verification node.

[0318] The ticket issuance node is also used to construct business tickets corresponding to business activities based on element information and ticket verification logic;

[0319] The ticket issuing node is also used to sign business tickets to obtain the first signature data, and to transmit the business ticket and the first signature data to the ticket verification node.

[0320] The ticket verification node is used to verify the first signature data and obtain the input verification parameters according to the ticket verification logic after successful verification.

[0321] The ticket verification node is also used to verify the element information according to the ticket verification parameters and ticket verification logic to obtain the first ticket verification result.

[0322] Optionally, in one embodiment, the ticket verification logic includes ticket verification logic text;

[0323] The ticket issuance node is used to convert the ticket verification logic text into a calculation expression, which includes operators, a first placeholder corresponding to the element information, and a second placeholder corresponding to the ticket verification parameters; and to construct a business ticket corresponding to the business behavior based on the element information and the calculation expression.

[0324] Optionally, in one embodiment, the ticket verification node is used to replace the first placeholder with element information, replace the second placeholder with ticket verification parameters, and perform calculations on the element information and ticket verification parameters according to the operator to obtain the calculation result; and obtain the first ticket verification result corresponding to the element information according to the calculation result.

[0325] Optionally, in one embodiment, the ticket verification node is used to call a pre-encapsulated ticket verification function with ticket verification parameters and element information as calling parameters, so as to replace the first placeholder with element information, replace the second placeholder with ticket verification parameters, and perform calculations on the element information and ticket verification parameters according to the operator to obtain the calculation result.

[0326] Optionally, in one embodiment, the ticket issuing node is used to determine the format verification strategy corresponding to the operation expression based on the expression type of the operation expression; to verify the format of the operation expression according to the format verification strategy; and if the format verification of the operation expression is successful, to construct a business ticket corresponding to the business behavior based on the element information and the operation expression.

[0327] Optionally, in one embodiment, the ticket processing system provided in this application further includes a downstream ticket verification node;

[0328] If the first verification result indicates that the verification of the element information is successful, the verification node is also used to obtain additional element information of the business behavior, as well as additional verification logic from the downstream verification node.

[0329] The ticket verification node is also used to construct additional business tickets corresponding to business activities based on additional element information and additional ticket verification logic;

[0330] The ticket verification node is also used to sign additional business tickets to obtain second signature data;

[0331] The ticket verification node is also used to transmit business tickets, supplementary business tickets, first signature data, and second signature data to downstream ticket verification nodes;

[0332] Downstream verification nodes are used to verify the first signature data and the second signature data, and when the verification is successful, they obtain the input verification parameters according to the verification logic, and obtain the input additional verification parameters according to the additional verification logic.

[0333] Downstream ticket verification nodes are also used to verify the element information based on the verification parameters and verification logic to obtain a second verification result.

[0334] Downstream ticket verification nodes are also used to verify additional element information based on additional ticket verification parameters and additional ticket verification logic to obtain a third ticket verification result.

[0335] Optionally, in one embodiment, the business behavior includes transaction behavior. If the second verification result indicates that the verification of the element information is successful, and the third verification result indicates that the verification of the additional element information is successful, the downstream verification node is also used to perform the account operation corresponding to the transaction behavior.

[0336] Optionally, in one embodiment, the ticket verification node is used to merge business tickets and supplementary business tickets to obtain a merged business ticket; and to attach the first signature data and the second signature data to the merged business ticket and transmit them together to the downstream ticket verification node.

[0337] Optionally, in one embodiment, the ticket verification node is further configured to provide a logical configuration interface, which includes a text input interface; acquiring natural language text received by the text input interface, and performing semantic recognition on the natural language text to obtain the ticket verification logical text; and transmitting the ticket verification logical text to the ticket issuing node.

[0338] The specific implementation details of each of the above nodes can be found in the previous embodiments, and will not be repeated here.

[0339] As can be seen from the above, the bill processing system provided in this application, on the one hand, obtains the element information of the business behavior and the verification logic from the verification node through the bill issuing node. Based on the obtained element information and verification logic, it constructs a business bill corresponding to the business behavior, signs the business bill to obtain first signature data, and finally transmits the business bill and the first signature data to the verification node. On the other hand, the verification node verifies the first signature data. If the verification is successful, it determines that the business bill has not been tampered with. It further verifies the element information based on the verification parameters provided by the verification logic to obtain the first verification result. Thus, by directly carrying the verification logic into the business bill, the verification logic can be flexibly designed according to verification requirements. Furthermore, when the verification logic needs to be changed, only the modified verification logic needs to be carried into the business bill, without any additional operations. In addition, signature verification is performed on the business bill carrying the verification logic, which can prevent the verification logic from being tampered with during the transmission of the business bill. In summary, the bill processing system provided in this application can improve the flexibility and security of bill verification.

[0340] This application also provides a ticket processing device; please refer to... Figure 9 The ticket processing device may include a logic acquisition module 410, a ticket acquisition module 420, a parameter acquisition module 430, and a ticket verification module 440. This ticket processing device can perform the above-described functions. Figure 6 The corresponding embodiment provides a bill processing method, wherein,

[0341] The logic acquisition module 410 is used to acquire the ticket verification logic and pass the ticket verification logic to the ticket issuing node;

[0342] The ticket acquisition module 420 is used to acquire the business ticket and the first signature data of the business behavior transmitted by the ticket issuing node. The business ticket is constructed by the ticket issuing node based on the element information of the business behavior and the ticket verification logic. The first signature data is obtained by the ticket issuing node signing the business ticket.

[0343] The parameter acquisition module 430 is used to verify the first signature data and, when the first signature data is successfully verified, to acquire the input verification parameters according to the verification logic.

[0344] The ticket verification module 440 is used to verify the element information according to the verification parameters and verification logic to obtain the first verification result.

[0345] Optionally, in one embodiment, the business ticket includes an operational expression obtained by the ticket verification logic. The operational expression includes an operator, a first placeholder corresponding to the element information, and a second placeholder corresponding to the ticket verification parameters. The ticket verification module 440 is used to replace the first placeholder with the element information and the second placeholder with the ticket verification parameters, and to perform operations on the element information and the ticket verification parameters according to the operator to obtain the operation result; and to obtain the first ticket verification result corresponding to the element information according to the operation result.

[0346] Optionally, in one embodiment, the ticket verification module 440 is used to call a pre-encapsulated ticket verification function with the ticket verification parameters and element information as calling parameters, so as to replace the first placeholder with the element information, replace the second placeholder with the ticket verification parameters, and perform calculations on the element information and ticket verification parameters according to the operators to obtain the calculation results.

[0347] Optionally, in one embodiment, the bill processing apparatus provided by this application further includes:

[0348] The second data acquisition module is used to acquire additional element information of business behavior if the first ticket verification result indicates that the ticket verification of element information is successful; and to acquire additional ticket verification logic from downstream ticket verification nodes.

[0349] The second bill construction module is used to construct additional business bills corresponding to business activities based on additional element information and additional bill verification logic.

[0350] The second document signature module is used to sign additional business documents to obtain second signature data;

[0351] The second document transmission module is used to transmit business documents, supplementary business documents, first signature data, and second signature data to downstream document verification nodes. After the downstream document verification node successfully verifies the first signature data, it uses the document verification logic to provide verification parameters to verify the element information and obtain the second verification result. After the downstream document verification node successfully verifies the second signature data, it uses the supplementary verification logic to provide supplementary verification parameters to verify the supplementary element information and obtain the third verification result.

[0352] Optionally, in one embodiment, the second ticket construction module is used to convert the additional ticket verification logic into an additional operation expression, the additional operation expression including an additional operator, a third placeholder corresponding to the additional element information, and a fourth placeholder corresponding to the additional ticket verification parameters; and to construct an additional business ticket corresponding to the business behavior based on the additional element information and the additional operation expression; wherein, the additional operation expression is used by the downstream ticket verification node to obtain the third ticket verification result based on the operation result obtained by the additional operator after replacing the third placeholder with the additional element information and the fourth placeholder with the additional ticket verification parameters.

[0353] Optionally, in one embodiment, the second ticket transmission module is used to merge business tickets and supplementary business tickets to obtain a merged business ticket; and to attach the first signature data and the second signature data to the merged business ticket and transmit them together to the downstream ticket verification node.

[0354] Optionally, in one embodiment, the ticket processing device provided in this application further includes a logic configuration module for providing a logic configuration interface, the logic configuration interface including a text input interface; acquiring natural language text received by the text input interface, and performing semantic recognition on the natural language text to obtain ticket verification logic text.

[0355] For details on the implementation of each of the above modules, please refer to the previous examples, which will not be repeated here.

[0356] This application also provides an electronic device, including a memory and a processor, wherein the processor executes the steps in the ticket processing method provided in the above embodiments by calling a computer program stored in the memory.

[0357] Please refer to Figure 10 , Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0358] The electronic device may include components such as a processor 101 with one or more processing cores, a memory 102 with one or more computer-readable storage media, a power supply 103, and an input unit 104. Those skilled in the art will understand that... Figure 10 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0359] The processor 101 is the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes software programs and / or modules stored in the memory 102, and calls data stored in the memory 102, to perform various functions and process data. Optionally, the processor 101 may include one or more processing cores; alternatively, the processor 101 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 101.

[0360] The memory 102 can be used to store software programs and modules. The processor 101 executes various functional applications and data processing by running the software programs and modules stored in the memory 102. The memory 102 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 102 may also include a memory controller to provide the processor 101 with access to the memory 102.

[0361] Specifically, in this embodiment, when the electronic device is configured as a ticket verification node, the processor 101 loads the executable code corresponding to one or more computer programs into the memory 102, and the processor 101 executes it. Figure 6 The corresponding implementation examples provide a ticket processing method, such as:

[0362] Obtain the ticket verification logic and pass it to the ticket issuing node;

[0363] The business document and first signature data of the business behavior transmitted by the issuing node are obtained. The business document is constructed by the issuing node based on the element information of the business behavior and the verification logic. The first signature data is obtained by the issuing node signing the business document.

[0364] Verify the first signature data, and when the first signature data is successfully verified, obtain the input verification parameters according to the verification logic;

[0365] Based on the ticket verification parameters and logic, the element information is verified to obtain the first ticket verification result.

[0366] It should be noted that the electronic device provided in the embodiments of this application is similar to... Figure 6 The bill processing methods provided in the corresponding embodiments belong to the same concept, and their specific implementation processes are detailed in the above-mentioned related embodiments, which will not be repeated here.

[0367] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program stored thereon is executed on the processor of the electronic device provided in the embodiments of this application, the processor of the electronic device implements the steps in the ticket processing method provided in this application. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0368] This application also provides a computer program product, which includes a computer program that, when executed on the processor of the electronic device provided in the embodiments of this application, causes the processor of the electronic device to implement the steps in the ticket processing method provided in this application.

[0369] The foregoing has provided a detailed description of the bill processing method, bill processing device, bill processing system, electronic device, computer-readable storage medium, and computer program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0370] It should be noted that when the above embodiments of this application are applied to specific products or technologies, and user-related data is involved, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A method for processing invoices, characterized in that, include: In response to a business action, the system obtains the element information of the business action through the ticket issuing node, as well as the ticket verification logic from the ticket verification node. Based on the element information and the ticket verification logic, a business ticket corresponding to the business behavior is constructed through the ticket issuing node; The business ticket is signed by the ticket issuing node to obtain first signature data, and the business ticket and the first signature data are transmitted to the ticket verification node. The first signature data is verified by the ticket verification node, and the input ticket verification parameters are obtained according to the ticket verification logic after the verification is successful. Based on the ticket verification parameters and the ticket verification logic, the element information is verified through the ticket verification node to obtain the first ticket verification result.

2. The bill processing method according to claim 1, characterized in that, The ticket verification logic includes ticket verification logic text. The step of constructing a business ticket corresponding to the business behavior through the ticket issuing node based on the element information and the ticket verification logic includes: The ticket issuance node converts the ticket verification logic text into a computational expression, which includes an operator, a first placeholder corresponding to the element information, and a second placeholder corresponding to the ticket verification parameters. Based on the element information and the calculation expression, a business ticket corresponding to the business behavior is constructed through the ticket issuing node.

3. The bill processing method according to claim 2, characterized in that, The step of verifying the element information through the ticket verification node according to the ticket verification parameters and the ticket verification logic to obtain a first ticket verification result includes: The ticket verification node replaces the first placeholder with the element information, replaces the second placeholder with the ticket verification parameter, and performs calculations on the element information and the ticket verification parameter according to the operator to obtain the calculation result. Based on the calculation result, the first ticket verification result corresponding to the element information is obtained through the ticket verification node.

4. The bill processing method according to claim 3, characterized in that, The step of replacing the first placeholder with the element information and the second placeholder with the ticket verification parameter through the ticket verification node, and performing calculations on the element information and the ticket verification parameter according to the operator to obtain the calculation result, includes: The ticket verification node calls the pre-encapsulated ticket verification function using the ticket verification parameters and the element information as calling parameters. The ticket verification function replaces the first placeholder with the element information, replaces the second placeholder with the ticket verification parameters, and performs calculations on the element information and the ticket verification parameters according to the operators to obtain the calculation result.

5. The bill processing method according to claim 2, characterized in that, The step of constructing a business ticket corresponding to the business behavior through the ticket issuing node based on the element information and the calculation expression includes: Based on the expression type of the operational expression, the format verification strategy corresponding to the operational expression is determined by the ticket issuing node; According to the format verification strategy, the format of the operational expression is verified by the ticket issuing node; If the format of the operation expression is successfully validated, then a business ticket corresponding to the business behavior is constructed through the ticket issuing node based on the element information and the operation expression.

6. The bill processing method according to claim 1, characterized in that, After verifying the element information through the ticket verification node according to the ticket verification parameters and the ticket verification logic to obtain the first ticket verification result, the method further includes: If the first ticket verification result indicates that the ticket verification of the element information is successful, then the additional element information of the business behavior is obtained through the ticket verification node, as well as the additional ticket verification logic from the downstream ticket verification node. Based on the additional element information and the additional ticket verification logic, an additional business ticket corresponding to the business behavior is constructed through the ticket verification node; The additional business ticket is signed by the ticket verification node to obtain second signature data; The ticket verification node transmits the business ticket, the supplementary business ticket, the first signature data, and the second signature data to the downstream ticket verification node.

7. The bill processing method according to claim 6, characterized in that, After the process of transmitting the business ticket, the supplementary business ticket, the first signature data, and the second signature data to the downstream ticket verification node through the ticket verification node, it further includes: The downstream ticket verification node verifies the first signature data and the second signature data, and when the verification is successful, it obtains the input verification parameters according to the ticket verification logic, and obtains the input additional verification parameters according to the additional ticket verification logic. Based on the ticket verification parameters and the ticket verification logic, the downstream ticket verification node verifies the element information to obtain a second ticket verification result. Based on the additional ticket verification parameters and the additional ticket verification logic, the additional element information is verified by the downstream ticket verification node to obtain the third ticket verification result.

8. The bill processing method according to claim 7, characterized in that, The business activity includes transaction activity. After verifying the additional element information through the downstream verification node according to the additional verification parameters and the additional verification logic to obtain the third verification result, it also includes: If the second verification result indicates that the verification of the element information is successful, and the third verification result indicates that the verification of the additional element information is successful, then the downstream verification node will execute the transaction operation corresponding to the transaction behavior.

9. The bill processing method according to claim 6, characterized in that, The step of transmitting the business ticket, the supplementary business ticket, the first signature data, and the second signature data to the downstream ticket verification node through the ticket verification node includes: The business ticket and the additional business ticket are merged through the ticket verification node to obtain a merged business ticket; The first signature data and the second signature data are attached to the converged business ticket and transmitted together to the downstream ticket verification node through the ticket verification node.

10. The bill processing method according to claim 2, characterized in that, Before obtaining the element information of the business behavior through the ticket issuing node and the ticket verification logic from the ticket verification node in response to the occurring business behavior, the process further includes: The ticket verification node provides a logical configuration interface, which includes a text input interface. The ticket verification node obtains the natural language text received by the text input interface, and performs semantic recognition on the natural language text to obtain the ticket verification logic text. The ticket verification logic text is transmitted to the ticket issuing node through the ticket verification node.

11. A method for processing invoices, characterized in that, include: Obtain the ticket verification logic and pass it to the ticket issuing node; The business ticket and first signature data of the business behavior transmitted by the ticket issuing node are obtained. The business ticket is constructed by the ticket issuing node based on the element information of the business behavior and the ticket verification logic. The first signature data is obtained by the ticket issuing node signing the business ticket. The first signature data is verified, and when the first signature data is successfully verified, the input verification parameters are obtained according to the verification logic. Based on the ticket verification parameters and the ticket verification logic, the element information is verified to obtain the first ticket verification result.

12. The bill processing method according to claim 5, characterized in that, The business ticket includes an operational expression derived from the ticket verification logic. The operational expression includes an operator, a first placeholder corresponding to the element information, and a second placeholder corresponding to the ticket verification parameters. The step of verifying the element information based on the ticket verification parameters and the ticket verification logic to obtain a first ticket verification result includes: The first placeholder is replaced with the element information, the second placeholder is replaced with the ticket verification parameter, and the element information and the ticket verification parameter are calculated according to the operator to obtain the calculation result; Based on the calculation result, the first ticket verification result corresponding to the element information is obtained.

13. The bill processing method according to claim 12, characterized in that, The step of replacing the first placeholder with the element information, replacing the second placeholder with the ticket verification parameter, and performing calculations on the element information and the ticket verification parameter according to the operator to obtain the calculation result includes: The pre-encapsulated ticket verification function is invoked using the ticket verification parameters and the element information as calling parameters. The ticket verification function replaces the first placeholder with the element information and the second placeholder with the ticket verification parameters, and performs calculations on the element information and the ticket verification parameters according to the operators to obtain the calculation result.

14. The bill processing method according to claim 11, characterized in that, After verifying the element information according to the verification parameters and the verification logic to obtain the first verification result, the method further includes: If the first ticket verification result indicates that the ticket verification of the element information is successful, then the additional element information of the business behavior is obtained, as well as the additional ticket verification logic from the downstream ticket verification node is obtained. Based on the additional element information and the additional ticket verification logic, construct an additional business ticket corresponding to the business behavior; The additional business ticket is signed to obtain second signature data; The business ticket, the supplementary business ticket, the first signature data, and the second signature data are transmitted to the downstream verification node. The business ticket is used by the downstream verification node to verify the element information according to the verification logic after the first signature data is successfully verified, and a second verification result is obtained. The supplementary business ticket is used by the downstream verification node to verify the supplementary element information according to the supplementary verification logic after the second signature data is successfully verified, and a third verification result is obtained.

15. A ticket processing system, characterized in that, This includes the ticket issuance node and the ticket verification node; The ticket issuing node is used to respond to the business behavior that occurs, obtain the element information of the business behavior, and obtain the ticket verification logic from the ticket verification node. The ticket issuing node is also used to construct a business ticket corresponding to the business behavior based on the element information and the ticket verification logic; The ticket issuing node is also used to sign the business ticket to obtain first signature data, and to transmit the business ticket and the first signature data to the ticket verification node. The ticket verification node is used to verify the first signature data and obtain the input ticket verification parameters according to the ticket verification logic when the verification is successful. The ticket verification node is also used to verify the element information according to the ticket verification parameters and the ticket verification logic to obtain a first ticket verification result.

16. The ticket processing system according to claim 15, characterized in that, The ticket processing system also includes downstream ticket verification nodes; If the first ticket verification result indicates that the ticket verification of the element information is successful, the ticket verification node is also used to obtain additional element information of the business behavior, and to obtain additional ticket verification logic from the downstream ticket verification node. The ticket verification node is also used to construct an additional business ticket corresponding to the business behavior based on the additional element information and the additional ticket verification logic. The ticket verification node is also used to sign the additional business ticket to obtain second signature data, and to transmit the business ticket, the additional business ticket, the first signature data and the second signature data to the downstream ticket verification node; The downstream ticket verification node is used to verify the first signature data and the second signature data, and when the verification is successful, obtain the input verification parameters according to the ticket verification logic, and obtain the input additional verification parameters according to the additional ticket verification logic. The downstream ticket verification node is also used to verify the element information according to the ticket verification parameters and the ticket verification logic to obtain a second ticket verification result; The downstream ticket verification node is also used to verify the additional element information according to the additional ticket verification parameters and the additional ticket verification logic to obtain a third ticket verification result.

17. A ticket processing device, characterized in that, include: The logic acquisition module is used to acquire the ticket verification logic and pass the ticket verification logic to the ticket issuing node; The ticket acquisition module is used to acquire the business ticket and first signature data of the business behavior transmitted by the ticket issuing node. The business ticket is constructed by the ticket issuing node based on the element information of the business behavior and the ticket verification logic. The first signature data is obtained by the ticket issuing node signing the business ticket. The parameter acquisition module is used to verify the first signature data and, when the first signature data is successfully verified, to acquire the input verification parameters according to the verification logic. The ticket verification module is used to verify the element information according to the verification parameters and the verification logic to obtain the first verification result.

18. An electronic device, characterized in that, The device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program in the memory when the electronic device is configured as a ticket verification node to implement the steps of the ticket processing method according to any one of claims 11 to 14.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for execution by a processor to implement the steps of the bill processing method according to any one of claims 11 to 14.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the bill processing method according to any one of claims 11 to 14.

Images