A rule engine-based internet of things package purchase method and system

Abstract

This invention discloses a method and system for purchasing IoT packages based on a rule engine, comprising the following steps: S1, receiving user requests and constructing multi-dimensional context information. When a user initiates a package query or purchase request, relevant information is obtained from the user center, device management module, and package configuration center according to the user identifier, device identifier, and target business scenario, respectively, to construct a context data packet containing user variables, device variables, and package variables. This invention has the advantage of high flexibility, solving the problems of rigid control of IoT package purchase conditions, inflexible rule configuration, scattered verification logic, poor operational autonomy, and difficulty in combining and prioritizing multiple rules in the prior art.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, specifically to a method and system for purchasing IoT packages based on a rules engine. Background Technology

[0002] Against the backdrop of the rapid development of cloud computing and Software as a Service (SaaS), SaaS platforms and IoT cloud platforms serve as crucial infrastructure supporting enterprise digital transformation and intelligent equipment management. One of their core functions is to provide users with flexible and configurable package services. Traditional package management systems typically use hard-coded methods to implement purchasing logic, supporting only simple billing models and static user access control, making it difficult to cope with the increasingly complex business scenarios. With the large-scale deployment of IoT devices and the increasing refinement of industry application scenarios, platform operators urgently need to support different conditional purchasing strategies to achieve refined operations and differentiated services. Furthermore, different partners or channel providers have highly customized requirements regarding the visibility, target audience, and purchase thresholds of packages. Traditional systems lack a unified and scalable rule configuration mechanism, resulting in high development costs, slow response times, and maintenance difficulties. Although some platforms have attempted to introduce configurable interfaces or script engines to improve flexibility, their rule expression capabilities are limited, their coupling is high, and it is difficult to guarantee the consistency and security of rule execution. Existing technical solutions have several shortcomings in implementing conditional purchase control for packages. Currently, they mainly employ hard-coding, simple configuration, or distributed verification methods. Hard-coding directly writes business logic into the code, lacking flexibility. Simple configuration only supports single-dimensional restrictions such as country code or price, making it difficult to handle scenarios with multiple combinations of conditions. Distributed verification, on the other hand, scatters verification logic for users, devices, and orders across various business modules, leading to maintenance difficulties and redundant development. Therefore, there is an urgent need for a conditional package purchase method and system based on a rules engine to solve the above problems. By decoupling business rules from core logic, the system can achieve dynamic package configuration, standardized condition judgment, and automated purchase control, thereby effectively supporting the complex package management needs of multi-tenant and multi-scenario environments. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for purchasing IoT packages based on a rule engine. This method and system have the advantages of high flexibility and solve the problems of rigid control of IoT package purchase conditions, inflexible rule configuration, scattered verification logic, poor operational autonomy, and difficulty in managing multiple rule combinations and priorities in the prior art. To achieve the above objectives, the present invention provides the following technical solution: a method for purchasing IoT packages based on a rules engine, comprising the following steps: S1. Receive user requests and construct multi-dimensional context information. When a user initiates a package query or purchase request, based on the user identifier, device identifier, and target business scenario, relevant information is obtained from the user center, device management module, and package configuration center respectively, and a context data packet containing user variables, device variables, and package variables is constructed. S2. Dynamically filter the list of visible packages based on the rule engine. First, retrieve all available packages, then filter the retrieved packages according to the context data package, and finally select the suitable packages. S3. Perform unified multi-dimensional condition verification on visible packages. For the selected compatible packages, conduct centralized and unified multi-dimensional verification before users purchase. S4. Create an order and complete service activation. If the target package passes all the verification conditions, the system generates an order record, deducts the user's balance or binds the payment method, completes the order status update, and triggers the service activation process. If the verification fails, the specific reason for the failure is returned to the front end for the user to be notified. As a preferred embodiment of the IoT package purchase method based on a rule engine according to the present invention, the user variables in S1 include user account, regional information, test identifier, historical purchase records and application information; the device variables include device type, network type, activation status, IoT card information and device product identifier; and the package variables include package ID, country code, price, status and custom label. In a preferred embodiment of the IoT package purchase method based on a rule engine according to the present invention, when filtering packages in S2, the rule identifier array associated with the package is obtained, the corresponding rule content is loaded from the rule library according to the rule identifier array, and sorted by priority to dynamically build a rule knowledge base. If the rule combination has been cached, the cached instance is directly reused, and the context data packet is used as the fact input to the rule engine. As a preferred embodiment of the IoT package purchase method based on the rule engine of the present invention, the rule engine executes the rules sequentially. If any rule determines that the current context does not meet the conditions, the package is marked as invisible and the execution of subsequent rules is terminated. The package is added to the list of visible compatible packages only when all rules are passed. As a preferred embodiment of the IoT package purchase method based on a rule engine according to the present invention, when S3 performs verification, it performs verification from the user dimension, device dimension and business dimension, and all verification logic is managed by a unified verification module. As a preferred method for purchasing IoT packages based on a rule engine according to the present invention, user dimension verification includes whether the user is a new user, whether the user belongs to a specified region, and whether the purchase limit has been reached. As a preferred method for purchasing IoT packages based on a rule engine according to the present invention, device dimension verification includes whether the device is activated and whether it matches a specified device type or IoT card operator. As a preferred embodiment of the IoT package purchase method based on a rule engine of the present invention, the business rule verification includes whether the account balance is sufficient, whether the current number of services exceeds the package limit, and whether the IoT card status is normal. As a preferred embodiment of the IoT package purchase method based on the rule engine of the present invention, when the background rules of the rule engine change, a new knowledge base version identifier is automatically generated according to the new rule identifier combination, thereby invalidating the cache and rebuilding the rule knowledge base, ensuring that the new rules take effect in real time. An IoT package purchase system based on a rules engine includes: The external service interface layer receives package purchase requests and processes network requests and responses. The underlying business service layer includes an engine module, a package management module, and a condition verification module. The data storage layer includes a package database, a rules database, a user database, and a device database. Compared with the prior art, the beneficial effects of the present invention are as follows: 1. The purchasing method of this invention, by constructing a data package containing contextual information of three dimensions: user, device, and package, and combining it with a rule knowledge base that is dynamically loaded and prioritized, achieves a highly flexible and accurate package selection mechanism. The rule engine judges each available package according to the real-time context, retaining only the options that are fully adapted to the user's current scenario, effectively avoiding the information overload or matching deviation problems caused by traditional static configuration. At the same time, the system supports automatic cache invalidation and knowledge base reconstruction after rule changes, ensuring that business strategy adjustments can take effect immediately, significantly improving the accuracy of package recommendations and the agility of system response. 2. The purchasing system of this invention achieves dynamic configuration changes in package management through the organic collaboration of the external service interface layer, the underlying business service layer, and the data storage layer. The system adopts a dynamic filtering mechanism driven by a rule engine, combining three types of context variables: user, device, and package, to support flexible combinations and real-time effects of complex and multi-dimensional conditions. At the same time, it centrally manages all verification logic through a unified condition verification module, completely solving the problems of scattered verification, repetitive development, and difficult maintenance in traditional solutions. Rules are stored in the rule database in the form of data, supporting version management and hot updates. Business strategy adjustments can be completed without modifying code or restarting services, significantly improving the system's agility and maintainability. Attached Figure Description

[0004] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system block diagram of the present invention. Detailed Implementation

[0005] Example 1 Please see Figure 1 A method for purchasing IoT packages based on a rules engine includes the following steps: S1. Receive user requests and construct multi-dimensional context information. When a user initiates a package query or purchase request, based on the user identifier, device identifier, and target business scenario, relevant information is obtained from the user center, device management module, and package configuration center respectively, and a context data packet containing user variables, device variables, and package variables is constructed. S2. Dynamically filter the list of visible packages based on the rule engine. First, retrieve all available packages, then filter the retrieved packages according to the context data package, and finally select the suitable packages. S3. Perform unified multi-dimensional condition verification on visible packages. For the selected compatible packages, conduct centralized and unified multi-dimensional verification before users purchase. S4. Create an order and complete service activation. If the target package passes all the verification conditions, the system generates an order record, deducts the user's balance or binds the payment method, completes the order status update, and triggers the service activation process. If the verification fails, the specific reason for the failure is returned to the front end for the user to be notified. Furthermore, the user variables in S1 include user account, region information, test identifier, historical purchase records and application information; the device variables include device type, network type, activation status, IoT card information and device product identifier; and the package variables include package ID, country code, price, status and custom label. Furthermore, when filtering packages in S2, the rule identifier array associated with the package is obtained. Based on the rule identifier array, the corresponding rule content is loaded from the rule library and sorted by priority to dynamically build a rule knowledge base. If the rule combination has been cached, the cached instance is directly reused, and the context data packet is used as the fact input to the rule engine. Furthermore, the rule engine executes the rules sequentially. If any rule determines that the current context does not meet the conditions, the package is marked as invisible and the execution of subsequent rules is terminated. Only when all rules pass is the package added to the list of visible compatible packages. Furthermore, when the rules in the rule engine's backend change, a new knowledge base version identifier is automatically generated based on the new rule identifier combination, which invalidates the cache and rebuilds the rule knowledge base, ensuring that the new rules take effect in real time. Furthermore, when S3 performs verification, it verifies from the user dimension, device dimension, and business dimension, and all verification logic is managed by a unified verification module. Furthermore, user-level verification includes whether the user is a new user, whether they belong to a specific region, and whether they have reached the purchase limit. Furthermore, device-level verification includes whether the device is activated and whether it matches a specified device type or IoT card operator. Furthermore, business rule verification includes whether the account balance is sufficient, whether the current number of services exceeds the package limit, and whether the IoT card is in normal status. This rule-engine-based IoT package purchasing method constructs a data package containing contextual information of users, devices, and packages, and combines it with a dynamically loaded and priority-sorted rule knowledge base to achieve a highly flexible and accurate package selection mechanism. The rule engine judges each available package according to the real-time context, retaining only the options that are fully adapted to the user's current scenario, effectively avoiding the information overload or matching deviation problems caused by traditional static configuration. At the same time, the system supports automatic cache invalidation and knowledge base reconstruction after rule changes, ensuring that business strategy adjustments can take effect immediately, significantly improving the accuracy of package recommendations and the agility of system response. Furthermore, this method introduces a unified multi-dimensional verification mechanism before users actually place an order, conducting centralized verification from three levels: user identity, device status, and business compliance. This not only ensures the legality and security of the transaction but also significantly reduces the order failure rate caused by non-compliance with preconditions. By abstracting complex judgment logic into configurable and reusable rules and verification modules, it has good maintainability and scalability, facilitating the addition of new business scenarios or adjustments to marketing strategies, thereby improving user experience, optimizing operational efficiency, and providing technical support for the large-scale service of the IoT platform. Example 2 Please see Figure 2 An IoT package purchase system based on a rules engine includes: The external service interface layer receives package purchase requests and processes network requests and responses. The external service interface layer serves as the unified entry point for this invention to interact with external systems or end users. It is responsible for receiving, parsing, scheduling, and responding to all network requests related to the package. When a client initiates a package query or purchase request, this layer first receives the request message through the standard HTTP / HTTPS protocol and performs legality verification on the request, including identity authentication, parameter integrity checks, and security controls such as anti-replay attack measures. Subsequently, the interface layer extracts and encapsulates the user identifier, device identifier, and target business scenario parameters into a structured context, and synchronously calls the core capabilities provided by the underlying business service layer, including services such as package visibility filtering, multi-dimensional condition verification, and order creation. During the call, the external service interface layer is responsible for coordinating asynchronous and synchronous logic to ensure request isolation and transaction consistency under high concurrency. After the underlying service completes the processing, the interface layer encapsulates the returned result into a standardized response body according to the predefined data format, and adds the necessary business status codes and error information, and finally sends it back to the client via the network. The underlying business service layer includes the engine module, the package management module, and the condition verification module. The package management module first queries the list of available packages based on user and device context information, and loads an array of rule identifiers associated with each package to establish a dynamic binding relationship between packages and business rules. Based on the rule identifier array, the rule engine module extracts the corresponding rule content from the rule base, sorts them by priority, and dynamically builds the rule knowledge base. At the same time, it uses rule combinations to generate unique version identifiers to achieve rule cache management. If the same rule combination already exists in a valid cache, it is directly reused to improve performance; otherwise, a new knowledge base instance is created. After the construction is completed, the rule engine injects three types of context facts—user, device, and package—into the knowledge base, executes the rule filtering logic, evaluates each condition, and determines whether the package is visible to the current user based on the execution result. Packages filtered by rules enter the condition verification module. This module performs centralized, multi-dimensional verification of package purchase conditions, including user-level verification, device-level verification, and business rule verification. All verification logic is scheduled and executed by a unified management mechanism to avoid logic fragmentation. Ultimately, only packages that pass both the visibility filtering of the rule engine and the purchase eligibility verification of the condition verification module are allowed to enter the order creation process. The entire underlying business service layer achieves an integrated, scalable, and highly cohesive technical architecture for rule configuration, dynamic filtering, and condition validation through close collaboration between modules. The data storage layer includes a package database, a rules database, a user database, and a device database. The data storage layer, serving as the underlying data support of this invention, consists of four core data units: a package database, a rule database, a user database, and a device database, providing structured, real-time, and consistent data services for the upper-layer business logic. When the system processes a package purchase request, it first retrieves the user's detailed information from the user database based on the user identifier, including geographic information, account status, historical purchase records, test identifier, and application context. Simultaneously, it queries the device database based on the device identifier to determine device type, activation status, network type, and IoT SIM card attributes, constructing a complete user and device context. Next, the package database is accessed to retrieve all currently available packages, and for each package, its basic attributes and associated rule identifier array are loaded. This rule identifier array is then used to access the rule database, retrieving corresponding rule content in batches for the rule engine to dynamically build the knowledge base. Throughout the process, each database is efficiently linked and data is interconnected through a unique identifier, ensuring the integrity and timeliness of contextual data. In addition, the rule database supports versioned storage of rules and hot updates with a caching mechanism. The user and device databases support high-frequency reading and real-time status synchronization to ensure the accuracy of the verification logic. The package database supports flexible metadata expansion to adapt to diverse business configuration needs. Overall, the data storage layer, through its design of four-database collaboration, on-demand loading, strong correlation, and high concurrency, provides a reliable, efficient, and scalable data foundation for the rule engine's dynamic filtering and multi-dimensional condition verification. The IoT package purchase system based on a rules engine achieves dynamic configuration changes in package management through the organic collaboration of the external service interface layer, the underlying business service layer, and the data storage layer. The system adopts a dynamic filtering mechanism driven by the rules engine, combining three types of context variables: user, device, and package, to support flexible combinations and real-time effects of complex and multi-dimensional conditions. At the same time, a unified condition verification module centrally manages all verification logic, completely solving the problems of scattered verification, redundant development, and difficult maintenance in traditional solutions. Rules are stored in the rules database in the form of data, supporting version management and hot updates. Business strategy adjustments can be completed without modifying code or restarting services, significantly improving the system's agility and maintainability. The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for purchasing IoT packages based on a rules engine, characterized in that, Includes the following steps: S1. Receive user requests and construct multi-dimensional context information. When a user initiates a package query or purchase request, based on the user identifier, device identifier, and target business scenario, relevant information is obtained from the user center, device management module, and package configuration center respectively, and a context data packet containing user variables, device variables, and package variables is constructed. S2. Dynamically filter the list of visible packages based on the rule engine. First, retrieve all available packages, then filter the retrieved packages according to the context data package, and finally select the suitable packages. S3. Perform unified multi-dimensional condition verification on visible packages. For the selected compatible packages, conduct centralized and unified multi-dimensional verification before users purchase. S4. Create an order and complete service activation. If the target package passes all the verification conditions, the system generates an order record, deducts the user's balance or binds the payment method, completes the order status update, and triggers the service activation process. If the verification fails, the specific reason for the failure is returned to the front end for the user to be notified.

2. The method for purchasing IoT packages based on a rule engine according to claim 1, characterized in that: The user variables in S1 include user account, region information, test identifier, historical purchase records and application information; the device variables include device type, network type, activation status, IoT card information and device product identifier; and the package variables include package ID, country code, price, status and custom label.

3. The method for purchasing IoT packages based on a rule engine according to claim 1, characterized in that: In step S2, when filtering packages, the rule identifier array associated with the package is obtained. Based on the rule identifier array, the corresponding rule content is loaded from the rule library and sorted by priority to dynamically build a rule knowledge base. If the rule combination has been cached, the cached instance is directly reused, and the context data packet is used as the fact input to the rule engine.

4. The method for purchasing IoT packages based on a rule engine according to claim 3, characterized in that: The rule engine executes the rules sequentially. If any rule determines that the current context does not meet the conditions, the package is marked as invisible and the execution of subsequent rules is terminated. The package is added to the list of visible compatible packages only when all rules pass.

5. The method for purchasing IoT packages based on a rule engine according to claim 1, characterized in that: When S3 performs verification, it verifies from the user dimension, device dimension, and business dimension, and all verification logic is managed by a unified verification module.

6. The method for purchasing IoT packages based on a rule engine according to claim 5, characterized in that: User verification includes whether the user is a new user, whether they belong to a specific region, and whether they have reached the purchase limit.

7. The method for purchasing IoT packages based on a rule engine according to claim 5, characterized in that: Device-level verification includes whether the device is activated and whether it matches a specified device type or IoT card operator.

8. The method for purchasing IoT packages based on a rule engine according to claim 5, characterized in that: Business rule verification includes checking whether the account balance is sufficient, whether the current number of services exceeds the package limit, and whether the IoT card is in normal status.

9. The method for purchasing IoT packages based on a rule engine according to claim 4, characterized in that: When the rules in the rule engine's backend are changed, a new knowledge base version identifier is automatically generated based on the new rule identifier combination, which invalidates the cache and rebuilds the rule knowledge base to ensure that the new rules take effect in real time.

10. A rule-engine-based IoT package purchase system, applicable to the rule-engine-based IoT package purchase method described in any one of claims 1-9, characterized in that, include: The external service interface layer receives package purchase requests and processes network requests and responses. The underlying business service layer includes an engine module, a package management module, and a condition verification module. The data storage layer includes a package database, a rules database, a user database, and a device database.

Images