Invoice management method and alliance chain
Through alliance chain technology, invoice management is realized in the taxi service industry, solving the problems of complex and low security invoice reimbursement process, and automatic acquisition of decrypted invoice information, improving process simplification and data security.
Patent Information
- Application Number
- CN202411211107.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-29
- Publication Date
- 2025-03-18
AI Technical Summary
The invoice reimbursement process in the existing taxi service industry is complex and has low security, so it requires manual upload of invoice information.
Adopting alliance chain technology, through the collaborative work of the side chain and the main chain, a decryption key is generated and encrypted invoice information is transmitted, so that the user equipment can automatically obtain the decrypted invoice information.
Simplify the invoice reimbursement process, improve the security of invoice information, avoid the cumbersomeness of manual upload, and enhance the protection and privacy of data.
Smart Images
Figure CN119652539A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of taxi service technology, and in particular, relates to an invoice management method and an alliance chain. Background Art
[0002] In the modern taxi service industry, invoicing services can be provided to passengers to meet their needs for expense reimbursement. For example, if a passenger takes a taxi home after overtime work, the taxi fare can be reimbursed. However, the invoice needs to be uploaded manually during reimbursement, which makes the reimbursement process more complicated and less secure. Summary of the invention
[0003] The embodiments of the present application provide an invoice management method and an alliance chain, which can simplify the reimbursement process and improve the security of invoice information.
[0004] In a first aspect, an embodiment of the present application provides an invoice management method, which is applied to a consortium chain, wherein the consortium chain includes a main chain and a side chain, and the invoice management method includes:
[0005] When the side chain receives the invoice access request from the first user device, it generates a first decryption key according to the attribute information of the first user holding the first user device, sends the first decryption key to the first user device, and sends the invoice access request to the main chain;
[0006] After receiving the invoice access request from the side chain, the main chain determines the first target information to be accessed according to the invoice access request, and sends the first target information to the side chain, where the first target information is the encrypted invoice information;
[0007] The side chain sends the first target information to the first user equipment;
[0008] The first target information and the first decryption key are used to instruct the first user device to obtain the decrypted invoice information.
[0009] In an embodiment of the present application, when the side chain in the alliance chain receives an invoice access request from the first user device, it can generate a first decryption key based on the attribute information of the first user, send the first decryption key to the first user device, and send the above invoice access request to the main chain. The main chain can determine the first target information to be accessed based on the above invoice access request, and send the first target information to the first user device through the side chain. The first decryption key and the first target information are used to instruct the first user device to obtain the decrypted invoice information. When the user wants to reimburse the invoice information, this solution sends the first decryption key and the first target information to the user device through the alliance chain, so that the user device can obtain the invoice information for reimbursement without the need for the user to manually upload it, which simplifies the reimbursement process. In addition, the first target information obtained from the alliance chain is encrypted invoice information, which can improve the security of the invoice information.
[0010] In a second aspect, an embodiment of the present application provides a consortium chain, wherein the consortium chain includes a main chain and a side chain;
[0011] The side chain is used to generate a first decryption key according to the attribute information of the first user holding the first user device when receiving the invoice access request from the first user device, send the first decryption key to the first user device, and send the invoice access request to the main chain;
[0012] The main chain is used to determine the first target information to be accessed according to the invoice access request after receiving the invoice access request from the side chain, and send the first target information to the side chain, where the first target information is the encrypted invoice information;
[0013] The side chain is further used to send the first target information to the first user equipment;
[0014] The first target information and the first decryption key are used to instruct the first user device to obtain the decrypted invoice information.
[0015] It can be understood that the beneficial effects of the second aspect mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0017] Figure 1It is a schematic diagram of a real-time invoice management system for taxi services based on blockchain provided in an embodiment of the present application;
[0018] Figure 2 is a schematic flow chart of the invoice management method provided in the embodiment of the present application;
[0019] Figure 3 It is a schematic diagram of the structure of the alliance chain provided in the embodiment of the present application. DETAILED DESCRIPTION
[0020] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.
[0021] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.
[0022] It should also be understood that the term "and / or" used in the present specification and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations. The character " / " generally indicates that the objects associated before and after are in an "or" relationship.
[0023] It should also be understood that in the embodiments of the present application, "plurality" refers to two or more than two.
[0024] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.
[0025] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.
[0026] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.
[0027] For example, Figure 1 The following is a schematic diagram of a real-time invoice management system for taxi services based on blockchain provided by an embodiment of the present application. Figure 1 As shown, the system includes an intelligent vehicle system, a consortium chain, a passenger device, a driver device, and a company device. A passenger device may refer to a device held by a passenger, such as a passenger's mobile phone, a tablet computer, etc. A driver device may refer to a device held by a driver, such as a driver's mobile phone, a tablet computer, etc. A company device may refer to a device owned by the company, such as a company computer.
[0028] An intelligent vehicle system can be installed on the taxi, which includes functions such as global positioning system (GPS) positioning and meter. After each trip is priced, the relevant driving information can be automatically recorded, including but not limited to the start time of the trip, the end time of the trip, the start location of the trip, the end location of the trip, the total price (i.e., the total fee) and other data. The intelligent vehicle system can also record the personal information of passengers and drivers. The information recorded by the intelligent vehicle system will be used to define subsequent access control policies.
[0029] The personal information of passengers can also be referred to as passenger information, including but not limited to the passenger's mobile phone number, payment account number, ID number, etc. The personal information of drivers can also be referred to as driver information, including but not limited to the driver's mobile phone number, work number, ID number, etc.
[0030] After the trip, the smart vehicle system can automatically display the payment QR code on the display screen, and the passenger can scan the code to pay for the trip through the passenger device. The smart vehicle system can obtain the passenger information through the payment channel after the passenger scans the code to pay. If the passenger pays in cash or prohibits obtaining personal information, he or she can also choose to scan the QR code displayed on the taxi screen after the payment is completed to fill in his or her own information or the information of the company he or she works for (i.e. company information). Company information includes but is not limited to the company name, the company's taxpayer identification number, etc.
[0031] After the smart car system uploads a single trip information to the alliance chain, the taxi driver, passenger, and the company the passenger works for should have the right to view the trip information, but each of them has sensitive data that cannot be viewed by the other party. For example, the driver can view the start time, end time, and total price of the trip, but is not allowed to view passenger information, and the passenger should not have the right to view the driver information. In order to achieve different information viewing permissions for different identities and ensure the privacy of passenger and driver information, the smart car system can use attribute-based encryption (ABE) technology to encrypt the trip information, passenger information, and driver information before uploading it to the alliance chain.
[0032] Attribute-based encryption is an encryption method that can implement complex access control policies. Based on business needs, the smart vehicle system can use attribute-based encryption to formulate access control policies for each type of data. Specifically, the data is encrypted according to the user's role (driver or passenger) and its attributes, and only users who meet specific attributes can decrypt and view the data. When encrypting, define access control policies, such as "attributes containing 'driver ID = X' are accessible" and / or "attributes containing 'passenger ID = Y' are accessible" for each data item. When a driver or passenger requests access to a specific trip record, the side chain verifies whether the user's attribute information matches the data access policy. If they match, the user can decrypt and view the data.
[0033] For example, data such as the start and end time of a trip, and the total price can be set to be accessible to both drivers and passengers, but the personal information of drivers and passengers (such as ID numbers) will be subject to stricter access restrictions. Attribute tags: Associate each data item with a specific user attribute. For example, fare information can be associated with the attributes "driver ID = X" and "passenger ID = Y" to ensure that only users with these attributes can access it. Passenger information is only associated with the attribute "passenger ID = Y".
[0034] Optionally, the smart vehicle system can generate encryption keys based on the user's attribute information through the Key Management Center (KMC). KMC maintains the attribute information and corresponding keys of all users. According to the access control policy defined above, the attribute information of the corresponding user can be used to generate encryption keys to encrypt data in information such as trip information, passenger information, and driver information. In other words, each of the above information can be encrypted so that only users with the correct attribute information can decrypt and access the data. And upload the encrypted trip information, encrypted passenger information, and encrypted driver information to the alliance chain. Since this information has been encrypted, even if this information is public on the alliance chain, users without corresponding permissions cannot interpret the data content. The data is stored in an encrypted form on the alliance chain to ensure that it cannot be tampered with and difficult to access illegally.
[0035] When a user (such as a passenger or driver) needs to access a certain travel record, he or she can use the corresponding user device (such as a passenger device held by a passenger, a driver device held by a driver, etc.) to send a data access request to the alliance chain to check whether the requester's attribute information complies with the access control policy of the data item. If the requester's attribute information matches the data access policy, the decryption key is provided to the user through KMC, and the user can use this key to decrypt the data to which he or she is entitled to access.
[0036] Encrypted company information can also be stored on the alliance chain. When paying for a taxi, passengers can fill in the information of the company they work for and send the company information to the smart car system. The smart car system can encrypt the company information, obtain the encrypted company information, and upload the encrypted company information to the alliance chain. Passengers can also enter their company information, such as the name of the company, position, etc., when registering on the alliance chain or updating information on the alliance chain. The user management and access control components in the alliance chain collect and update their company information, which is stored in the central database. Each type of data in the company information is associated with the user ID for subsequent access control judgment.
[0037] It should be noted that the encryption method of company information is the same as the encryption method of itinerary information, passenger information and driver information. For details, please refer to the specific encryption scheme of itinerary information, passenger information and driver information, which will not be repeated here.
[0038] The consortium chain is a layered blockchain architecture. The consortium chain can include a main chain and at least one side chain. Users (such as passengers, drivers, or companies where passengers work, etc.) can interact with the main chain through the side chain. This can maintain the management efficiency and security of the consortium chain, achieve a balance between data security and processing efficiency, and allow a large number of dynamic users to participate in the invoice management system.
[0039] Encrypted trip information, encrypted passenger information, encrypted driver information, and encrypted company information can be stored in the side chain to achieve data isolation and protect these personal privacy information from being exposed on the main chain. The side chain can decrypt these encrypted information and encrypt them after processing. For example, the side chain can decrypt the encrypted trip information and encrypted company information to obtain the data required to generate invoice information, such as the total price, company name, taxpayer identification number, etc., and send these data to the main chain. The main chain can generate invoice information based on these decrypted data, encrypt the invoice information, obtain the encrypted invoice information and store it. Using the alliance chain to generate and store invoice information can solve the problem of fraud such as false invoices to the greatest extent.
[0040] It should be noted that the encryption method of invoice information is the same as the encryption method of itinerary information, passenger information and driver information. For details, please refer to the specific encryption scheme of itinerary information, passenger information and driver information, which will not be repeated here.
[0041] The main chain can be managed by core participants such as taxi companies, regulators and core service providers (such as technical service providers, payment processing companies, etc.), handling key business logic and data, such as invoice management and large transaction verification.
[0042] The main chain can be designed as a modular structure, with each module focusing on a specific type of business logic. For example, one module handles invoice issuance and verification, and another module handles identity authentication and permission management. Implementing strong identity authentication and permission management on the main chain ensures that all data interactions and access are performed by authenticated nodes. Public Key Infrastructure (PKI) can be used to authenticate nodes.
[0043] Among them, invoice issuance can refer to the generation of invoice information, and the invoice information refers to electronic invoice. Invoice verification can refer to the integrity check of invoice information, data consistency check (check whether the trip information on the invoice is consistent with the trip information recorded by the intelligent vehicle system), duplicate invoice check (check whether the same invoice record exists in the database of the main chain), etc. Identity authentication can refer to confirming the identity of all participants in the invoice management system (such as passengers, drivers, companies, etc.) to ensure that only legitimate users can access and operate system resources. For example, when a user uses the invoice management system for the first time, he needs to register and provide the necessary identity information. When logging in, the invoice management system verifies the user's identity through information such as username and password. Permission management can refer to defining and managing the permissions of various participants (such as taxi companies, regulators, core service providers, etc.) in the invoice management system, including data access rights, transaction verification permissions, etc.
[0044] The sidechain can be used by passengers, the company they work for, and the driver (for example, passengers and the company they work for can interact with the sidechain through the passenger device and the company device respectively). It is mainly responsible for collecting, verifying and processing passenger information, company information, driver information, and trip information, creating an independent account book for each passenger or driver, and recording personal trips and transaction history, such as trip details. The sidechain's verification of information is mainly used to ensure the integrity and accuracy of the information. For example, verify the integrity and accuracy of the detailed records of each trip, such as the start time of the trip, the end time of the trip, the start location of the trip, the end location of the trip, the total price, etc., to ensure that there are no omissions or errors in the information record. If there are omissions or errors, you can request a supplementary or retransmission from the intelligent vehicle system.
[0045] The sidechain can periodically submit aggregated and verified information to the main chain to ensure the integrity and consistency of the information. This can be achieved in the form of anchor points or summaries, and the main chain regularly checks the information submitted by the sidechain to ensure that it has not been tampered with.
[0046] End-to-end encryption technology can be used when information is stored and transmitted on the alliance chain to ensure the security of the information.
[0047] The consortium chain uses a cross-chain communication mechanism, allowing the main chain and side chain to exchange information securely and efficiently. Smart contracts are used to coordinate and process cross-chain transactions. Smart contracts automatically execute complex business logic on the main chain and side chain, such as fee settlement, invoice verification, etc. All relevant rules are encoded in the smart contract to ensure transparent and fair information processing, such as invoice generation and verification rules, data access and privacy protection rules, etc.
[0048] The embodiments of the present application utilize blockchain technology to realize the instant, secure, and tamper-proof uploading and management of invoice information in taxi services, which can not only improve the overall transparency and efficiency of taxi services, but also ensure the security and accuracy of all transaction data, effectively protect the rights and interests of passengers and service providers, and reduce the possibility of fraud and errors.
[0049] See also Figure 2 , Figure 2 The schematic flow chart of the invoice management method provided in the embodiment of the present application is shown, and the method is applied to the alliance chain, and the alliance chain includes a main chain and a side chain. As an example but not a limitation, the method includes the following steps:
[0050] Step 201, when the side chain receives an invoice access request from a first user device, it generates a first decryption key according to the attribute information of the first user holding the first user device, sends the first decryption key to the first user device, and sends the invoice access request to the main chain.
[0051] The invoice access request is used to access the encrypted invoice information stored on the main chain. The invoice information stored on the main chain is encrypted using attribute-based encryption technology. Therefore, when the encrypted invoice information needs to be decrypted, a decryption key can be generated based on the attribute information of the first user, and the encrypted invoice information can be decrypted using the decryption key to obtain the decrypted invoice information, thereby realizing access to the invoice information and simplifying the reimbursement process.
[0052] When a passenger needs to claim reimbursement from the company he / she works for, the first user device may refer to a company device, i.e., a device used by company employees (e.g., company finance personnel) to access invoice information, or a computer used by company finance personnel to access invoice information. The first user may refer to the company the passenger works for. Of course, it is understandable that the first user may also be any user such as a passenger or a driver. When the first user is a passenger, the first user device is a passenger device. When the first user is a driver, the first user device is a driver device.
[0053] In one possible implementation, when the side chain receives an invoice access request from a first user device, it determines whether the attribute information of the first user is associated with a first data type, where the first data type is invoice information, to determine whether the attribute information of the first user matches the access control policy of the invoice information; if the attribute information of the first user is associated with the first data type, it is determined that the attribute information of the first user matches the access control policy of the invoice information, and a first decryption key can be generated based on the attribute information of the first user; if the attribute information of the first user is not associated with the first data type, it is determined that the attribute information of the first user does not match the access control policy of the invoice information, which means that the first user has no authority to access the invoice information, so there is no need to generate a first decryption key based on the attribute information of the first user.
[0054] In a possible implementation, the side chain stores the second target information, which includes at least one of the encrypted trip information, the encrypted passenger information, the encrypted driver information, and the encrypted company information. Each of the second target information may include multiple data. For example, the encrypted trip information includes multiple data such as the trip start time, the trip end time, the trip start location, the trip end location, and the total price.
[0055] Users can obtain any of the above information stored on the side chain by sending a data access request to the side chain.
[0056] Specifically, when the side chain receives a data access request from a second user device, it determines whether the attribute information of the second user holding the second user device is associated with the second data type, where the second data type is the data type to be accessed by the data access request, so as to determine whether the attribute information of the second user matches the access control policy of the second data type; if the attribute information of the second user is associated with the second data type, it is determined that the attribute information of the second user matches the access control policy of the second data type, and a second decryption key can be generated based on the attribute information of the second user. According to the second decryption key, the data of the second data type can be decrypted to obtain the decrypted data; if the attribute information of the second user is not associated with the second data type, it is determined that the attribute information of the second user does not match the access control policy of the second data type, which means that the second user has no authority to access the data of the second data type and cannot successfully decrypt the data of the second data type, so there is no need to generate a second decryption key based on the attribute information of the second user.
[0057] The data access request carries a second data type.
[0058] The second user may be the same as or different from the first user, and this application does not limit this. For example, the first user is a company, and the second user may be any user such as the company, a passenger, or a driver.
[0059] As an example but not a limitation, the second data type is the total price, the second user is the passenger, and the second user device is the passenger's mobile phone. If the passenger wants to view the total price in a certain itinerary information, the passenger can send a data access request to the side chain through the mobile phone. When the side chain receives the data access request from the passenger's mobile phone, it determines whether the passenger's attribute information is associated with the total price. If so, a decryption key can be generated based on the passenger's attribute information, and the total price in the itinerary information to be accessed can be decrypted using the decryption key.
[0060] In one possible implementation, when the side chain receives an invoice access request from a first user device, it may first authenticate the first user to verify the legitimacy of the first user; if the first user passes the identity authentication, it is determined that the first user is legitimate, and a first decryption key can be generated based on the attribute information of the first user; if the first user fails the identity authentication, it is determined that the first user is illegitimate, and there is no need to generate a first decryption key based on the first user's information.
[0061] In a possible implementation, when the invoice access request carries an authorization token, the identity authentication of the first user can be implemented by verifying the validity of the authorization token. Specifically, the validity of the authorization token is verified; if the authorization token passes the verification, it is determined that the first user passes the identity authentication; if the authorization token fails the verification, it is determined that the first user fails the identity authentication.
[0062] The side chain can verify the validity of the authorization token through its signature and validity period. Checking the signature of the authorization token can ensure that the authorization token has not been tampered with. The signature can be verified using the public key. If the signature verification fails, it can be determined that the authorization token has not passed the verification, and the side chain can reject the invoice access request. Check the validity period of the authorization token to ensure that the current time is within the validity period of the authorization token. If the current time is not within the validity period of the authorization token, it can be determined that the authorization token has expired, the authorization token has not passed the verification, and the side chain can reject the invoice access request.
[0063] Step 202: After receiving the invoice access request from the side chain, the main chain determines the first target information to be accessed according to the invoice access request, and sends the first target information to the side chain, where the first target information is the encrypted invoice information.
[0064] After receiving the invoice access request forwarded by the side chain, the main chain can return the corresponding first target information to the side chain, so as to forward the first target information to the first user device through the side chain.
[0065] In one possible implementation, when the invoice access request carries an authorization token, the authorization token also includes permission information. After the main chain receives the invoice access request from the side chain, if the permission information indicates that it has access rights, the first target information is determined according to the invoice access request.
[0066] The main chain can check whether the permission information in the authorization token matches the requested operation, so as to ensure that the holder of the authorization token (i.e., the first user) has the permission to perform the requested operation and prevent privilege escalation attacks. For example, the above permission information can be permissions such as "access", "delete", and "modify". For an invoice access request, if the permission information in the authorization token is "access", the invoice access request can be executed. If the permission information in the authorization token is permissions such as "delete" and "modify", and there is no "access" permission, the invoice access request will be rejected.
[0067] In one possible implementation, the authorization token also includes a specific time and a specific data type. Based on the specific time and the specific data type, the first target information is determined. The first target information is the encrypted invoice information stored on the main chain, whose corresponding trip start time and / or trip end time is within the specific time and the data type belongs to the specific data type.
[0068] The specific time mentioned above may refer to the time period during which the passenger authorizes the company to access the data. For example, the specific time mentioned above is from May 1, 2024 to May 31, 2024.
[0069] The above-mentioned specific data types may refer to the types of accessible data that the passenger authorizes the company he / she works for, for example, the above-mentioned specific data types include invoice information, total price, and the passenger's ID number.
[0070] In one application scenario, a passenger can open a user interface through a mobile phone, and the passenger can specify the specific time and specific data type authorized to his company in the user interface. The authorization management system can generate an authorization token containing the specific time and specific data type according to the passenger's request. Of course, it is understandable that the authorization token can also include information such as permission information, validity period, specific itinerary records, etc., which is not limited in this application.
[0071] When the company that a passenger works for needs to apply for reimbursement of the invoice information of a certain trip of the passenger, the passenger can directly authorize the company to view the invoice information of the trip through the authorization token. There is no need to enter it manually. The company can view it directly through the alliance chain. This can not only reduce the tediousness of manually uploading invoices, but also prevent passengers from using false invoices for reimbursement.
[0072] In another possible implementation, when the invoice access request carries a target invoice number, the main link can determine the first target information based on the target invoice number, and the first target information is the encrypted invoice information whose invoice number stored on the main link is the target invoice number.
[0073] The target invoice number is the invoice number of the invoice information that the first user wants to access.
[0074] If the passenger directly fills in the company information when paying for a taxi fare for a certain trip, the passenger can also directly provide the company with the invoice number. The company can directly find the invoice information for the trip through the invoice number on the alliance chain. This can not only reduce the tediousness of manually uploading invoices, but also prevent passengers from using false invoices for reimbursement.
[0075] In another possible implementation, the main chain can also determine the target ride order based on the identity information of the first user, where the target ride order is the ride order bound to the identity information of the first user; based on the target ride order, determine the first target information, where the first target information is the encrypted invoice information corresponding to the target ride order stored on the main chain.
[0076] When the first user is a company, the identity information of the first user may refer to company information.
[0077] When passengers pay for taxi fares, the on-board intelligent system is prohibited from obtaining personal information. Instead, they can directly fill in the order with the information of the company they work for. The order can be directly bound to the passenger's company (that is, the ride order is bound to the company information). When the company wants to access the invoice information of a certain order, it can directly access it without the passenger's authorization. This can not only reduce the tediousness of manually uploading invoices, but also prevent passengers from using false invoices for reimbursement.
[0078] Step 203: The side link sends first target information to the first user equipment.
[0079] The first target information and the first decryption key are used to instruct the first user device to obtain the decrypted invoice information.
[0080] After receiving the first target information and the first decryption key from the side chain, the first user device can use the first decryption key to decrypt the first target information, thereby obtaining the decrypted invoice information, realizing access to the invoice information, and simplifying the reimbursement process of the invoice information.
[0081] In this embodiment, when a user wants to reimburse invoice information, the first decryption key and the first target information are sent to the user device through the alliance chain, so that the user device can obtain the invoice information for reimbursement without the need for the user to manually upload it, thereby simplifying the reimbursement process. In addition, the first target information obtained from the alliance chain is encrypted invoice information, which can improve the security of the invoice information.
[0082] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.
[0083] Corresponding to the invoice management method described in the above embodiment, Figure 3 A schematic diagram of the structure of the alliance chain provided in an embodiment of the present application is shown. For the sake of convenience of explanation, only the parts related to the embodiment of the present application are shown.
[0084] Reference Figure 3 , the alliance chain includes a main chain 301 and a side chain 302;
[0085] The side chain 302 is used to generate a first decryption key according to the attribute information of the first user holding the first user device when receiving the invoice access request from the first user device, send the first decryption key to the first user device, and send the invoice access request to the main chain 301;
[0086] The main chain 301 is used to determine the first target information to be accessed according to the invoice access request after receiving the invoice access request from the side chain, and send the first target information to the side chain 302, where the first target information is the encrypted invoice information;
[0087] The side chain 302 is further used to send the first target information to the first user equipment;
[0088] The first target information and the first decryption key are used to instruct the first user device to obtain the decrypted invoice information.
[0089] Optionally, the side chain 302 is specifically used for:
[0090] When the invoice access request is received from the first user device, the first user is authenticated; if the first user passes the authentication, the first decryption key is generated according to the attribute information of the first user.
[0091] Optionally, when the invoice access request carries an authorization token, the side chain 302 is specifically used to:
[0092] Verifying the validity of the authorization token;
[0093] If the authorization token passes the verification, it is determined that the first user passes the identity authentication;
[0094] If the authorization token fails to be verified, it is determined that the first user fails to pass the identity authentication.
[0095] Optionally, the authorization token also includes permission information. The main chain 301 is specifically used for:
[0096] After receiving the invoice access request from the side chain, the main chain determines the first target information according to the invoice access request if the permission information indicates that the access right exists.
[0097] Optionally, the authorization token includes a specific time and a specific data type. The main chain 301 is specifically used for:
[0098] The first target information is determined according to the specific time and the specific data type, where the first target information is the encrypted invoice information stored on the main chain, whose corresponding trip start time or trip end time is within the specific time and whose data type belongs to the specific data type.
[0099] Optionally, when the invoice access request carries a target invoice number, the main chain 301 is specifically used to:
[0100] The first target information is determined according to the target invoice number, where the first target information is the encrypted invoice information whose invoice number is the target invoice number and is stored on the main chain.
[0101] Optionally, the main chain 301 is specifically used for:
[0102] Determine a target ride order according to the identity information of the first user, where the target ride order is a ride order bound to the identity information of the first user;
[0103] The first target information is determined according to the target ride order, where the first target information is the encrypted invoice information corresponding to the target ride order and stored on the main chain.
[0104] Optionally, the side chain 302 is specifically used for:
[0105] Upon receiving the invoice access request from the first user device, determining whether the attribute information of the first user is associated with a first data type, the first data type being invoice information;
[0106] If the attribute information of the first user is associated with the first data type, the first decryption key is generated according to the attribute information of the first user.
[0107] Optionally, the side chain 302 stores second target information, and the second target information includes at least one of encrypted trip information, encrypted passenger information, encrypted driver information, and encrypted company information; the side chain 302 is also used for:
[0108] Upon receiving a data access request from a second user device, determining whether attribute information of a second user holding the second user device is associated with a second data type, the second data type being the data type to be accessed by the data access request;
[0109] If the attribute information of the second user is associated with the second data type, generating a second decryption key according to the attribute information of the second user;
[0110] The data of the second data type is decrypted according to the second decryption key to obtain decrypted data.
[0111] It should be noted that the information interaction, execution process, etc. between the above-mentioned main chain and the side chain are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part, and will not be repeated here.
[0112] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0113] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0114] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.
Claims
1. An invoice management method, characterized in that: Applied to a consortium chain, the consortium chain includes a main chain and a side chain, and the invoice management method includes: When the side chain receives the invoice access request from the first user device, it generates a first decryption key according to the attribute information of the first user holding the first user device, sends the first decryption key to the first user device, and sends the invoice access request to the main chain; After receiving the invoice access request from the side chain, the main chain determines the first target information to be accessed according to the invoice access request, and sends the first target information to the side chain, where the first target information is the encrypted invoice information; The side chain sends the first target information to the first user equipment; The first target information and the first decryption key are used to instruct the first user device to obtain the decrypted invoice information.
2. The invoice management method according to claim 1, characterized in that: When the side chain receives the invoice access request from the first user device, it generates a first decryption key according to the attribute information of the first user holding the first user device, including: When the side chain receives the invoice access request from the first user device, it authenticates the first user; if the first user passes the authentication, it generates the first decryption key according to the attribute information of the first user.
3. The invoice management method according to claim 2, characterized in that: In the case where the invoice access request carries an authorization token, authenticating the first user includes: Verifying the validity of the authorization token; If the authorization token passes the verification, it is determined that the first user passes the identity authentication; If the authorization token fails to be verified, it is determined that the first user fails to pass the identity authentication.
4. The invoice management method according to claim 3, characterized in that: The authorization token also includes permission information. After receiving the invoice access request from the side chain, the main chain determines the first target information to be accessed according to the invoice access request, including: After receiving the invoice access request from the side chain, the main chain determines the first target information according to the invoice access request if the permission information indicates that the access right exists.
5. The invoice management method according to claim 4, characterized in that: The authorization token includes a specific time and a specific data type, and the determining the first target information according to the invoice access request includes: The first target information is determined according to the specific time and the specific data type, where the first target information is the encrypted invoice information stored on the main chain, whose corresponding trip start time or trip end time is within the specific time and whose data type belongs to the specific data type.
6. The invoice management method according to claim 1, characterized in that: In the case where the invoice access request carries a target invoice number, determining the first target information to be accessed according to the invoice access request includes: The first target information is determined according to the target invoice number, where the first target information is the encrypted invoice information whose invoice number is the target invoice number and is stored on the main chain.
7. The invoice management method according to claim 1, characterized in that: The determining the first target information to be accessed according to the invoice access request includes: Determine a target ride order according to the identity information of the first user, where the target ride order is a ride order bound to the identity information of the first user; The first target information is determined according to the target ride order, where the first target information is the encrypted invoice information corresponding to the target ride order and stored on the main chain.
8. The invoice management method according to any one of claims 1 to 7, characterized in that: When the side chain receives the invoice access request from the first user device, it generates a first decryption key according to the attribute information of the first user holding the first user device, including: When the side chain receives the invoice access request from the first user device, it determines whether the attribute information of the first user is associated with a first data type, where the first data type is invoice information; If the attribute information of the first user is associated with the first data type, the first decryption key is generated according to the attribute information of the first user.
9. The invoice management method according to any one of claims 1 to 7, characterized in that: The side chain stores second target information, wherein the second target information includes at least one of encrypted trip information, encrypted passenger information, encrypted driver information, and encrypted company information; The invoice management method further includes: When receiving a data access request from a second user device, the side chain determines whether the attribute information of a second user holding the second user device is associated with a second data type, where the second data type is the data type to be accessed by the data access request; If the attribute information of the second user is associated with the second data type, generating a second decryption key according to the attribute information of the second user; The data of the second data type is decrypted according to the second decryption key to obtain decrypted data.
10. A consortium chain, characterized in that: The alliance chain includes a main chain and a side chain; The side chain is used to generate a first decryption key according to the attribute information of the first user holding the first user device when receiving the invoice access request from the first user device, send the first decryption key to the first user device, and send the invoice access request to the main chain; The main chain is used to determine the first target information to be accessed according to the invoice access request after receiving the invoice access request from the side chain, and send the first target information to the side chain, where the first target information is the encrypted invoice information; The side chain is further used to send the first target information to the first user equipment; The first target information and the first decryption key are used to instruct the first user device to obtain the decrypted invoice information.