VR right and interest unified updating system based on multiple payment channels

Abstract

The invention discloses a VR right and interest unified updating system based on multiple payment channels. According to the invention, through AES-256 symmetric encryption adopted by the end-to-end encryption component, full-process encryption processing is carried out on right and interest data, each step from data generation to equipment receiving follows a strict encryption rule, illegal interception and tampering are effectively prevented, and a safety barrier of right and interest information is built; the right and interest data compression unit combines LZ77 compression with sliding window Hash matching, so that the data volume is greatly reduced while the right and interest structural features are reserved, the VR equipment can quickly complete right and interest synchronization even in a low-bandwidth environment, and the network transmission delay and resource consumption are reduced; the equipment side right cache and verification unit utilizes SHA-256 hash verification, regularly compares the right data hash value of the local cache and the right data hash value of the server side, and only synchronizes the difference part, so that the data consistency is ensured, the redundancy of full-amount synchronization is avoided, the risk of local malicious tampering is prevented from the source, and the system reliability and the continuity of user experience are comprehensively improved.

Description

A unified update system for VR rights based on multiple payment channels Technical Field

[0001] This invention belongs to the field of electronic payment technology, specifically a VR rights unified update system based on multiple payment channels. Background Technology

[0002] With the popularization of virtual reality (VR) technology, users usually need to complete the payment operation through different payment channels (such as PayPal, Awx, Alipay, WeChat Pay, etc.) when purchasing VR content, function modules or value-added services.

[0003] In existing technologies, different payment channels have their own payment interfaces, callback parameters, and verification mechanisms. This requires the backend system to implement separate logic for different channels when processing payment results, which increases system complexity, maintenance costs, and error risks.

[0004] Furthermore, the rights and interests associated with VR devices are typically related to feature unlocking, time-limited access, or content access permissions. Due to the unique nature of communication between the device and the server, if the rights and interests data is not encrypted during transmission, there is a risk of tampering or theft. Most existing solutions lack a unified encrypted distribution mechanism, making it difficult to guarantee the secure activation of user rights and interests on the device.

[0005] Therefore, there is an urgent need for a system solution that can unify access to multiple payment channels, standardize payment callback processing, and securely distribute rights and interests information to VR devices in order to improve the scalability and security of the payment system. Summary of the Invention

[0006] The purpose of this invention is to provide a unified VR rights update system based on multiple payment channels in order to solve the problems mentioned above.

[0007] The technical solution adopted in this invention is as follows: A unified VR rights update system based on multiple payment channels, comprising: a payment behavior abstraction module, a payment callback processing module, an order status management module, a rights update module, and a VR device-side rights security synchronization module; the VR device-side rights security synchronization module internally includes: an end-to-end encryption component, a rights data compression unit, a device-side rights caching and verification unit, and an offline rights synchronization compensation module; the request output end of the payment behavior abstraction module is connected to the callback receiving end of the payment callback processing module, and its order creation output end is connected to the order initialization input end of the order status management module; the result output end of the payment callback processing module is connected to the status update input end of the order status management module; the rights trigger output end of the order status management module is connected to the rights issuance input end of the rights update module; the synchronization output end of the rights update module is connected to the rights receiving input end of the VR device-side rights security synchronization module.

[0008] In a preferred embodiment, the payment behavior abstraction module internally includes a channel adaptation submodule, a parameter standardization submodule, and a security preprocessing submodule: the channel adaptation submodule maintains the access configuration of mainstream channels such as WeChat Pay and Alipay, and supports dynamically adding new channels; the parameter standardization submodule converts information such as order amount, product description, and user identifier transmitted from the device into an internally unified parameter format, and maps it to the required fields of the corresponding channel; the security preprocessing submodule generates a valid signature string according to the channel requirements, encrypts sensitive parameters to ensure the security of the payment request during transmission, and finally forwards the processed request to the target payment channel, waiting for the callback result to be returned.

[0009] In a preferred embodiment, the payment callback processing module internally includes: a callback verification submodule, a parameter parsing submodule, a status mapping submodule, and an exception handling submodule. The callback verification submodule first performs signature verification on the request from the channel to confirm the legality of the source and the integrity of the data. The parameter parsing submodule extracts information such as order status, payment time, and transaction serial number from the callback and converts it into an internally recognizable format. The status mapping submodule maps the statuses returned by the channel, such as "payment successful," "payment failed," and "pending confirmation," to the order status codes within the system. The exception handling submodule performs deduplication for duplicate callback scenarios, records detailed logs and triggers alarms for requests that fail verification or have incorrect parameters, and also supports a manual retry mechanism to ensure that the callback result is correctly processed and synchronized to the order status management module.

[0010] In a preferred embodiment, the order status management module includes: a status storage submodule, a status flow rotor module, a status query submodule, and a timeout processing submodule. The status storage submodule uses a combination of database and cache to store the current status of the order and its historical flow records. The status flow rotor module drives status changes based on payment callback results or user operation instructions, such as switching the order from "pending payment" to "payment completed" after successful payment. The status query submodule provides an internal interface that allows the rights update module or the user terminal to query the real-time status of the order. The timeout processing submodule periodically scans orders in the "pending payment" status, automatically marks orders that have not been paid within a preset time as "cancelled," and synchronizes this information to the rights update module to prevent invalid rights issuance.

[0011] In a preferred embodiment, the rights update module is a crucial link connecting payment results and user rights, completing the issuance and synchronization of rights after successful order payment. The module includes a rights rule matching submodule, a rights issuance submodule, a rights synchronization submodule, and a log recording submodule: the rights rule matching submodule matches preset rights issuance rules based on the order's product type and user level to determine the type and duration of rights to be issued; the rights issuance submodule writes rights information into the user's account, such as extending membership validity or unlocking specific VR content; the rights synchronization submodule synchronizes newly issued rights to the rights cache module on the VR device, ensuring users can immediately use them on the device; the log recording submodule records detailed information such as rights issuance time, user ID, and rights type, providing a basis for subsequent auditing and troubleshooting.

[0012] In a preferred embodiment, the end-to-end encryption component includes: an RSA key negotiation submodule, a session key generation submodule, an AES data encryption submodule, and a data decryption and verification submodule. The RSA key negotiation submodule is responsible for the asymmetric key exchange between the device and the server: upon initial connection, the device requests a public key from the server; the server returns a digitally signed RSA public key; the device verifies the signature using the root certificate and stores the public key; the session key generation submodule generates a 128-bit session key SK using a hardware pseudo-random number generator on the device, encrypts SK using the server's RSA public key, and sends it; the AES data encryption submodule, after the server decrypts the SK, encrypts the data using AES-128-CBC mode—the device splits the data into fixed blocks, generates a random initialization vector N, XORs each plaintext block with N, and then encrypts it, simultaneously calculating a SHA-256 hash value as a checksum; the data decryption and verification submodule extracts N and the hash value at the receiving end, decrypts the plaintext using SK, recalculates the hash value, and if they match, the data is confirmed as valid; otherwise, resynchronization is triggered. The RSA session key encryption formula is: In the formula, SK is the 128-bit session key generated by the device; e is the public exponent of the server's RSA public key; n is the modulus of the server's RSA public key; E RSA SK is the encrypted session key; the AES-CBC mode data encryption formula is: ;in , In the formula: SK represents the session key; IV i M represents the initialization vector for the i-th block of data; i Represents the i-th block of plaintext data; C i N represents the ciphertext data of the i-th block; N: The initial random vector data integrity verification formula is: H=SHA256(M); H′=SHA256(M′) M: original plaintext data; H: SHA-256 hash value of the original data; M': decrypted plaintext data; H': SHA-256 hash value of the decrypted data.

[0013] In a preferred embodiment, the rights data compression unit is a lightweight efficiency optimization core component of the VR device-side rights security synchronization module, which contains four sub-modules: a data block preprocessing sub-module, an LZ4 fast hash matching sub-module, a literal-matching pair encoding sub-module, and a compressed frame encapsulation sub-module. The data block preprocessing submodule divides the serialized equity data into contiguous data blocks according to the optimal block size of 64KB, while aligning block boundaries to preserve repeated fields in the structured data; the LZ4 fast hash matching submodule uses a 32-bit sliding window, generates hash values ​​for consecutive 3-byte sequences within the window using a fast hash function, and stores them in a hash table to establish a position index. When a new sequence hash value exists, it searches for the longest repeating matching sequence within the window; the literal-match pair encoding submodule converts unmatched consecutive bytes and repeating sequences into LZ4 variable-length encoding format, where the literal length is encoded using 1-5 bytes, and the matching length and offset are encoded using 2 bytes and 1-5 bytes respectively; the compressed frame encapsulation submodule adds a frame header to each compressed block, concatenates multiple blocks into a complete frame, and calculates the CRC check value to ensure that the compressed data is not damaged; the formula for calculating the dynamic window hash value is: Parameter definitions: Di is the byte value at position i of the data block; H is the 16-bit hash value of the current 3-byte window; i is the starting index of the sliding window; the longest matching length constraint formula is: Parameter definitions: Lcurr is the number of consecutive bytes currently matched; Lbase is the minimum LZ4 match length; Lwin is the remaining byte length of the sliding window; L is the final encoded match length; the compressed block size optimization formula is: In the formula: S lit Number of bytes encoded for the literal portion; S match To match the number of partially encoded bytes; 4 represents the fixed number of bytes in the compressed block frame header; Scomp This represents the total number of bytes in the compressed block.

[0014] In a preferred embodiment, the local equity caching module of the device-side equity caching and verification unit adopts a hierarchical storage architecture, with its core comprising a key-value pair cache pool, a hardware encrypted storage submodule, and an expired equity cleanup submodule. The key-value pair cache pool uses a unique equity identifier as the key, and the stored numerical fields cover the encrypted equity content, expiration stamp, and local hash value. Sensitive equity content is encrypted using the AES-128 algorithm and stored in the device's built-in hardware security module, only temporarily decrypted during verification or use, effectively preventing malicious local tampering. The expired equity cleanup submodule performs a scan every hour, marking and deleting equity entries with expiration stamps earlier than the current system time. Simultaneously, it updates the local merged hash value in real time, ensuring the cache pool always retains valid and up-to-date equity data. Furthermore, the cache pool supports an LRU eviction policy, automatically removing the least accessed equity entry when storage capacity reaches its limit, balancing resource consumption and access efficiency.

[0015] The formula for verifying the validity of a timestamp is: In the formula: T current Indicates the current time of the server system; T request This indicates the timestamp that the device requests to be carried; ΔT represents the maximum time difference allowed for the timestamp.

[0016] In a preferred embodiment, the meta-hash verification module is the core component for ensuring cache consistency, consisting of a global hash request submodule, a local merge hash calculation submodule, and an incremental synchronization triggering submodule. When the device starts up or recovers from offline operation, the global hash request submodule sends a timestamp-laden request to the server to obtain the global merge hash value of all currently valid user benefits; the local merge hash calculation submodule iterates through all benefit entries in the cache pool, extracts the local hash value of each entry, and concatenates them in ascending order by benefit ID, generating a local merge hash using the SHA256 algorithm; the incremental synchronization triggering submodule performs an XOR operation between the local merge hash and the global hash returned by the server. If the result is not zero, incremental synchronization is triggered, requesting only the list of differing benefits from the server to reduce bandwidth consumption. To prevent replay attacks, the timestamp carried in the request must pass the server's validity verification; requests exceeding the threshold will be rejected and required to be re-initiated. The local merge hash calculation formula is as follows: In the formula: H local H represents the combined hash value of all valid interests on the device side; i represents the SHA256 hash value of the i-th stake entry; concat represents the function for sequentially concatenating multiple strings; n represents the total number of valid stake entries in the cache pool; the hash difference detection formula is: In the formula: ΔH represents the XOR result of the global hash and the local hash; Hglobal This represents the globally merged hash value of user rights returned by the server; H local This represents the locally merged hash value calculated on the device side.

[0017] In a preferred embodiment, the offline rights synchronization compensation mechanism of the offline rights synchronization compensation module consists of a rights temporary storage queue module on the server side and an online status awareness module and an incremental synchronization retrieval module on the device side. When the VR device is offline, the rights temporary storage queue module on the server side automatically receives and stores all rights update instructions for that device. Each instruction is accompanied by a unique device identifier and a generation timestamp, and is arranged in chronological order. Invalid instructions exceeding the retention period are periodically cleaned up to free up storage space. The online status awareness module on the device side sends a query request containing its own identifier and the most recent synchronization time to the server as soon as the device regains network connectivity. Upon receiving the request, the server locates the corresponding temporary storage queue based on the device identifier, filters out all rights update records whose generation time is later than the most recent synchronization time, and returns them to the device. The incremental synchronization retrieval module on the device side retrieves the detailed content of these differing records one by one, updates the local last synchronization time immediately after synchronization is completed, and sends a confirmation signal of synchronization completion to the server. Upon receiving the confirmation, the server removes the successfully synchronized records from the queue. If the device goes offline again during the synchronization process, the incremental synchronization retrieval module will save the current synchronization progress and continue to retrieve the incomplete records from the breakpoint when the device comes back online. This ensures that all rights updates during the offline period can be completely and accurately synchronized to the device, avoiding omissions or duplicate synchronization issues.

[0018] In summary, due to the adoption of the above technical solutions, the beneficial effects of this invention are as follows: 1. In this invention, the AES-256 symmetric encryption adopted by the end-to-end encryption component performs end-to-end encryption processing on the rights data. Every step from data generation to device reception follows strict encryption rules, effectively preventing illegal interception and tampering, and building a solid security barrier for rights information; the rights data compression unit applies LZ77 compression combined with sliding window hash matching, which greatly reduces the data volume while retaining the structured characteristics of rights, allowing VR devices to quickly complete rights synchronization even in low-bandwidth environments, reducing network transmission latency and resource consumption; The device-side rights caching and verification unit utilizes SHA-256 hash verification to periodically compare the hash values ​​of rights data in the local cache with those on the server, synchronizing only the differences. This ensures data consistency while avoiding the redundancy of full synchronization. Simultaneously, a hardware-encrypted storage mechanism, combined with temporary decryption logic, prevents the risk of malicious local tampering from the source. The offline rights synchronization compensation module, based on timestamp comparison, automatically filters rights update records generated during offline periods after the device restores its network. Combined with breakpoint resume, it continues to retrieve incomplete data from the last synchronization position, ensuring that users do not miss any rights changes, comprehensively improving system reliability and the continuity of user experience.

[0019] 2. In this invention, the payment behavior abstraction module shields the protocol differences between different payment channels, providing a unified payment request entry point for VR devices. Users can complete payments without needing to concern themselves with the underlying channel details. The signature verification and anomaly deduplication mechanism of the callback processing module ensures that payment results are accurately synchronized to the system, avoiding duplicate or erroneous benefit distribution. The order status management module maintains the order's full lifecycle status through a combination of database and caching. The timeout handling submodule automatically cancels unpaid orders, ensuring system order. The benefit update module immediately matches rules to distribute benefits after successful payment and synchronizes them to the device's cache, allowing users to use new benefits in real time. The offline synchronization compensation mechanism allows the device to automatically retrieve benefit updates from the offline period after network recovery, ensuring the continuity of the user's benefit experience and improving overall system reliability and user satisfaction. Attached Figure Description

[0020] Figure 1 is an overall system block diagram of the present invention; Figure 2 is a system block diagram of the VR device-side rights and interests security synchronization module in the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0022] Example: Referring to Figures 1-2, a unified VR rights update system based on multiple payment channels includes: a payment behavior abstraction module, a payment callback processing module, an order status management module, a rights update module, and a VR device-side rights security synchronization module; the VR device-side rights security synchronization module internally includes: an end-to-end encryption component, a rights data compression unit, a device-side rights caching and verification unit, and an offline rights synchronization compensation module; the request output of the payment behavior abstraction module is connected to the callback receiving end of the payment callback processing module, and its order creation output is connected to the order initialization input of the order status management module; the result output of the payment callback processing module is connected to the status update input of the order status management module; the rights trigger output of the order status management module is connected to the rights issuance input of the rights update module; the synchronization output of the rights update module is connected to the rights receiving input of the VR device-side rights security synchronization module.

[0023] The payment behavior abstraction module internally includes a channel adaptation submodule, a parameter standardization submodule, and a security preprocessing submodule: The channel adaptation submodule maintains the access configuration for mainstream channels such as WeChat Pay and Alipay, and supports dynamically adding new channels; the parameter standardization submodule converts information such as order amount, product description, and user identifier transmitted from the device into an internally unified parameter format, and maps it to the required fields of the corresponding channel; the security preprocessing submodule generates a valid signature string according to the channel requirements, encrypts sensitive parameters to ensure the security of the payment request during transmission, and finally forwards the processed request to the target payment channel, waiting for the callback result to be returned.

[0024] The payment callback processing module has the following internal components: a callback verification submodule, a parameter parsing submodule, a status mapping submodule, and an exception handling submodule. The callback verification submodule first verifies the signature of the request from the channel to confirm the source's legality and data integrity. The parameter parsing submodule extracts information such as order status, payment time, and transaction serial number from the callback and converts it into an internally recognizable format. The status mapping submodule maps the channel's returned statuses, such as "payment successful," "payment failed," and "pending confirmation," to the system's internal order status codes. The exception handling submodule performs deduplication for duplicate callbacks, logs detailed information and triggers alarms for failed verifications or requests with incorrect parameters, and supports a manual retry mechanism to ensure that the callback result is correctly processed and synchronized to the order status management module.

[0025] The order status management module includes: a status storage submodule, a status flow rotor module, a status query submodule, and a timeout handling submodule. The status storage submodule uses a combination of database and cache to save the current status of the order and its historical progress records. The status flow rotor module drives status changes based on payment callback results or user operation instructions, such as switching the order from "pending payment" to "payment completed" after successful payment. The status query submodule provides an internal interface that allows the benefits update module or the user client to query the real-time status of the order. The timeout handling submodule periodically scans orders in the "pending payment" status, automatically marks orders that have not been paid within a preset time as "cancelled," and synchronizes this information to the benefits update module to prevent invalid benefits from being issued.

[0026] The benefits update module is a crucial link connecting payment results and user benefits, completing the issuance and synchronization of benefits after successful order payment. This module includes a benefits rule matching submodule, a benefits issuance submodule, a benefits synchronization submodule, and a log recording submodule: The benefits rule matching submodule matches preset benefits issuance rules based on the order's product type and user level, determining the type and duration of benefits to be issued; the benefits issuance submodule writes the benefits information into the user's account, such as extending membership validity or unlocking specific VR content; the benefits synchronization submodule synchronizes newly issued benefits to the benefits cache module on the VR device, ensuring users can immediately use them on their devices; the log recording submodule records detailed information such as benefits issuance time, user ID, and benefit type, providing a basis for subsequent auditing and troubleshooting.

[0027] The end-to-end encryption component includes: an RSA key negotiation submodule, a session key generation submodule, an AES data encryption submodule, and a data decryption and verification submodule. The RSA key negotiation submodule is responsible for the asymmetric key exchange between the device and the server: upon initial connection, the device requests a public key from the server, which returns a digitally signed RSA public key. The device verifies the signature using the root certificate and stores the public key. The session key generation submodule generates a 128-bit session key SK using a hardware pseudo-random number generator on the device, encrypts SK using the server's RSA public key, and sends it. The AES data encryption submodule, after the server decrypts the SK, encrypts the data using AES-128-CBC mode—the device splits the data into fixed blocks, generates a random initialization vector N, XORs each plaintext block with N, and then encrypts it, simultaneously calculating a SHA-256 hash value as a checksum. The data decryption and verification submodule extracts N and the hash value from the receiver, decrypts the plaintext using SK, recalculates the hash value, and if they match, the data is confirmed as valid; otherwise, resynchronization is triggered. The RSA session key encryption formula is: In the formula, SK is the 128-bit session key generated on the device; e is the public exponent of the server's RSA public key (default is 65537); n is the modulus of the server's RSA public key (the product of two prime numbers); ERSA SK is the encrypted session key; the AES-CBC mode data encryption formula is: ;in , In the formula: SK represents the session key; IV i M represents the initialization vector for the i-th block of data; i Represents the i-th block of plaintext data; C i N represents the ciphertext data of the i-th block; N: The initial random vector data integrity verification formula is: H=SHA256(M); H′=SHA256(M′) M: original plaintext data; H: SHA-256 hash value of the original data; M': decrypted plaintext data; H': SHA-256 hash value of the decrypted data.

[0028] The rights data compression unit is a lightweight, efficiency-optimized core component of the rights security synchronization module on VR devices. It contains four sub-modules: data block preprocessing sub-module, LZ4 fast hash matching sub-module, literal-matching pair encoding sub-module, and compressed frame encapsulation sub-module. The data segmentation preprocessing submodule divides the serialized rights data (such as the JSON byte stream of DeviceEquityOrderVO) into contiguous data blocks according to the optimal block size of 64KB, while aligning block boundaries to preserve repeated fields of structured data (such as device ID and rights type prefix). The LZ4 fast hash matching submodule uses a 32-bit sliding window (window size 64KB) to generate hash values ​​for consecutive 3-byte sequences within the window using a fast hash function, and stores them in a hash table to establish a position index. When a new sequence hash value exists, it searches for the longest repeated matching sequence within the window. The literal-match pair encoding submodule converts unmatched consecutive bytes (literals) and repeated sequences (match pairs, including offsets and lengths) into LZ4 variable-length encoding format, where the literal length is encoded using 1-5 bytes, and the matching length and offset are encoded using 2 bytes and 1-5 bytes respectively. The compressed frame encapsulation submodule adds a frame header (including block type, original size, and compressed size) to each compressed block, concatenates multiple blocks into a complete frame, and calculates the CRC check value to ensure that the compressed data is not corrupted.

[0029] The formula for calculating the dynamic window hash value is as follows: Parameter definitions: Di is the byte value at position i of the data block (0-255); H is the 16-bit hash value of the current 3-byte window; i is the starting index of the sliding window; the longest matching length constraint formula is: Parameter definitions: Lcurr is the number of consecutive bytes currently matched; Lbase is the minimum LZ4 match length (4 bytes); Lwin is the remaining byte length of the sliding window; L is the final encoded match length; the compressed block size optimization formula is: In the formula: S litNumber of bytes encoded for the literal portion; S match To match the number of partially encoded bytes; 4 represents the fixed number of bytes in the compressed block frame header; S comp The total number of bytes in the compressed block; the local equity cache module of the device-side equity cache and verification unit adopts a hierarchical storage architecture, with the core including a key-value pair cache pool, a hardware encrypted storage submodule, and an expired equity cleanup submodule. The key-value pair cache pool uses a unique equity identifier (such as an equity ID) as the key, and stores numeric fields covering the encrypted equity content, expiration stamp, and local hash value. Sensitive equity content is encrypted using the AES-128 algorithm and stored in the device's built-in hardware security module (HSM), only temporarily decrypted during verification or use, effectively preventing malicious local tampering. The expired equity cleanup submodule performs a scan every hour, marking and deleting equity entries with expiration stamps earlier than the current system time. Simultaneously, it updates the local merged hash value in real time, ensuring the cache pool always retains valid and up-to-date equity data. Furthermore, the cache pool supports an LRU eviction policy, automatically removing the least accessed equity entry when storage capacity reaches its limit, balancing resource consumption and access efficiency.

[0030] The formula for verifying the validity of a timestamp is: In the formula: T current Represents the current server system time (second-level timestamp); T request This indicates the timestamp (in seconds) carried in the device request; ΔT represents the maximum allowed time difference between timestamps (default 60 seconds); the meta-hash verification module is the core component ensuring cache consistency, consisting of a global hash request submodule, a local merge hash calculation submodule, and an incremental synchronization triggering submodule. When the device starts up or recovers from offline operation, the global hash request submodule sends a timestamp-laden request to the server to obtain the global merge hash value of all currently valid user benefits; the local merge hash calculation submodule iterates through all benefit entries in the cache pool, extracts the local hash value of each entry, concatenates them in ascending order by benefit ID, and generates a local merge hash using the SHA256 algorithm; the incremental synchronization triggering submodule performs an XOR operation between the local merge hash and the global hash returned by the server. If the result is not zero, incremental synchronization is triggered, requesting only the list of differing benefits from the server to reduce bandwidth consumption. To prevent replay attacks, the timestamp carried in the request must pass the server's validity verification; requests exceeding the threshold will be rejected and required to be re-initiated.

[0031] The formula for calculating the local merge hash is: In the formula: H local H represents the combined hash value of all valid interests on the device side; i represents the SHA256 hash value of the i-th stake entry; concat represents the function for sequentially concatenating multiple strings; n represents the total number of valid stake entries in the cache pool; the hash difference detection formula is: In the formula: ΔH represents the XOR result of the global hash and the local hash; H global This represents the globally merged hash value of user rights returned by the server; H local This represents the locally merged hash value calculated on the device side.

[0032] The offline rights synchronization compensation module consists of a server-side rights temporary storage queue module and a device-side online status awareness module and incremental synchronization retrieval module. When the VR device is offline, the server-side rights temporary storage queue module automatically receives and stores all rights update instructions for that device. Each instruction includes a unique device identifier and a generation timestamp, and is arranged in chronological order. Invalid instructions exceeding the retention period are periodically cleaned up to free up storage space. The device-side online status awareness module sends a query request containing its own identifier and the most recent synchronization time to the server as soon as the device regains network connectivity. Upon receiving the request, the server locates the corresponding temporary storage queue based on the device identifier, filters out all rights update records whose generation time is later than the most recent synchronization time, and returns them to the device. The device-side incremental synchronization retrieval module retrieves the detailed content of these discrepancies record by record, updates the local last synchronization time immediately after synchronization is complete, and sends a synchronization completion confirmation signal to the server. Upon receiving the confirmation, the server removes the successfully synchronized records from the queue. If the device goes offline again during the synchronization process, the incremental synchronization retrieval module will save the current synchronization progress and continue to retrieve the incomplete records from the breakpoint when the device comes back online. This ensures that all rights updates during the offline period can be completely and accurately synchronized to the device, avoiding omissions or duplicate synchronization issues.

[0033] As can be seen from the above, in this invention, the AES-256 symmetric encryption adopted by the end-to-end encryption component encrypts the rights data throughout the entire process. Every step from data generation to device reception follows strict encryption rules, effectively preventing illegal interception and tampering, and building a solid security barrier for rights information. The rights data compression unit uses LZ77 compression combined with sliding window hash matching, which greatly reduces the data volume while preserving the structured characteristics of rights, allowing VR devices to quickly complete rights synchronization even in low-bandwidth environments, reducing network transmission latency and resource consumption. The device-side rights caching and verification unit uses SHA-256 hash verification to periodically compare the hash values ​​of rights data in the local cache with those on the server, synchronizing only the differences, ensuring data consistency and avoiding the redundancy of full synchronization. At the same time, the hardware encryption storage mechanism, combined with temporary decryption logic, prevents the risk of malicious local tampering from the source. The offline rights synchronization compensation module, based on timestamp comparison, automatically filters the rights update records generated during offline periods after the device restores the network, and continues to pull incomplete data from the last synchronization position with breakpoint resume, ensuring that users do not miss any rights changes, comprehensively improving system reliability and the continuity of user experience.

[0034] In this invention, the payment behavior abstraction module shields the protocol differences between various payment channels, providing a unified payment request entry point for VR devices. Users can complete payments without needing to concern themselves with the underlying channel details. The signature verification and anomaly deduplication mechanism of the callback processing module ensures that payment results are accurately synchronized to the system, avoiding duplicate or erroneous benefit distribution. The order status management module maintains the order's full lifecycle status through a combination of database and caching. The timeout handling submodule automatically cancels unpaid orders, ensuring system order. The benefit update module immediately matches rules to distribute benefits upon successful payment and synchronizes them to the device's cache, allowing users to use new benefits in real time. The offline synchronization compensation mechanism allows the device to automatically retrieve benefit updates from the offline period after network recovery, ensuring the continuity of the user's benefit experience and improving overall system reliability and user satisfaction.

[0035] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0036] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A unified VR rights update system based on multiple payment channels, characterized in that: It includes: a payment behavior abstraction module, a payment callback processing module, an order status management module, a rights update module, and a VR device-side rights security synchronization module; the VR device-side rights security synchronization module internally includes: an end-to-end encryption component, a rights data compression unit, a device-side rights caching and verification unit, and an offline rights synchronization compensation module; the request output of the payment behavior abstraction module is connected to the callback receiving end of the payment callback processing module, and its order creation output is connected to the order initialization input of the order status management module; the result output of the payment callback processing module is connected to the status update input of the order status management module; the rights trigger output of the order status management module is connected to the rights issuance input of the rights update module; and the synchronization output of the rights update module is connected to the rights receiving input of the VR device-side rights security synchronization module.

2. The VR rights unified update system based on multiple payment channels as described in claim 1, characterized in that: The payment behavior abstraction module internally includes a channel adaptation submodule, a parameter standardization submodule, and a security preprocessing submodule: the channel adaptation submodule maintains the access configuration of WeChat Pay and Alipay payment channels and supports the dynamic addition of new channels; the parameter standardization submodule converts the order amount, product description, and user identification information transmitted from the device into an internally unified parameter format and maps them to the required fields of the corresponding channel. The security preprocessing submodule generates a valid signature string according to the channel requirements, encrypts sensitive parameters to ensure the security of the payment request during transmission, and finally forwards the processed request to the target payment channel, waiting for the callback result to be returned.

3. The VR rights unified update system based on multiple payment channels as described in claim 1, characterized in that: The payment callback processing module has the following internal components: a callback verification submodule, a parameter parsing submodule, a status mapping submodule, and an exception handling submodule. The callback verification submodule first performs signature verification on the request from the channel to confirm the legality of the source and the integrity of the data. The parameter parsing submodule extracts the order status, payment time, and transaction serial number information from the callback and converts them into an internally recognizable format.

4. The VR rights unified update system based on multiple payment channels as described in claim 1, characterized in that: The order status management module includes: a status storage submodule, a status flow rotor module, a status query submodule, and a timeout handling submodule. The status storage submodule uses a combination of database and cache to store the current status of the order and its historical flow records. The status flow rotor module drives status changes based on payment callback results or user operation instructions. The status query submodule provides an internal interface that allows the rights update module or the user terminal to query the real-time status of the order. The timeout handling submodule periodically scans orders in the "pending payment" status, automatically marks orders that have not been paid within a preset time as "cancelled," and synchronizes this information to the rights update module to prevent invalid rights issuance.

5. The VR rights unified update system based on multiple payment channels as described in claim 1, characterized in that: The rights update module is a key link connecting payment results and user rights, completing the issuance and synchronization of rights after successful order payment. The module includes a rights rule matching submodule, a rights issuance submodule, a rights synchronization submodule, and a log recording submodule: the rights rule matching submodule matches preset rights issuance rules based on the order product type and user level to determine the type and duration of rights to be issued; the rights issuance submodule writes the rights information into the user account.

6. The VR rights unified update system based on multiple payment channels as described in claim 1, characterized in that: The end-to-end encryption component includes: an RSA key negotiation submodule, a session key generation submodule, an AES data encryption submodule, and a data decryption and verification submodule. The RSA key negotiation submodule is responsible for the asymmetric key exchange between the device and the server: upon initial connection, the device requests a public key from the server, which returns a digitally signed RSA public key. The device verifies the signature using the root certificate and stores the public key. The session key generation submodule generates a 128-bit session key SK using a hardware pseudo-random number generator on the device, then encrypts SK using the server's RSA public key and sends it. The AES data encryption submodule, after the server decrypts SK, encrypts the data using AES-128-CBC mode—the device splits the data into fixed blocks, generates a random initialization vector N, XORs each plaintext block with N, and then encrypts it, simultaneously calculating a SHA-256 hash value as a checksum. The data decryption and verification submodule extracts N and the hash value from the receiver, decrypts the plaintext using SK, recalculates the hash value, and if they match, the data is confirmed as valid; otherwise, resynchronization is triggered. The RSA session key encryption formula is: In the formula, SK is the 128-bit session key generated by the device; e is the public exponent of the server's RSA public key; n is the modulus of the server's RSA public key; E RSA SK is the encrypted session key; the AES-CBC mode data encryption formula is: ;in ， In the formula: SK represents the session key; IV i M represents the initialization vector for the i-th block of data; i Represents the i-th block of plaintext data; C i N represents the ciphertext data of the i-th block; N: The initial random vector data integrity verification formula is: H=SHA256(M); H′=SHA256(M′) M: original plaintext data; H: SHA-256 hash value of the original data; M': decrypted plaintext data; H': SHA-256 hash value of the decrypted data.

7. The VR rights unified update system based on multiple payment channels as described in claim 1, characterized in that: The rights data compression unit is a lightweight efficiency optimization core component of the VR device-side rights security synchronization module. It contains four sub-modules: data block preprocessing sub-module, LZ4 fast hash matching sub-module, literal-matching pair encoding sub-module, and compressed frame encapsulation sub-module. The data block preprocessing submodule divides the serialized equity data into contiguous data blocks according to the optimal block size of 64KB, while aligning block boundaries to preserve duplicate fields in the structured data; the LZ4 fast hash matching submodule uses a 32-bit sliding window, generates hash values ​​for consecutive 3-byte sequences within the window using a fast hash function, and stores them in a hash table to establish a position index. When a new sequence hash value exists, it searches for the longest repeating matching sequence within the window; the literal-match pair encoding submodule converts unmatched consecutive bytes and repeating sequences into LZ4 variable-length encoding format; the formula for calculating the dynamic window hash value is: Parameter definitions: Di is the byte value at position i of the data block; H is the 16-bit hash value of the current 3-byte window; i is the starting index of the sliding window; the longest matching length constraint formula is: Parameter definitions: Lcurr is the number of consecutive bytes currently matched; Lbase is the minimum LZ4 match length; Lwin is the remaining byte length of the sliding window; L is the final encoded match length; the compressed block size optimization formula is: In the formula: S lit Number of bytes encoded for the literal portion; S match To match the number of partially encoded bytes; 4 represents the fixed number of bytes in the compressed block frame header; S comp This represents the total number of bytes in the compressed block.

8. The VR rights unified update system based on multiple payment channels as described in claim 1, characterized in that: The local rights cache module of the device-side rights cache and verification unit adopts a hierarchical storage architecture, which includes a key-value pair cache pool, a hardware encrypted storage submodule, and an expired rights cleanup submodule. The key-value pair cache pool uses the unique rights identifier as the key, and the stored numerical fields cover the encrypted rights content, expiration stamp, and local hash value. Sensitive rights content is encrypted using the AES-128 algorithm and stored in the device's built-in hardware security module. It is only temporarily decrypted during verification or use, effectively preventing local malicious tampering. The expired rights cleanup submodule performs a scan every hour, marking rights entries with expiration stamps earlier than the current system time as invalid and deleting them. At the same time, it updates the local merged hash value in real time to ensure that the cache pool always retains valid and up-to-date rights data. The formula for verifying the validity of a timestamp is: In the formula: T current Indicates the current time of the server system; T request This indicates the timestamp that the device requests to be carried; ΔT represents the maximum time difference allowed for the timestamp.

9. A VR rights unified update system based on multiple payment channels as described in claim 8, characterized in that: The meta-hash verification module is the core component for ensuring cache consistency. It consists of a global hash request submodule, a local merge hash calculation submodule, and an incremental synchronization triggering submodule. When the device starts up or recovers from offline operation, the global hash request submodule sends a timestamped request to the server to obtain the global merge hash value of all the user's current valid rights. The local merge hash calculation submodule traverses all equity entries in the cache pool, extracts the local hash value of each entry, concatenates them in ascending order by equity ID, and generates a local merge hash using the SHA256 algorithm; The incremental synchronization triggering submodule performs an XOR operation between the local merged hash and the global hash returned by the server. If the result is not zero, incremental synchronization is triggered, and only the difference rights list is requested from the server, reducing bandwidth consumption. The formula for calculating the local merged hash is as follows: In the formula: H local H represents the combined hash value of all valid interests on the device side; i This represents the SHA256 hash value of the i-th stake entry; concat represents the function for sequentially concatenating multiple strings; n represents the total number of valid stake entries in the cache pool; The formula for hash difference detection is: ； In the formula: ΔH represents the XOR result of the global hash and the local hash; H global This represents the globally merged hash value of user rights returned by the server; H local This represents the locally merged hash value calculated on the device side.

10. A VR rights unified update system based on multiple payment channels as described in claim 1, characterized in that: The offline rights synchronization compensation module's offline rights synchronization compensation mechanism consists of a rights temporary storage queue module on the server side and an online status perception module and an incremental synchronization retrieval module on the device side.

Images