Permission synchronization method, high-permission function execution method and cloud server

Abstract

The invention relates to the technical field of information processing and authority management, and discloses an authority synchronization method, a high-authority function execution method and a cloud server. The permission synchronization method is applied to a cloud server, the cloud server is connected with payment equipment, and the method comprises the steps that an authorization strategy file is acquired, and the authorization strategy file comprises use permission rules of the payment equipment; generating an authorization token by using an encryption algorithm according to the authorization strategy file; and storing the authorization token, and issuing the authorization token to payment equipment corresponding to the authorization token to realize strategy synchronization with the payment equipment. Through the execution of the process, the instant and safe synchronization of the authority rule from the cloud server to the payment equipment is realized, the payment equipment is ensured to activate and execute the purchased function of the client after receiving the authorization token, and the payment equipment is prevented from being incapable of executing the existing function.

Description

Technical Field

[0001] This invention relates to the field of information processing and access control technology, specifically a method for access control synchronization, a method for executing high-privilege functions, and a cloud server. Background Technology

[0002] In related technologies, the functional configuration on the cloud server cannot be synchronized with the payment device in real time. After a customer purchases a function, the device cannot perform the corresponding function due to the mismatch in configuration, which greatly affects the user experience. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a permission synchronization method to realize the synchronization of functional permissions between cloud servers and payment devices, and to ensure that payment devices can perform functions.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A permission synchronization method is applied to a cloud server, the cloud server being connected to a payment device, the method comprising: Obtain the authorization policy file, which includes the usage permission rules for the payment device; Based on the authorization policy file, an authorization token is generated using an encryption algorithm; The authorization token is saved and sent to the payment device corresponding to the authorization token to achieve synchronization with the payment device policy.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A method for executing high-privilege functions, applied to a cloud server, wherein the cloud server connects a user terminal and a payment device, the method comprising: The system receives a high-privilege function configuration task from the user terminal, which is used to configure the functions of the payment device. An authorization token is generated based on the high-privilege function configuration task; the authorization token is generated according to one of the above-described permission synchronization methods. The authorization token is used to perform an initial verification of the high-privilege function configuration task. After the initial verification is successful, the configuration task and the authorization token are sent to the payment device, and a secondary verification instruction is sent at the same time. The secondary verification instruction is used to drive the payment device to call the authorization token to perform a secondary verification of the high-privilege function configuration task, and execute the high-privilege function configuration task after the verification is successful. Receive the execution result returned by the payment device.

[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A cloud server includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described permission synchronization method or the steps of the above-described high-privilege function execution method.

[0007] The beneficial effects of this invention are as follows: To address the issue of inability to execute purchased functions on payment devices due to the lack of real-time synchronization of function permission configurations between cloud servers and payment devices, this application proposes a permission synchronization method executed on the cloud server side. First, an authorization policy file containing the usage permission rules for payment devices is obtained, providing a structured and accurate basis for synchronization. Then, an authorization token is generated using an encryption algorithm and written to the corresponding payment device. By transforming permission information into a secure and tamper-proof credential, the security of the transmission process is ensured. Through this process, the permission rules are synchronized instantly and securely from the cloud server to the payment device, ensuring that the payment device can activate and execute the customer's purchased functions immediately upon receiving the authorization token, preventing the payment device from being unable to execute existing functions. By customizing the authorization policy file, the authorization policy requirements in complex business scenarios can be met, making management more flexible and diverse, and improving the user experience. Attached Figure Description

[0008] Figure 1 A flowchart illustrating the steps of a permission synchronization method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the steps of a high-privilege function execution method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a cloud server provided in an embodiment of the present invention. Detailed Implementation

[0009] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0012] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0013] Basic functions of a POS system are typically enabled by default after device purchase, while advanced functions require additional purchase or authorization from the customer. In traditional authorization models, advanced functions often employ single-end control, verifying only at the POS terminal. This leads to issues such as inconsistent authorization status between the management end and the terminal, susceptibility to tampering of authorization information, and insufficient security. Furthermore, this model lacks flexible group authorization strategies, making it difficult to support subscription-based service requirements, and business operations are easily affected by network outages.

[0014] As POS systems gradually transition to a SaaS (Software as a Service) model, the industry is placing higher demands on differentiated feature openness, unified cross-platform permissions, and business continuity. While cloud servers can configure rich advanced features for payment devices, a significant drawback remains: the function permission configuration on the cloud server cannot be reliably synchronized with the payment device in real time. When a customer completes a feature purchase or update in the cloud, the payment device often cannot obtain the latest permissions in a timely manner, causing authorized functions to malfunction and severely impacting user experience and service timeliness. The system needs to ensure that control commands issued from the cloud (such as POS machine lock commands) can be reliably received and executed by the terminal device. This process relies on real-time synchronization of the configuration status between the cloud and the device. If the device fails to successfully synchronize and update its local configuration, even if a command has been issued from the cloud, the command will not take effect on the device.

[0015] Therefore, how to achieve secure, flexible, and real-time synchronization of permission information between cloud servers and payment devices has become a key technical challenge for improving system reliability and supporting SaaS service models.

[0016] To address the aforementioned issues, this application provides a permission synchronization method that synchronizes the functional permissions of the cloud server and the payment device, ensuring that the payment device can perform its functions.

[0017] The following describes in detail a permission synchronization method of the present invention, applied to a cloud server. The cloud server connects to a payment device, as shown in the appendix. Figure 1 This includes steps 110-130.

[0018] Step 110: Obtain the authorization policy file, which includes the usage permission rules for the payment device. The usage permission rules include a list of basic and advanced functions that the customer can access.

[0019] Step 120: Generate an authorization token using an encryption algorithm based on the authorization policy file. The encryption algorithm can be RSA or ECC.

[0020] Step 130: Save the authorization token and send it to the payment device corresponding to the authorization token to achieve synchronization with the payment device policy.

[0021] As described above, to address the issue of inability to execute purchased functions after they have been purchased due to the lack of real-time synchronization of function permission configurations between the cloud server and the payment device, this application first obtains an authorization policy file containing the payment device's usage permission rules. This provides a structured and accurate basis for synchronization. Then, an authorization token is generated using an encryption algorithm and written to the corresponding payment device. By transforming permission information into a secure and tamper-proof credential, the security of the transmission process is ensured. Through this process, this application achieves instant and secure synchronization of permission rules from the cloud server to the payment device, ensuring that the payment device can activate and execute the customer's purchased functions immediately upon receiving the authorization token, thus preventing the payment device from being unable to execute existing functions.

[0022] In one embodiment of this application, before step 110 obtains the authorization policy file, the method further includes: The system obtains the target characteristics of payment devices, preset grouping rules, and usage permission rules for payment devices. Among these, the target characteristics include merchant ID, store ID, device serial number, geographical location, user behavior characteristics, subscription level, and affiliated institution information.

[0023] The target features are grouped using preset grouping rules to obtain grouping information. The corresponding usage permission rules for each group are then located, and an authorization policy file is generated based on these rules. The preset grouping rules include geolocation rules, organizational level rules, subscription level rules, device characteristic rules, user behavior rules, function combination rules, and security and compliance rules. The grouping rules also support hierarchical nesting, including region level, business type level, subscription level level, and organizational level, meeting the authorization policy requirements of complex business scenarios. At the organizational level, multiple charging models (fully free, fully charged, partially charged) can be configured and combined with other dimensions (region, business type, etc.) to form differentiated authorization and billing policies, thus satisfying the authorization policy requirements of complex business scenarios.

[0024] As described above, this application can collect customer information from multiple dimensions, including the management terminal of the cloud server and the POS terminal, as target features. A preset rule engine dynamically analyzes these features based on preset grouping rules, automatically grouping them to obtain group information. Then, based on the usage permission rules corresponding to the group information, an authorization policy file is generated. The aforementioned target features ensure the data foundation for grouping, while the usage permission rules map the grouping results to specific permission rules and generate the authorization policy file. The effect is that it can dynamically and accurately generate authorization policy files based on the objective attributes of the devices, significantly improving the efficiency and accuracy of policy file generation and avoiding omissions and inconsistencies that may arise from manual configuration.

[0025] In one embodiment of this application, step 120, which generates an authorization token using an encryption algorithm based on the authorization policy file, further includes: Obtain the validity period information of the rules controlling usage permissions; Add the expiration date information to the authorization policy file; Authorization tokens are generated using an asymmetric encryption algorithm based on the authorization policy document.

[0026] The authorization policy file may also include the following: 1. Customer identification information: This includes merchant identification, store identification, device serial number, affiliated organization identification, etc., which are used to uniquely identify customers and terminals.

[0027] 2. Customer grouping information: Grouping and hierarchical nesting based on multi-dimensional features, used to determine the scope of permissions.

[0028] 3. Function permission set: A list of basic and advanced functions that customers can access.

[0029] 4. Institution and subscription strategy identifier: Pricing model, subscription level or package type, used for differentiated control and billing.

[0030] 5. Validity Information: Authorization start and end time or token validity period, controlling the duration of access permissions. Device Binding Information: Binding terminal serial number or hardware ID, preventing token abuse across devices.

[0031] 6. Extended Fields: Reserved fields for future additions of features or strategy dimensions.

[0032] Specifically, this solution integrates the validity period information into the authorization policy file by obtaining the set validity period. The introduction of validity period information sets a clear time boundary for permission granting, enabling lifecycle management of tokens based on validity periods. When a token reaches its preset validity period, a customer's subscription expires, or abnormal behavior is detected, the terminal verifies the token's invalidity through a hardware security module, rejects function calls, and reports to the cloud service management terminal. When a token is nearing its expiration date or a customer renews their subscription, the management terminal generates a new authorization policy file and a new token, which is then sent to the terminal via secure communication to replace the old token, achieving seamless renewal. When a customer cancels their subscription, the device is scrapped, or the token is found to have been tampered with / stolen, the management terminal pushes a revocation command to the terminal. The terminal deletes or marks the token as invalid, stops function calls, and records a recycling log for auditing purposes.

[0033] As described above, this scheme generates tokens using an asymmetric encryption algorithm based on the authorization policy document with an expiration date. Leveraging the public-key encryption and private-key decryption characteristics, it ensures the unforgeability and credible origin of the authorization tokens. This scheme effectively prevents authorization tokens from being tampered with or misused beyond their expiration date, thereby significantly improving security levels and fine-grained control capabilities.

[0034] In one embodiment of this application, step 130, which involves saving the authorization token and sending it to the payment device corresponding to the authorization token, further includes: The version information of the authorization token is recorded. When a new token is generated or a policy is updated on the management terminal of the cloud server, the version number or timestamp is recorded. At the same time, when the local token is updated or renewed on the POS terminal, the version number or timestamp is also recorded.

[0035] A copy of the authorization token is stored. Both the management end and the terminal store copies of the token, with the terminal storing them preferentially in the HSM / TPM to prevent tampering or unauthorized extraction.

[0036] At preset time intervals, the version information and the version information of the authorization token on the payment device are verified. If the verification results are inconsistent, a token copy is issued to replace the authorization token on the payment device.

[0037] Specifically, the management terminal can proactively push updated tokens to the terminals. The terminals can periodically retrieve the latest tokens from the management terminal to maintain synchronization. When both terminals update tokens simultaneously, the final token is determined by a priority rule based on version number or timestamp, and then synchronously overwrites the other terminal.

[0038] As described above, this solution constructs a synchronous update and automatic recovery mechanism for authorization tokens by introducing version information, token copies, and preset time interval verification features. Recording version information identifies the status of the authorization token, providing a reliable source for restoring token copies, while the preset time interval verification proactively detects and corrects inconsistencies in token versions on payment devices. This application ensures that the authorization tokens on payment devices are always in an up-to-date and valid state, effectively preventing business interruptions caused by expired or abnormal token versions, thereby improving the reliability and continuity of payment system access control.

[0039] In one embodiment of this application, step 130, which involves saving the authorization token and sending it to the payment device corresponding to the authorization token, includes: The authorization token is sent to the payment device corresponding to the authorization token using a secure communication protocol.

[0040] As described above, this scheme uses a secure communication protocol to issue tokens, enhancing the security of the authorization token transmission process. Employing secure communication protocols (such as HTTPS and TLS) establishes an encrypted channel in the transmission link of the authorization token from the server to the payment device, effectively resisting man-in-the-middle attacks such as network eavesdropping and data tampering. This scheme ensures the confidentiality and integrity of this critical and sensitive information during transmission, preventing the token from being intercepted or destroyed during the distribution stage, thereby improving the security level of the entire authorization management system from the communication level.

[0041] In one embodiment of this application, it further includes: Receive the token status from the payment device. The token status includes validity period information and version information. If both the validity period information and version information pass verification, then the usage permission rules will be granted to the payment device.

[0042] As described above, the cloud server's management console can receive the token status of payment devices. The token includes validity period information, version information, and security fields such as customer group information, institution charging policy identifier, function permission set, and device binding information. The received validity period and version information are then verified. If the token has expired, been revoked, or the version is incompatible, the corresponding permissions are not granted, and function call requests are blocked. This solution verifies the token's validity on the management console, improving security and ensuring that only valid tokens can use advanced functions.

[0043] In one embodiment of this application, it further includes: Obtain the unique hardware identifier of the payment device; Add a unique hardware identifier to the authorization token.

[0044] Specifically, when a payment device is activated or reactivated for the first time, the cloud server reads and obtains the device's unique hardware identifier (such as device serial number, TPM key, or HSM key ID) through a standard interface, and uses an encryption algorithm to bind the unique hardware identifier with an authorization token to generate an authorization token containing the unique hardware identifier. When the POS terminal calls a function, its hardware security module reads the local device identifier and compares it with the token binding information. If they match, the call is allowed; otherwise, the operation is rejected, thereby preventing the token from being used illegally on other devices.

[0045] As described above, this application achieves real-time and reliable synchronization of permission information between the cloud server and the payment device by introducing a binding mechanism between a unique hardware identifier and an authorization token. Specifically, the addition of a unique hardware identifier makes the authorization token device-specific, effectively preventing the unauthorized use of the token across devices; the application of encryption algorithms ensures the security of the binding process and prevents the authorization information from being tampered with; and the verification mechanism of the hardware security module guarantees the reliable execution of permission verification, maintaining business continuity even in the event of a network outage.

[0046] In one embodiment of this application, it further includes: Receive status change notifications; Update the contents of the authorization policy file according to the status change notification; Generate a new authorization token based on the updated authorization policy file; Save the new authorization token to the payment device corresponding to the new authorization token.

[0047] Specifically, the cloud server receives a status change notification from the management terminal, updates the content of the authorization policy file according to the notification, generates a new authorization token based on the updated authorization policy file, and securely distributes the new authorization token to the corresponding payment device. By periodically comparing the version number, check value, or signature of the tokens on the management terminal and the terminal, the system automatically detects the consistency of the authorization status. When an anomaly is detected, the system uses the management terminal as the authoritative source and remotely overwrites the abnormal copy of the terminal with the latest token through a secure channel, while recording the synchronization anomaly and repair operation logs.

[0048] As described above, this application achieves real-time synchronization and self-healing of permission information between the cloud server and payment devices through a state change notification mechanism and an automatic consistency repair strategy. State change notifications ensure timely triggering of permission updates, dynamic updates to the authorization policy file support flexible permission configuration, provide a reliable consistency detection method for version number and checksum comparison, and a remote overwrite strategy based on management authority guarantees rapid recovery from abnormal states. Therefore, this application improves system reliability through an automated synchronization repair mechanism, while comprehensive logging provides a basis for audit trails, fully supporting the high standards of business continuity and security required in a SaaS service model.

[0049] The following describes in detail a high-privilege function execution method of the present invention, applied to a cloud server, which connects a user terminal and a payment device, as shown in the appendix. Figure 2 This includes steps 210-270: Step 210: Receive a high-privilege function configuration task from the user client. This task is used to configure the payment device's functions. Banks and intermediaries initiate high-privilege configuration tasks on the cloud server to configure the payment device's functions. Corresponding functions can be added to the payment device; these functions primarily target POS management, including advanced features such as device locking and unlocking.

[0050] Step 220: Generate an authorization token based on the high-privilege function configuration task; the authorization token is generated according to one of the above-mentioned permission synchronization methods; Step 230: Use the authorization token to perform the initial verification of the high-privilege function configuration task; perform the initial verification on the cloud server side to filter illegal requests, and then perform a second verification on the payment device side through the local verification module using the same authorization token.

[0051] Step 240: After the initial verification is successful, the configuration task and authorization token are sent to the payment device, and a secondary verification instruction is sent at the same time. The secondary verification instruction is used to drive the payment device to call the authorization token to perform a secondary verification of the high-privilege function configuration task, and execute the high-privilege function configuration task after the verification is successful. Step 250: Receive the execution result returned by the payment device. The execution result is generated by the payment device based on the secondary verification instruction, calling the local verification module to perform secondary verification of the authorization token, and then executing the configuration task. Step 260: Receive requests from payment devices to invoke target permissions; that is, the cloud server can receive requests from payment devices to invoke target permissions. Before the POS terminal invokes advanced functions, the authorization token must be verified for integrity, validity, and device binding through the hardware security module. The locally stored authorization token is hashed or its signature is verified through the hardware security module. The module compares the calculation result with the signature or hash value pre-embedded in the token. If they match, it means the token has not been tampered with; otherwise, the function call is rejected and an exception log is recorded. The module also checks the validity period field, subscription status, or version number in the token. If the token has expired, been revoked, or the version does not match, the function call is blocked, and the status is reported to the management terminal to ensure that only valid tokens can use advanced functions. Simultaneously, the POS terminal sets multi-level verification strategies based on the permission levels and call frequencies of different advanced functions. For example, for highly sensitive permissions or high-value transaction functions, the hardware security module requires full verification of integrity, validity, and device binding upon the first call. If the function is called frequently in a short period of time, a fast verification mode can be adopted, which only checks the validity of the token and device binding, skipping hash or signature calculations to improve performance. For low-sensitive permissions or low-value functions, only basic device binding verification is required for each call.

[0052] Step 270: Based on the authorization token verification request, if the verification is successful, the target permissions are granted to the payment device; after the POS terminal calls the advanced function, the cloud server verifies the authorization token, and if the verification is successful, the permissions for the corresponding function are granted to the payment device.

[0053] As described above, this application's method for executing high-privilege functions allows the user client to configure high-privilege functions, then distribute the configured tasks and authorization tokens to the payment device. Upon receiving the configuration task and verifying the authorization token, the payment device can securely configure the corresponding functions and initiate corresponding function execution requests. This achieves secure function distribution and secure, real-time, and flexible synchronous execution of high-privilege functions on both ends. Through a layered strategy, the security of high-risk operations is ensured while reducing the performance impact of frequent calls.

[0054] The following is a specific application example of this application: Customer information is collected from multiple dimensions, including the management terminal of the cloud server and the payment device terminal, as target features. A preset rule engine is used to dynamically analyze these target features based on preset grouping rules, which include: 1. Geographic location rules: Group stores by different cities, regions or store types. For example, stores in first-tier cities can have full functionality enabled, while stores in high-risk areas have limited functionality. Differentiated pricing and function authorization by region are supported.

[0055] 2. Organizational hierarchy rules: Grouped by parent company, subsidiary, and branch. For example, the headquarters has all functions, while some functions of subsidiaries are restricted, supporting differentiated management and authorization of multi-level organizations.

[0056] 3. Subscription tier rules: Divided according to subscription packages (free, basic, premium, VIP). For example, premium subscriptions can use promotional features, while basic subscriptions are limited to sales statistics. Differentiated subscription services and billing strategies are supported.

[0057] 4. Device characteristic rules: Group by device type, serial number, model or hardware capabilities. For example, new POS terminal models enable the latest functions, while older models retain only core functions to ensure functional compatibility and security of different devices.

[0058] 5. User behavior rules: Group users based on their behavior or historical operations. For example, high-frequency users can have access to quick features, while low-frequency users have limited features by default. This fine-grained feature control improves user experience and resource utilization efficiency.

[0059] 6. Function combination rules: Combine function permissions for specific business scenarios. For example, the promotion function must be enabled at the same time as the inventory management function to be used, to ensure the integrity of function call logic and prevent permission abuse.

[0060] 7. Security and Compliance Rules: Adjust permissions based on risk level, abnormal behavior, or violation records. For example, automatically downgrade some functions for stores that detect abnormal transactions to improve system security and prevent abuse or attacks.

[0061] Based on the aforementioned preset rules, the engine analyzes customer characteristics to achieve automated customer grouping and obtain grouping information.

[0062] Banks and intermediaries, as users, can configure corresponding functions for payment devices through the management terminal. They can also adjust customer groups and permission assignments in real time via drag-and-drop operations in the visual authorization policy management interface of the management terminal. Each adjustment triggers the system to regenerate the authorization policy file. The system then retrieves the adjusted authorization policy file, corresponding to step 110 above. Based on this file, a new authorization token is generated using the ECC algorithm. The token contains security fields such as customer group information, institution fee policy identifier, function permission set, device binding information, and validity period, corresponding to step 120 above.

[0063] The updated authorization token is securely distributed to the payment device using the TLS secure communication protocol to ensure that the authorization status of the management terminal and the payment device remains consistent. This corresponds to step 130 above. A multi-level local cache is designed on the payment device to cache valid authorization tokens and related metadata, supporting short-term business continuity during network outages. The offline caching strategy combines timestamps and expiration control to ensure that expired tokens automatically become invalid, preventing long-term unauthorized use. When the payment device connects to the network periodically, it automatically synchronizes with the management terminal to complete token renewal and status verification, ensuring real-time authorization updates.

[0064] When a subscription expires, the default rules engine detects a change in subscription status and automatically marks the customer's group permissions as "expired" or "downgraded," updating the availability and validity fields of the corresponding functions in the authorization policy file. A new authorization token is then generated and synchronized to the payment device. During subsequent function call verification, the payment device automatically performs function disabling or downgrading operations based on the updated permissions, thus achieving intelligent revocation of permissions.

[0065] Please refer to Figure 3 The present invention also provides a cloud server 300, including a processor 301 and a memory 302, and a computer program stored on the memory 302 and running on the processor 301. When the processor 301 executes the computer program, it implements the steps of the permission synchronization method described above or the steps of the high-privilege function execution method described above.

[0066] The beneficial effects of the cloud server of the present invention are the same as those of the above method, and will not be repeated here.

[0067] In summary, this invention proposes a permission synchronization method, a high-privilege function execution method, and a cloud server. First, an authorization policy file containing payment device usage permission rules is obtained, providing a structured and accurate permission basis for synchronization. Then, an authorization token is generated using an encryption algorithm and written to the corresponding payment device. By transforming permission information into a secure and tamper-proof credential, the security of the transmission process is ensured. Through this process, permission rules are synchronized instantly and securely from the cloud server to the payment device, ensuring that the payment device can activate and execute the customer's purchased functions immediately upon receiving the authorization token, preventing the payment device from being unable to execute existing functions. This invention also allows the user terminal to configure high-privilege functions and then send the configured task and authorization token to the payment device. After receiving the configuration task and verifying the authorization token, the payment device can securely configure the corresponding function and initiate the corresponding function execution request, achieving secure function distribution and secure, real-time, and flexible synchronous execution of high-privilege functions on both ends. Through a layered strategy, the security of high-risk operations is guaranteed while reducing the performance impact of frequent calls. Furthermore, the token in this invention is preferentially stored in the hardware security module and verified before function calls. It supports event-driven policy adjustments and automatic revocation, and features offline authorization caching, periodic renewal, multi-dimensional logging, and anomaly detection capabilities, enabling flexible and secure authorization and billing management across multiple organizations and scenarios.

[0068] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method of synchronizing permissions, the method comprising: The method is applied to a cloud server connected with a payment device, and comprises the following steps: obtaining an authorization policy file, wherein the authorization policy file comprises a use permission rule of the payment device; generating an authorization token by using an encryption algorithm according to the authorization policy file; storing the authorization token and issuing the authorization token to the payment device corresponding to the authorization token to realize policy synchronization with the payment device.

2. The method of claim 1, wherein, Before the step of obtaining the authorization policy file, the method further comprises the following steps: obtaining a target feature of the payment device, a preset grouping rule and a use permission rule of the payment device; grouping the target feature by using the preset grouping rule to obtain grouping information, finding a use permission rule corresponding to the grouping information, and generating an authorization policy file according to the use permission rule.

3. The method of claim 2, wherein, In the step of generating the authorization token by using the encryption algorithm according to the authorization policy file, the method further comprises the following steps: obtaining validity information for controlling the use permission rule; adding the validity information into the authorization policy file; generating the authorization token by using an asymmetric encryption algorithm according to the authorization policy file.

4. The method of claim 1, wherein, In the step of storing the authorization token and issuing the authorization token to the payment device corresponding to the authorization token, the method further comprises the following steps: recording version information of the authorization token; storing a token copy of the authorization token; checking the version information and version information of the authorization token on the payment device every interval of a preset time period, and issuing the token copy to replace the authorization token on the payment device if the checking result is inconsistent.

5. The method of claim 1, wherein, In the step of storing the authorization token and issuing the authorization token to the payment device corresponding to the authorization token, the method further comprises the following step: issuing the authorization token to the payment device corresponding to the authorization token by using a secure communication protocol.

6. The method of claim 1, wherein, The method further comprises the following steps: receiving token state of the payment device, wherein the token state comprises validity information and version information; opening the use permission rule to the payment device if the validity information and the version information are verified.

7. The method of claim 3, wherein, The method further comprises the following steps: obtaining a hardware unique identifier of the payment device; adding the hardware unique identifier into the authorization token.

8. The method of claim 1, wherein, The method further comprises the following steps: receiving a state change notification; updating content of the authorization policy file according to the state change notification; generating a new authorization token according to the updated authorization policy file; storing the new authorization token to the payment device corresponding to the new authorization token.

9. A high-privilege function execution method characterized by comprising: The method is applied to a cloud server connected with a user terminal and a payment device, and comprises the following steps: receiving a high-privilege function configuration task from the user terminal, wherein the high-privilege function configuration task is used for function configuration of the payment device; generating an authorization token based on the high-privilege function configuration task, wherein the authorization token is generated according to the permission synchronization method in claim 1; performing first verification on the high-privilege function configuration task by using the authorization token; issuing the configuration task and the authorization token to the payment device after the first verification passes, and simultaneously issuing a second verification instruction, wherein the second verification instruction is used to drive the payment device to call the authorization token to second verify the high-privilege function configuration task, and execute the high-privilege function configuration task after the second verification passes. Receiving the execution result returned by the payment device. 10.A cloud server, comprising a memory and a processor, wherein the memory stores a computer program, and the cloud server is configured to perform the method according to any one of claims 1-9. The processor implements the steps of the permission synchronization method in any one of claims 1 to 8 or the steps of the high-permission function execution method in claim 9 when executing the computer program.

Images