An adaptive SaaS function authorization and charging method based on real-time behavior analysis

Abstract

The application provides a kind of adaptive SaaS function authorization and charging method based on real-time behavior analysis, belong to data processing field, this method includes: SaaS service platform is determined whether user current executes to key operation by continuously collecting the operation sequence that user executes in target SaaS application, and operation sequence includes at least two successive operations;In the case where user current executes to key operation, SaaS service platform determines the type of authorization to the response of key operation according to key operation and the authorization quota information of user in SaaS service platform;SaaS service platform sends the response information of key operation matching the type of authorization to target SaaS application, and SaaS service platform charges response information, and obtains the charging event of user.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to an adaptive SaaS function licensing and billing method based on real-time behavior analysis. Background Technology

[0002] Currently, SaaS (Software as a Service) service platforms typically adopt prepaid packages or pay-as-you-go billing models. In SaaS service scenarios targeting battery swapping cabinet operation and GPS asset tracking, under the prepaid package model, users need to pre-purchase usage rights for a fixed number of battery swapping cabinet slots, the number of activated GPS trackers, or the duration of trajectory data storage. Any additional battery swapping command calls or location data uploads exceeding the package limit will be directly blocked or incur additional charges. Under the pay-as-you-go model, the service platform generates bills based on post-event statistics such as the frequency of user calls to application interfaces (APIs) for battery compartment door opening and closing commands, the frequency of real-time vehicle location trajectory uploads, and the number of times electronic fence alarms are triggered, as well as resource consumption.

[0003] However, the above billing methods are difficult to meet the future needs for flexible and secure billing. Summary of the Invention

[0004] This invention provides an adaptive SaaS function authorization and billing method based on real-time behavior analysis to meet the dual requirements of future SaaS services for billing flexibility and security.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, an adaptive SaaS function authorization and billing method based on real-time behavior analysis is provided. The method is applied to a SaaS service platform and includes: the SaaS service platform continuously collects the operation sequence executed by the user in the target SaaS application to determine whether the user has currently executed a critical operation; the operation sequence includes at least two consecutive operations; if the user has executed a critical operation, the SaaS service platform determines the type of authorization for the response to the critical operation based on the critical operation and the user's authorization quota information in the SaaS service platform; the SaaS service platform sends response information matching the authorization type of the critical operation to the target SaaS application; and the SaaS service platform bills the response information to obtain the user's billing event.

[0006] Therefore, this invention continuously collects the user's operation sequence in the target SaaS application to determine in real time whether the user has executed a critical operation. When a critical operation is executed, the authorization type is dynamically determined based on the critical operation and the user's authorization quota information, and a response message matching the authorization type is sent to the target SaaS application. Simultaneously, billing is applied to this response message. This method deeply binds authorization decisions with the user's real-time operational behavior, achieving dynamic and differentiated authorization of SaaS functions. It avoids the rigid "block if exceeded" experience of traditional prepaid models and overcomes the limitation of a single billing dimension in pay-as-you-go models. While ensuring the continuity of user operations, it provides real-time, fine-grained decision-making basis for subsequent accurate billing, meeting the future dual needs of SaaS services for billing flexibility and security.

[0007] Optionally, the SaaS service platform continuously collects the operation sequence performed by the user in the target SaaS application to determine whether the user is currently performing a key operation. This includes: the SaaS service platform predicts whether the operation the user is about to perform is an operation in a preset set of key operations based on the operations that have already occurred in the operation sequence; the set of key operations includes multiple operations that trigger resource consumption and / or value output; if the operation the user is about to perform belongs to the set of key operations, the SaaS service platform determines that the operation the user is about to perform is a key operation, and continues to determine whether the user is currently performing a key operation by analyzing the operation sequence.

[0008] Therefore, by predicting whether the user's upcoming action is a preset key action, the system achieves proactive perception of user behavior. When a key action is predicted, the system can prepare authorization in advance and respond instantly when the user actually performs the key action, eliminating the response delay caused by real-time calculation in traditional models and further improving the user experience.

[0009] Optionally, the SaaS service platform predicts whether the user's upcoming operation is an operation from a preset set of key operations based on the operations that have already occurred in the operation sequence. This includes: the SaaS service platform inputting the operations that have already occurred in the operation sequence into an intent recognition model to obtain the user's operation intent and the corresponding confidence level, where the confidence level represents the degree of certainty that the intent recognition model has in determining the user's operation intent; the SaaS service platform determining at least one candidate operation corresponding to the user's operation intent in a preset intent-operation mapping relationship, and the matching degree corresponding to each candidate operation among the at least one candidate operation; if the SaaS service platform determines that the confidence level is greater than or equal to a preset confidence threshold, then the SaaS service platform selects the candidate operation with the highest matching degree from the at least one candidate operation as the operation that the user is about to execute; and the SaaS service platform determining whether the operation that the user is about to execute is an operation from the set of key operations.

[0010] Therefore, by deeply analyzing user operation sequences through an intent recognition model, the user's operational intent and corresponding confidence level can be obtained. Furthermore, by combining the intent-operation mapping relationship, candidate operations and their matching degrees can be determined. Selecting the candidate operation with the highest matching degree as the operation the user is about to execute under high confidence conditions significantly improves the accuracy of user behavior prediction, avoids erroneous authorization due to misjudgment, and makes authorization decisions more intelligent.

[0011] Optionally, the SaaS service platform inputs the operation intent recognition model into the operation sequence to obtain the user's operation intent and the corresponding confidence level, including: the SaaS service platform breaks down the operation sequence into multiple atomic operations; the SaaS service platform inputs the multiple atomic operations into the intent recognition model to obtain the user's operation intent and the corresponding confidence level.

[0012] Therefore, it can be seen that by breaking down the operation sequence into multiple atomic operations and inputting them into the intent recognition model, the atomic operations, as the smallest granular unit of SaaS functions, can more finely characterize the user's behavior patterns, making the input features of the intent recognition model richer and more accurate, thereby further improving the accuracy of operation intent recognition.

[0013] Optionally, the SaaS service platform determines the type of authorization for the response to the critical operation based on the critical operation and the user's authorization quota information in the SaaS service platform. This includes: the SaaS service platform obtaining the user's authorization quota information, which includes the user's remaining quota within the pre-designed fee period; if the SaaS service platform determines that the remaining quota is greater than or equal to the quota threshold required to execute the critical operation, then the SaaS service platform determines that the type of authorization for the response to the critical operation is full authorization; if the SaaS service platform determines that the remaining quota is less than the quota threshold, then the SaaS service platform determines that the type of authorization for the response to the critical operation is progressive intervention authorization.

[0014] Therefore, based on the comparison between the user's remaining quota and the quota threshold required for critical operations, two authorization types are clearly distinguished: "full authorization" and "gradual intervention authorization." This distinction allows the system to provide full service when the quota is sufficient and trigger an intervention mechanism when the quota is insufficient, ensuring continuous use for users and providing a basis for decision-making regarding subsequent gradual experience interventions.

[0015] Optionally, the SaaS service platform sends response information to the target SaaS application that matches the type of authorization key operation. This includes: if the type of authorization is full authorization, the SaaS service platform sends a complete response to the target SaaS application, and the response information is a complete response; or, if the type of authorization is progressive intervention authorization, the SaaS service platform determines the level of progressive intervention based on the difference between the remaining quota and the quota threshold, and truncates the complete response according to the level of progressive intervention to obtain response information, and sends the response information to the target SaaS application. The degree to which the complete response is truncated is positively correlated with the level of progressive intervention.

[0016] Therefore, in a progressive intervention authorization scenario, the intervention level is determined based on the difference between the remaining quota and the quota threshold. The complete response is then truncated to varying degrees before being sent to the user according to the intervention level. The degree of truncation is positively correlated with the intervention level, achieving a smooth transition from "full service" to "partial service." This avoids the abrupt experience of "direct blocking" in traditional models, allowing users to still receive some service value even when their quota is insufficient.

[0017] Optionally, the SaaS service platform bills for the response information to obtain the user's billing event, including: the SaaS service platform obtaining the real-time context information of the SaaS service platform when the SaaS service platform generates the response information, the real-time context information including at least one of the SaaS service platform's system load information, user profile information, and business impact information; the SaaS service platform calculating the value weight of the response information based on the response information and the real-time context information; and the SaaS service platform generating the user's billing event for the response information based on the value weight.

[0018] Therefore, by introducing real-time contextual information into the billing process, including multi-dimensional indicators such as system load, user profiles, and business impact, and calculating the value weight of response information based on these indicators, the billing amount no longer depends solely on the operation itself, but is deeply bound to the real-time environment in which the operation occurs. This achieves the "value-anchored" billing concept, making the billing results more accurately reflect the actual value of the operation and thus more precise billing.

[0019] Optionally, the SaaS service platform calculates the value weight of the response information based on the response information and real-time context information, including: the basic weight value W0 corresponding to the key operation obtained by the SaaS service platform; the load adjustment coefficient α determined by the SaaS service platform based on the system load information of the SaaS service platform in the real-time context information, where the load adjustment coefficient α is positively correlated with the system load information; the user level adjustment coefficient β determined by the SaaS service platform based on the user profile information in the real-time context information, where the user level adjustment coefficient β is positively correlated with the user payment level indicated by the user profile information; the business impact adjustment coefficient γ determined by the SaaS service platform based on the business impact information in the real-time context information, where the business impact adjustment coefficient γ is positively correlated with the degree of business impact of the response information on the SaaS service platform indicated by the business impact information; and the SaaS service platform determines the value weight W of the response information according to W = W0 × α × β × γ, where W0 is the basic weight value, α is the load adjustment coefficient, β is the user level adjustment coefficient, and γ is the business impact adjustment coefficient.

[0020] Therefore, by defining value weight as the product of a base weight value and multiple adjustment coefficients—where the load adjustment coefficient reflects the impact of real-time system load on operational value, the user level adjustment coefficient reflects the value difference of user identity, and the business impact adjustment coefficient measures the operation's contribution to the platform's business—this quantitative calculation method makes the determination of value weight more transparent and interpretable, and can respond to environmental changes in real time, resulting in more accurate billing.

[0021] Optionally, the method further includes: the SaaS service platform obtaining the user's operation intent and the corresponding confidence level of the operation intent, wherein the confidence level is used to represent the degree of certainty of the user's operation intent determined by the intent recognition model, and the confidence level ranges from 0 to 1; the SaaS service platform determining a confidence adjustment coefficient based on the confidence level, wherein the confidence adjustment coefficient satisfies the following relationship: 1 + k × C, where k is a preset confidence weight coefficient and k>0, and C is the confidence level; the SaaS service platform determining the value weight W of the response information based on W = W0× α × β × γ, including: the SaaS service platform determining the value weight W of the response information based on W = W0×α × β × γ × δ, wherein γ is the business impact adjustment coefficient and δ is the confidence adjustment coefficient.

[0022] Therefore, by incorporating the confidence level of the user's intent into the value weight calculation, the higher the confidence level, the larger the confidence adjustment coefficient, and the higher the final value weight. This design directly reflects the clarity of the user's intent in the billing results, assigning higher billing weights to operations with clear intent and high value, achieving a deep binding between intent and value, and further improving the accuracy of billing.

[0023] Optionally, the SaaS service platform generates a billing event for the user's response information based on the value weight, including: the SaaS service platform determines the billing amount F of the response information according to F = W × P, where W is the value weight and P is the unit price coefficient corresponding to the information content of the response information; the SaaS service platform generates a billing event record, which includes the identifier of the key operation, the information content of the response information, the value weight W, the billing amount F, and real-time context information; and the method further includes: the SaaS service platform stores the billing event record in the blockchain and updates the user's remaining quota within the pre-designed billing period according to the billing event record.

[0024] Therefore, by explicitly defining the billing amount as the product of value weight and unit price coefficient, and generating and storing billing event records containing key operation identifiers, information content, value weight, billing amount, and real-time context information on the blockchain, the trustworthy evidence storage characteristics of the blockchain ensure the traceability and immutability of the billing process. Simultaneously, real-time updates of remaining quotas provide users with a transparent and reliable billing query service, enhancing user trust in the billing results and improving the user experience.

[0025] In a second aspect, an electronic device is provided, comprising: a processor and a memory; the memory is used to store a computer program, which, when executed by the processor, causes the electronic device to perform the method described in the first aspect.

[0026] In one possible design, the electronic device described in the second aspect may further include a transceiver. This transceiver may be a transceiver circuit or an interface circuit. The transceiver can be used for communication between the electronic device described in the second aspect and other electronic devices.

[0027] In the embodiments of the present invention, the electronic device described in the second aspect may be a terminal, or a chip (system) or other component or assembly disposed in the terminal, or a system containing the terminal.

[0028] Thirdly, a computer-readable storage medium is provided, comprising: a computer program or instructions; when the computer program or instructions are executed on a computer, the computer causes the computer to perform the method described in the first aspect. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the architecture of a SaaS service system provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the adaptive SaaS function authorization and billing method based on real-time behavior analysis provided in an embodiment of the present invention; Figure 3This is a schematic diagram illustrating the process of billing response information by the SaaS service platform provided in this embodiment of the invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0030] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0031] In this embodiment of the invention, descriptions such as "when," "under the circumstances," "if," and "if" all refer to the device making corresponding processing under certain objective circumstances, and are not limited to a specific time. They do not require the device to make a judgment action during implementation, nor do they imply any other limitations.

[0032] To facilitate understanding of the embodiments of the present invention, firstly, let's take... Figure 1 The SaaS service system shown in the image is an example. Figure 1 As shown, the SaaS service system may include: a SaaS service platform and target SaaS applications.

[0033] The SaaS service platform is a server device, server cluster, or distributed system based on a cloud-native architecture deployed in the cloud. Its form includes physical servers, virtual machines, or containerized service instances. The SaaS service platform has the capabilities to receive, store, compute, and analyze data. It is used to centrally process user operation data such as battery swapping requests, GPS location trajectories, and battery status monitoring from various target SaaS applications. It executes core business logic such as intent recognition for scanning to open the locker, authorization decisions for door opening and battery rental, and billing calculations based on the number of battery swaps or location frequency.

[0034] The target SaaS application is an application deployed on user terminal devices, including smartphones, tablets, and personal computers where the battery swapping operator's management backend is located, as well as smart wearable devices worn by on-site maintenance personnel. The target SaaS application can take the form of a native application (App), a web application (WebApp), a mini-program, or a hybrid application. The target SaaS application provides users with specific software services such as monitoring the status of battery swapping cabinet slots, querying battery power, real-time vehicle location tracking, and historical trajectory playback. It also has the capability to capture and report user scanning actions, battery swapping confirmation operations, and vehicle GPS data collection.

[0035] In this system: The SaaS service platform and the target SaaS application establish a connection via wired or wireless communication networks, and interact with each other using an Application Programming Interface (API) based on HyperText Transfer Protocol (HTTP), HyperText Transfer Protocol Secure (HTTPS), WebSocket, or a custom Transmission Control Protocol (TCP). Specifically, the target SaaS application, as a client, proactively initiates a connection request to the SaaS service platform, establishing a long or short connection channel. The SaaS service platform, as a server, provides an API interface to receive user operation data reported by the target SaaS application, such as QR code scanning instructions for opening the battery compartment, latitude and longitude data reported by the GPS locator, and battery level change events. The platform then sends authorization decisions, response information, gradual intervention prompts, and intent clarification options such as "confirm battery removal" or "temporarily increase location reporting frequency" to the target SaaS application. The communication between the two uses an encrypted transmission mechanism to ensure the security and integrity of the battery swapping operation instructions and vehicle location information data transmission.

[0036] Figure 2 This is a flowchart illustrating the method provided in an embodiment of the present invention. This adaptive SaaS function authorization and billing method based on real-time behavior analysis is applicable to the aforementioned SaaS service system, involving the aforementioned SaaS service platform and the target SaaS application. The specific process is as follows: S201, the SaaS service platform determines whether the user has performed a critical operation by continuously collecting the sequence of operations performed by the user in the target SaaS application. The sequence of operations includes at least two consecutive operations.

[0037] An operation sequence refers to a set of consecutive operations performed by a user in a target SaaS application. These operations are arranged chronologically, reflecting the user's behavioral trajectory while using the target SaaS application. Each operation in the operation sequence records the operation type, operation object, operation timestamp, and operation context parameters. The operation sequence includes at least two consecutive operations to facilitate the analysis of user behavior patterns and operational intentions. For example, taking user Xiao Li's usage scenario in the intelligent data analysis platform as an example, the operation sequence collected by the SaaS service platform could be: Operation 1 "Open the sales data dashboard", Operation 2 "Filter out data from East China", Operation 3 "Aggregate data by month", Operation 4 "Generate a line chart preview", Operation 5 "Stare at the chart for 15 seconds".

[0038] The SaaS service platform predicts whether the user's upcoming operation is an operation from a pre-defined set of key operations based on the operations that have already occurred in the operation sequence. The set of key operations includes multiple operations that trigger resource consumption and / or value output.

[0039] In this context, "operations that have already occurred" refers to the actions a user has completed within the sequence of actions performed in the target SaaS application. These operations form the input basis for the intent recognition model. The key operation set is a pre-configured set of operation types that require authorization decisions. This set includes multiple operations that trigger resource consumption and / or value output, such as "export the complete report," "generate a shareable link," and "download raw data." For example, continuing the previous example, when user Xiao Li performs operation 5, "staring at the chart for 15 seconds," operations 1 through 5 are considered "operations that have already occurred." Based on these five "operations that have already occurred," the SaaS service platform predicts whether the user's upcoming operation falls within the key operation set, such as whether they are about to execute the key operation "export the complete report." In other words, all operations within the operation sequence can be understood as "operations that have already occurred."

[0040] For example, a SaaS service platform can use an input intent recognition model to identify the user's operational intent and its corresponding confidence level from the input intent recognition model of the operations that have occurred in the operation sequence. The intent recognition model is a machine learning model deployed on the SaaS service platform, used to analyze the user's operational behavior and infer the user's operational purpose. This model can adopt a Transformer-based neural network architecture, supporting real-time inference. Operation intent refers to the classification result of the user's operational purpose output by the intent recognition model, which may include "exploratory use," "productive use," or "commercial delivery use." Confidence level is a probability value between 0 and 1, used to represent the degree of certainty that the intent recognition model determines the user's operational intent; the higher the confidence level, the more confident the model is in its judgment. For example, continuing the above example, the SaaS service platform inputs the intent recognition model of the five operations that have occurred (operations 1 to 5), and the model outputs the operational intent as "commercial delivery use," with a corresponding confidence level of 85%.

[0041] Specifically, the SaaS service platform breaks down the operations that have occurred in the operation sequence into multiple atomic operations. An atomic operation is an indivisible unit of operation obtained by decomposing the functionality of the target SaaS application into its smallest granularity; it is the basic component constituting complex user behavior. For example, the operation "Export complete report" can be broken down into multiple atomic operations such as "Click the export button," "Select export format," "Select data range," and "Confirm export." Continuing with the above example, operations 1 to 5 can be broken down into multiple atomic operations such as "Click the dashboard," "Click the filter," "Select East China region," "Click the aggregation option," "Select monthly," "Click to generate preview," and "Preview for 15 seconds." The SaaS service platform then inputs these atomic operations into an intent recognition model to obtain the user's operation intent and the corresponding confidence level. Based on this, the SaaS service platform can determine at least one candidate operation corresponding to the user's operation intent, and the matching degree of each candidate operation within that at least one candidate operation, using a pre-configured intent-operation mapping relationship. The intent-operation mapping relationship is a pre-configured mapping table that defines multiple candidate operations that may correspond to each operation intent, as well as the matching degree of each candidate operation with that intent. Candidate actions refer to the predicted subsequent actions a user might perform based on their intended action. The matching degree is a value between 0 and 1, representing the degree of correlation between the candidate action and the intended action; a higher matching degree indicates that the candidate action is more consistent with the current intended action. For example, continuing the previous example, the SaaS service platform queries the intent-action mapping relationship for candidate actions corresponding to the intent "commercial delivery use," obtaining three candidate actions: Candidate action A "Export complete report" with a matching degree of 0.9, Candidate action B "Generate share link" with a matching degree of 0.6, and Candidate action C "Download raw data" with a matching degree of 0.8. If the SaaS service platform determines that the confidence level is greater than or equal to a preset confidence threshold, then the SaaS service platform selects the candidate action with the highest matching degree from at least one candidate action as the action the user is about to perform, and determines whether the action the user is about to perform is an action in the key action set. For example, continuing the previous example, assuming the preset confidence threshold is 70%, since the model output confidence level of 85% is greater than 70%, the SaaS service platform selects the candidate action A "Export complete report" with the highest matching degree from the three candidate actions as the action the user is about to perform.

[0042] Therefore, if the operation a user is about to perform belongs to the set of critical operations, the SaaS service platform determines that the operation is critical and continues to analyze the operation sequence to determine whether the user has actually performed a critical operation. For example, continuing the above example, the SaaS service platform determines whether "Export the complete report" belongs to the set of critical operations. Since "Export the complete report" is an operation that triggers resource consumption and belongs to the set of critical operations, the SaaS service platform determines that "Export the complete report" is a critical operation and continues to monitor the user's operation sequence. When the user actually performs operation 6, "Click the Export Complete Report button," the SaaS service platform determines that the user has performed a critical operation, triggering the subsequent authorization and billing process.

[0043] S202, When a user is currently performing a critical operation, the SaaS service platform determines the type of authorization to respond to the critical operation based on the critical operation and the user's authorization quota information in the SaaS service platform.

[0044] For example, the SaaS service platform obtains the user's authorized quota information, which includes the user's remaining quota within the pre-designed fee period. If the SaaS service platform determines that the remaining quota is greater than or equal to the quota threshold required to perform a critical operation, the SaaS service platform determines that the type of authorization for the response to the critical operation is full authorization. If the SaaS service platform determines that the remaining quota is less than the quota threshold, the SaaS service platform determines that the type of authorization for the response to the critical operation is incremental intervention authorization.

[0045] The authorized quota information refers to the data set stored by the user in the SaaS service platform related to authorized usage rights, used to measure the user's currently available service quota. The authorized quota information includes at least the user's remaining quota within the pre-designed billing period. The pre-designed billing period refers to a pre-set billing time interval, such as a calendar month, a calendar quarter, or a custom settlement cycle. The remaining quota refers to the unused authorized quota within the current pre-designed billing period, which can be quantified based on various dimensions such as the number of operations, data volume, and computing resource consumption. For example, continuing the above example, suppose user Li's pre-designed billing period is a calendar month, and the current period is February 2026. Li purchased the basic package during this period, which includes an authorized quota of 1000 "commercial delivery operations" (i.e., allowing the execution of 1000 critical commercial delivery operations). As of now, Li has executed 700 commercial delivery operations within this period, therefore, his remaining quota is 300.

[0046] The quota threshold refers to the authorized amount required to execute the current critical operation. This threshold can be pre-configured based on factors such as the type, complexity, and resource consumption of the critical operation. For example, for the critical operation "export a complete report," the quota threshold can be configured to consume the quota of one commercial delivery operation; for a high-load operation like "export a report containing 100,000 rows of data," the quota threshold can be configured to consume the quota of five operations. Full authorization means allowing the complete response information to be sent to the target SaaS application without any truncation or restriction. Progressive intervention authorization means providing partial services to the user through certain intervention methods (such as truncating the response, delaying the response, prompting the user, etc.) when the quota is insufficient, rather than directly blocking it.

[0047] For example, continuing the previous example, for the critical operation "Export Full Report," let's assume its quota threshold is configured to consume the quota of one business delivery operation. User Li currently has 300 remaining quotas, exceeding the quota threshold of one. Therefore, the SaaS service platform determines the authorization type for this critical operation to be full authorization. If we assume another scenario: Li has already performed 999 business delivery operations in this period, leaving only one quota. If the "Export Full Report" critical operation is performed again, since the remaining quota of one is equal to the quota threshold of one, the SaaS service platform can still determine the authorization type as full authorization and deduct this last quota after execution. If we further assume Li's remaining quota is 0, less than the quota threshold of one, then the SaaS service platform determines the authorization type for this critical operation to be progressive intervention authorization. Subsequent progressive intervention processes will be triggered, such as partially truncating the exported report data, prompting the user that the quota is insufficient, and providing supplementary purchase options. Through the above methods, the SaaS service platform can dynamically determine the authorization type for critical operations based on the user's real-time quota, thereby ensuring the continuity of user services while achieving fine-grained control over the use of SaaS functions.

[0048] S203, the SaaS service platform sends response information to the target SaaS application that matches the type of key operation authorized, and the SaaS service platform bills the response information to obtain the user's billing event.

[0049] In this context, response information refers to the data content generated and returned by the SaaS service platform to the target SaaS application in response to a key operation performed by a user. The specific form of the response information depends on the type of the key operation. For example, for the "export a complete report" operation, the response information could be a file stream containing report data; for the "generate a chart" operation, the response information could be binary data of the chart image. The authorization type is determined in S202, including full authorization and progressive intervention authorization. If the authorization type is full authorization, the SaaS service platform sends the complete response information to the target SaaS application; if the authorization type is progressive intervention authorization, the SaaS service platform determines the level of progressive intervention based on the difference between the remaining quota and the quota threshold, and truncates the complete response information accordingly before sending it. The truncated response information is the response information sent in this instance. For example, continuing the examples in S201 and S202, if user Xiao Li's key operation is "export a complete report," and S202 determines that his authorization type is full authorization, then the SaaS service platform sends the complete exported report data to the target SaaS application as the response information. After receiving the response information, the target SaaS application displays the complete report content on the user interface for Xiao Li to view or download.

[0050] Furthermore, such as Figure 3 As shown, the SaaS service platform bills for response information and obtains the user's billing events, including the following: S301, When the SaaS service platform obtains the response information generated by the SaaS service platform, the real-time context information of the SaaS service platform.

[0051] Real-time context information refers to multi-dimensional data related to the operating environment and state of the SaaS service platform at the moment it generates and sends response information. Real-time context information reflects the current state of the service platform, user characteristics, and the business value of the operation, and is an important basis for subsequent value weight calculations. Real-time context information includes at least one of the following: system load information, user profile information, and business impact information of the SaaS service platform.

[0052] 1) System load information refers to the current resource usage of the SaaS service platform, such as CPU utilization, memory usage, and network bandwidth utilization. System load information reflects the busy level of the service platform at any given moment; the higher the load, the more system resources are consumed in generating response information.

[0053] 2) User profile information refers to the user characteristic descriptions constructed by the SaaS service platform based on data such as the user's historical behavior, payment level, and usage frequency. User profile information includes the user's payment level (such as basic version, professional version, enterprise version), historical conversion tendency (such as whether they frequently convert from free users to paid users), and feature preferences.

[0054] 3) Business impact information refers to the evaluation metrics for the contribution of this response information to the business value of the SaaS service platform. Business impact information can be determined through pre-defined knowledge graphs or business rules. For example, the "export financial statements" operation may be marked as high business impact, while the "export daily logs" operation may be marked as low business impact.

[0055] For example, continuing the above example, when the SaaS service platform generates Xiao Li's "Export Full Report" response, the real-time context information collected is as follows: System load information: The current CPU utilization is 75%, which is a high load state. User profile information: Xiao Li's payment level is "Basic", historical usage frequency is "High Frequency", and historical conversion tendency is "High" (i.e., frequently switching from free features to paid features). Business impact information: According to business rules, the "Export Full Report" operation involves financial data and is marked with a business impact score of 0.8 (value range 0~1).

[0056] S302, the SaaS service platform calculates the value weight of the response information based on the response information and real-time context information.

[0057] The value weight is a dimensionless numerical value used to quantify the relative value of the response information in a specific context. The higher the value weight, the greater the value of the operation under the current system state, user attributes, and business scenario, and the higher the corresponding billing amount.

[0058] For example, the SaaS service platform obtains the base weight value W0 corresponding to key operations. The base weight value refers to the baseline weight pre-configured for each key operation, reflecting the basic value of the operation under standard conditions. For example, the base weight value of the "Export Full Report" operation can be configured as 1.0, and the base weight value of the "Generate Share Link" operation can be configured as 0.5.

[0059] Continuing with the example above, the SaaS service platform obtains the basic weight value W0 = 1.0 corresponding to the key operation "Export Full Report".

[0060] The SaaS service platform determines a load adjustment coefficient α based on the system load information from the real-time context information. The load adjustment coefficient α is positively correlated with the system load information. The load adjustment coefficient is a real number greater than 0, used to adjust the base weight according to the system load level. The higher the load, the larger the adjustment coefficient, reflecting the additional cost required to provide services when resources are scarce. For example, the load adjustment coefficient α can be defined as 1 + (CPU utilization - 50%) / 100%, but it must be ensured that the coefficient does not fall below a certain lower limit. For example, continuing the above example, if the current CPU utilization is 75%, the load adjustment coefficient α can be set as 1 + (75% - 50%) / 100% = 1.25.

[0061] The SaaS service platform determines the user level adjustment coefficient β based on user profile information in real-time context information. This coefficient is positively correlated with the user's payment level indicated by the user profile information. The user level adjustment coefficient is used to adjust the base weight based on the user's payment level. The higher the payment level, the larger the coefficient, reflecting the service weight of high-value users. For example, β=1.0 for basic users, β=1.2 for professional users, and β=1.5 for enterprise users. Continuing the above example, if Xiao Li is a "basic" user, the user level adjustment coefficient β can be set to 1.0.

[0062] The SaaS service platform determines a business impact adjustment coefficient γ based on business impact information in real-time context information. This coefficient is positively correlated with the degree of business impact of the response information indicated by the business impact information on the SaaS service platform. The business impact adjustment coefficient is used to adjust the base weight according to the business importance of the operation. The higher the business impact, the larger the coefficient. For example, the business impact adjustment coefficient γ can be set as 1 + business impact.

[0063] Continuing with the example above, if the business impact is 0.8, then the business impact adjustment coefficient γ = 1 + 0.8 = 1.8.

[0064] The SaaS service platform determines the value weight W of the response information based on W = W0 × α × β × γ, where W0 is the basic weight value, α is the load adjustment coefficient, β is the user level adjustment coefficient, and γ is the business impact adjustment coefficient.

[0065] Continuing with the example above, the value weight W = 1.0 × 1.25 × 1.0 × 1.8 = 2.25.

[0066] Optionally, the method further includes: The SaaS service platform obtains the user's operation intent and the corresponding confidence level. The confidence level is used to represent the degree of certainty that the intent recognition model determines the user's operation intent. The confidence level ranges from 0 to 1. Based on the confidence level, the SaaS service platform determines the confidence level adjustment coefficient, which satisfies the following relationship: δ = 1 + k ×C, where k is the preset confidence level weight coefficient and k>0, and C is the confidence level.

[0067] The confidence adjustment coefficient is used to incorporate the degree of certainty in intent recognition into the value weight calculation. The clearer the intent (the higher the confidence), the larger the adjustment coefficient, reflecting that actions with clear user intent have higher value. The preset confidence weight coefficient k controls the contribution of confidence to the final weight and can be adjusted according to business needs, for example, k = 0.5.

[0068] Continuing with the example above, the operational intent output by the intent recognition model in S201 is "commercial delivery use," with a confidence level C = 85% = 0.85. Assuming the preset confidence weight coefficient k = 0.5, then the confidence adjustment coefficient δ = 1 + 0.5 × 0.85 = 1.425.

[0069] Therefore, the SaaS service platform determines the value weight W of the response information according to W = W0 × α × β × γ × δ, where γ is the business impact adjustment coefficient and δ is the confidence adjustment coefficient.

[0070] Continuing with the example above, after introducing the confidence adjustment coefficient, the value weight W = 1.0 × 1.25 × 1.0 × 1.8 × 1.425 ≈ 3.21.

[0071] S303, the SaaS service platform generates billing events for users based on value weights and response information.

[0072] Specifically, the SaaS service platform determines the billing amount F for the response information based on F = W × P, where W is the value weight and P is the unit price coefficient corresponding to the amount of information in the response information. The unit price coefficient refers to the monetary amount corresponding to a unit of value weight, which can be dynamically adjusted according to the amount of information in the response information (such as data volume, computational complexity, etc.). For example, for exporting reports, the unit price coefficient P can be defined to be proportional to the number of rows of data exported, such as P = 0.1 yuan for every 1000 rows of data.

[0073] Continuing with the example above, suppose the report exported by Xiao Li contains 100,000 rows of data, and the unit price coefficient P is set to 0.01 yuan / thousand rows, that is, P = 0.01 × (100000 / 1000) = 1.0 yuan. Then the billing amount F = W × P = 3.21 × 1.0 = 3.21 yuan.

[0074] The SaaS service platform generates billing event logs, which include identifiers of key operations, information content of response messages, value weight W, billing amount F, and real-time context information. Billing event logs are a complete data structure describing a billing process and are used for subsequent billing generation, auditing, and user queries.

[0075] Continuing with the example above, the generated billing event record can include the following fields: Key operation identifier: "export_full_report", Response information volume: 100,000 rows, Value weight W: 3.21, Billing amount F: 3.21 yuan, Real-time context information: {System load: 75%, User level: Basic version, Business impact: 0.8, Confidence level: 0.85}, Timestamp, User identifier: Xiao Li's user ID. Additionally, the SaaS service platform stores billing event records in the blockchain and updates the user's remaining quota within the pre-designed billing cycle based on the billing event records.

[0076] Blockchain, a decentralized distributed ledger technology, ensures the immutability and traceability of billing event records. Storing billing event records on the blockchain prevents malicious modification of billing data and enhances user trust in billing results. Simultaneously, the SaaS service platform updates the user's remaining quota within the pre-designed billing cycle based on the billing amount or the quota consumed in this transaction. For example, if this operation consumed the quota for one commercial delivery operation (since the quota threshold is configured as one), the remaining quota is updated from 300 to 299.

[0077] Continuing with the example above, the SaaS service platform records the aforementioned billing events in the blockchain system and updates Xiao Li's remaining quota to 299 times. Users can subsequently view their billing history through a query interface, including the intent, confidence level, context information, value weight, and billing amount for each operation, achieving a completely transparent billing experience.

[0078] Through the above steps, the SaaS service platform completes the sending and billing of key operation response information, realizing accurate billing based on real-time behavior analysis and dynamic value weighting.

[0079] In summary, this invention continuously collects the sequence of user operations performed in a target SaaS application to determine in real time whether the user has executed a critical operation. When a critical operation is executed, the authorization type is dynamically determined based on the critical operation and the user's authorization quota information, and a response message matching the authorization type is sent to the target SaaS application. Simultaneously, billing is applied to this response message. This method deeply binds authorization decisions to the user's real-time operational behavior, achieving dynamic and differentiated authorization of SaaS functions. It avoids the rigid "block if exceeded" experience of traditional prepaid models and overcomes the limitation of a single billing dimension in pay-as-you-go models. While ensuring the continuity of user operations, it provides real-time, fine-grained decision-making basis for subsequent accurate billing, meeting the dual needs of future SaaS services for billing flexibility and security.

[0080] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, the electronic device 400 may include a processor 401. Optionally, the electronic device 400 may also include a memory 402 and / or a transceiver 403. The processor 401 is coupled to the memory 402 and the transceiver 403, for example, via a communication bus.

[0081] The following is combined Figure 4 A detailed description of each component of the electronic device 400 is provided below: The processor 401 is the control center of the electronic device 400. It can be a single processor or a collective term for multiple processing elements. For example, the processor 401 can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of the present invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0082] Optionally, the processor 401 can perform various functions of the electronic device 400 by running or executing software programs stored in the memory 402 and calling data stored in the memory 402, such as performing the aforementioned functions. Figure 2 The diagram illustrates an adaptive SaaS feature licensing and billing method based on real-time behavior analytics.

[0083] In a specific implementation, as one example, processor 401 may include one or more CPUs, for example... Figure 4 CPU0 and CPU1 are shown in the diagram.

[0084] In a specific implementation, as one example, the electronic device 400 may also include multiple processors. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0085] The memory 402 is used to store the software program that executes the solution of the present invention, and is controlled by the processor 401 to execute it. The specific implementation method can be referred to the above method embodiment, and will not be repeated here.

[0086] Optionally, the memory 402 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 402 may be integrated with the processor 401 or exist independently, and may be accessed through the interface circuit of the electronic device 400. Figure 4 (Not shown in the image) is coupled to processor 401, and this embodiment of the invention does not specifically limit this.

[0087] Transceiver 403 is used for communication with other electronic devices.

[0088] Alternatively, transceiver 403 may include a receiver and a transmitter. Figure 4 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.

[0089] Alternatively, the transceiver 403 can be integrated with the processor 401, or it can exist independently and be connected via the interface circuit of the electronic device 400. Figure 4(Not shown in the image) is coupled to processor 401, and this embodiment of the invention does not specifically limit this.

[0090] Understandable Figure 4 The structure of the electronic device 400 shown does not constitute a limitation on the electronic device. Actual electronic devices may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0091] Furthermore, the technical effects of the electronic device 400 can be referred to the technical effects of the methods described in the above method embodiments, and will not be repeated here.

[0092] It should be understood that the processor in the embodiments of the present invention can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0093] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0094] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0095] It should be understood that, in various embodiments of the present invention, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0096] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

Claims

1. An adaptive SaaS function authorization and billing method based on real-time behavior analysis, characterized in that, The method is applied to a SaaS service platform, and the method includes: The SaaS service platform determines whether the user has executed a critical operation by continuously collecting the operation sequence performed by the user in the target SaaS application. The operation sequence includes at least two consecutive operations. When the user is currently performing a critical operation, the SaaS service platform determines the type of authorization to respond to the critical operation based on the critical operation and the user's authorization quota information in the SaaS service platform; The SaaS service platform sends response information to the target SaaS application that matches the key operation of the authorization type, and the SaaS service platform bills the response information to obtain the user's billing event.

2. The method according to claim 1, characterized in that, The SaaS service platform continuously collects the sequence of operations performed by users in the target SaaS application to determine whether the user has currently performed a critical operation, including: The SaaS service platform predicts whether the operation the user is about to perform is an operation from a preset set of key operations based on the operations that have already occurred in the operation sequence; the set of key operations includes multiple operations that trigger resource consumption and / or value output. If the operation that the user is about to perform belongs to the set of key operations, the SaaS service platform determines that the operation that the user is about to perform is the key operation, and continues to determine whether the user has currently performed the key operation by analyzing the operation sequence.

3. The method according to claim 2, characterized in that, The SaaS service platform predicts whether the user's upcoming operation is an operation from a preset set of key operations based on the operations that have already occurred in the operation sequence, including: The SaaS service platform uses the operation input intent recognition model that has occurred in the operation sequence to obtain the user's operation intent and the confidence level corresponding to the operation intent. The confidence level is used to represent the degree of certainty that the intent recognition model determines the user's operation intent. The SaaS service platform determines at least one candidate operation corresponding to the user's operation intent in a preset intent-operation mapping relationship, and the matching degree corresponding to each candidate operation in the at least one candidate operation; If the SaaS service platform determines that the confidence level is greater than or equal to a preset confidence level threshold, then the SaaS service platform selects the candidate operation with the highest matching degree from the at least one candidate operation as the operation that the user is about to execute. The SaaS service platform determines whether the operation that the user is about to perform is an operation in the set of key operations.

4. The method according to claim 3, characterized in that, The SaaS service platform uses the operation input intent recognition model that has occurred in the operation sequence to obtain the user's operation intent and the confidence level corresponding to the operation intent, including: The SaaS service platform breaks down the operations that have occurred in the operation sequence into multiple atomic operations; The SaaS service platform inputs the multiple atomic operations into the intent recognition model to obtain the user's operation intent and the confidence level corresponding to the operation intent.

5. The method according to claim 1, characterized in that, The SaaS service platform determines the type of authorization for the response to the key operation based on the key operation and the user's authorization quota information in the SaaS service platform, including: The SaaS service platform obtains the user's authorized quota information, which includes the user's remaining quota within the pre-designed fee period; If the SaaS service platform determines that the remaining quota is greater than or equal to the quota threshold required to perform the critical operation, then the SaaS service platform determines that the authorization type for the response to the critical operation is full authorization; if the SaaS service platform determines that the remaining quota is less than the quota threshold, then the SaaS service platform determines that the authorization type for the response to the critical operation is progressive intervention authorization.

6. The method according to claim 5, characterized in that, The SaaS service platform sends response information to the target SaaS application that matches the key operation of the authorization type, including: If the type of authorization is full authorization, then the SaaS service platform sends a complete response to the target SaaS application, and the response information is the complete response; or, If the authorization type is progressive intervention authorization, the SaaS service platform determines the progressive intervention level based on the difference between the remaining quota and the quota threshold, and truncates the complete response according to the progressive intervention level to obtain the response information, and sends the response information to the target SaaS application. The degree to which the complete response is truncated is positively correlated with the progressive intervention level.

7. The method according to claim 1, characterized in that, The SaaS service platform bills the response information to obtain the user's billing events, including: When the SaaS service platform obtains the response information generated by the SaaS service platform, the real-time context information of the SaaS service platform includes at least one of the following: system load information, user profile information, and business impact information of the SaaS service platform. The SaaS service platform calculates the value weight of the response information based on the response information and the real-time context information; The SaaS service platform generates the user's billing event based on the value weight.

8. The method according to claim 7, characterized in that, The SaaS service platform calculates the value weight of the response information based on the response information and the real-time context information, including: The SaaS service platform obtains the basic weight value W0 corresponding to the key operation; The SaaS service platform determines a load adjustment coefficient α based on the system load information of the SaaS service platform in the real-time context information, and the load adjustment coefficient α is positively correlated with the system load information; The SaaS service platform determines the user level adjustment coefficient β based on the user profile information in the real-time context information. The user level adjustment coefficient β is positively correlated with the user payment level indicated by the user profile information. The SaaS service platform determines a business impact adjustment coefficient γ based on the business impact information in the real-time context information. The business impact adjustment coefficient γ is positively correlated with the degree of business impact of the response information indicated by the business impact information on the SaaS service platform. The SaaS service platform determines the value weight W of the response information according to W = W0 × α × β × γ, where W0 is the basic weight value, α is the load adjustment coefficient, β is the user level adjustment coefficient, and γ is the business impact adjustment coefficient.

9. The method according to claim 8, characterized in that, The method further includes: The SaaS service platform obtains the user's operation intent and the confidence level corresponding to the operation intent. The confidence level is used to represent the degree of certainty that the intent recognition model is certain about the user's operation intent. The confidence level ranges from 0 to 1. The SaaS service platform determines a confidence adjustment coefficient based on the confidence level, wherein the confidence adjustment coefficient satisfies the following relationship: 1 + k × C, where k is a preset confidence weight coefficient and k>0, and C is the confidence level; The SaaS service platform determines the value weight W of the response information based on W = W0 × α × β × γ, including: The SaaS service platform determines the value weight W of the response information according to W = W0 × α × β × γ × δ, where γ is the business impact adjustment coefficient and δ is the confidence adjustment coefficient.

10. The method according to any one of claims 7-9, characterized in that, The SaaS service platform generates the user's billing event based on the value weight, including: The SaaS service platform determines the billing amount F of the response information according to F = W × P, where W is the value weight and P is the unit price coefficient corresponding to the information content of the response information. The SaaS service platform generates billing event records, which include the identifier of the key operation, the information content of the response information, the value weight W, the billing amount F, and the real-time context information. Furthermore, the method further includes: The SaaS service platform stores the billing event records in the blockchain and updates the user's remaining quota within the pre-designed billing cycle based on the billing event records.

Images