Ticket fair distribution method and system based on end-cloud cooperation

Abstract

The application discloses a ticket fair distribution method and system based on end-cloud cooperation, which comprises the following steps: a cloud end issues a ticket grabbing strategy package containing a dynamic difficulty coefficient to a user terminal according to system load; the user terminal performs a memory hard-dependent proof of work calculation and environment verification to generate a fair ticket grabbing voucher; the cloud end verifies the voucher and puts the verified request into a fair distribution queue; a multi-dimensional weighted scoring algorithm is used to sort the requests in the queue and perform verification based on physical micro-motion characteristics and touch-gesture space-time coupling to identify simulation devices; and finally, tickets are distributed according to the sorting and verification results. The application disperses the calculation pressure to the client, thereby relieving the concurrent pressure of the server; the memory hard-dependent algorithm and multi-dimensional fair sorting effectively curb machine ticket scalping and guarantee the distribution fairness; and the verification mechanism based on physical causality accurately identifies advanced simulator attacks, thereby improving the security of the system.

Description

Technical Field

[0001] This application relates to the field of Internet data processing technology, specifically to a method and system for fair ticket allocation through end-to-end cloud collaboration. Background Technology

[0002] With the widespread adoption of internet technology, online ticketing platforms have become the primary means for the public to purchase tickets for performances, sporting events, and transportation. In scenarios involving the sale of popular ticket resources, such as transportation tickets for specific holidays or performance tickets for well-known artists, the system needs to process massive numbers of concurrent ticket purchase requests within a very short time. Existing ticket allocation technologies typically face significant technical challenges.

[0003] On the one hand, most systems adopt a "first-come, first-served" allocation strategy, where all user requests arrive at the server at roughly the same time. This can easily lead to the instantaneous exhaustion of server computing resources, storage resources, and network bandwidth, potentially causing service delays or even systemic crashes. Although some systems have introduced mechanisms such as message queues to buffer instantaneous traffic, server-side processing bottlenecks still exist when faced with millions or even higher levels of concurrent requests, making it difficult to completely solve the impact of high concurrency.

[0004] On the other hand, existing ticketing systems face fairness issues arising from automation tools. Some individuals utilize automated scripts, cloud computing resource clusters, and group control simulators to initiate ticket purchase requests at a frequency and speed far exceeding that of ordinary users manually. This unequal competition based on computing power and network advantages results in a large amount of ticket resources falling into the hands of a few professional ticket snatchers, impacting the fair rights of ordinary users. Existing defense mechanisms, such as CAPTCHAs or IP address-based access frequency restrictions, have become significantly less effective with the development of artificial intelligence visual recognition technology and proxy IP pool services, making it difficult to effectively identify and block malicious requests from automated tools.

[0005] Furthermore, the queuing mechanisms in current ticketing systems often lack transparency for users. After submitting a request, users cannot know their exact position in the queue, nor can they verify whether the system's allocation process follows preset fair rules. This lack of transparency easily raises user concerns about the platform's fairness. In addition, there is a technical attack method that utilizes cloud-based mobile phones (i.e., mobile terminal environments simulated using server virtualization technology) or virtualized container technology based on specific processor architectures to simulate the hardware characteristics of real mobile terminals in batches. This bypasses traditional device fingerprint-based risk control strategies, rendering traditional client-side feature-based defenses ineffective.

[0006] Therefore, the current technology field needs a new technical solution to effectively alleviate the high concurrency pressure on the server side, while accurately identifying and suppressing automated machine behavior, and ensuring the balance, efficiency and verifiability of the ticket allocation process. Summary of the Invention

[0007] This application provides a cloud-edge collaborative ticketing fair allocation method and system to solve the problems of system stability caused by high concurrency, low allocation efficiency and uneven allocation caused by automation tools, and opaque allocation mechanism in the prior art.

[0008] Firstly, this application provides a method for fair ticket allocation through end-to-end cloud collaboration, the method comprising the following steps:

[0009] Step 1: In response to the pre-handshake request initiated by the user terminal, the cloud access gateway dynamically generates and sends a ticket-grabbing strategy package to the user terminal based on the current global system load;

[0010] Step 2: After receiving the ticket-grabbing strategy package, the user terminal runs a preset memory hard-dependency hash algorithm locally based on the calculation seed and dynamic difficulty coefficient in the ticket-grabbing strategy package. It continuously tries different random numbers to calculate until it finds a random number that meets the requirements of the dynamic difficulty coefficient. It also collects the device's physical fingerprint information to generate a trusted device signature. The found random number and the trusted device signature are then encapsulated to generate a fair ticket-grabbing certificate.

[0011] Step 3: The user terminal sends the generated fair ticket-grabbing certificate to the cloud access gateway, which verifies the received fair ticket-grabbing certificate. The verification includes verifying whether the random number meets the dynamic difficulty coefficient requirement and verifying the legality of the device's trusted signature, so as to filter out legitimate requests.

[0012] Step 4: Place the verified legitimate requests into the fair allocation queue of the cloud system, and sort the legitimate requests in the fair allocation queue according to the preset sorting rules;

[0013] Step 5: Based on the sorting result of the fair allocation queue, allocate ticket inventory to the legitimate requests in the queue in turn, and push the allocation result to the corresponding user terminal.

[0014] In one possible implementation, the ticket-grabbing strategy package includes a dynamic difficulty coefficient for defining the complexity of subsequent computational tasks and a computational seed for the subsequent computation process. The magnitude of the dynamic difficulty coefficient is positively correlated with the global load of the system. The trusted device signature is generated by the user terminal by calling the trusted execution environment or security unit interface of the device's underlying layer to collect hardware fingerprint information that can characterize the physical uniqueness of the device. The memory hard-dependent hash algorithm is the Argon2 algorithm or the Scrypt algorithm.

[0015] In one possible implementation, step four, which involves sorting the legitimate requests in the fair allocation queue according to the preset sorting rules, specifically includes: calculating a fair score for each legitimate request using a multidimensional weighted scoring algorithm, and sorting the legitimate requests in the fair allocation queue based on the fair scores; wherein the calculation formula of the multidimensional weighted scoring algorithm includes the following parameters: a scoring item based on the time taken for the user terminal to complete the proof of work, a user credit score calculated based on the user's historical behavior data, a device trust level calculated based on the source and strength of the device's trusted signature, and a network latency compensation value; the network latency compensation value is calculated based on the difference between the timestamp of the request sent by the user terminal and the timestamp of the request received by the cloud access gateway, and is used to compensate users whose network latency is higher than a preset threshold.

[0016] In one possible implementation, the scoring item based on the time taken to complete the proof of work by the user terminal specifically involves: setting a first score for requests within a preset time interval and setting a second score for requests outside the preset time interval, wherein the first score is greater than the second score.

[0017] In one possible implementation, before allocating ticket inventory in step five, the method further includes: performing touch-gesture spatiotemporal coupling verification on requests in the sorted queue. The verification includes: receiving screen touch data and device gesture data synchronously collected and uploaded by the user terminal when initiating a ticket purchase operation; wherein the screen touch data includes touch pressure values, and the device gesture data includes transient impact response data collected by an accelerometer and a gyroscope; verifying the synchronization of the screen touch data and the device gesture data on the time axis and the causal correlation in amplitude to determine the authenticity of the operation and intercepting requests that fail verification.

[0018] In one possible implementation, in step two, while the user terminal is running the memory hard-dependency hash algorithm, it also collects and uploads a raw data stream from the gyroscope and accelerometer for a preset duration; the method further includes the cloud access gateway performing spectrum analysis on the received raw data stream and determining whether the request comes from an analog device based on the spectrum characteristics.

[0019] In one possible implementation, the method further includes: controlling the linear motor of the user terminal to emit a vibration of a preset frequency and waveform via a cloud access gateway command; requiring the user terminal to synchronously collect the response data of the vibration on the device using an accelerometer; and the cloud access gateway determining the authenticity of the operation by verifying the biodamping response characteristics characterized by the vibration attenuation envelope and resonant frequency drift in the response data.

[0020] In one possible implementation, the method further includes recording the hash value of the fair ticket-grabbing credential of the successfully allocated ticket request, the allocation timestamp, and the allocation result summary to a distributed ledger to generate an immutable fairness audit log.

[0021] Secondly, this application provides a cloud-edge collaborative ticketing fair allocation system, which includes:

[0022] The cloud access gateway is used to respond to the pre-handshake request initiated by the user terminal, and dynamically generate and send the ticket grabbing strategy package to the user terminal based on the current global system load.

[0023] The user terminal, upon receiving the ticket-grabbing strategy package, runs a preset memory hard-dependency hash algorithm locally based on the calculation seed and dynamic difficulty coefficient in the ticket-grabbing strategy package. It continuously tries different random numbers to perform calculations until a random number that meets the dynamic difficulty coefficient requirement is found. It also collects the device's physical fingerprint information to generate a trusted device signature, encapsulates the found random number and the trusted device signature to generate a fair ticket-grabbing credential, and sends the generated fair ticket-grabbing credential to the cloud access gateway.

[0024] The cloud access gateway is also used to verify the received fair ticket-grabbing certificate. The verification includes verifying whether the random number meets the dynamic difficulty coefficient requirement and verifying the legality of the device's trusted signature, so as to filter out legitimate requests.

[0025] The core scheduling service module is used to place the verified legitimate requests into the fair allocation queue of the cloud system, sort the legitimate requests in the fair allocation queue according to a preset sorting rule, allocate ticket inventory to the legitimate requests in the queue in turn according to the sorting result of the fair allocation queue, and push the allocation result to the corresponding user terminal.

[0026] The technical solution provided in this application can produce the following beneficial effects:

[0027] First, by introducing a proof-of-work mechanism on user terminals, the computational pressure, which was originally concentrated on the server side, is effectively distributed to a massive number of client devices. During peak traffic periods, each client must spend a certain amount of computation time to generate a valid request. This physically shapes the originally instantaneous, pulse-like traffic into a smooth traffic curve, thereby reducing the peak pressure on the server side and improving the stability and availability of the system.

[0028] Secondly, by adopting a memory-hard-dependent proof-of-work algorithm, the cost of using specialized hardware for batch, high-speed computation is significantly increased, making automated ticket-grabbing tools no longer economically advantageous, thereby curbing malicious machine ticket-grabbing behavior to some extent.

[0029] Furthermore, by introducing a fair ranking algorithm that incorporates multiple factors such as network latency compensation, device credibility weighting, and user credit, the unfair situation dominated by network speed and device performance in the traditional "first-come, first-served" model is broken, providing ordinary users with a fairer opportunity to compete and achieving fairness at the algorithm level.

[0030] Furthermore, this solution introduces a "touch-gesture spatiotemporal coupling verification" mechanism based on physical laws, which elevates the dimension of human-machine recognition from traditional behavioral data feature analysis to the verification of physical causal relationships. If an attacker wants to forge such an attack, they need to build a complex physical model to calculate the gesture response that precisely matches each random click operation in real time. This raises the technical barrier to attack and can effectively defend against advanced replay attacks and artificial intelligence-based synthetic data attacks. Attached Figure Description

[0031] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0032] Figure 1 This is a schematic diagram of the overall architecture of the end-to-cloud collaborative ticketing fair allocation system provided in an embodiment of the present invention.

[0033] Figure 2 This is a flowchart of the end-to-cloud collaborative ticketing fair allocation method provided in an embodiment of the present invention.

[0034] Figure 3 This is a flowchart illustrating the touch-attitude spatiotemporal coupling verification sub-step in an embodiment of the present invention.

[0035] Figure 4 This is a schematic diagram of the functional modules of the end-to-cloud collaborative ticketing fair allocation system provided in an embodiment of the present invention.

[0036] Figure 5 This is a signal comparison diagram of the PoW flow shaping effect of the present invention.

[0037] Figure 6 This is a comparison chart of real users and simulated devices for touch-gesture verification based on FFT spectrum analysis, according to the present invention.

[0038] Figure 7 This is a schematic diagram of the finger touch mechanical transmission and device micro-motion response of the present invention.

[0039] Figure 8 This is a comparison chart of the concurrent load timing curves of the server side in this invention.

[0040] Figure 9 This is a heatmap showing the attack detection rate of the multi-layer verification mechanism of this invention.

[0041] Figure 10 This is a comparison chart of the distribution of fair scores for users under different network conditions according to the present invention. Detailed Implementation

[0042] 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.

[0043] Please see Figure 1 and Figure 2 This invention provides a method for fair ticket allocation through end-to-end cloud collaboration. Figure 1 The system environment of the method is shown, which mainly includes user terminal 100, cloud access gateway 200 and core scheduling service module 300. Figure 2 This is a detailed description of the method.

[0044] In terms of specific deployment, the user terminal 100 can be a smartphone, tablet, or other mobile computing device with network communication capabilities and sensor hardware. The cloud access gateway 200 can be deployed as a multi-instance stateless service cluster, distributing traffic to each instance through a load balancer to achieve horizontal scaling. The cloud access gateway 200 communicates with the core scheduling service module 300 via an internal high-speed message bus (such as remote procedure calls based on the gRPC protocol or Apache Kafka message queues). The communication link between the user terminal 100 and the cloud access gateway 200 is encrypted using the TLS 1.3 protocol to ensure the confidentiality and integrity of data transmission. To cope with a geographically dispersed user group, the cloud access gateway 200 can be deployed in multiple active-active deployments in data centers across multiple geographical regions, and uses global DNS scheduling to route user requests to the access point with the closest geographical location, thereby reducing network transmission latency.

[0045] Example 1

[0046] The method in this embodiment may specifically include the following steps:

[0047] Step S100: In response to the pre-handshake request initiated by the user terminal, the cloud access gateway 200 dynamically generates and sends a ticket grabbing strategy package to the user terminal based on the current global system load and ticket inventory level.

[0048] Specifically, during the initialization phase of the user's ticket purchase interface—that is, before the user clicks the final purchase button—the user terminal 100 first initiates a lightweight pre-handshake request to the cloud access gateway 200. This is to prevent all purchase requests carrying complete business data from flooding in simultaneously at the moment the ticket grabbing begins, thereby establishing communication in advance and obtaining instructions for the next operation. The function of generating the ticket grabbing strategy package can be handled by the strategy distributor 210 deployed within the cloud access gateway 200 in the system implementation. This strategy distributor 210 monitors the system's key performance indicators in real time, such as the current number of active connections, CPU utilization, memory usage, and the remaining ticket inventory. Based on this real-time data, it dynamically generates the ticket grabbing strategy package. In this process, the specific calculation method for the system's global load can adopt a weighted average method, which weights and sums CPU utilization, memory usage, network bandwidth utilization, and database transactions per second (TPS) according to preset weights (e.g., 0.3, 0.3, 0.2, 0.2 respectively). The ticket inventory level can be divided into multiple intervals, such as: ample interval (remaining tickets greater than 50% of the total), tight interval (remaining tickets between 10% and 50%), and critical interval (remaining tickets less than 10%). The strategy distributor 210 retrieves the corresponding basic difficulty coefficient from a table based on the interval to which the current load belongs.

[0049] The ticket-grabbing strategy package is a data structure containing a set of constraints to guide user terminals in subsequent operations. Specifically, the strategy package may include a dynamic difficulty coefficient, a calculation seed, and client-side environment verification instructions. The dynamic difficulty coefficient is a numerical value used to define the complexity of subsequent calculation tasks. For example, when the system load is low, the difficulty coefficient can be set to 20, requiring the hash value of the calculation result to have 20 leading zeros; when the number of concurrent requests exceeds a set threshold (e.g., 500,000 times) within 1 second, the difficulty coefficient can be immediately increased to 24, thereby increasing the client's calculation time, smoothing traffic peaks, and reducing instantaneous traffic pressure. The data format of the ticket-grabbing strategy package can be JSON, XML, or Protocol Buffers. The specific value range of the dynamic difficulty coefficient can be set to an integer between 1 and 255. The calculation seed can be a 256-bit random string generated by a server-side hardware random number generator and hashed using the current Unix timestamp (accurate to microseconds). The computation seed is data containing a random salt value generated by the server and the current precise timestamp, which is used to ensure that the input for each proof-of-work computation is unique, effectively preventing attackers from pre-calculating the result or replaying old requests.

[0050] Furthermore, the ticket-grabbing strategy package also includes a strategy version number and an expiration date field. The strategy version number is an incrementing integer used to identify and reject requests generated using expired strategy packages during the cloud verification phase. The expiration date field is a Unix timestamp indicating the expiration time of the strategy package. When a user terminal detects that the strategy package has expired, it needs to re-initiate a pre-handshake request to obtain the latest strategy package. This expiration date mechanism can prevent attackers from obtaining easy-to-use strategy packages during low-load periods and then using them to initiate requests during high-concurrency periods.

[0051] The dynamic difficulty coefficient adjustment follows an asymmetric strategy of step-by-step increase and gradual decrease. Specifically, when the system detects that the concurrent request volume exceeds a preset increase threshold within a preset monitoring window time (e.g., a sliding window of the last 5 seconds), the difficulty coefficient is immediately increased to the corresponding higher level to quickly suppress traffic surges. Conversely, when the concurrent request volume drops below a preset decrease threshold and remains below it for a period of time (e.g., 30 seconds), the difficulty coefficient is slowly and progressively decreased to avoid drastic traffic fluctuations. The policy distributor 210 internally maintains a state machine. The input of this state machine is the real-time system load indicator, and the output is the current appropriate difficulty coefficient level. The state transition rules of this state machine and the difficulty coefficient values ​​corresponding to each level can be set and hot-updated through a configuration file without restarting the service.

[0052] In addition, during the processing of pre-handshake requests, the cloud access gateway 200 will also perform initial frequency limiting on the source IP address of the request. If the number of pre-handshake requests from the same IP address exceeds a preset threshold within a unit of time (e.g., no more than 10 requests per second from the same IP), the excess requests will be returned with a rate-limiting response to defend against simple flooding denial-of-service attacks in the earliest stage.

[0053] Step S200: After receiving the ticket-grabbing strategy package, the user terminal performs preset calculation tasks and environment verification locally to generate a fair ticket-grabbing certificate.

[0054] This step is executed locally on user terminal 100 and can be broken down into several sub-steps.

[0055] First, the integrity of the execution environment is verified. The end-side SDK module within the user terminal 100 calls the secure interfaces provided by the underlying Trusted Execution Environment (TEE) or Secure Element (SE). These interfaces operate in a secure environment isolated from the main operating system, enabling access to device hardware information that cannot be tampered with by upper-layer applications. The collected physical hardware fingerprint information may specifically include: hardware information that characterizes the physical uniqueness of the device and is obtained through the secure interface, such as a hardware-guaranteed unique device identifier or encryption key handle provided by the Trusted Execution Environment (TEE), and micro-motion data sequences from the gyroscope and accelerometer collected within a specific time window (e.g., 500 milliseconds) after the pre-handshake request is initiated. Specifically, the unique device identifier may include the International Mobile Equipment Identity (IMEI), Media Access Control (MAC) address, Bluetooth address, baseband version number, screen factory calibration parameters, etc. The Trusted Execution Environment (TEE) may be based on TrustZone technology based on the ARM architecture, or SGX technology based on the Intel architecture, or a hardware-isolated environment based on the Secure Element (SE) chip. This multi-source, heterogeneous hardware information is combined and hashed, then signed using the device's private key stored in the TEE or SE to generate a trusted device signature. This signature proves that the request indeed originates from a physical device with a root of trust.

[0056] Secondly, Proof of Work (PoW) is executed. The user terminal runs a specified memory-dependent hash algorithm based on the computation seed and dynamic difficulty coefficient obtained from the ticket-grabbing strategy package. Preferably, the Argon2 algorithm can be used. The specific parameters of the Argon2 algorithm, including time cost (t_cost), memory cost (m_cost), and parallelism, are all included in the ticket-grabbing strategy package. For example, m_cost can be set to 64KB, 128KB, or higher to ensure that the computation process must occupy significant memory bandwidth, thereby resisting attacks from dedicated hardware based on FPGAs or ASICs. This algorithm is characterized by requiring a large amount of memory read and write operations during computation, making acceleration using a graphics processing unit (GPU) or application-specific integrated circuit (ASIC) with strong parallel computing capabilities but high memory access latency far less efficient than using a general-purpose CPU. The user terminal uses the computation seed, device ID, and initial random number (Nonce) as input to execute the Argon2 algorithm. If the calculated hash result does not meet the difficulty coefficient requirements (e.g., insufficient leading zeros), a new random number is generated and the calculation is repeated. This continuous trial and error process continues until a random number that meets the conditions is found, thereby imposing a controllable time delay on the client side.

[0057] Finally, the credentials are encapsulated. The random number found through the computational power proof-of-work, the trusted device signature generated in the previous step, the current user's identity, and the client's local timestamp are combined into a data packet. To prevent eavesdropping or tampering during transmission, the data packet is asymmetrically encrypted using a system public key pre-installed in the client, generating the final fair ticket-grabbing credential.

[0058] During the execution of the aforementioned proof-of-work, the user terminal can employ a multi-threaded parallel search strategy to improve the efficiency of finding random numbers that meet the requirements. Specifically, the user terminal can create a corresponding number of worker threads based on the number of CPU cores in the device. Each worker thread is assigned a different random number starting range and performs Argon2 hash calculations in parallel. When any thread finds a valid random number that meets the difficulty coefficient requirement, it notifies other threads to stop calculating through an inter-thread communication mechanism (e.g., atomic variables or condition variables). This parallel strategy can fully utilize the multi-core processing power of the terminal device, shorten the user's waiting time, and does not change the security guarantee of proof-of-work, because the independent calculations performed by each thread are still constrained by the memory-dependent algorithm.

[0059] During the generation of the trusted device signature, to prevent the signature data from being intercepted by a man-in-the-middle and used for replay attacks, the input data for the signature also includes the hash value of the current computation seed and a one-time random challenge value generated by the terminal. This one-time random challenge value is bound to the current ticket-grabbing session and its uniqueness is verified during cloud-based validation. This mechanism ensures that each trusted device signature is only valid for the current session and cannot be extracted and reused in other sessions.

[0060] The data structure of the fair ticket-grabbing credential includes, in addition to the aforementioned valid random number, trusted device signature, user identity identifier, and local timestamp, the following fields: the strategy version number of the ticket-grabbing strategy package, used for cloud verification of the timeliness of the strategy package; the version number of the client-side SDK, used for cloud-based compatibility with verification logic of different versions; and a credential integrity verification code, which is generated by hashing all fields in the credential except itself, and is used by the receiver to verify that the credential data has not been tampered with during transmission.

[0061] Please see Figure 5 and Figure 8 This invention significantly shapes the concurrent load on the server by introducing a Proof-of-Work (PoW) mechanism. For example... Figure 5 As shown, without the PoW mechanism, the number of requests per second on the server surges to approximately one million QPS at the moment ticket grabbing begins, forming a sharp, pulsed traffic surge that far exceeds the system capacity threshold of 200,000 QPS, easily leading to server overload and crashes. After introducing a PoW mechanism with a fixed difficulty coefficient of 20, the arrival time of requests is naturally dispersed because each request needs to complete proof-of-work calculations on the client side. The peak QPS drops to approximately 150,000, below the system capacity threshold, and the traffic curve exhibits a smooth bell-shaped distribution. Further employing a dynamic difficulty adaptive mechanism, the system dynamically adjusts the PoW difficulty coefficient based on real-time load, further reducing the peak QPS to approximately 80,000, with a more even and smooth traffic distribution. The overall peak reduction rate reaches 85% to 92%, effectively shaping the pulsed traffic into a smooth curve, ensuring that the server always operates within a safe capacity range under high-concurrency ticket grabbing scenarios, significantly improving system stability and availability. Figure 8 The time-series curves of server-side concurrent load are further illustrated, intuitively reflecting the aforementioned traffic shaping process. In this load test experiment, the server hardware environment was configured as follows: an Intel Xeon Gold 6248R processor with a clock speed of 3.0GHz and 256GB of DDR4 memory; the network environment was a 10Gbps direct fiber optic connection. JMeter 5.4.1 was used for stress testing, simulating 1 million concurrent users, with the request sending strategy conforming to a Poisson distribution. The system capacity threshold was set based on the maximum processing capacity when the server CPU utilization reached 80%.

[0062] Step S300: The user terminal sends the generated fair ticket-grabbing voucher to the cloud ticketing system, and the cloud access gateway performs pre-verification and filtering on all received requests.

[0063] User terminal 100 sends the encrypted fair ticket-grabbing voucher as the core part of the formal ticket purchase request to cloud access gateway 200. Cloud access gateway 200, as the system entry point, performs initial verification of the request and executes efficient, stateless verification on the massive influx of requests. The verification process specifically includes two checks:

[0064] First, rapid verification of proof-of-work. The gateway uses the system's private key to decrypt the fair ticket-grabbing credential, extracting information such as the random number and computation seed. The asymmetric encryption algorithm can be either RSA-2048 or ECC-secp256r1 to balance security and decryption performance. Then, the gateway only needs to perform a single hash operation and compare the result with the difficulty coefficient issued in the ticket-grabbing strategy package. Since the computational cost of the verification process is much less than that of the generation process, the gateway can quickly identify and discard invalid requests that have not completed proof-of-work or have forged computation results with extremely low computational cost.

[0065] Second, verify the trusted device signature. The gateway extracts the trusted device signature and decrypts and verifies it using the corresponding device public key (or verified by a trusted root certificate system). This confirms the authenticity of the device originating from the request. Simultaneously, the gateway compares the device ID contained in the signature with a dynamically updated blacklist database. To achieve millisecond-level fast queries in high-concurrency scenarios, the blacklist database can be stored using a memory-based Redis cluster and pre-screened using a Bloom filter. A Bloom filter can determine whether a device ID "might exist" in the blacklist with minimal memory usage. Only when the Bloom filter determines that it might exist is the Redis cluster further queried, thus significantly reducing database I / O pressure. The data sources for this blacklist database include historical cheating records, malicious device fingerprints pushed by threat intelligence platforms, and abnormal devices identified by real-time risk control systems. This blacklist database records information on known cheating devices, emulators, or abused devices. To ensure query efficiency under high concurrency, the blacklist database can be stored in memory using a Redis cluster and combined with a Bloom filter for rapid prediction. Updates to the blacklist data can be analyzed by an offline big data risk control system and then asynchronously pushed to the gateway cache via a message queue. Any request that fails signature verification or whose device ID is on the blacklist will be immediately discarded. Through these two layers of filtering, only legitimate requests that have completed the required procedures can enter the backend system.

[0066] During the verification process, the cloud access gateway 200 also implements a replay attack prevention mechanism. Specifically, the gateway maintains a time-window-based deduplication cache in memory. This cache can be implemented using a key-value storage structure with automatic expiration (such as Redis's SET data structure combined with a TTL expiration policy). Whenever a fair ticket-grabbing credential passes verification, the gateway stores the credential's hash digest as the key in the deduplication cache and sets its expiration time to be consistent with the policy package's validity period. Subsequent received credentials are checked for their hash digests in the deduplication cache before proof-of-work verification. If they exist, they are considered replay requests and discarded. This mechanism effectively prevents attackers from intercepting legitimate users' credentials and submitting them repeatedly.

[0067] To ensure the cloud access gateway 200's processing capacity under extremely high concurrency scenarios, its verification logic is implemented using an asynchronous, non-blocking event-driven model. Specifically, after receiving a request, the gateway places it into a local lock-free circular buffer, which is then asynchronously consumed and the verification logic is executed by a background worker thread pool. The number of threads in the worker thread pool can be dynamically adjusted based on the current number of CPU cores and the load. After verification, the result is returned to the network I / O thread via a callback mechanism, which is responsible for sending a response to the client or forwarding the request to the backend service. This architecture decouples the gateway's network I / O and business processing logic, preventing long-running verification operations from blocking network connection reception and maintenance, thereby improving the gateway's throughput and concurrent processing capabilities.

[0068] In addition, the cloud access gateway 200 records the verification results and related metadata (including request source IP, device ID, verification time, rejection reason, etc.) for each request during the verification process, and writes this data to the log system asynchronously. The log system can be implemented using a distributed log collection framework (such as a combination of Elasticsearch, Logstash, and Kibana). This log data can be used for subsequent offline security analysis and risk control model training, while also providing observability support for system operation and maintenance.

[0069] Step S400: Place the legitimate requests verified by the cloud gateway into the fair allocation queue in the cloud, and use a multi-dimensional weighted scoring algorithm to calculate the fair score for each request. Finally, sort the requests in the queue according to the score.

[0070] Requests that pass gateway verification are sent to the fair allocation queue within the core scheduling service module 300. Technically, this fair allocation queue can employ a Redis Sorted Set data structure, using the calculated fair score as the Score and the request ID as the Member, leveraging Redis's native sorting capabilities to achieve high-performance real-time sorting. In this queue, the system no longer uses a simple first-come, first-served (FIFO) strategy, but instead calculates a comprehensive fair score for each request. The formula for calculating this score can be expressed as: Score = w1 * f(PoW_Time) + w2 * User_Credit + w3 * Device_Trust_Level + w4 * Network_Latency_Compensation.

[0071] The terms in the formula are defined as follows:

[0072] Score: The final fair score. Requests with higher scores are ranked higher in the queue. To eliminate the influence of parameters with different dimensions, each parameter needs to be normalized (Min-MaxNormalization) before weighted summation, mapping it to the interval [0, 1].

[0073] w1, w2, w3, w4: Preset weighting coefficients, which can be adjusted by the system operator according to business objectives to determine the degree of influence of each factor on the final ranking.

[0074] f(PoW_Time): A scoring function based on the proof-of-work time (PoW_Time). This function rewards users who complete the calculation within a reasonable time interval and penalizes requests with abnormally long execution times. For example, a target time interval can be set (e.g., 3-5 seconds). When PoW_Time falls within this interval, f(PoW_Time) outputs a higher value; when PoW_Time is too short (e.g., less than 1 second, possibly indicating a cheating device) or too long (e.g., more than 10 seconds, possibly indicating a device with poor performance or extremely poor network conditions), f(PoW_Time) outputs a lower value. Specifically, f(PoW_Time) can be constructed using a Gaussian function: f(x) = a * exp(-(x - b)^2 / (2 * c^2)), where x is PoW_Time, b is the target mean time (e.g., 4 seconds), c is the standard deviation (e.g., 1.5 seconds), and a is the peak constant (e.g., 100). This function design ensures that the closer the execution time is to the target value, the higher the score, with a smooth decay towards both ends. This design is used to filter out users who participate normally.

[0075] User_Credit: User credit score. This score is determined by the system based on a user's historical behavior. As a non-restrictive example, the user credit score can be quantified as a value from 0 to 1000, where factors such as the user's historical purchase records, fulfillment status (e.g., refund rate), and account activity can all be used in the calculation. Users who are consistently active and have no violations will have higher credit scores.

[0076] Device_Trust_Level: Device trust level. The system classifies devices into levels and quantifies them as numerical values ​​based on the source and strength of the trusted signature. As a non-limiting example, a device trust level can be mapped to a normalized value between 0 and 1.0. For example, a device that can provide hardware-level signatures via TEE scores 1.0, a device that can only provide software-level security proofs scores 0.5, and a device that cannot provide any trusted signatures or has been marked as risky scores 0.1 or lower.

[0077] Network_Latency_Compensation: This is the network latency compensation value. It is calculated by subtracting the user terminal's local sending timestamp from the timestamp of the request received from the cloud, as contained in the credentials. To ensure timestamp accuracy, the user terminal synchronizes its clock with the cloud server via Network Time Protocol (NTP) during the pre-handshake phase, calculating and storing the local clock deviation. The calibrated timestamp is used when generating credentials. This compensation value is used to provide appropriate positive score compensation for users in high-latency network environments. The compensation value can be calculated using a logarithmic decay model: Compensation = k * log(1 + Latency), where Latency is the calculated one-way latency, and k is an adjustment coefficient. This model ensures reasonable compensation for normal network fluctuations while preventing excessively high scores for extremely high latency (potentially due to spoofing or proxy forwarding). This compensates for request arrival delays caused by poor network conditions, thus providing a fairer competitive opportunity for users in different network environments. To accurately calculate latency, the system can use the NTP (Network Time Protocol) to synchronize the time between the user terminal and the cloud gateway, or use the RTT (Round-Trip Time) during the TCP handshake process to estimate the one-way latency. The compensation value can be calculated using the formula: Compensation = min(Max_Comp, k * (Latency - Base_Latency)), where k is the compensation coefficient and Base_Latency is the baseline latency.

[0078] In the management of the fair allocation queue, to prevent the queue from expanding indefinitely and causing memory overflow, the system sets a maximum capacity limit for the queue. When the number of requests in the queue reaches this limit, newly validated requests will be temporarily stored in a disk-based overflow queue. Once space becomes available in the main queue, these requests will be sequentially transferred to the main queue in a first-in, first-out order for scoring and sorting. The overflow queue can be implemented using a persistent message queue (such as the persistent mode of Apache Kafka or RabbitMQ) to ensure that requests are not lost due to queue overload.

[0079] For requests in the fair allocation queue, the system also sets a maximum waiting time threshold. If a request has not received a ticket allocation after waiting for more than the maximum waiting time threshold, the system automatically marks the request as timed out and pushes a timeout notification to the corresponding user terminal. This timeout mechanism can prevent user requests from being suspended indefinitely due to system anomalies.

[0080] The weight coefficients w1, w2, w3, and w4 in the multidimensional weighted scoring algorithm can be determined using the Analytic Hierarchy Process (AHP) or statistical regression analysis based on historical data. During initial system deployment, the operator can set initial weight values ​​according to business needs. During system operation, a large amount of real ticket purchase request data and user feedback information can be collected, and machine learning regression models can be used to iteratively optimize the weight coefficients to make the scoring results more consistent with fairness requirements. Adjustments to the weight coefficients must be verified for effectiveness through A / B testing before taking effect to avoid fairness biases caused by improper parameter adjustments.

[0081] When multiple requests receive the same fair score after multi-dimensional weighted scoring, the system employs an auxiliary sorting strategy to perform a secondary sorting of the tied requests. This auxiliary sorting strategy can use a hash value sorting method based on user identity and the random salt value of the current batch. Specifically, the user identity of each tied request is concatenated with the batch salt value randomly generated by the server at the start of the current ticketing activity. Then, the SHA-256 hash value of this concatenated string is calculated, and finally, the requests are sorted according to the lexicographical order of the hash values. Since the batch salt value is unpredictable before the start of the activity, this method introduces randomness while ensuring deterministic sorting, preventing any user from gaining a fixed sorting advantage through a known strategy.

[0082] like Figure 10As shown, the multi-dimensional weighted ranking mechanism of this invention significantly improves the fairness of users under different network conditions. Under the traditional FIFO (First-Come, First-Served) mechanism, the user's fairness score is strongly negatively correlated with network latency. The median for the low-latency group is approximately 0.85, decreasing to approximately 0.62 for the medium-latency group, only about 0.35 for the high-latency group, and even lower to about 0.15 for the ultra-high-latency group. The range of the medians across the four groups reaches 0.70, indicating that network advantage directly dominates the ticket-grabbing result, which is extremely unfair to high-latency users. After adopting the multi-dimensional weighted ranking mechanism of this invention, the network latency compensation factor is used to adjust the weights of users under different network conditions. The median fairness scores for the four groups of users are approximately 0.72, 0.70, 0.68, and 0.66, respectively, and the range of the medians is reduced to approximately 0.06, a decrease of more than 90%. Meanwhile, the standard deviations of all group values ​​remained within a uniform range of 0.09 to 0.11. Box plots and scatter plots showed a high degree of overlap between the groups, indicating that the distribution of fair scores was no longer significantly affected by network latency. This effectively broke the unfair phenomenon dominated by network speed and device performance, ensuring equal opportunities for users with different network conditions to obtain ticketing resources. In the fairness verification experiment, a simulation environment containing 100,000 virtual users was constructed. The user group was divided into four groups based on network latency: low latency (10-50ms), medium latency (50-150ms), high latency (150-300ms), and ultra-high latency (300-500ms), with an equal number of users in each group. The experiment was repeated 50 times, with different initial request times randomly generated each time. The confidence interval for the final statistical data was 95%.

[0083] Step S500: Before executing ticket allocation, physical micro-motion feature challenge and touch-gesture spatiotemporal coupling verification are performed on the request to identify and block requests from cloud phones, group control simulators and advanced replay attacks.

[0084] This step is a final, in-depth validation of high-scoring requests that are about to enter the allocation process. Please refer to [link / reference]. Figure 3 This step can be further refined.

[0085] As a sub-step S501 of the physical micro-motion characteristic challenge, the cloud can include a posture challenge instruction when issuing the ticket-grabbing strategy package. This instruction requires the user terminal to continuously collect and upload a raw data stream from the gyroscope and accelerometer for a duration of T (e.g., 3 seconds) while performing proof-of-work. After receiving this data stream, the cloud performs Fast Fourier Transform (FFT) analysis on it in S502. Before performing the FFT, the raw data is first denoised and normalized. The sampling frequency can be set from 50Hz to 100Hz, and the sampling window length is 128 or 256 points. When a real user holds a mobile phone, physiological tremors (such as heartbeat, breathing, and hand muscle tremors) will generate irregular noise spectra within a specific frequency band (e.g., 0.5Hz-15Hz). However, the sensor data of group control devices fixed on a bracket or cloud phones running on a server are zero values ​​or regular simulated noise, and their spectral characteristics differ significantly from those of real physical scenes. The cloud can determine the physical state of the device through model comparison.

[0086] Furthermore, as a sub-step S503 for verifying the spatiotemporal coupling of touch and posture, the terminal's edge SDK module accurately captures the pressure value and contact area of ​​the touch event the instant the user clicks the ticket purchase button on the screen, and simultaneously records the transient impact response data of the accelerometer and gyroscope at that moment (accurate to milliseconds). According to basic physics principles, the force of a finger clicking the screen will cause a tiny reverse motion in the device. In S504, the cloud system verifies the causal relationship between these two sets of data. The specific verification algorithm can use a cross-correlation function to calculate the correlation between the touch signal sequence and the acceleration signal sequence in terms of time lag. The system sets a time tolerance window (e.g., ±50 milliseconds) and searches for the cross-correlation peak within this window. For example, a click event with a pressure value of P should theoretically produce an instantaneous vibration on the Z-axis that is highly synchronized with its time and has an acceleration value within the estimated range. If the system detects a strong touch signal, but the sensor data does not respond accordingly, or the response time is severely delayed, it can be determined that the operation is very likely from software simulation rather than a real physical click.

[0087] To improve the robustness of this verification mechanism under complex real-world conditions such as different device models, phone cases, and user grip postures, in a preferred embodiment of the present invention, the cloud system can introduce baseline calibration and machine learning models. For example, during non-ticket-buying periods, the system can collect baseline data by guiding users to complete some simple interactive operations, and establish a personalized physical response model for each device or user. Alternatively, the system can utilize massive amounts of real user operation data to train a deep learning model. The deep learning model can employ a Long Short-Term Memory (LSTM) network or a hybrid architecture of Convolutional Neural Network (CNN) and LSTM (CNN-LSTM). The model's input is multi-channel time-series sensor data, and the output is the probability value of whether the operation belongs to "real human hand" or "machine simulation". This model can learn deep features of real physical interactions from sensor data, thereby more accurately distinguishing normal operations from various interference factors and simulated attacks, significantly improving the stability and reliability of the verification.

[0088] Optionally, to defend against more sophisticated attacks capable of replaying real sensor data, this method can also introduce an active haptic-sensing closed-loop response verification mechanism. When issuing a challenge command, the cloud can specify a random vibration pattern (specific frequency and waveform), instructing the linear motor of the user terminal to trigger the vibration at a specific time point. Simultaneously, the terminal's accelerometer is required to synchronously collect and upload the response data of this vibration on the device. Since the damping effect (absorption and attenuation of vibration) of the human hand is completely different from that of a rigid support, the cloud can construct a physical layer closed-loop verification that cannot be broken by simple replay attacks by analyzing the uploaded vibration attenuation envelope and resonant frequency drift.

[0089] In the described active tactile-sensing closed-loop response verification mechanism, the vibration command issued from the cloud includes the following parameters: vibration frequency range (e.g., 50Hz to 300Hz), vibration waveform type (e.g., sine wave, square wave, or sawtooth wave), vibration duration (e.g., 200 milliseconds to 500 milliseconds), and precise time offset of vibration start. During each verification, the cloud randomly selects a pattern from a predefined vibration pattern library, or generates a new vibration pattern in real time using a pseudo-random algorithm. This randomness ensures that attackers cannot prepare corresponding simulation data in advance.

[0090] When analyzing vibration response data uploaded by user terminals, the cloud system extracts the following feature vectors for judgment: vibration decay time constant τ, which is the time required for the amplitude to decay to 1 / e of the initial value from the cessation of vibration; the drift of the resonant frequency, which is the difference between the measured fundamental frequency and the command frequency; and the energy proportion of higher harmonic components, which is the ratio of the sum of the energies of all harmonics higher than the fundamental frequency to the total energy in the power spectral density of the response signal. When a real user holds the device, due to the damping absorption effect of human tissues (such as skin, muscles, and bones) on vibration, the above feature values ​​will exhibit specific distribution patterns. For example, the decay time constant τ is usually greater than the τ value of a device fixed on a rigid support, and the resonant frequency will undergo a measurable shift due to the coupling effect of human soft tissues. The cloud compares the measured feature vectors with pre-established real user feature distribution models and machine equipment feature distribution models, calculates the log-likelihood ratio, and when the ratio is lower than a preset judgment threshold, it determines that the request comes from a non-real handheld environment.

[0091] The training process of the deep learning model specifically includes the following steps: First, a large-scale labeled dataset is collected from historical data. This dataset contains positive samples generated by real users under various grip postures (such as single-handed vertical grip, two-handed horizontal grip, flat placement on a table, etc.) and various device models, as well as negative samples generated by various simulators, cloud phones, and group control devices. Second, the raw sensor time series data is preprocessed. This preprocessing includes resampling to a uniform sampling rate, sliding window segmentation, Z-score normalization, and data augmentation (such as adding random noise and random time offsets). Then, a CNN-LSTM hybrid neural network model is constructed, where one-dimensional convolutional layers are responsible for extracting local time-frequency features from the sensor data, and LSTM layers are responsible for modeling long-range dependencies in the time series. The output layer of the model uses the Sigmoid activation function, outputting the probability value that the operation belongs to a real human hand operation. The training process uses the binary cross-entropy loss function and the Adam optimizer for parameter updates. After training, the model is deployed to a cloud inference service. To adapt to the evolution of new attack methods, the model adopts a periodic incremental training strategy, which involves periodically collecting new labeled sample data and fine-tuning and updating the deployed model.

[0092] To further improve the accuracy of touch-gesture spatiotemporal coupling verification and reduce the false positive rate, the system can introduce an adaptive threshold adjustment mechanism. This mechanism operates by: the system continuously calculating the ratio of successful to unsuccessful verification requests in recent times (e.g., within the last hour), as well as false positive cases identified through manual review. When the statistical data indicates that the false positive rate exceeds a preset acceptable range, the system automatically fine-tunes the stringency of the verification judgment threshold. The adjustment magnitude and direction of the threshold are determined by a preset PID control algorithm to achieve smooth threshold adjustment and avoid drastic threshold fluctuations.

[0093] Please see Figure 6 , Figure 6 This demonstrates a comparison between real users and simulated devices in touch-gesture verification based on FFT spectral analysis. For example... Figure 6 As shown, the top left image displays the acceleration time-domain waveform of a real user, exhibiting irregular tremors and random amplitude variations; the top right image shows its corresponding FFT spectrum, revealing rich irregular energy distribution within the physiological frequency band of 0.5Hz to 15Hz. In contrast, the bottom left image shows the acceleration time-domain waveform of the simulated device, with values ​​close to zero and lacking physiological variations; the bottom right image shows its FFT spectrum, indicating that the energy within the physiological frequency band is close to zero. By comparing spectral characteristics, the system can effectively determine whether a request originates from a real handheld environment. Experimental data collection involved 20 different models of mainstream smartphones (covering iOS and Android systems), as well as 10 common group control devices and cloud phone emulators. Real user samples were collected from 50 volunteers in different postures (standing, sitting, walking), yielding 5000 valid samples; simulated device samples were generated through script control and virtualization software, totaling 5000 samples. The sensor sampling frequency was uniformly set to 100Hz, and the data precision was 16 bits.

[0094] Please see Figure 7 , Figure 7 This further demonstrates the principles of finger touch force transmission and device micro-motion response. For example... Figure 7 As shown, when the user's finger F1 touches the touch screen surface F2 and applies touch pressure F, the device body F3 generates a small reverse displacement dx due to the force, which causes a transient impact acceleration a at the location of the internal accelerometer F4. Figure 7 The time-domain signal correspondence diagram below shows the correspondence between the touch pressure signal and the accelerometer response signal on the time axis: the touch pressure signal rises in a pulse shape, and the accelerometer response signal generates a decaying oscillation waveform that is synchronized with the time within a very short time window dt after the pressure pulse is applied. There is a strict physical causal relationship between the two. Figure 7 The comparison area on the right further demonstrates the essential difference between real touch and simulated touch: In a real touch scenario, an increase in pressure will inevitably be accompanied by an increase in acceleration response, and the two are causally matched; however, in a software simulated touch scenario, although it is possible to fake an increase in pressure signal, the accelerometer will not produce a corresponding impact response due to the lack of real physical force, resulting in a causal mismatch, which is then identified by the system as non-human operation.

[0095] like Figure 9As shown, the multi-layer verification mechanism of this invention has progressively higher interception capabilities against different types of automated attacks. For simple script tools, the Proof-of-Work (PoW) layer achieves a 99% recognition rate, and the device trusted signature verification layer further reaches 98%, with the first two layers sufficient for effective interception. For proxy IP pool and script attacks, the PoW layer achieves an 85% recognition rate, the device signature verification layer increases this to 95%, and the overall interception rate reaches 99.25%. For GPU-accelerated batch computing attacks, due to the increased computational cost of specialized hardware caused by the memory-dependent PoW, the PoW layer achieves a 60% recognition rate, the device signature verification layer 90%, and the spectrum analysis layer 95%, with the three layers working together to achieve efficient interception. For cloud phone and virtualized container attacks, the first two layers have relatively low recognition rates, but the spectrum analysis layer achieves 97% by detecting physical micro-motion features, and the touch-gesture coupling verification layer further increases this to 99%. For the most challenging AI-synthesized sensor data attacks, the four layers of verification progressively increase the recognition rate, ultimately relying on touch-gesture spatiotemporal coupling verification to achieve a 96% recognition rate, with an overall interception rate of 99.52%. This multi-layered, defense-in-depth architecture ensures an overall interception rate exceeding 99% for all types of automated attacks. In attack defense performance testing, a mixed traffic dataset was constructed, containing 200,000 normal user requests and 800,000 various attack requests. Simple script tools were simulated using the Python Requests library; proxy IP pool attacks invoked a proxy service containing 5,000 active nodes; GPU-accelerated attacks used an NVIDIA Tesla T4 graphics card cluster to run a custom PoW solver; and cloud phone attacks were based on ARM-based server virtualization instances. The identification rate metric was defined as the proportion of attack requests correctly intercepted by the system out of the total number of requests of that type of attack.

[0096] Step S600: Based on the sorting result of the fair allocation queue, allocate ticket inventory to the requests in the queue in turn, and push the allocation result asynchronously to the corresponding user terminal.

[0097] After all verifications are completed, the inventory transaction manager of the core scheduling service module 300 will strictly allocate ticket inventory to requests according to the final order of the fair allocation queue, starting from the head of the queue. The allocation process uses atomic operations to ensure data consistency. The result of successful or failed allocation will be pushed to the corresponding user terminal 100 via asynchronous message.

[0098] To enhance the transparency and credibility of the entire process, the system packages key information from each successful ticket allocation record, such as anonymized user identifiers, the hash value of the fair ticket-grabbing voucher, the final fair score, and the allocation timestamp, into a transaction and writes it to a distributed ledger (such as a consortium blockchain). Due to the immutability and traceability of the distributed ledger, this creates a publicly auditable log. Users can use a query interface to input relevant information to verify whether their requests were processed fairly and whether the allocation results were accurately recorded.

[0099] In the process of allocating ticket inventory, the specific implementation of the atomic operation is as follows: When allocating tickets, the core scheduling service module 300 executes an atomic transaction containing inventory query and inventory deduction for each request to be allocated. In a distributed system environment, to prevent overselling, this atomic transaction can be implemented in one of the following two ways. The first way is pessimistic concurrency control based on distributed locks: Before executing inventory deduction, an exclusive lock for the corresponding ticket category is first acquired through a distributed lock service (such as the Redlock algorithm based on Redis or the ephemeral sequential node mechanism based on ZooKeeper). After successfully acquiring the lock, the inventory query and deduction operations are executed, and the lock is released after completion. This method ensures that only one request can operate on the inventory of a specific category at any given time, thereby avoiding concurrency conflicts. The second approach is a comparison and swap (CSS) operation based on optimistic locking: The current inventory quantity is used as the version number. When deducting inventory, the current inventory value is read first, and then a CAS command (such as Redis's WATCH / MULTI / EXEC transaction or the database's optimistic locking mechanism) is used to attempt to decrement the inventory by 1. The CAS operation will only succeed if the inventory value has not been modified by other concurrent operations. If the CAS operation fails, the inventory value is reread and the operation is retried, with the number of retries not exceeding a preset limit.

[0100] During ticket allocation, when inventory is reduced to zero, the system marks the remaining unallocated requests in the fair allocation queue as "sold out" and pushes a sold-out notification to the corresponding user terminal. To reduce the waste of ticket resources caused by individual users failing to complete payment within the timeout period, the system can introduce an inventory pre-reservation and release mechanism. Specifically, when a request is allocated a ticket, the system marks the ticket as "pre-reserved" and starts a countdown timer for a preset duration (e.g., 15 minutes). If the user completes payment before the countdown ends, the ticket status is changed to "sold out." If the user has not completed payment by the end of the countdown, the system automatically releases the pre-reserved ticket, puts it back into the allocable inventory pool, and allocates it to the next waiting user according to the current order in the fair allocation queue.

[0101] The allocation result push mechanism is implemented using a WebSocket long-lived connection. When the user terminal initiates a pre-handshake request, a WebSocket long-lived connection is established between the user terminal and the cloud. This connection is used by the cloud to push queuing progress information, allocation results, and timeout notifications to the user terminal in real time. In a backup scenario where the WebSocket connection is interrupted, the system can send an offline notification to the user terminal via a mobile push notification service (such as APNs or FCM). After receiving the offline notification, the user terminal can proactively query the cloud for the latest allocation status.

[0102] In the specific implementation of the distributed ledger, a consortium blockchain architecture can be adopted. The participating nodes of the consortium blockchain include the ticketing platform operator, regulatory agencies, and independent third-party auditing institutions, with each node jointly maintaining the ledger data. The consensus mechanism can employ a practical Byzantine fault-tolerant algorithm or the Raft algorithm to provide high transaction throughput while ensuring data consistency. Each allocation record written to the blockchain includes the following fields: a user identifier that has been hash-de-identified, the SHA-256 hash value of the fair ticket-grabbing credential, the final fair score of the request, the ticket allocation timestamp, the unique ticket number allocated, and the hash value of the previous record (used to form a chain structure). Due to the append-only and immutable nature of the blockchain, any attempt to modify the recorded data will cause the hash verification of subsequent blocks to fail, thus being detected by the participating nodes. Ordinary users can use the public query interface provided by the system to input their own request identifier or the hash value of their fair ticket-grabbing credential to query the corresponding allocation record and independently verify the integrity and authenticity of the record.

[0103] Example 2

[0104] Please see Figure 4 This invention also provides an edge-cloud collaborative ticketing fair allocation system, which is the execution entity of the above-described method. This system may include:

[0105] The edge SDK module 410 is integrated into the ticketing application running on the user terminal 100. The edge SDK module 410 may internally include: a policy receiving unit 411, used to communicate with the cloud, receive and parse the ticket-grabbing policy package issued by the cloud access gateway; a PoW computing engine 412, which has a built-in memory hard-dependency hash algorithm (such as Argon2), responsible for performing computational proof-of-work calculations based on the dynamic difficulty coefficient and computation seed in the policy package; and an environment perception unit 413, which is responsible for calling the device's underlying security interfaces (such as TEE) and sensor interfaces to obtain the device's physical fingerprint information and real-time data from sensors such as gyroscopes and accelerometers, used to generate a trusted device signature and respond to physical challenges.

[0106] The cloud access gateway 200 is deployed at the front end of the cloud service cluster, serving as the traffic entry point. Internally, the cloud access gateway 200 may include: a policy distributor 210, which is responsible for real-time monitoring of the entire system's load and ticket inventory status, and dynamically generating ticket-grabbing strategy packages accordingly, adjusting the difficulty of proof-of-work; and a verification filter 220, which is responsible for performing efficient stateless verification on all fair ticket-grabbing credentials entering the system, including rapid verification of proof-of-work and validation of the legitimacy of trusted device signatures, to intercept the vast majority of invalid and malicious requests.

[0107] The core scheduling service module 300, deployed on the backend of the cloud service, is responsible for processing core business logic. Internally, this module may include: a fair sorting engine 310, which is responsible for running the aforementioned multi-dimensional weighted scoring algorithm on legitimate requests verified by the gateway, calculating a fair score for each request, and maintaining a high-performance memory priority queue based on that score; and an inventory transaction manager 320, which, after sorting, sequentially executes atomic deduction operations on ticket inventory, starting from the head of the fair queue, ensuring the accuracy and data consistency of the allocation process, and notifying users of the allocation results.

[0108] In actual deployment, the data flow of the edge-cloud collaborative ticketing fair allocation system is as follows: When a user opens the ticketing application and enters the ticket purchase page, the policy receiving unit 411 in the edge SDK module 410 first initiates a pre-handshake request to the cloud access gateway 200. After receiving the request, the policy distributor 210 queries the current system load status and inventory data, generates a ticket-grabbing policy package, and returns it to the policy receiving unit 411. After parsing the policy package, the policy receiving unit 411 passes the calculation parameters in it to the PoW calculation engine 412, and simultaneously notifies the environment perception unit 413 to start sensor data acquisition. The PoW calculation engine 412 performs the calculation of the memory hard-dependent hash algorithm, and the environment perception unit 413 collects device hardware fingerprints and sensor data in parallel. After the two tasks are completed, the edge SDK module 410 integrates, encrypts, and encapsulates the calculation results and collected data into a fair ticket-grabbing credential, which is transmitted to the cloud access gateway 200 via the network. The verification filter 220 in the cloud access gateway 200 verifies the credential, and requests that pass the verification are forwarded to the core scheduling service module 300. After the fair sorting engine 310 performs multi-dimensional scoring and sorting on the requests, the inventory transaction manager 320 performs ticket allocation and sends the allocation results back to the user terminal 100 via the cloud access gateway 200.

[0109] To handle ticketing events of varying scales, the system supports elastic scaling deployment. Both the cloud access gateway 200 and the core scheduling service module 300 are deployed in a containerized manner within a Kubernetes cluster. The system is configured with a horizontal auto-scaling strategy based on CPU utilization and request queue depth. When monitoring metrics exceed preset scaling thresholds, Kubernetes automatically creates new service instances to distribute the load; when metrics fall below scaling thresholds and remain below for a period of time, excess instances are automatically reclaimed to conserve computing resources. Furthermore, for foreseeable large-scale ticketing events (such as the sale of tickets for specific performances), the system supports pre-scaling, i.e., scaling up to the estimated required number of instances before the event begins to avoid service degradation due to untimely scaling during traffic surges.

[0110] In summary, this invention, through an edge-cloud collaborative design, introduces dynamically adjustable proof-of-work difficulty and physical feature-based deep environment verification on the client side, effectively distributing the high concurrency pressure on the server side and significantly increasing the attack cost and technical threshold for automated tools. Simultaneously, the cloud-based system replaces the traditional "first-come, first-served" mechanism with a fair ranking algorithm based on multi-dimensional weighted scoring, creating a more equitable ticket acquisition opportunity for ordinary users. Finally, by leveraging distributed ledger technology, the transparency and auditability of the allocation process are enhanced, resolving issues related to system stability, allocation fairness, and mechanism transparency present in existing technical solutions.

[0111] Example 3

[0112] This embodiment provides a cloud-edge collaborative method for fair ticket allocation in a limited-edition digital art release scenario. In this scenario, the technical challenges faced by the business system include not only the instantaneous generation of extremely high concurrent requests, but also a large number of automated tools controlled by professional attackers and based on cloud virtualization container technology. These tools can simulate the device environment characteristics of mobile terminals in batches, making traditional device fingerprint-based risk control strategies ineffective. Therefore, the method described in this application is necessary.

[0113] Specifically, at the start of the sales event, the digital collectibles platform deployed the fair ticket allocation system of this invention. In step S100, when a massive number of pre-handshake requests arrive instantly, the cloud access gateway detects that the system's concurrent traffic far exceeds a preset threshold, and then dynamically generates and distributes a ticket-grabbing strategy package containing a high dynamic difficulty coefficient. This requires each client to perform several seconds of computational proof-of-work calculation before generating a valid fair ticket-grabbing certificate, thereby effectively smoothing the pulse-like request traffic over time.

[0114] In steps S200 and S300, the user terminal performs a calculation based on a memory-hard-dependency hash algorithm locally and encapsulates a fair ticket-grabbing credential containing a trusted device signature. The cloud access gateway performs pre-verification filtering on the received credential. A large number of requests that do not contain valid proof of work or use forged device signatures are directly discarded at this stage. These requests mainly originate from simple script tools that do not use the client-side SDK module provided in this application.

[0115] For requests that pass the pre-verification, this embodiment focuses on performing the physical micro-motion feature challenge and touch-attitude spatiotemporal coupling verification in step S500 to address the aforementioned cloud-based virtualized container attacks. Since the cloud-based virtual devices used by attackers lack physical sensors, when the system issues an attitude challenge command, these virtual devices cannot return micro-motion data streams that match the characteristics of the user's handheld device, or they return invalid or regular simulated data. The system identifies the differences between the sensor data and the real physical environment through spectral analysis, thus classifying such requests as abnormal. Furthermore, when verifying the authenticity of the user's click to purchase, the system requires verification of the temporal and physical causal coupling relationship between the touch pressure signal and the device's transient attitude response signal. Although the attacker's virtualized environment can simulate touch events, it cannot generate accelerometer response data that is precisely synchronized in time with the simulated touch and has a reasonable physical force transmission relationship. By detecting this contradictory phenomenon of "touch but no corresponding physical response," the system accurately identifies and intercepts automated requests from the cloud-based virtualized container.

[0116] Ultimately, only legitimate requests that pass all detection processes, including physical layer verification, are allowed to enter the fair allocation queue in step S400. The system uses a multi-dimensional weighted scoring algorithm to sort the queue and completes the allocation of digital artworks in step S600 based on the sorting results. This method effectively ensures a fair opportunity for ordinary users to participate when facing attacks from advanced automated tools.

[0117] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for fair ticket allocation through end-to-end cloud collaboration, characterized in that, Includes the following steps: Step 1: In response to the pre-handshake request initiated by the user terminal, the cloud access gateway dynamically generates and sends a ticket-grabbing strategy package to the user terminal based on the current global system load; Step 2: After receiving the ticket-grabbing strategy package, the user terminal runs a preset memory hard-dependency hash algorithm locally based on the calculation seed and dynamic difficulty coefficient in the ticket-grabbing strategy package. It continuously tries different random numbers to calculate until it finds a random number that meets the requirements of the dynamic difficulty coefficient. It also collects the device's physical fingerprint information to generate a trusted device signature. The found random number and the trusted device signature are then encapsulated to generate a fair ticket-grabbing certificate. The computation seed is data containing a random salt value generated by the server and the current precise timestamp, which is used to ensure that the input for each proof-of-work computation is unique; Step 3: The user terminal sends the generated fair ticket-grabbing certificate to the cloud access gateway, which verifies the received fair ticket-grabbing certificate. The verification includes verifying whether the random number meets the dynamic difficulty coefficient requirement and verifying the legality of the device's trusted signature, so as to filter out legitimate requests. Step 4: Place the verified legitimate requests into the fair allocation queue of the cloud system, and sort the legitimate requests in the fair allocation queue according to the preset sorting rules; Specifically, step four, which involves sorting the legitimate requests in the fair allocation queue according to the preset sorting rules, includes: A multidimensional weighted scoring algorithm is used to calculate the fair score for each legitimate request, and the legitimate requests in the fair allocation queue are sorted according to the fair score. The calculation formula of the multidimensional weighted scoring algorithm includes the following parameters: a scoring item based on the time taken for the user terminal to complete the proof of work, a user credit score calculated based on the user's historical behavior data, a device trust level calculated based on the source and strength of the device's trusted signature, and a network latency compensation value. The network latency compensation value is calculated based on the difference between the timestamp of the request sent by the user terminal and the timestamp of the request received by the cloud access gateway, and is used to provide score compensation to users whose network latency is higher than a preset threshold. The scoring item for calculating the time taken to complete the proof of workload based on the user terminal specifically involves: setting a first score for requests within a preset time interval and setting a second score for requests outside the preset time interval, wherein the first score is greater than the second score. Step 5: Based on the sorting result of the fair allocation queue, allocate ticket inventory to the legitimate requests in the queue in turn, and push the allocation result to the corresponding user terminal.

2. The method according to claim 1, characterized in that, The ticket-grabbing strategy package includes a dynamic difficulty coefficient for defining the complexity of subsequent calculation tasks and a calculation seed for the subsequent calculation process. The magnitude of the dynamic difficulty coefficient is positively correlated with the global load of the system. The trusted signature of the device is generated by the user terminal by calling the trusted execution environment or security unit interface of the device's underlying layer to collect hardware fingerprint information that can characterize the physical uniqueness of the device. The memory hard-dependency hash algorithm is either the Argon2 algorithm or the Scrypt algorithm.

3. The method according to claim 1, characterized in that, Prior to step five, which allocates ticket inventory, the method further includes: The requests in the sorted queue are subjected to touch-gesture spatiotemporal coupling verification, the verification including: The system receives screen touch data and device posture data synchronously collected and uploaded by the user terminal when initiating a ticket purchase operation; wherein, the screen touch data includes touch pressure values, and the device posture data includes transient impact response data collected by an accelerometer and a gyroscope; Verify the synchronization of the screen touch data and the device posture data on the time axis and the causal correlation in amplitude to determine the authenticity of the operation and block requests that fail the verification.

4. The method according to claim 1, characterized in that, In step two, while running the memory hard-dependency hash algorithm, the user terminal also collects and uploads a raw data stream from the gyroscope and accelerometer for a preset duration. The method also includes the cloud access gateway performing spectrum analysis on the received raw data stream and determining whether the request comes from an analog device based on the spectrum characteristics.

5. The method according to claim 3, characterized in that, The method further includes: The user terminal's linear motor is controlled by cloud access gateway commands to emit a vibration of a preset frequency and waveform. The user terminal is required to synchronously collect the vibration response data on the device using an accelerometer; The cloud access gateway verifies the authenticity of the operation by checking the biodamping response characteristics represented by the vibration attenuation envelope and resonant frequency drift in the response data.

6. The method according to claim 1, characterized in that, The method further includes recording the hash value of the fair ticket-grabbing credential of the successfully allocated ticket request, the allocation timestamp, and the allocation result summary into a distributed ledger to generate an immutable fairness audit log.

7. A cloud-edge collaborative ticketing fair allocation system, characterized in that, include: The cloud access gateway is used to respond to the pre-handshake request initiated by the user terminal, and dynamically generate and send the ticket grabbing strategy package to the user terminal based on the current global system load. The user terminal, upon receiving the ticket-grabbing strategy package, runs a preset memory hard-dependency hash algorithm locally based on the calculation seed and dynamic difficulty coefficient in the ticket-grabbing strategy package. It continuously tries different random numbers to perform calculations until a random number that meets the dynamic difficulty coefficient requirement is found. It also collects the device's physical fingerprint information to generate a trusted device signature, encapsulates the found random number and the trusted device signature to generate a fair ticket-grabbing credential, and sends the generated fair ticket-grabbing credential to the cloud access gateway. The computation seed is data containing a random salt value generated by the server and the current precise timestamp, which is used to ensure that the input for each proof-of-work computation is unique; The cloud access gateway is also used to verify the received fair ticket-grabbing certificate. The verification includes verifying whether the random number meets the dynamic difficulty coefficient requirement and verifying the legality of the device's trusted signature, so as to filter out legitimate requests. The core scheduling service module is used to place the verified legitimate requests into the fair allocation queue of the cloud system, sort the legitimate requests in the fair allocation queue according to a preset sorting rule, allocate ticket inventory to the legitimate requests in the queue in turn according to the sorting result of the fair allocation queue, and push the allocation result to the corresponding user terminal. The core scheduling service module sorts the legitimate requests in the fair allocation queue according to the preset sorting rules. Specifically, this includes: calculating a fair score for each legitimate request using a multi-dimensional weighted scoring algorithm, and sorting the legitimate requests in the fair allocation queue according to the fair scores. The multi-dimensional weighted scoring algorithm includes the following parameters: a scoring item based on the time taken to complete the proof-of-work calculation by the user terminal, a user credit score calculated based on the user's historical behavior data, a device trust level calculated based on the source and strength of the device's trusted signature, and a network latency compensation value. The network latency compensation value is calculated based on the difference between the timestamp of the request sent by the user terminal and the timestamp of the request received by the cloud access gateway, and is used to compensate users whose network latency is higher than a preset threshold. The scoring item based on the time taken to complete the proof-of-work calculation by the user terminal specifically involves: setting a first score for requests within a preset time interval and setting a second score for requests outside the preset time interval, wherein the first score is greater than the second score.

Images