Device Management System and Method

Abstract

An example device management system and method are described. In one implementation, techniques identify a first plurality of devices that communicate using a first rate plan associated with a carrier. The techniques further identify a second plurality of devices that communicate using a second rate plan associated with the carrier. The techniques analyze the first rate plan and the second rate plan based on data usage. The techniques then identify at least one recommended rate plan change for at least one of the first plurality of devices or the second plurality of devices based on the analysis.

Description

Technical Field

[0001] This application claims the benefit of priority of U.S. Provisional Patent Application No. 63 / 068,334, filed on August 20, 2020, the entire disclosure of which is incorporated herein by reference.

[0002] This disclosure relates to the management of devices such as IoT (Internet of Things) devices and related 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 be able to move across multiple cellular carrier networks. Furthermore, cellular carrier management systems and IoT management platforms are diverse. As a result, a business's IoT deployment may be composed 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 that can overcome these problems.

[0004] Non-limiting and non-exhaustive embodiments of the present disclosure will be described 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

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11A

Figure 11B

Figure 12

Figure 13A

Figure 13B

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Best Mode 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 certain embodiments, these systems and methods are associated with the information management of cellular connectivity data associated with IoT (Internet of Things) devices deployed within any number of geographical areas.

[0007] In the following disclosure, reference is made to the accompanying drawings, which form a part hereof, and in which are shown, by way of illustration, specific implementations in which the disclosure may be practiced. It is understood that other implementations may be utilized and structural changes may be made without departing from the scope of the disclosure. References in the specification to "one embodiment," "an embodiment," "an illustrative embodiment," etc., mean that the particular feature, structure, or characteristic described in connection with the embodiment may be included, but not every embodiment necessarily includes that particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, the particular feature, structure, or characteristic may be described in connection with one embodiment, but, whether or not explicitly described, it is within the knowledge of those skilled in the art to make changes to such feature, structure, or characteristic in connection with other embodiments.

[0008] Implementations of the systems, devices, and methods disclosed herein may include a special-purpose or general-purpose computer that includes, as discussed herein, computer hardware, such as, for example, one or more processors and system memory. Implementations within the scope of the 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 that is accessible by a general-purpose or special-purpose 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, by way of example and not limitation, implementations of the disclosure may include at least two distinctly different types of computer-readable media, namely computer storage media (devices) and transmission media.

[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. The 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 on 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 particular 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. Although the subject matter is described in a language specific to structural features and / or methodological operations, 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 of implementing each claim.

[0012] Those skilled in the art will appreciate that the present disclosure can 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, cellular telephones, PDAs, tablets, pagers, 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 hardware, software, firmware, digital components, or analog components. For example, one or more application specific integrated circuits (ASICs) can be programmed to execute one or more of the systems and procedures described herein. Specific terms are used throughout this specification and the claims to refer to particular system components. Those skilled in the art will appreciate that components may sometimes be referred to by different names. This document is not intended to distinguish between components that differ in name but not function.

[0014] It should be noted that the sensor examples discussed herein may comprise computer hardware, software, firmware, or any combination of these for implementing at least a portion of these functions. For example, a sensor may include computer code configured to be executed on one or more processors, and may also include hardware logic / electrical circuits controlled by the computer code. These exemplary devices are provided herein for illustrative purposes and are not intended to be limiting. Embodiments of the present disclosure may be implemented in still other types of devices known to those skilled in the art.

[0015] At least some embodiments of the present disclosure are directed to a computer program product comprising such logic (e.g., in the form of software) stored on any computer-usable medium. Such software, when executed on one or more data processing devices, operates the devices as described herein.

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

[0017] In business, the deployment of IoT smart devices with intelligent physical components that form a network is increasingly expanding. 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 review industries and each field of an industry. For example, in the case of a wind turbine, each rotor blade can be controlled for each rotation by a small microcontroller in such a way that maximum wind energy is used. As another example, some autonomous vehicle companies are leveraging sensors and software to constantly scan for objects around the vehicle and continuously read traffic control, traffic signs, etc. Combined with a detailed three-dimensional map delivered to the vehicle via a built-in cellular connectivity function, the deployment of autonomous vehicles continues to increase. The systems and methods discussed herein are also useful for emerging technologies by changing the way an enterprise interacts 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. Using the systems and methods discussed herein, the limitations of existing systems can be alleviated or eliminated.

[0019] In some situations, traditional information management systems often focus on the organization, protection, and recovery of data from fixed computing devices such as servers or desktop computers. As a result, data managed by people and mobile data may be dispersed outside the scope of management of traditional information management systems, and accordingly, no backup or other active management is performed on that data. Therefore, if a mobile device is lost or damaged or there is a service interruption in the hosted service, there is a risk that very important data of a person will be lost and there will be no way to recover it.

[0020] The systems and methods described herein can overcome the above problems and provide additional benefits. For example, the systems and methods described herein can receive and analyze various types of data to identify optimal data carrier assignments to multiple devices such as cellular IoT devices. In these systems and methods, this assignment is optimized by determining which devices should be assigned to a particular carrier (and a particular carrier plan) to simultaneously execute multiple scenarios to provide services to those devices and optimize the cost of optimizing the performance of the devices. Based on certain optimizations and analyses, the described systems and methods generate recommendations for changes to services associated with one or more devices to satisfy the determined optimizations.

[0021] Furthermore, the systems and methods contemplated herein describe various embodiments and features such as an interactive query builder (also referred to as an "interactive query engine"), a notification engine, a reporting engine, and other components, methods, etc.

[0022] FIG. 1 is a block diagram showing an environment 100 in which an exemplary embodiment may be implemented. As shown in FIG. 1, a 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, 104 can have associated device states such as active, cancelled, stopped, and unknown. Although two devices 102 and 104 are shown in FIG. 1, a particular implementation can include any number of devices 102, 104 coupled to device management system 102.

[0023] Data sources 108 and 110 can be any type of data source that provides (or receives from the device management system 102) any type of data to the device management system 102. Data sources 108 and 110 can be associated with one or more third - party companies or other entities. In some embodiments, data sources 108, 110 can provide data related to manufacturer information, hardware information, network information, operating system information, programmability information, geographical location information, etc. Although two data sources 108 and 110 are shown in FIG. 1, a particular implementation may include any number of data sources 108, 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 any other entity that provides services. Although two service providers 112 and 114 are shown in FIG. 1, 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 coupled 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 using any communication protocol.

[0026] As shown in FIG. 1, the device management system 102 is also coupled to a database 116 that stores various information associated with the device management system 102. For example, the database 116 can store data associated with any number of managed devices 104, 106, service / tariff data associated with any number of cellular carriers, CDR (Call Detail Record) and usage data, and statistical data. The database 116 can also store any other type 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 the devices 104, 106 and data sources 108, 110 shown in FIG. 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 a system or a user (e.g., a system administrator) to construct a query that can define at least a part of the operation of the device management system 102. In some embodiments, the graphical query builder 124 is extended on the interactive query builder discussed herein. For example, the interactive query builder includes a GUI (graphical user interface) that enables a user to interact with one or more underlying data catalogs. This GUI enables the user to make selections from a set of information and apply criteria to each, as shown in FIG. 24. In an alternative embodiment of the graphical query builder 124, as shown in FIG. 25, a user can visually identify the location of a device of interest through the use of interactive widgets and charts / graphs.

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

[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 process multiple API requests related to IoT devices by grouping multiple API requests and processing those groups of API requests, as contemplated herein. The bulk API engine 130 also manages various API requests, including resubmitting API requests that were not successfully executed initially.

[0031] The statistical analysis engine 132 performs various statistical operations on the 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 save data to the database 116 and retrieve data from the database 116. For example, the statistical analysis engine 132 may combine and correlate multiple data sets such as device profiles, tags created by users, third-party device information, usage information, etc. 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 format that is easily accessible to the user. In some embodiments, the results generated by the statistical analysis engine 132 may be added to the data catalog used by the interactive query builder contemplated herein. Exemplary analyses that can be performed by the statistical analysis engine 132 include various usage patterns such as standard deviation and variance, average, lifetime, last 12 months, and monthly aggregation.

[0032] The evaluation and mediation engine 134 can calculate the fees for connectivity, device management, and other services for which the provider of the device management system 102 has a payment obligation to third-party customers and customers who are partners. The evaluation and mediation engine 134 can also be used for internal cost allocation to different departments or units of the company. In some embodiments, there are the following three types of evaluation models.

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

[0034] 2. Single price list - In this model, the downstream customer is billed based on a price list for the services it uses.

[0035] 3. Multiple price lists - In this model, the downstream customer can select two or more price lists and then assign one of the multiple price lists to a specific device based on the usage scenario of the device.

[0036] The mediation aspect of the evaluation and mediation engine 134 provides the ability to identify whether a particular type of service used (and measured) by the downstream customer is billable or not. The evaluation and mediation engine 134 can also implement one or more integrations as follows.

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

[0038] 2. The fee calculation can be made available via one or more APIs that will be integrated with the billing processing system or other systems.

[0039] As shown in FIG. 1, device management system 102 also includes a business process automation engine 136 and a service / tariff plan management system 138. The business process automation engine 136 enables a user (e.g., an administrator) or a system to define various business rules, business activity triggers, etc. as contemplated herein. In certain implementations, the business process automation engine 136 can apply (or execute) multiple business rules simultaneously or sequentially within the same process. This may be referred to as "stacking" business rules. In some examples, 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 / tariff plan management system 138 monitors various services and tariff plans presented by any number of different carriers.

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

[0041] In some examples, device management system 102 can receive various types of data from any number of carriers. Exemplary types of data include SIM directory data, device information, usage data, change history, account information, etc.

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

[0043] It will be understood that the embodiments of FIG. 1 are given merely as examples. Other embodiments may include fewer or additional components without departing from the scope of the present disclosure. Further, without limitation, the illustrated components may be combined or included within other components.

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

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

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

[0047] FIG. 3 is a block diagram showing an embodiment of optimization engine 128. As shown in FIG. 3, optimization engine 128 includes a communication management unit 302, a processor 304, and a memory 306. Communication management unit 302 enables optimization engine 128 to communicate with other systems and components. Processor 304 executes various instructions for implementing the functionality provided by optimization engine 128 as contemplated herein. Memory 306 stores these instructions along with other data used by processor 304 and other modules and components included in 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 implements various scenarios for comparing various results of pricing and services, such as by changing service plans for various devices to different carriers. The carrier data management unit 310 identifies and maintains current data regarding different carriers, such as different tariff plans and target geographical areas. The inflection point module 312 may determine the optimal number of devices to move from one tariff plan to another. In some embodiments, the inflection point module 312 may identify local minima to determine the optimal number of devices to move between tariff plans such that the combined cost for two tariff plans is optimized. This embodiment may test multiple techniques to find the optimal number of tariff plan migrations. In some implementations, the inflection point module 312 may include ways to enable a user to test different techniques 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 causes a user to create "pods" of devices that are to be defined using any device attributes, such as tags or usage profiles. These pods may have various sets of optimization rules and applied constraints.

[0050] The prediction and simulation module 316 implements both a prediction function and a simulation function. With respect to prediction, optimization is typically performed before the end of the billing cycle, which means that after the optimization is complete and the pricing plan is changed, the device continues to use data. To mitigate this situation, the systems and methods described herein add "predictions" to the most recent usage data available at the time of the last optimization run before the billing cycle ends. These predictions can be at the device level, pod level, pricing plan level, or aggregate level, depending on the customer's needs.

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

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

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

[0054] FIG. 4A is a flow diagram illustrating an example of a 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 can include any number of rules. In some embodiments, a user or system creating an optimization algorithm can select and test the rules individually before adding them to the optimization algorithm.

[0055] The process 400 continues with the testing 406 of the rules defined at 404, and the results of the rule testing are evaluated. If the results of the test are not successful at 408, the process continues with editing of the rules 410 and re-tests the edited rules at 406. If the results of the test are successful at 408, the rule is added to the optimization algorithm 412. The user or system then defines another rule 414 and then tests and evaluates the new rule at 406. The process 400 continues by adding and testing new rules until the optimization algorithm meets the goal of the optimization process.

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

[0057] In some embodiments, an optimization ensemble (or model) represents a set of mutually exclusive optimization algorithms, each of which can predict the best assignment of a pricing plan to a device. The optimization ensemble may also include a generalized orchestration module capable of performing various steps, handling error scenarios, analyzing performance statistics, and creating a plan change manifest for use by the bulk API engine (discussed herein) to effect a pricing plan change for an appropriate carrier.

[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 implement the various functions discussed herein. In certain implementations, a rule-based architecture may support the decomposition of code into small functions, sometimes called rules. The described systems and methods 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. A user 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] FIG. 5 is a flowchart showing an example of a process 500 for executing an optimization algorithm. First, at 502, the process generates all beneficial tariff plan change scenarios for each pod, such as a change from tariff plan A to tariff plan B or a change from tariff plan B to tariff plan A. In some embodiments, the tariff plan change scenarios are each unique (e.g., mutually exclusive) and include all possible combinations. For example, if there are 10 devices and 2 available carriers (each carrier having one tariff plan), the 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. To know which specific combination is the most cost-effective, all combinations can be determined and tested. The process continues at 504 by applying evaluation and other calculation rules to evaluate each scenario in terms of the increment of cost reduction. In some embodiments, process 500 complies with all of the device rules, tariff plan rules, device constraints, etc. Then process 500 selects the best scenario (e.g., the change with the best increment of cost reduction) at 506.

[0060] Process 500 continues by performing an inflection point calculation at 508. As shown in FIG. 5, the process may identify N devices that should be moved from tariff plan A to tariff plan B. For example, in some situations, the result of moving N + 1 or N - 1 devices may both result in less cost reduction than moving N devices. The process implements the changes identified in the previous activity at 510, then returns to 502 and repeats this process until no significant incremental profit is possible. Finally, upon reaching the best result at 512, the process logs the results, records the movement of devices between tariff plans, records performance statistics, etc.

[0061] FIG. 6 is a block diagram showing an embodiment of the notification engine 126. As shown in FIG. 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 for implementing the functionality provided by the notification engine 126 as contemplated 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] Further, 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 enables 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-set timers for specific types of alerts. The trigger and listener module 612 can perform anomaly detection, job failures, etc. The trigger and listener module 612 may automatically escalate a specific problem if necessary. In some embodiments, other systems or methods may automatically detect the escalation of a problem and generate an appropriate notification.

[0063] The notification engine 126 further includes a message editing module 614, a message sending module 616, user preferences 618, and a portal management unit 620. The message editing module 614 may select an appropriate template for the message based on the detected topic. Exemplary topics include optimization completion notification, tariff plan change completion notification, billing cycle reminder, data pipe job failure notification, data pipe job completion notification, business process automation (BPA) execution failure notification, BPA execution completion notification, bulk API execution failure notification, bulk API execution completion notification, available report notification, etc. Exemplary data change topics include new tariff plan notification, tariff plan change notification, data quality and integrity check notification, new user notification, etc. The message editing module 614 may also enable the user to define custom alerts based on usage terms, status changes, and other criteria, and then set a timer for alert notifications.

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

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

[0066] FIG. 7 is a flowchart showing an example of a process 700 for generating and communicating notifications. First, the process receives a message request 702. In some implementations, a specific process may be performed at a schedule defined by the user to create one or more message requests.

[0067] In some examples, the received request can be logged or queued in one of the following ways.

[0068] 1. Timer-based (asynchronous): For timer-based (e.g., billing cycle reminder) topics, the notification engine itself may start logging the request.

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

[0070] The process 700 executes the message request 704. In some examples, an email or SMS message can be created using an email / SMS template related to the topic by a message compiler, and the data required to complete the template is retrieved. In some examples, customized queries can be executed to create the message content, subject line, and recipient list. The process 700 may implement a message throttle. In some implementations, the process 700 may use recipients associated with alerts or queries regarding new messages. In certain situations, the recipient list can be determined based on the user's role.

[0071] The process then transmits one or more messages 706 based on the executed message requests. In some embodiments, created email or SMS messages (or both) are transmitted by the message transmitter. The process 700 then synchronizes one or more message tables in the portal 708 to enable them to be shown within a notification pane or window. In some embodiments, a service can synchronize the notification database with what is shown in the portal. Finally, the process 700 uploads a report file to the portal administrator 710. Further, in some embodiments, if a device is affected, the topic may require providing a list to the user. 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. Further, messages and notifications can be transmitted across multiple carriers. In this case, the message table and portal considered with respect to FIG. 7 can handle any messages and notifications from multiple carriers, multiple devices (of any carrier), etc.

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

[0074] Figure 9 shows an exemplary 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 a distribution list for notifications. All recent notifications can be displayed in a notification pane (e.g., a window), regardless of whether they are sent as emails or SMS messages. The notification pane may also support settings for emails and / or SMS messages regarding specific alerts such as usage alerts or change tracking alerts.

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

[0076] Carrier-agnostic with respect to requests, responses, connection protocols, etc.

[0077] Executing 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] Supporting multiple integration methods with customer and third-party applications

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

[0084] Integrating carrier-specific authentication protocols

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

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

[0087] Process 1000 continues by creating one or more batches of API calls 1008 and creating a plurality of threads for parallel execution of the batch of API calls 1010. The process retries any API calls that did not succeed 1012 (e.g., re-execute). Process 1000 then concatenates all responses 1014 and updates one or more data views associated with the API calls. The process displays the status of the requests 1016 (e.g., batches and individual IoT devices). Finally, method 1000 provides notifications of the results and status of the requests to one or more systems, users, etc. 1018.

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

[0089] FIG. 12 illustrates an exemplary embodiment of a 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 exemplary embodiment of various features 1300 of an API catalog. In some implementations, the API catalog may include multiple business process APIs. Figure 13B shows an exemplary embodiment of a process 1350 for implementing a service-type API (APIaaS). In some implementations, process 1350 integrates a bulk API engine with the API catalog.

[0091] Figure 14 shows an exemplary embodiment of an implementation 1400 of an optimization engine.

[0092] Figure 15 shows an exemplary embodiment of a flowchart 1500 for implementing an optimization engine.

[0093] Figure 16 shows an exemplary embodiment 1600 of a rule-based optimization engine that shows the results of various initializations, calculation groups, an ensemble of optimization algorithms, specific rules, and the execution of one or more optimization algorithms.

[0094] Figure 17 shows an exemplary embodiment of an implementation 1700 of a bulk API engine. The example of Figure 17 also shows the interaction of the bulk API engine with a data pipe and a notification engine.

[0095] Figures 18 to 20 illustrate exemplary embodiments of GUIs 1800, 1900, and 2000 that present various information to a user of a device management system. The exemplary GUIs shown in Figures 18 to 20 illustrate various claim processing data, usage data, device activity, average data usage, and the like. For example, GUI 1800 shows a dashboard format having various data that can be aggregated from multiple carriers, multiple platforms, multiple devices, and the like. In the example of Figure 19, a device-level snapshot of data is illustrated in GUI 1900. For example, GUI 1900 can enable 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 enterprise deployment / department hierarchy. In some embodiments, data is aggregated across customers / deployments / departments and the user can view all of the aggregated data or a specific group of data. In some implementations, GUI 2000 enables a user to drill down into specific IoT devices to obtain more granular data. In some embodiments, queries can be constructed across one or more carriers and across one or more customers / deployments / departments.

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

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

[0098] Interactive Query Builder

[0099] Consumer demand for technological innovation and new experiences is driving a rethinking of business models - As a means to keep up in a highly competitive consumer environment, IoT strategies and scaled complex deployments are being promoted. In the context of traditional IT, it is important that such deployments provide a flexible, secure, and efficient connectivity foundation, standardized device and data management, and automated processes. However, many IoT deployments are more than traditional business IT or network deployments. They are driving a rethinking of business models that require real-time intelligent insights, not just the capture of vast and diverse fragmented data. The Interactive Query Builder is built with business owners in mind and reconnects business owners and IT partners in a view of sales-aligned performance-based deployments in their pursuit of very complex and continuous business value. The Interactive Query Builder informs of same-day execution and results and also defines the next-day trajectory.

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

[0101] 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 situations, adjust their operations to peak processing capabilities, and maximize the value obtained from factory investments. For example, in the industrial oil industry, IoT sensors and transducers are deployed to collect data. By leveraging cellular services, these devices can be connected to a gateway, and then the data is transmitted from the gateway to the cloud. The described systems and methods can obtain data consumption information from each device, including but not limited to carriers, rate plans, consumption trends and anomaly reports, rate plans, costs, and optimization evaluations, directly from the carrier or connectivity platform via an API, while also recording and maintaining the device's life - cycle history.

[0102] In some embodiments, devices can be classified according to definitions provided by end - users regarding attributes such as facilities, geographical conditions, and business - specific departments, and / or activities including measurement, reporting, and notification of IoT applications.

[0103] For example, the systems and methods described herein enable an enterprise to cross - correlate different types of data with respect to 1) connectivity, 2) devices, and 3) device applications, creating one overall storyline that transcends the enterprise's functions and intentions to promote a more holistic strategy that is cross - cutting with respect to business strategy and technology deployment.

[0104] In several industries such as automotive and technology, companies are building the next generation of smart, connected cars. The companies are not only making driving safer but also directly accessing and analyzing data from vehicles for improving the customer experience, enhancing product development and manufacturing processes, and expanding their business.

[0105] In some situations, the retail industry has been reexamined based on customers' expectations for convenience, responsiveness, and personalization, through both digital and physical means. Collecting, consolidating, and managing customer data across multiple touchpoints is complex, but combining in-store data from the IoT with digital customer data has value in pursuing personalization of the shopping experience.

[0106] 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 identify and focus on areas of data of interest. When using the interactive query builder, minimal training based on how to use the interface is required of the user.

[0107] In some embodiments, the interactive query builder presents columns of attributes, facts, and measurements to the user in an intuitive GUI while performing input control meaningful for the selected columns. The actual queries against the query catalog are generated by leveraging completely configuration-based rules without code, dynamically depending on the context. In some embodiments, the query catalog is a curated and enriched dataset that combines carrier datasets, additional attributes created by the user, and third-party datasets. The query catalog can also be tailored to enable non-technical business users to conduct intuitive, high-quality interactions.

[0108] In some examples, various types of raw data are received from one or more carriers. This raw data can include, for example, SIM catalogs, device information, usage information, change history, account information, and the like. Curated data is created from the raw data, and this data is enhanced based on custom tags and groups created by the user and further enhanced based on third-party data (e.g., data related to manufacturers, hardware, networks, operating systems, programmability, geographical location, etc.).

[0109] An 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 a notification engine as contemplated herein.

[0110] In some embodiments, the interactive query builder also includes a plurality of buckets, i.e., enhanced and standardized correlated data sets that include device information, life cycle history, and usage data. Device information includes anything that describes an IoT or phone device, with the exception of life cycle history, connectivity, and usage information. The interactive query builder enhances the basic information received from the carrier's data platform with additional information provided by the user using a portal or API, third-party data related to device type, hardware, networking, and software specifications, and marketing terms. The system and method also perform a standard high-quality statistical profiling of this information, which enables the system and method to make inferences as additional attributes to the device profile.

[0111] The life cycle history includes data associated with operations and events that are not tracked by a carrier. The described systems and methods record operations and events each time data is generated from a carrier. This is achieved by comparing data recently generated from a carrier with data that has already been acquired. In some embodiments, data capture is continuous so that changes can be captured more quickly and be more accurate when they are associated with smaller time windows. Additionally, a user can perform additional operations not supported by a carrier, such as distributing a device portfolio to downstream customers, geographical departments, and business units. The user can also add groups of devices to watch lists and segments. When the user changes any of these additional features, the described systems and methods can track those changes via a switch without requiring any additional code. As a result, the user can obtain complete visibility into the device life cycle and additional operations performed during its existence by using an interactive query builder.

[0112] In some embodiments, the life cycle events tracked may include the following.

[0113] - Provisioning of the SIM chip (e.g., movement from catalog to available state)

[0114] - Startup, end-of-life (EOL), and non-EOL stops

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

[0116] - Change of the phone number associated with the physical device

[0117] - Movement of the SIM card from one billing account to another

[0118] - Transfer of SIM card from one end customer to another end customer

[0119] - Transfer of SIM card from one carrier to another carrier

[0120] - Change of tariff plan or service SKU associated with SIM card or phone number

[0121] - Change of attributes based on the systems and methods described herein

[0122] - Change of attributes based on statistical profiling

[0123] - Change of the main place of operation (e.g., geographically, network, etc.)

[0124] As used herein, "usage" broadly refers to the consumption of services provided by a carrier. Usage data may include data, SMS text, voice, and video. Usage data is typically provided by a carrier on a monthly aggregate, daily aggregate, or session-level data (CDR) basis for each SIM card / phone line.

[0125] In some embodiments, the monthly aggregate is a billed record that has gone through the carrier's mediation and rating process. The daily aggregate and session data may include unmediated and unrated calls.

[0126] In some carriers, additional slices are available, although not consistent for daily or monthly feeds. These additional slices include, for example, the geographical location of use (e.g., country, country-region, network area, etc.), and direction (e.g., origin / initiation, termination / termination, etc.), and in some cases more precise granularity information about the network itself (e.g., tower location, server IP, etc.).

[0127] The described systems and methods may also include refined use cases for determining which data feeds to use. For example, by using pre-mediated and pre-evaluated information provided as a daily feed and adding predictive techniques, this information enables a user to perform rate plan optimization early in the billing cycle to avoid future contingencies. This approach is also useful in financial budget management and inventory planning.

[0128] The systems and methods described herein may also include data pipelines implemented using inexpensive general-purpose storage and cloud processing capabilities that assist in the rapid ingestion and processing of millions of records. This approach is limited only by the capabilities of the carriers responding to data requests. In the case of CDRs, the systems and methods receive data per call session, and the systems and methods can reconstruct daily and monthly aggregates for slices of data (e.g., geographical location, directionality, etc.) that are typically lost from raw daily and monthly feeds.

[0129] The data sets generated and used by the systems and methods described herein are standardized such that the data sets are agnostic to carriers, data platforms, voice-to-IoT, service types (e.g., data, voice, text, video, etc.), start vs. end, paid vs. free, and many other dimensions and characteristics. This standardization of the data sets supports various features and activities associated with and implemented by an interactive query builder. These features provide a simplified UI and GUI that enable the rapid display of information on a single screen. As the boundary between IoT devices and telephones becomes more blurred, and with the emergence of eSIM and 5G networks, the features provided by the interactive query builder become more useful and valuable to end users.

[0130] 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 may have three accounts with Verizon and another account with AT&T. Using conventional systems and methods, in order to view data from the four different accounts, perform any device management actions, or create a general analysis, the customer would have to log in separately to each Verizon account and the one AT&T account, pull out the necessary data, and perform data collation and standardization before being able to perform any general reports or analysis regarding finance, operations, or other departments. The systems and methods described herein provide an improved and more efficient approach. With these systems and methods, a significant portion of the costs associated with system integration, maintaining these integrations when carriers release new features, and subsequent inevitable retraining and turnover of personnel is saved.

[0131] Notification engine

[0132] The adoption of IoT typically requires real-time or near-real-time data and processing to continuously evaluate abnormal activities among a vast number of parameters such as fraud detection, network monitoring, e-commerce and risk management, network security, etc.

[0133] Using the statistical profiling considered herein, the interactive query builder, and in combination with established business rules set by the end user, the data structure executes pre-defined formulas on the data and continuously explores data patterns using sophisticated processing techniques.

[0134] Notifications and reports are the most basic form of analysis - their main purpose is to present "events" relevant to the end user in real time by converting complex data into a useful summary of insightful information.

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

[0136] In some examples, industrial IoT implementations can include IoT sensor applications that identify application defects. At the same time, the systems and methods described herein identify changes to the "stopped" device state via pre - defined lifecycle notifications triggers through its cellular carrier API. The described systems and methods can "activate" the SIM state to reconnect to cellular connectivity functionality. The end - user IoT sensor application can reset and resume normal functionality. This example reflects 1) a device sensor application, and 2) real - time device "incidents" identified via cellular connectivity functionality. In some embodiments, the root cause was identified through connectivity troubleshooting, the cellular service was reconnected, and the device was restored online without human interaction.

[0137] Additional uses include real - time usage analysis regarding pre - configured triggers and frequent anomalies. Further uses can include creating and managing connectivity service plans for real - time or near - real - time device usage to optimize costs and evaluate service levels.

[0138] In some embodiments, the notification engine is built on 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 misbehaving device, the user has two options: receive a notification of the misbehavior or trigger an automated device management action upon receipt of the notification. For example, if a device provisioned for domestic use suddenly starts billing for international roaming data, the user can automate the device's suspension during the user's investigation of the situation to prevent the charges. In some embodiments, these misbehaving devices are identified using statistical anomaly detection, which can be part of an ongoing data processing system and method that facilitates the automation of various business processes.

[0139] Ad-hoc reporting engine

[0140] In some embodiments, an ad-hoc reporting engine (also referred to as the "reporting engine") is built on the standardized datasets and interactive query builders discussed herein. The user can interact with the dataset and view and / or download the results interactively (e.g., in Excel spreadsheet format) for further analysis. In some embodiments, the user can choose to have the report delivered to a secure FTP location accessible only to the user. This is particularly useful when the dataset (e.g., data results) is large. This feature can substantially reduce the time and money spent by the carrier and the user on the reporting infrastructure.

[0141] FIG. 23 illustrates an exemplary block diagram of a computing device 2300 suitable for implementing the systems and methods described herein. In some embodiments, a cluster of computing devices interconnected by a network may be used to implement any one or more components of the systems contemplated herein.

[0142] The computing device 2300 may be used to perform various procedures, such as those described herein. The computing device 2300 may function as a server, a client, or any other computing entity. The computing device can implement various functions as contemplated herein and can execute one or more application programs, such as the application programs described herein. The computing device 2300 can be any of a variety of computing devices, such as a desktop computer, a notebook computer, a server computer, a handheld computer, a tablet computer, etc.

[0143] 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 a bus 2312. The processor 2302 includes one or more processors or control devices that execute instructions stored in the memory device 2304 and / or the mass storage device 2308. The processor 2302 may also include various types of computer-readable media, such as cache memory.

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

[0145] The mass storage device 2308 includes various computer-readable media such as magnetic tape, magnetic disk, optical disk, solid state memory (e.g., flash memory), etc. As shown in FIG. 23, a particular mass storage device is the hard disk drive 2324. The mass storage device 2308 may also include various drives for enabling reading and / or writing to various computer-readable media. The mass storage device 2308 includes removable media 2326 and / or non-removable media.

[0146] The I / O device 2310 includes various devices that enable inputting data and / or other information into or retrieving the same from the computing device 2300. Exemplary 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 capture devices, etc.

[0147] 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, video projection devices, etc.

[0148] Interface 2306 includes various interfaces that enable computing device 2300 to interact with other systems, devices, or computing environments. Exemplary interfaces 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 user interface 2318 and 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 an interface for a printer, a pointing device (mouse, track pad, etc.), a keyboard, and the like.

[0149] Bus 2312 enables 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 a system bus, a PCI bus, an IEEE 1394 bus, a USB bus, and the like.

[0150] For illustrative purposes, programs and other executable program components are shown herein as individual blocks, but such programs and components may exist at various times within different storage components of computing device 2300 and be executed by processor 2302, as will be understood. Alternatively, the systems and procedures described herein may be implemented in hardware, or a combination of hardware, software, and / or firmware. For example, one or more application specific integrated circuits (ASICs) can be programmed to execute one or more of the systems and procedures described herein.

[0151] Although various embodiments of the present disclosure are described herein, it should be understood that they are presented by way of example and not limitation. It will be apparent to those skilled in the art that various changes in form and detail can be made therein without departing from the spirit and scope of the present disclosure. Accordingly, the breadth and scope of the present disclosure are not limited by any of the exemplified embodiments described herein but are defined only by the following claims and their equivalents. The description herein is presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of the teachings disclosed. Further, it should be noted that any or all of the alternative implementations discussed herein may be used in any desired combination to form additional hybrid implementations of the present disclosure.

Claims

1. One or more processors, One or more non-transitory computer-readable media storing instructions executable by the one or more processors, wherein the instructions, when executed, cause the system to, Identify a plurality of devices each communicating using either a first pricing plan or a second pricing plan, Analyze the first pricing plan and the second pricing plan based on consumption of telecommunications services by the plurality of devices, the analyzing including, (a) Determining a first incremental benefit for a first scenario including moving from the first pricing plan to the second pricing plan and a second incremental benefit for a second scenario of moving from the first pricing plan to the second pricing plan; (b) Selecting, based on the greater of the first incremental benefit and the second incremental benefit, either the first scenario or the second scenario as a selected scenario; (c) Performing an inflection point analysis to identify a number of the plurality of devices to move based on the selected scenario; (d) Moving the number of the plurality of devices between the first pricing plan and the second pricing plan based on the selected scenario; and (e) Repeating (a) the determining step, (b) the selecting step, (c) the identifying step, and (d) the moving step until it is determined in the determining step that there is no incremental benefit. A system that performs analysis thereby.

2. The step of determining the first incremental benefit of the first scenario and the second incremental benefit of the second scenario includes evaluating an operating cost associated with the plurality of devices, the system of claim 1.

3. The plurality of devices are Internet of Things (IoT) devices, the system of claim 1.

4. The step of selecting, based on the greater of the first incremental benefit and the second incremental benefit, either the first scenario or the second scenario as the selected scenario includes evaluating the first scenario and the second scenario based on a plurality of rules, the system of claim 1.

5. A method comprising, A computing device includes steps of analyzing a first tariff plan and a second tariff plan based on the consumption of telecommunication services by a plurality of devices, wherein each of the plurality of devices communicates using either the first tariff plan or the second tariff plan, and the analyzing steps include (a) determining a first incremental profit of a first scenario of moving from the first tariff plan to the second tariff plan, and determining a second incremental profit of a second scenario of moving from the first tariff plan to the second tariff plan; (b) based on the larger one of the first incremental profit and the second incremental profit, selecting one of the first scenario or the second scenario as the selected scenario; (c) performing an analysis of the inflection point to identify the number of the plurality of devices to be moved based on the selected scenario; (d) based on the selected scenario, moving the number of the plurality of devices between the first tariff plan and the second tariff plan; (e) repeating (a) the determining step, (b) the selecting step, (c) the identifying step, and (d) the moving step until it is determined that there is no incremental profit in the determining step; A method for performing the analysis.

6. The method according to claim 5, wherein the plurality of devices are Internet of Things (IoT) devices.

7. One or more non-transitory computer-readable media, when executed, cause one or more processors to identify a plurality of devices each communicating using either a first tariff plan or a second tariff plan; store instructions for performing operations including analyzing the first tariff plan and the second tariff plan based on the consumption of telecommunication services by the plurality of devices, and the analyzing steps include (a) determining a first incremental profit of a first scenario of moving from the first tariff plan to the second tariff plan, and determining a second incremental profit of a second scenario of moving from the first tariff plan to the second tariff plan; Step of selecting, as the selected scenario, either the first scenario or the second scenario based on the greater of the first incremental profit and the second incremental profit; Step of performing an inflection point analysis to identify the number of the plurality of devices to be migrated based on the selected scenario; Step of moving the number of the plurality of devices between the first pricing plan and the second pricing plan based on the selected scenario; Step of repeating (a) the determining step, (b) the selecting step, (c) the identifying step, and (d) the moving step until it is determined in the determining step that there is no incremental profit; One or more non-transitory computer-readable media for performing the analysis.

Images