Notification management system and method

Abstract

[0006] Exemplary notification management systems and methods are described. In one implementation, techniques identify a plurality of devices communicating using a carrier and identify a trigger associated with at least one of the plurality of devices. Based on identifying the trigger, the techniques may apply at least one business rule associated with at least one of the plurality of devices. The techniques may further generate at least one notification in response to applying the business rule.

Description

Technical Field

[0001] This application claims the benefit of priority of U.S. Provisional Patent Application No. 63 / 068,334, filed Aug. 20, 2020, the disclosure of which is hereby incorporated by reference in its entirety.

[0002] This disclosure relates to the management of devices, such as Internet of Things (IoT) devices, and associated data.

Background Art

[0003] In many situations, when an entity deploys its own IoT smart devices, it may not be able to utilize a single cellular carrier. For example, a business IoT deployment may span multiple areas where different cellular carriers exist, or conversely, a single IoT deployment (such as a connected car) may move across multiple cellular carrier networks. Additionally, cellular carrier management systems and IoT management platforms are diverse. As a result, a business's IoT deployment may consist of fragmented financial and operational data from multiple cellular carriers and IoT management platforms, creating a complex situation when the business evaluates its own IoT deployment. There is a need for systems and methods to overcome these problems.

[0004] Non-limiting and non-exhaustive embodiments of the present disclosure will be described below with reference to the following figures, wherein like reference numerals refer to like parts throughout these individual figures unless otherwise specified.

Brief Description of the Drawings

[0005] [Figure 1] A block diagram showing an environment in which an exemplary embodiment may be implemented. [Figure 2] A flowchart showing an example of a process for managing devices and associated data. [Figure 3]Block diagram showing an example of the optimization engine. [Figure 4A] This flowchart illustrates an example of the process for creating, editing, and testing optimization algorithms. [Figure 4B] This is a flowchart illustrating an example of the optimization process. [Figure 5] This is a flowchart illustrating an example of the process for executing an optimization algorithm. [Figure 6] Block diagram showing an example of a notification engine. [Figure 7] This is a flowchart illustrating an example of the process for generating and communicating notifications. [Figure 8] This is a flowchart illustrating an example of a process for generating various types of notifications. [Figure 9] This figure shows an example of selecting and configuring notification settings. [Figure 10] This flowchart illustrates an example of a process for handling multiple API (application programming interface) requests related to IoT devices. [Figure 11A] This figure shows an example of a process for performing bulk API processing. [Figure 11B] This figure shows an example of various features of the bulk API engine. [Figure 12] This figure shows an example of a process for business process automation. [Figure 13A] This figure shows examples of various features of the API catalog. [Figure 13B] This figure shows an example of a process for implementing a Service-type API (APIaaS: API as a Service). [Figure 14] This figure shows an example implementation of an optimization engine. [Figure 15] This figure shows another example of an implementation of an optimization engine. [Figure 16]This figure shows an example of a rule-based optimization engine. [Figure 17] This figure shows an example implementation of a bulk API engine. [Figure 18] This figure shows an example of a GUI that presents various information to users of a device management system. [Figure 19] This figure shows an example of a GUI that presents various information to users of a device management system. [Figure 20] This figure shows an example of a GUI that presents various information to users of a device management system. [Figure 21] This figure shows an example of a GUI that can be used to construct one or more queries. [Figure 22] This figure shows an example of an optimization ensemble that includes multiple pods. [Figure 23] This is a diagram illustrating an example of a computing device block diagram. [Modes for carrying out the invention]

[0006] In some embodiments, the systems and methods discussed herein perform various information management tasks associated with multiple devices. In specific embodiments, these systems and methods are associated with information management of cellular connectivity data associated with IoT (Internet of Things) devices deployed within any number of geographical areas.

[0007] The following disclosure refers to attached drawings that form part thereof, which illustrate specific implementations in which this disclosure may be carried out. It is understood that other implementations may be used and structural modifications may be made without departing from the scope of this disclosure. References in the specification such as “one embodiment,” “a certain embodiment,” and “exemplary embodiment” suggest that the described embodiment may include certain features, structures, or characteristics, but not all embodiments may necessarily include those specific features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics are described in relation to a certain embodiment, but it goes without saying that such features, structures, or characteristics may be modified in relation to other embodiments, whether or not they are explicitly stated, as is known to those skilled in the art.

[0008] Implementations of the systems, devices, and methods disclosed herein may include or utilize a dedicated or general-purpose computer, including, for example, one or more processors and system memory, as discussed herein. Implementations within the scope of this disclosure may also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available media accessible to a general-purpose or dedicated computer system. A computer-readable medium that stores computer-executable instructions is a computer storage medium (device). A computer-readable medium that carries computer-executable instructions is a transmission medium. Thus, to the present and not limit, implementations of this disclosure may include at least two distinctly different types of computer-readable media: a computer storage medium (device) and a transmission medium.

[0009] Computer storage media (devices) include RAM, ROM, EEPROM, CD-ROM, solid state drives (SSDs: e.g., RAM-based), flash memory, phase-change memory (PCM), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code means in the form of computer-executable instructions or data structures and that is accessible by a general purpose or special purpose computer.

[0010] Implementations of the devices, systems, and methods disclosed herein may communicate via a computer network. A "network" is defined as one or more data links that enable the transmission of electronic data between computer systems and / or between modules and / or between other electronic devices. When information is transmitted or provided to a computer via a network or another communication connection (either embedded hardware, wireless, or a combination of embedded hardware or wireless), the computer may consider the connection to be a transmission medium. A transmission medium may include a network and / or data link that can be used to carry desired program code means in the form of computer-executable instructions or data structures and that is accessible by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

[0011] Computer-executable instructions, for example, when executed in a processor, include instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions. The computer-executable instructions may be, for example, binary, intermediate form instructions such as assembly language, or even source code. The subject matter is described in a language specific to structural features and / or methodological operations, but it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features described or the operations described herein. Rather, the described features and operations are disclosed as exemplary forms for implementing each claim.

[0012] One of ordinary skill in the art will appreciate that the present disclosure may be implemented in a network computing environment having many types of computer system configurations, including, for example, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, cell phones, PDAs, tablets, pocket bells, routers, switches, various storage devices, and the like. The present disclosure may also be implemented in a distributed system environment where both local and remote computer systems, linked via a network (either by a solid-line connection data link, a wireless data link, or a combination of solid-line and wireless data links), perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[0013] Furthermore, where appropriate, the functions described herein can be implemented in one or more of the following: hardware, software, firmware, digital components, or analog components. For example, one or more application-specific integrated circuits (ASICs) can be programmed to perform one or more of the systems and procedures described herein. Certain terms are used throughout this specification and the claims to refer to specific system components. Those skilled in the art will understand that components may be referred to by different names. This document is not intended to distinguish between components that have different names but the same function.

[0014] It should be noted that the sensor embodiments discussed herein may comprise computer hardware, software, firmware, or any combination thereof for performing at least some of these functions. For example, a sensor may include computer code configured to run on one or more processors, or it may include hardware logic / electrical circuits controlled by the computer code. These exemplary devices are provided herein for illustrative purposes only and are not intended to be limiting. Embodiments of this disclosure may be implemented in yet another type of device known to those skilled in the art.

[0015] At least some embodiments of this disclosure are directed to computer program products having such logic (e.g., in the form of software) stored on any computer-usable medium. When such software is executed on one or more data processing devices, it causes the devices to operate as described herein.

[0016] In some embodiments, the systems and methods described herein may provide information management for data relating to business IoT deployments (such as enterprise operations) and receive an inventory of deployed assets, such as IoT devices. The data managed may include information associated with subscriber identity modules (SIMs) from the entity, as well as requested connectivity data, such as usage and evaluation data (e.g., pricing plans) associated with SIMs from one or more cellular carriers. The systems and methods described may also receive data associated with SIMs from cellular carriers and standardize and aggregate data SIMs, usage, and evaluation elements across multiple cellular carriers into a single, unified business view. Furthermore, the systems and methods may provide the entity with cost-related and operational information from deployed SIMs (e.g., enterprise IoT deployments) via a private, secure website or web-based application. As used herein, cellular carriers may be referred to as carriers, data carriers, cellular service providers, service providers, etc.

[0017] In business, the deployment of IoT smart devices, which possess intelligent physical components that form networks, is expanding rapidly. For example, these IoT devices can be used for data collection, analysis, transmission, and reception to improve performance through monitoring, control, optimization, and automation. In some embodiments, IoT devices are used to rethink various industrial and industrial sectors. For example, in the case of wind turbines, a small microcontroller can control each rotor blade with each rotation in a way that maximizes wind energy utilization. In another example, some autonomous vehicle companies are leveraging sensors and software to constantly scan objects around the vehicle and continuously read traffic control, traffic signs, etc. Combined with detailed three-dimensional maps built and delivered to the vehicle via cellular connectivity, the deployment of autonomous vehicles continues to increase. The systems and methods discussed herein are also useful for newly emerging technologies by changing the way businesses interact with customers, other systems, etc.

[0018] The systems and methods described herein help overcome problems related to multi-cellular carrier connectivity in business IoT deployments. The systems and methods discussed herein can be used to mitigate or eliminate the limitations of existing systems.

[0019] In some situations, traditional information management systems often focus on organizing, protecting, and recovering data from fixed computing devices such as servers or desktop computers. As a result, human-managed data and mobile data may be dispersed outside the scope of traditional information management systems, and this data is therefore not backed up or otherwise actively managed. Consequently, there is a risk that if a mobile device is lost or damaged, or if there is a service interruption to the hosted service, highly sensitive personal data may be lost with no way to recover it.

[0020] The systems and methods described herein can overcome the above-mentioned problems and provide additional benefits. For example, the systems and methods described herein can receive and analyze various types of data to identify the optimal data carrier assignment to multiple devices, such as cellular IoT devices. These systems and methods optimize this assignment by simultaneously running multiple scenarios to determine which devices should be assigned to a particular carrier (and a particular carrier plan) in order to optimize the cost of servicing those devices and optimizing device performance. Based on the specific optimization and analysis, the systems and methods described herein generate recommendations for changes to the services associated with one or more devices that satisfy the determined optimizations.

[0021] Furthermore, the systems and methods discussed herein describe various embodiments and features, including interactive query builders (also known as “interactive query engines”), notification engines, reporting engines, and other components and methods.

[0022] Figure 1 is a block diagram showing an environment 100 in which an exemplary embodiment may be implemented. As shown in Figure 1, the device management system 102 is coupled to a first device 104, a second device 106, a first data source 108, a second data source 110, a first service provider 112, and a second service provider 114. Devices 102 and 104 can be any type of device, such as IoT devices or other devices that communicate via a cellular network or other data communication system. In some embodiments, devices 102 and 104 may have associated device states, such as started, canceled, stopped, and unknown. Although two devices 102 and 104 are shown in Figure 1, a particular implementation may include any number of devices 102 and 104 coupled to the device management system 102.

[0023] Data sources 108 and 110 can be any type of data source that provides any type of data to (or receives any type of data from) the device management system 102. Data sources 108 and 110 may be associated with one or more third-party companies or other entities. In some embodiments, data sources 108 and 110 may provide data related to manufacturer information, hardware information, network information, operating system information, programmability information, geolocation information, etc. Although two data sources 108 and 110 are shown in Figure 1, a particular implementation may include any number of data sources 108 and 110 coupled to the device management system 102.

[0024] Service providers 112 and 114 can be any type of service provider that provides services to (or receives any type of service from) the device management system 102. For example, service providers 112 and / or 114 may be cellular service providers or entities that provide any other type of service. Figure 1 shows two service providers 112 and 114, but a particular implementation may include any number of service providers 112, 114 coupled to the device management system 102.

[0025] In some embodiments, the device management system 102 is connected to devices 104, 106, data sources 108, 110, and service providers 112, 114 via any number of data communication networks, cellular communication networks, or other communication networks. Communication between the device management system 102 and devices 104, 106, data sources 108, 110, and service providers 112, 114 may use any type of network topology with any communication protocol.

[0026] As shown in Figure 1, the device management system 102 is also linked to a database 116 that stores various information associated with the device management system 102. For example, the database 116 may store data associated with any number of managed devices 104, 106, service / charge data associated with any number of cellular carriers, CDR (Call Detail Record) and usage data, as well as statistical data. The database 116 may also store any other types of data, such as any data generated or received by the device management system 102.

[0027] In some embodiments, the device management system 102 includes a communication management unit 118, a processor 120, and a memory 122. The communication management unit 118 enables the device management system 102 to communicate with other systems, such as devices 104, 106 and data sources 108, 110 shown in Figure 1. The processor 120 executes various instructions to implement the functionality provided by the device management system 102, as discussed herein. The memory 122 stores these instructions along with other data used by the processor 120 and other modules and components included in the device management system 102.

[0028] Furthermore, the device management system 102 includes a graphical query builder 124, a notification engine 126, and an optimization engine 128. The graphical query builder 124 may enable the system or a user (e.g., a system administrator) to construct queries that can define at least part of the operation of the device management system 102. In some embodiments, the graphical query builder 124 is an extension of the interactive query builder discussed herein. For example, the interactive query builder includes a graphical user interface (GUI) that enables the user to interact with one or more underlying data catalogs. This GUI allows the user to make selections from a set of information and apply criteria to each, as shown in Figure 24. In an alternative embodiment of the graphical query builder 124, as shown in Figure 25, the user can visually locate the location of a device of interest through the use of interactive widgets and charts / graphs.

[0029] The notification engine 126 may provide one or more systems or users with a variety of alerts, reports, messages, and other notifications. These notifications may be based on rules, business processes, and other technologies, as described herein. The optimization engine 128 may analyze multiple devices (e.g., devices 104, 106), usage data, pricing plans, etc., to optimize the data plans, carriers, and other aspects of multiple devices in order to optimize (e.g., minimize) the cost of cellular services associated with multiple devices or to optimize other factors associated with multiple devices. Examples of alerts include high usage alerts, new startup alerts, no usage alerts, per-device usage alerts, and usage exceeding thresholds. Examples of rules include company information, notification types, and thresholds.

[0030] The device management system 102 further includes a bulk API (Application Programming Interface) engine 130, a statistical analysis engine 132, and an evaluation and mediation engine 134. The bulk API engine 130 can handle multiple API requests related to IoT devices by grouping multiple API requests together and processing those groups of API requests, as will be discussed herein. The bulk API engine 130 also manages various API requests, including resubmitting API requests that were not initially performed successfully.

[0031] The statistical analysis engine 132 performs various statistical operations on data received and managed by the device management system 102. In some embodiments, the statistical analysis engine 132 may use device profile information and usage data when performing statistical operations. In some embodiments, the statistical analysis engine 132 can store data in and retrieve data from the database 116. For example, the statistical analysis engine 132 may combine and correlate multiple datasets, such as device profiles, user-created tags, third-party device information, and usage information. The statistical analysis engine 132 may also perform multiple analyses and mine the results of the analyses so that they can be presented in a user-friendly format. In some embodiments, the results generated by the statistical analysis engine 132 may be added to a data catalog used by the interactive query builder discussed herein. Exemplary analyses that can be performed by the statistical analysis engine 132 include various usage patterns such as standard deviation and variance, mean, lifetime, last 12 months, and monthly aggregation.

[0032] The valuation and mediation engine 134 can calculate the charges for connectivity, device management, and other services that are payable to third-party customers and partners of the provider of the device management system 102. The valuation and mediation engine 134 can also be used for internal cost allocation to different departments or divisions of a company. In some embodiments, there are three types of valuation models.

[0033] 1. Cost Plus Markup - In this model, the cost a customer pays to their carrier is distributed across each IoT device, and then a markup is added to calculate the price that the downstream customer should pay.

[0034] 2. Single Price List - In this model, downstream customers are charged based on a price list for the services they use.

[0035] 3. Multiple Price Lists - In this model, downstream customers can select two or more price lists, and then, based on the device's use case, one of the multiple price lists is assigned to a specific device.

[0036] The intermediary aspect of the evaluation and intermediation engine 134 provides the ability to identify whether certain types of services used (and measured) by downstream customers are billable or not. The evaluation and intermediation engine 134 may also enable one or more integrations, such as:

[0037] 1. Device assignment to specific downstream customers / departments originates from the customer's ERP or order management system.

[0038] 2. Billing may be available via one or more APIs that will be integrated with the billing system or other systems.

[0039] As shown in Figure 1, the device management system 102 also includes a business process automation engine 136 and a service / pricing plan management system 138. The business process automation engine 136 allows a user (e.g., an administrator) or the system to define various business rules, business activity triggers, etc., as discussed herein. In certain implementations, the business process automation engine 136 may apply (or execute) multiple business rules simultaneously or sequentially within the same process. This is sometimes referred to as "stacking" business rules. In some embodiments, the business process automation engine 136 functions in combination with a notification engine 126 to provide various notifications in response to business rules, business activity triggers, etc. The service / pricing plan management system 138 monitors various service and pricing plans offered by any number of different carriers.

[0040] Various components (e.g., engines) in the device management system 102 can be interconnected by a bus 140 or other communication mechanism. Although a single bus 140 is shown in Figure 1, other embodiments may include any number of buses 140 that enable specific components to communicate with one another.

[0041] In some embodiments, the device management system 102 may receive various types of data from any number of carriers. Examples of data types include SIM catalog data, device information, usage data, change history, and account information.

[0042] In certain embodiments, the systems and methods disclosed herein can simultaneously support the control of multiple devices across any number of carriers, pricing plans, etc. Furthermore, the systems and methods described can control and identify data associated with a single device. In this case, these systems simultaneously provide a wide variety of device analysis and control, from a low-granularity level to addressing large groups of devices.

[0043] It should be understood that the embodiment in Figure 1 is given merely as an example. Other embodiments may include fewer or additional components without departing from the scope of this disclosure. Furthermore, without limitation, the illustrated components may be combined or included within other components.

[0044] Figure 2 is a flowchart illustrating an embodiment of process 200 for managing devices and associated data. First, the device management system receives device data from multiple devices 202. The multiple devices may be of different types, located in different geographical areas, and serviced by different service providers (e.g., different cellular communication networks). Process 200 continues 204 with the device management system receiving data from multiple data sources. The device management system also receives service / charge data from multiple service providers 206.

[0045] Process 200 continues with the optimization engine analyzing data received from multiple devices, multiple data sources, and multiple service providers to optimize overall service charges for multiple devices 208. The device management system further generates recommended service / pricing changes based on the analysis of the optimization engine 210. In some embodiments, the device management system may compare a first pricing plan with a second pricing plan based on historical usage data of one or more devices as well as other factors and data.

[0046] The process continues with the device management system communicating recommended service / price changes to the service / price plan management system. The device management system then stores data associated with multiple devices, multiple data sources, multiple service providers, and the results of the analysis / optimization. Process 200 continues with the device management system continuing to receive and analyze device data, data from multiple data sources, and service / price data. In some embodiments, the device management system regularly monitors the received data and continuously optimizes the overall service pricing based on changes in the received data.

[0047] Figure 3 is a block diagram showing an embodiment of the optimization engine 128. As shown in Figure 3, the optimization engine 128 includes a communication management unit 302, a processor 304, and a memory 306. The communication management unit 302 enables the optimization engine 128 to communicate with other systems and components. The processor 304 executes various instructions to implement the functionality provided by the optimization engine 128, as will be discussed herein. The memory 306 stores these instructions along with other data used by the processor 304 and other modules and components included in the optimization engine 128.

[0048] Furthermore, the optimization engine 128 includes a scenario execution management unit 308, a carrier data management unit 310, and an inflection point module 312. The scenario execution management unit 308 executes various scenarios to compare different outcomes of pricing and service, for example, by changing service plans for various devices to different carriers. The carrier data management unit 310 identifies and maintains current data for different carriers, such as different pricing plans and target geographic areas. The inflection point module 312 can determine the optimal number of devices that should move from one pricing plan to another. In some embodiments, the inflection point module 312 can identify local minima for determining the optimal number of devices that should move between pricing plans so that the combined costs for the two pricing plans are optimized. This embodiment may test multiple methods to find the optimal number of pricing plan moves. In some implementations, the inflection point module 312 may include a method that allows the user to test different methods using a visual editor.

[0049] The optimization engine 128 also includes a device tagging management unit 314, a prediction and simulation module 316, and a cross-carrier optimization module 318. The device tagging management unit 314 allows the user to create "pods" of devices that will be defined using arbitrary device attributes such as tags or usage profiles. These pods may have various sets of optimization rules and applicable constraints.

[0050] The forecasting and simulation module 316 performs both forecasting and simulation functions. With regard to forecasting, optimization is typically performed before the end of the billing cycle, meaning that devices continue to use data after optimization is complete and the pricing plan has changed. To mitigate this situation, the systems and methods described herein add “forecasts” to the most recent usage data available at the time of the last optimization run before the end of the billing cycle. These forecasts may be at the device level, pod level, pricing plan level, or aggregate level, depending on the customer’s needs.

[0051] With regard to simulation, the forecasting and simulation module 316 may use Monte Carlo simulation to forecast the number of devices and data usage during one or more future billing periods. An evaluation engine may then be applied to the simulated usage. In some embodiments, the forecasting and simulation module 316 may be used to estimate the costs of scenarios such as planning over-the-air (OTA) software updates and other technology migrations for field-deployed IoT devices.

[0052] The cross-carrier optimization module 318 uses a catalog of pricing plans offered by various carriers. In some embodiments, optimization is performed on the pricing plan offered by the current carrier, and another optimization is performed on a list of pricing plans offered by one or more other carriers.

[0053] In other embodiments, the optimization engine 128 may use a visual editor that allows the user to define rules and functions that define the optimization process (also called an optimization algorithm), for example, via a GUI. The user can create a larger optimization process by incorporating multiple smaller individual rules and functions into a larger optimization process. When creating future optimization processes, specific parts of the larger optimization process can be reused. Furthermore, the user can test the behavior and operation of each individual step / function and analyze the results of individual steps / functions for optimization activities before continuing to build a larger optimization process. In some embodiments, this visual editor supports rapid modeling of new optimization scenarios and the creation of new optimization processes.

[0054] Figure 4A is a flowchart illustrating an example of process 400 for creating, editing, and testing an optimization algorithm. First, the process determines the goal of the optimization process 402. The process continues by defining the rules associated with the optimization process 404. A particular optimization algorithm may contain any number of rules. In some embodiments, the user or system creating the optimization algorithm may select and test the rules individually before adding them to the optimization algorithm.

[0055] Process 400 continues with the rules defined in 404 being tested 406, and the results of the rule tests being evaluated. If the test results in 408 are not successful, the process continues editing the rules 410, and the edited rules are retested in 406. If the test results in 408 are successful, the rules are added to the optimization algorithm 412. The user or system then defines another rule 414, and the new rules are tested and evaluated in 406. Process 400 continues by adding and testing new rules until the optimization algorithm satisfies the goals of the optimization process.

[0056] Figure 4B is a flowchart illustrating an example of the optimization process 450. First, the process 450 creates one or more pods, e.g., groups of devices 452. As mentioned above, a pod can be a group of devices defined using any device attributes such as tags or usage profiles. The process 450 continues by generating multiple optimization algorithms to cover different scenarios 454. The process then runs each optimization algorithm for each pod, if applicable 456. The process 450 continues by selecting the best result from each optimization algorithm for each pod 458. In some embodiments, the process may analyze performance statistics (e.g., optimization algorithms and code) to identify new and improved optimization algorithms 460.

[0057] In some embodiments, an optimization ensemble (or model) represents a set of mutually exclusive optimization algorithms, each capable of predicting the best allocation of rate plans to devices. The optimization ensemble may also include a generalized orchestration module capable of performing various steps, addressing error scenarios, analyzing performance statistics, and creating plan change manifests used by the bulk API engine (considered herein) to implement rate plan changes for appropriate carriers.

[0058] In some embodiments, a visual editor may be used to edit or add new rules, edit or add new optimization algorithms, edit or add new ensembles, and edit or add new pods to perform the various functions discussed herein. In certain implementations, a rule-based architecture may support the decomposition of code into smaller functions, which may be called rules. The systems and methods described may provide version control for any number of rules. In some embodiments, the systems and methods may include various testing, debugging, state management, and other tools for the development and testing of rules, optimization algorithms, etc. In certain implementations, the systems and methods may implement various logging and tuning functions. Users may create any number of algorithms (e.g., optimization algorithms) and ensembles, test the algorithms and ensembles, and deploy one or more algorithms and / or ensembles if the tests are successful.

[0059] Figure 5 is a flowchart illustrating an example of process 500 for executing the optimization algorithm. First, in 502, the process generates all beneficial fare plan change scenarios for each pod, such as changing from fare plan A to fare plan B, or from fare plan B to fare plan A. In some embodiments, each fare plan change scenario is unique (e.g., mutually exclusive) and encompasses all possible combinations. For example, if there are 10 devices and 2 available carriers (each carrier having one fare plan), possible combinations include: devices 1-9 of carrier 1 and device 10 of carrier 2; devices 1-8 of carrier 1 and devices 9-10 of carrier 2; devices 1 and 3 of carrier 1 and devices 2 and 4-10 of carrier 2, and so on. All combinations can be determined and tested to determine which particular combination is the most cost-effective. In 504, the process continues by applying evaluation and other calculation rules to evaluate each scenario in terms of incremental cost savings. In some embodiments, process 500 follows all device rules, fare plan rules, device constraints, etc. Process 500 then selects the best scenario (e.g., a change that results in the best cost reduction increment) 506.

[0060] Process 500 is continued by 508, which performs inflection point calculations. As shown in Figure 5, the process may identify N devices that should be moved from rate plan A to rate plan B. For example, in some situations, moving N+1 or N-1 devices may result in smaller cost savings than moving N devices. The process implements the changes identified in the preceding activity 510, then returns to 502, and repeats this process until significant incremental benefits are no longer possible. Finally, at 512, the process reaches the best result, logs the results, records the device moves between rate plans, records performance statistics, etc.

[0061] Figure 6 is a block diagram showing an embodiment of the notification engine 126. As shown in Figure 6, the notification engine 126 includes a communication management unit 602, a processor 604, and a memory 606. The communication management unit 602 enables the notification engine 126 to communicate with other systems and components. The processor 604 executes various instructions to implement the functionality provided by the notification engine 126, as will be discussed herein. The memory 606 stores these instructions along with other data used by the processor 604 and other modules and components included in the notification engine 126.

[0062] Furthermore, the notification engine 126 includes an email template storage unit 608, a timer and scheduler module 610, and a trigger and listener module 612. The email template storage unit 608 contains any number of email templates for providing various notifications. In some embodiments, the email templates in the storage unit 608 are editable by the user. The timer and scheduler module 610 allows the user to create custom alerts and select a specific schedule for those alerts. In some embodiments, the timer and scheduler module 610 may include pre-configured timers for specific types of alerts. The trigger and listener module 612 can perform anomaly detection, job failure detection, etc. The trigger and listener module 612 may automatically escalate certain issues if necessary. In some embodiments, another system or method may automatically detect the escalation of an issue and generate an appropriate notification.

[0063] The notification engine 126 further includes a message editing module 614, a message sending module 616, a user preference 618, and a portal management unit 620. The message editing module 614 can select an appropriate template for a message based on a detected topic. Examples of topics include optimization completion notifications, rate plan change completion notifications, billing cycle reminders, data pipe job failure notifications, data pipe job completion notifications, business process automation (BPA) execution failure notifications, BPA execution completion notifications, bulk API execution failure notifications, bulk API execution completion notifications, and availability report notifications. Examples of data change topics include new rate plan notifications, rate plan change notifications, data quality and integrity check notifications, and new user notifications. The message editing module 614 may also allow users to define custom alerts based on terms of use, status changes, and other criteria, and then set timers for alert notifications.

[0064] The message sending module 616 can send messages in various formats such as email and SMS. User preferences 618 can be configured by the user to include, for example, email only, text only, email and text, stop all notifications, and limit notifications on a daily quota. The portal management unit 620 can perform various functions, such as selecting notifications of interest and adding distribution lists for each notification type according to the subject.

[0065] In some embodiments, notifications may be triggered by one or more rules, settings, etc. For example, if a rule is triggered when device usage exceeds a threshold, the notification engine 126 may automatically generate a notification of excessive device usage and communicate that notification to any number of systems, devices, users, etc., in any format.

[0066] Figure 7 is a flowchart illustrating an embodiment of process 700 for generating and communicating notifications. First, process 702 receives a message request. In some implementations, specific processes may be executed on a user-defined schedule to generate one or more message requests.

[0067] In some embodiments, received requests can be logged or queued using one of the following methods:

[0068] 1. Timer-based (asynchronous): In the case of timer-based topics (e.g., billing cycle reminders), the notification engine itself may initiate the logging of requests.

[0069] 2. Process-based (synchronous): In this scenario, the operation itself (e.g., optimization or price plan change bulk API) logs the request for successful completion or failure.

[0070] Process 700 executes the message request 704. In some embodiments, a message compiler can create an email or SMS message using an email / SMS template relevant to the topic, and the data necessary to complete the template is retrieved. In some embodiments, customized queries may be executed to create the message content, subject line, and recipient list. Process 700 may perform message throttling. In some implementations, process 700 may use recipients associated with alerts or queries regarding new messages. In some situations, the list of recipients may be determined based on the user's role.

[0071] The process then sends one or more messages based on the executed message request 706. In some embodiments, the created email or SMS message (or both) is sent by the message sending unit. Process 700 then synchronizes one or more message tables in the portal 708 so that they can be displayed in the notification pane or window. In some embodiments, the service can synchronize the notification database with the one displayed in the portal. Finally, process 700 uploads the report file to the portal management unit 710. Furthermore, in some embodiments, the topic may request that a list be provided to the user if a device is affected. In this situation, the notification engine can execute the necessary queries, create an Excel / CSV file, and save it to a cloud repository or other data storage system. This information is available to the user via the portal.

[0072] In some embodiments, messages and notifications can be received via multiple different carriers. Furthermore, messages and notifications can be sent across multiple carriers. In this case, the message table and portal discussed with respect to Figure 7 can handle arbitrary messages and notifications from multiple carriers, multiple devices (of any carrier), etc.

[0073] Figure 8 is a flowchart illustrating an embodiment of process 800 for generating various types of notifications. As shown in Figure 8, process 800 can generate at least three different types of optimization alerts: 1) reminders about an approaching billing cycle, 2) notifications regarding the completion of optimization, and 3) notifications indicating the completion of a bulk API (e.g., a rate plan change). In other embodiments, any type of optimization alert may be generated and communicated to any number of users or systems.

[0074] Figure 9 shows an example embodiment 900 for selecting and configuring notification settings. As shown in Figure 9, a portal user or a system associated with the portal can select topics of interest and assign them to a notification distribution list. All recent notifications, whether sent via email or SMS message, can be displayed in a notification pane (e.g., window). The notification pane may also support setting up email and / or SMS messages for specific alerts, such as usage alerts or change tracking alerts.

[0075] Figure 10 is a flowchart illustrating an embodiment of process 1000 for processing multiple API requests related to IoT devices. In some embodiments, process 1000 is performed at least partially by a bulk API engine 130. Some of the features and functions implemented by the bulk API engine 130 are as follows:

[0076] Carrier-agnostic regarding request, response, and connection protocols.

[0077] Execute multiple parallel threads

[0078] Single and bulk requests

[0079] Asynchronous fault-tolerant execution

[0080] Real-time updates / notifications via multiple vehicles

[0081] Real-time data synchronization

[0082] Supports multiple integration methods with customer and third-party applications.

[0083] Wrap functionality as an end-to-end actual business process.

[0084] Integrate carrier-specific authentication protocols

[0085] Convert all APIs to REST regardless of carrier implementation.

[0086] Referring to process 1000, the process first receives multiple API requests to perform device actions related to IoT devices 1002. Device actions include, for example, changing the device's pricing plan or changing the device's service provider. The process continues 1004 by sorting the API requests by mobile network (carrier) and platform. Each API request is checked based on carrier API rules such as throttling, concurrent calls, batch size, and latency 1006.

[0087] Process 1000 continues by creating one or more batches of API calls 1008 and creating multiple threads 1010 for parallel execution of the batches of API calls. Process 1000 retries any unsuccessful API calls 1012 (e.g., reruns). Process 1000 then concatenates all responses 1014 and updates one or more data views associated with the API calls. Process 1016 displays the status of the requests (e.g., batches and individual IoT devices). Finally, Method 1000 provides one or more systems, users, etc., with notification of the results and status of the requests 1018.

[0088] Figure 11A shows an exemplary embodiment of process 1100 for performing bulk API processing. In some embodiments, bulk API processing is invoked by a service-type API or by a portal. Figure 11B shows an exemplary embodiment of various features 1150 of the bulk API engine.

[0089] Figure 12 illustrates an exemplary implementation of process 1200 for business process automation. In some implementations, process 1200 may use a bulk API engine and an interactive query engine.

[0090] Figure 13A shows an example of various features 1300 of the API catalog. In some implementations, the API catalog may include multiple business process APIs. Figure 13B shows an example of process 1350 for implementing API as a Service (APIaaS). In some implementations, process 1350 integrates a bulk API engine with the API catalog.

[0091] Figure 14 shows an example of an implementation of the optimization engine 1400.

[0092] Figure 15 illustrates an example of a flowchart 1500 for implementing an optimization engine.

[0093] Figure 16 illustrates an exemplary example of a rule-based optimization engine, 1600, showing various initializations, computation groups, ensembles of optimization algorithms, specific rules, and the results of running one or more optimization algorithms.

[0094] Figure 17 illustrates an exemplary implementation of the Bulk API Engine 1700. The example in Figure 17 also illustrates the interaction of the Bulk API Engine with the data pipe and notification engine.

[0095] Figures 18-20 illustrate exemplary implementations of GUI 1800, 1900, and 2000, which present various information to users of a device management system. The exemplary GUIs shown in Figures 18-20 illustrate various billing data, usage data, device activity, average data usage, and more. For example, GUI 1800 shows a dashboard format with various data that can be aggregated from multiple carriers, platforms, and devices. In the example in Figure 19, GUI 1900 illustrates a device-level snapshot of the data. For example, GUI 1900 may allow a user to view all of their devices across multiple carriers or data platforms. In the example of GUI 2000, a user can create their own downstream customer hierarchy or internal department / division hierarchy. In some implementations, data is aggregated across customers / departments / divisions, and the user can view all of the aggregated data or a specific group of data. In some implementations, GUI 2000 allows a user to drill down into a specific IoT device to obtain more granular data. In some embodiments, queries can be constructed across one or more carriers and across one or more customers / departments / divisions.

[0096] Figure 21 illustrates an exemplary embodiment of GUI2100 that can be used to construct one or more queries. In some implementations, GUI2100 may support drag-and-drop construction of queries and provide multiple options for displaying the results of one or more queries.

[0097] Figure 22 shows an exemplary embodiment of the optimization ensemble 2200 encompassing multiple pods. In some implementations, the optimization ensemble 2200 includes multiple mutually exclusive optimization engines that can collectively predict the best (e.g., lowest cost) pricing plan for multiple devices. The optimization ensemble 2200 may also include generalized orchestration modules for performing various steps, addressing error scenarios, mining performance statistics, and creating plan change manifests. The plan change manifests can be used by a bulk API engine to actually implement pricing plan changes to carriers. Additional details regarding the operation of the optimization ensemble 2200 are discussed herein, for example, with respect to Figures 4A, 4B, and 5.

[0098] Interactive query builder Technological innovation and consumer demand for new experiences are driving a re-evaluation of business models—IoT strategies and scaled, complex deployments are being driven as a means of keeping pace with a fiercely competitive consumer environment. In the traditional IT sense, such deployments are important for providing a flexible, secure, and efficient foundation of connectivity, standardized devices and data management, and automated processes. However, many IoT deployments are more than just traditional business IT or network deployments. They are driving a re-evaluation of business models that require real-time, intelligent insights, not just the ingestion of vast amounts of diverse and fragmented data. The interactive query builder is built with business owners in mind, reconnecting business owners and IT partners in a sales-oriented, performance-based deployment view in the pursuit of highly complex and continuous business value. The interactive query builder notifies of daily execution and results, and also defines the trajectory for the following day.

[0099] By incorporating third-party / corporate business reference data, statistical profiling, and AI / ML into augmented, standardized, and correlated datasets, data is translated into information and insights that can be directly used by non-technical business strategists via an interactive query builder. The following are some examples of how augmented data drives real-time decision-making.

[0100] Industrial IoT is driving improvements in factory operations. By using streaming data in real time, manufacturers with connected factories can respond more quickly to changing circumstances, adjust their operations to match peak processing capacity, and maximize the value derived from their factory investments. For example, in the industrial oil industry, IoT sensors and transducers are deployed to collect data. By utilizing cellular services, these devices can be connected to a gateway, from which the data is then transmitted to the cloud. The described systems and methods can obtain data consumption information from each device directly from the carrier or connectivity platform via APIs, including but not limited to carrier, pricing plan, consumption trends and anomaly reporting, pricing plan, cost, and optimization evaluation, while also recording and maintaining the device lifecycle history.

[0101] In some embodiments, devices may be segmented according to end-user definitions of attributes such as facility, geographical location, and business unit, as well as / or activities including measurement, reporting, and notification of IoT applications.

[0102] For example, the systems and methods described herein enable entities to correlate different types of data across the board with respect to 1) connectivity, 2) devices, and 3) device applications, thereby creating a single, overarching script that transcends the functions and intentions of the enterprise to drive a more comprehensive, cross-cutting strategy regarding business strategy and technology deployment.

[0103] Companies in several industries, including automotive and technology, are developing a new generation of smart, connected cars. These companies are not only making driving safer, but are also gaining direct access to and analysis of vehicle data to improve customer experience, enhance product development and manufacturing processes, and expand their business performance.

[0104] In some situations, the retail industry has been re-evaluated based on customer expectations for convenience, responsiveness, and personalization through both digital and physical means. While collecting, unifying, and managing customer data across multiple touchpoints is complex, combining in-store data from the IoT with digital customer data is valuable in the pursuit of personalized shopping experiences.

[0105] The interactive query builder discussed herein provides an interface that enables users (including non-technical business users) to interact with various datasets in an interactive manner to locate and focus on data of interest. When using an interactive query builder, the training required of users on how to use the required interface is minimal.

[0106] In some embodiments, the interactive query builder presents attribute, fact, and measure columns to the user in an intuitive GUI, while providing meaningful input control for selected columns. The actual queries against the query catalog are generated by dynamically depending on the context and leveraging a fully configuration-based rule storage system without the use of code. In some embodiments, the query catalog is a curated and enhanced dataset combining carrier datasets, additional user-created attributes, and third-party datasets. The query catalog can also be tailored to enable intuitive, high-quality interactions for users in non-technical businesses.

[0107] In some cases, various types of raw data are received from one or more carriers. This raw data may include SIM catalogs, device information, usage information, change history, account information, etc. Curated data is created from this raw data, and this data is supplemented based on custom tags and groups created by the user, and further supplemented based on third-party data (e.g., data related to manufacturer, hardware, network, operating system, programmability, geolocation, etc.).

[0108] The interactive query builder is provided with one or more query catalogs that enable the interactive query builder to generate responses to one or more user queries. In some embodiments, the generated responses are provided to a reporting engine and / or notification engine, such as those discussed herein.

[0109] In some embodiments, the interactive query builder also includes augmented, standardized, and correlated datasets encompassing multiple buckets, namely device information, lifecycle history, and usage data. Device information includes anything describing an IoT or phone device, with the exception of lifecycle history, connectivity, and usage information. The interactive query builder augments the basic information received from the carrier's data platform with additional information provided by the user via a portal or API, as well as third-party data related to device type, hardware, networking, and software specifications, and marketing terminology. The system and method also performs standardized, high-quality statistical profiling of this information, thereby enabling the system and method to add inferences as additional attributes to the device profile.

[0110] The lifecycle history includes data associated with actions and events not tracked by the carrier. The described system and method record actions and events whenever data is generated from the carrier. This is achieved by comparing recently generated data from the carrier with previously acquired data. In some embodiments, data acquisition is continuous so that changes can be captured more quickly and more accurately when associated with smaller time windows. Furthermore, users can distribute the device portfolio to additional actions not supported by the carrier, such as downstream customers, geographical departments, and business-specific departments. Users can also add groups of devices to watchlists and segments. If a user changes any of these additional characteristics, the described system and method can track those changes via a switch without requiring any additional code. As a result, users can gain complete visibility into the device lifecycle and additional actions performed during its lifespan by using an interactive query builder.

[0111] In some embodiments, the life-cycle events tracked may include:

[0112] - Deployment of SIM chips (e.g., moving from inventory to available state)

[0113] - Startup, expiration of service life (EOL: end-of-life), and shutdown not due to EOL

[0114] - Removal from and attachment to the actual physical device.

[0115] - Changing the phone number associated with a physical device

[0116] - Moving a SIM card from one billing account to another.

[0117] - Transferring a SIM card from one end customer to another.

[0118] - Moving a SIM card from one carrier to another.

[0119] - Changes to rate plans or service SKUs associated with a SIM card or phone number.

[0120] - Changes to attributes based on the systems and methods described herein.

[0121] - Changes to attributes based on statistical profiling

[0122] - Changes to the primary location of operations (e.g., geographically, network, etc.)

[0123] As used herein, “usage” broadly refers to the consumption of services provided by a carrier. Usage data may include data, SMS texts, voice, and video. Usage data is typically provided by carriers per SIM card / phone line as monthly, daily, or session-level data (CDR).

[0124] In some implementations, monthly summaries are billable records that have gone through the carrier's mediation and evaluation process. Daily summaries and session data may include unmediated and unevaluated calls.

[0125] Some carriers make additional slices available, although this is inconsistent with daily or monthly feeds. These additional slices may include, for example, geographical location of use (e.g., country, country-region, network area, etc.) and direction (e.g., origin / departure, termination / incoming, etc.), and in some cases, more granular information about the network itself (e.g., tower location, server IP, etc.).

[0126] The systems and methods described may also include refined use cases for determining which data feeds should be used. For example, by using pre-mediated and pre-evaluated information provided as a daily feed, and by adding predictive technology, this information can enable users to optimize their pricing plans early in the billing cycle to avoid future unforeseen circumstances. This approach is also useful in financial budgeting and inventory planning.

[0127] The systems and methods described herein may also include data pipelines implemented using inexpensive, general-purpose storage and cloud processing capabilities to facilitate the rapid ingestion and processing of millions of records. This approach is limited only by the carrier's ability to respond to data requests. In the case of CDR, the system and method receive data for each call session, and the system and method can reconstruct daily and monthly aggregates with respect to slices of data (e.g., geolocation, orientation, etc.) that would normally be lost from the raw daily and monthly feeds.

[0128] The datasets generated and used by the systems and methods described herein are standardized to be agnostic with respect to carriers, data platforms, voice vs. IoT, service types (e.g., data, voice, text, video, etc.), occurrence vs. termination, paid vs. free, and many other dimensions and characteristics. This standardization of datasets supports the various features and activities associated with and implemented by the interactive query builder. These features provide a simplified UI and GUI that enables rapid display of information on a single screen. As the boundaries between IoT devices and telephones become more blurred, and with the advent of eSIMs and 5G networks, the features provided by the interactive query builder become more useful and valuable to end users.

[0129] In some embodiments, dataset standardization involves aggregating data across all service contracts a customer has with any number of carriers or other service providers. For example, a customer might have three accounts with Verizon and another with AT&T. Using conventional systems and methods, to view data from four different accounts, perform some device management action, or create a summary analysis, the customer would have to log in separately to each Verizon account and the one AT&T account, retrieve the necessary data, and then reconcile and standardize the data before they could produce any summary report or analysis on finance, operations, or other departments. The systems and methods described herein provide improved and more efficient techniques. These systems and methods save a significant portion of the costs associated with system integration, maintaining those integrations as carriers release new features, and the subsequent unavoidable personnel retraining and turnover.

[0130] Notification engine The adoption of IoT typically requires real-time or near-real-time data and processing to continuously evaluate anomalous activity across a vast array of parameters, including fraud detection, network monitoring, e-commerce and risk management, and network security.

[0131] Using the statistical profiling discussed herein, the interactive query builder, combined with established business rules set by the end user, executes predefined expressions on the data structure while simultaneously using sophisticated processing techniques to continuously explore data patterns.

[0132] Notifications and reports are the simplest forms of analysis—their primary purpose is to present relevant “events” to end users in real time by transforming complex data into useful summaries of insightful information.

[0133] Notifications and reports can facilitate real-time awareness of IoT deployments by monitoring device scenarios, creating application workflows, and implementing those workflows via email or text alerts.

[0134] In some examples, industrial IoT implementations may include IoT sensor applications that identify application malfunctions. Simultaneously, the systems and methods described herein identify changes to a device state to “down” via predefined lifecycle notification triggers through their cellular carrier API. The described systems and methods can “activate” the SIM state to reconnect to cellular connectivity functionality. End-user IoT sensor applications can reset and resume normal functionality. This example reflects real-time device “incidents” identified via 1) a device sensor application and 2) cellular connectivity functionality. In some embodiments, the root cause was identified through connectivity troubleshooting without human interaction, cellular services were reconnected, and the device was brought back online.

[0135] Additional applications include real-time usage analysis based on pre-configured triggers and frequent anomalies. Further applications include creating and managing connectivity service plans for real-time or near-real-time device usage to optimize costs and evaluate service levels.

[0136] In some embodiments, the notification engine is built upon the datasets and interactive query builders discussed herein. The notification engine is a critical part of systems and methods that provide automated device lifecycle management. When a user creates a custom alert to identify a malfunctioning device, the user has two options: to be notified of the malfunction or to be notified and trigger automated device management actions. For example, if a device provisioned for domestic use suddenly starts charging for international roaming data, the user can automate the shutdown of the device while the user investigates the situation, so that billing can be prevented. In some embodiments, these malfunctioning devices are identified using statistical anomaly detection, which may be part of a continuous data processing system and methods that facilitate the automation of various business processes.

[0137] Ad-hoc reporting engine In some embodiments, an ad-hoc reporting engine (also called the “reporting engine”) is built upon the standardized datasets and interactive query builders discussed herein. Users can interact with the dataset and interactively view and / or download the results (e.g., in Excel spreadsheet format) for deeper analysis. In some embodiments, users can choose to have reports delivered to a secure FTP location accessible only to them. This is particularly useful when the dataset (e.g., data results) is large. This feature can substantially reduce the time and money spent by carriers and users on reporting infrastructure.

[0138] Figure 23 illustrates an illustrative block diagram of a computing device 2300 suitable for carrying out the systems and methods described herein. In some embodiments, a cluster of network-interconnected computing devices may be used to implement any one or more components of the systems discussed herein.

[0139] The computing device 2300 can be used to perform various procedures, such as those discussed herein. The computing device 2300 can function as a server, client, or any other computing entity. The computing device can perform various functions, such as those discussed herein, and can run one or more application programs, such as those described herein. The computing device 2300 may be any of the wide variety of computing devices, such as desktop computers, notebook computers, server computers, handheld computers, and tablet computers.

[0140] The computing device 2300 includes one or more processors 2302, one or more memory devices 2304, one or more interfaces 2306, one or more mass storage devices 2308, one or more input / output (I / O) devices 2310, and a display device 2330, all of which are coupled to the bus 2312. The processor 2302 includes one or more processors or control devices that execute instructions stored in the memory devices 2304 and / or the mass storage devices 2308. The processor 2302 may also include various types of computer-readable media, such as cache memory.

[0141] The memory device 2304 includes various computer-readable media, such as volatile memory (e.g., random access memory (RAM) 2314) and / or non-volatile memory (e.g., read-only memory (ROM) 2316). The memory device 2304 may also include rewritable ROM, such as flash memory.

[0142] The mass storage device 2308 includes various computer-readable media such as magnetic tape, magnetic disks, optical disks, and solid-state memory (e.g., flash memory). As shown in Figure 23, a specific mass storage device is a hard disk drive 2324. The mass storage device 2308 may also include various drives that enable reading and / or writing to various computer-readable media. The mass storage device 2308 includes removable media 2326 and / or non-removable media.

[0143] The I / O devices 2310 include a variety of devices that enable data and / or other information to be input to or retrieved from the computing device 2300. Examples of I / O devices 2310 include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other image acquisition devices.

[0144] The display device 2330 includes any type of device capable of displaying information to one or more users of the computing device 2300. Examples of the display device 2330 include monitors, display terminals, and video projection devices.

[0145] Interface 2306 includes a variety of interfaces that enable the computing device 2300 to interact with other systems, devices, or computing environments. Examples of interface 2306 include any number of different network interfaces 2320, such as interfaces to a local area network (LAN), a wide area network (WAN), a wireless network, and the Internet. Other interfaces include a user interface 2318 and a peripheral device interface 2322. Interface 2306 may also include one or more user interface elements 2318. Interface 2306 may also include one or more peripheral interfaces, such as interfaces for printers, pointing devices (mouse, trackpad, etc.), and keyboards.

[0146] Bus 2312 enables the processor 2302, memory device 2304, interface 2306, mass storage device 2308, and I / O device 2310 to communicate with each other and with other devices or components coupled to bus 2312. Bus 2312 represents one or more of several types of bus structures, such as the system bus, PCI bus, IEEE 1394 bus, and USB bus.

[0147] For illustrative purposes, programs and other executable program components are shown herein as separate blocks; however, it is understood that such programs and components may reside at different times within different storage components of the computing device 2300 and be executed by the processor 2302. Alternatively, the systems and procedures described herein may be implemented in hardware, or in a combination of hardware, software, and / or firmware. For example, one or more application-specific integrated circuits (ASICs) may be programmed to execute one or more of the systems and procedures described herein.

[0148] While various embodiments of the Disclosure are described herein, it should be understood that they are presented merely as examples and not as limitations. It will be apparent to those skilled in the art that various modifications of form and detail can be made in these embodiments without departing from the spirit and scope of the Disclosure. Therefore, the breadth and scope of the Disclosure are not limited by any of the exemplary embodiments described herein, but are defined solely by the following claims and their equivalents. The descriptions herein are presented for illustrative and explanatory purposes only. It is not intended to be exhaustive or to limit the Disclosure to the exact forms disclosed. Many modifications and changes are possible in light of the disclosed teachings. Furthermore, it should be noted that any or all of the alternative implementations considered herein may be used in any desired combination to form hybrid additional implementations of the Disclosure.

Claims

1. One or more processors, The system comprises one or more non-temporary computer-readable media storing instructions that can be executed by the one or more processors, and when the instructions are executed, the system... Receiving data from multiple carriers relating to multiple devices, wherein the data relates to multiple different types of services, the multiple devices communicate with the multiple carriers, each of the multiple devices communicates via at least one subscriber identity module (SIM) contained in each device, and the multiple devices have multiple different types of services including voice services, data services, video services, and text services. Standardizing the data to be agnostic for the aforementioned multiple carriers and the aforementioned multiple different types of services, In the aforementioned data, identify the trigger associated with at least one of the plurality of devices, In response to identifying the trigger, apply at least one business rule associated with at least one of the plurality of devices, A system that performs actions including generating at least one notification in response to applying at least one of the aforementioned business rules.

2. The system according to claim 1, wherein the trigger is at least one of timer expiration, data change, or activation of a user-defined trigger.

3. The system according to claim 1, wherein the trigger is at least one of a predefined trigger or a user-created trigger.

4. The system according to claim 1, wherein the at least one notification includes at least one of an email or a short message service (SMS) message.

5. The system according to claim 1, wherein the at least one notification includes an alert associated with the trigger.

6. The system according to claim 1, wherein the operation further comprises communicating the at least one notification to a user or system.

7. The system according to claim 1, wherein the operation further includes selecting a template to be used when creating the message associated with the at least one notification.

8. The system according to claim 7, wherein the operation further comprises obtaining at least one data element to complete the template.

9. The aforementioned operation is, Creating the message using the template and the at least one data element, The system according to claim 8, further comprising sending the message to at least one recipient.

10. Receiving data from multiple carriers relating to multiple devices, wherein the data relates to multiple different types of services, the multiple devices communicate with the multiple carriers, each of the multiple devices communicates via at least one subscriber identity module (SIM) contained in each device, and the multiple devices have multiple different types of services including voice services, data services, video services, and text services. Standardizing the data to be agnostic for the aforementioned multiple carriers and the aforementioned multiple different types of services, In the aforementioned data, identify the trigger associated with at least one of the plurality of devices, In response to identifying the trigger, apply at least one business rule associated with at least one of the plurality of devices, In response to applying the aforementioned at least one business rule, generate at least one notification, Methods that include...

11. The method according to claim 10, wherein the trigger is at least one of the following: timer expiration, data change, or activation of a user-defined trigger.

12. The method according to claim 10, wherein the trigger is at least one of a predefined trigger or a user-created trigger.

13. The method according to claim 10, wherein the at least one notification includes at least one of an email or a short message service (SMS) message.

14. The method according to claim 10, wherein the at least one notification includes an alert associated with the trigger.

15. The method according to claim 10, further comprising selecting a template to be used when creating the message associated with the at least one notification.

16. When executed, it will be used on one or more processors. Receiving data from multiple carriers relating to multiple devices, wherein the data relates to multiple different types of services, the multiple devices communicate with the multiple carriers, each of the multiple devices communicates via at least one subscriber identity module (SIM) contained in each device, and the multiple devices have multiple different types of services including voice services, data services, video services, and text services. Standardizing the data to be agnostic for the aforementioned multiple carriers and the aforementioned multiple different types of services, In the aforementioned data, identify the trigger associated with at least one of the plurality of devices, In response to identifying the trigger, apply at least one business rule associated with at least one of the plurality of devices, One or more non-temporary computer-readable media storing instructions for performing actions including generating at least one notification in response to applying the aforementioned at least one business rule.

17. The trigger is at least one of timer expiration, data change, or activation of a user-defined trigger, one or more non-temporary computer-readable media according to claim 16.

18. The one or more non-temporary computer-readable media according to claim 16, wherein the at least one notification includes an alert associated with the trigger.

Images