Patent Application
20180374364
The embodiments described herein relate generally to network connected devices and more particularly to visualization including icon, color coding and historical routing information for IoT devices.
In many Internet-of-Things (IoT)/Machine-to-Machine (M2M) solutions, particularly running on moving machines, for example, vehicles, it may be useful to the fleet operator to visualize a color coded representation of the state of the vehicle on a map, e.g., if the vehicle loses communication completely i.e. if it is stolen, something wrong with the vehicle.
In one example embodiment, a computer-implemented method and system for providing visualization of information are disclosed. The method includes receiving current device status information for one or more IoT devices; receiving historical information for one or more IoT devices; correlating the received current device status information with the received historical information for each of the one or more IoT devices; determining overall state of each of the one or more mobile devices based on the correlation of the current device status information with historical information for each of the one or more IoT devices; and presenting the information in visual format based on the determination.
In an embodiment, the system for visualization of information comprises at least one IoT device, a data processing system and a user interface, wherein the data processing system further comprises: a storage database, wherein the storage database receives current device status information for one or more IoT devices and historical information for one or more IoT devices; an analytics engine and a rules engine, wherein the analytics engine and the rules engine correlate the received current device status information with the received historical information for each of the one or more IoT devices and determines overall state of each of the one or more IoT devices based on the correlation of the current device status information with historical information for each of the one or more IoT devices by using rules provided by the rules engine; and a report service, wherein the report service presents the information in visual format based on the determination.
In an embodiment, a non-transitory computer-readable medium having executable instructions for providing visualization of information is disclosed. The non-transitory computer-readable medium having executable instructions stored therein that, when executed, causes one or more processors corresponding to a system having a database and a user interface to perform operations including receiving current device status information for one or more IoT devices; receiving historical information for one or more IoT devices; correlating the received current device status information with the received historical information for each of the one or more IoT devices; determining overall state of each of the one or more mobile devices based on the correlation of the current device status information with historical information for each of the one or more IoT devices; and presenting the information in visual format based on the determination.
The embodiments described herein relate generally to communication networks, which may be cellular and/or wireless networks and more particularly to visualization including icon, color coding and historical routing information for IoT devices or mobile devices that are capable of moving, connected to a wireless communications network, such as a cellular network, and that share other characteristics, for example, vehicles belonging to a commercial fleet. The IoT devices or the mobile devices have the ability to transmit data over the internet. The transmission may also take place, for instance, through a blue-tooth connection to one's phone which uses cellular connectivity.
The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the embodiments described herein are not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.
In many Internet-of-Things (IoT)/Machine-to-Machine (M2M) solutions, particularly running on moving machines, for example, vehicles, it may be useful to the fleet operator to visualize a color coded representation of the state of the vehicle on a map, e.g., if the vehicle loses communication completely in events such as theft, vehicle malfunction, etc. The system and method described herein uses advanced visualization techniques to communicate key status information of one or more vehicles belonging to a fleet to system users, e.g., fleet operators. The key visualization techniques may involve representation including any one or more of: cluster, icon mapping, color-coding and historical routing representation. Alerts and visual trips are the best representations of how visualization is used to illustrate status to customers.
Generally customers or users, e.g., fleet operators, manually track the state of their assets or did not track the state at all. The method and system described herein provides the users with both, a quick holistic view and a more detail presentation of the state of their vehicles. Previously, users or fleet operators would manually maintain the status of their fleet by communicating with the drivers and vehicle operators. They would then have to manually correlate different data to determine more complex states and track the overall status of fleets on paper or in spreadsheets/documents.
In an embodiment, the system and method described herein, uses real-time or near real-time event evaluators that correlate both historical and current events to determine the overall state of individual vehicles and/or groups of vehicles. The data is stored and presented in the User Interface provided by mobile application & web application in real time or near real time. The state information is rolled up into reports and other views in the site to provide a holistic representation of the state of vehicles belonging to a particular fleet.
The system and method helps fleet managers, drivers and operators with a way to quickly determine any one or more of: which vehicles are experiencing issues, the type of issues/problems experienced by those vehicles and severity of the issues, through the unique visualization. Thus, the method and system described herein allows users to visualize the state of mobile or IoT devices, e.g., vehicles, in a unique and color-coded fashion that gives users a clear view of the state of one or more IoT devices belonging to a fleet/group of IoT devices.
In an embodiment, the system and method allows users to visualize states of one or more IoT devices e.g., vehicles, in maps.
The system and method uses color coding to represent key states of a vehicle or asset monitored by a monitoring system. For example, 1. Moving vehicles: any vehicle that is moving when the map is loaded may be shown by a green icon on the map; 2. Stopped vehicles: any vehicle that is stopped when the map is loaded may be shown by a black icon on the map; 3. Alert vehicles: any vehicle that had generated an alert may be shown by a red icon on the map, which may also be based upon the severity of the alert; 4. Offline vehicles: any vehicle that is offline (the device is disabled or for some other reason not sending the location & other data) may be shown by a grey icon on the map; 5. Cluster of vehicles: any group of vehicles that are in close proximity may be represented in a cluster-circle with the counts of vehicle. For example, a cluster may be represented by blue color, color coding may be assigned to the clusters to show the status based on the highest priority/severity status in the cluster; 6. Discovered places: added by the system and may be shown by a location icon in a green circle representing the number of visits based on the circle size. Details for discovered places may also be shown; 7. Critical: alert state of type critical may be shown in red, including icons associated with the state; 8. Warning: alert state of type critical may be shown in orange including icons associated with the state; 9. Information: alert state of type non-critical may be shown in blue including includes icons associated with the state.
The system and method described herein enables users, e.g., fleet operators, to customize their experience based on their preferences using user settings or account settings. The system and method described herein allows users to configure their icon types and website theme colors through account management settings along with other key aspects that they may be able to modify, for example, role, units (see below) and language etc.:
Icons and themes used by the system and method may be system generated or analytics driven or may be chosen and set up by the users. The system and method may allow users to define which icon represents their asset (car, truck, motorcycle, construction equipment, etc.). The users may be asked to provide an image in a scalable vector graphics (SVG) file. Additionally, or alternatively, the user may be allowed to choose the logo and colors to be used for their site. Additionally, or alternatively, the user may be allowed to choose the logo and themes to be used for their account. Additionally, or alternatively, the user may be allowed to choose map colors.
The mobile devices 104, 104′, . . . 104n′ may include IoT devices capable of communication, for example, vehicles connected to the cellular network or cellular-enabled devices via SIMs that are installed in the mobile or IoT devices as either integrated in the vehicle itself or removably installed in the vehicle on each of the fleet vehicle. These communication devices could be devices using a radio module and Wifi, or any other wireless communication technology that are capable of transmitting relevant vehicle data to database 106 and/or the data processing system 102 of the monitoring system.
In an embodiment, the devices, e.g., vehicles, may have monitoring devices installed in them, that are also capable of communication via SIMs that are installed in them. These monitoring devices may also be devices using a radio module and Wifi, or any other wireless communication technology that are capable of transmitting relevant vehicle/monitoring data to database 106 and/or the data processing system 102 of the monitoring system.
Moving devices either directly or via monitoring devices installed in them, send various data to a database as they perform their jobs. This data may be processed further by extracting information for relevant fields using application programming interface (API) keys to read data contained in specific data fields.
In an embodiment, the data may be containerized and stored based on a subscription identifier. The data is accessed through APIs using API keys and user authentication to securely transmit the data. Management of data received from these devices and access to application specific data to be used by specific applications is described in a related U.S. patent application Ser. No. 14/207,378, entitled, “MANAGEMENT OF DATA FEEDS FROM DEVICES AND PUBLISHING AND CONSUMPTION OF DATA” filed Mar. 12, 2014 and is herein incorporated by reference in its entirety.
In another embodiment, device data sent directly from the devices to the storage database may also be used, where the data may be accessed through APIs using API keys and user authentication to securely transmit the data.
In yet another embodiment, the device data is sent to a data processor, e.g., adapter 116, where it is processed and then sent to the storage database 106 to be used by the analytics engine.
Various data are collected from the moving devices either directly or via monitoring devices installed in them, as they perform their jobs. The gathered data may include route information along with the device records, for example, device identifier, start location of the route, destination location for the route, location of the device at time t=0 . . . n, time of the day for the travel, day of the week for the travel, time taken for or duration of the travel, distance covered during the travel, etc. The system may further involve usage of a computer to determine proximity to a location of interest, e.g., starting location, ending location, locations on route etc., among a vast number of such locations on a map using radius of proximity. The gathered data may further include fuel level, coolant temperature/level, speed, location, radius for geofence, accidents, odometer readings, time of the day, duration of travel, voltage level of monitoring device, ignition status of the IoT device, power level/battery status, monitoring device status, e.g., plugged/unplugged, vehicle deceleration etc. The devices may also report On-Board Diagnostics version 2 Diagnostic Trouble Code (OBDII DTC), J1939 (which is a standard for communication among vehicle components by Society of Automotive Engineers (SAE)), fault, battery voltage and faults regarding other components such as lamps. Backend systems may receive device status as ignition on and off or changes in ignition status, idle time, e.g., when ignition is on but no movement is recorded in terms of location with respect to time, e.g., GPS movement.
This gathered data is analyzed by the processing component of the system such as an analytics engine, by comparing the parameters of the gathered data with the threshold conditions provided to the system. If any of the parameters of the gathered data exceed the pre-determined or pre-defined threshold parameters, an alert may be issued by the monitoring system. The method and system for issuing alerts is described in U.S. application Ser. No. __/___,___, entitled “ISSUING ALERTS FOR IoT DEVICES”, filed on Jun. 21, 2018 (Attorney Docket No. 4016.915BS) and is herein incorporated by reference in its entirety.
For example, an alert may be issued for an IoT or mobile device as it goes around performing a job assigned to it, regarding geofencing, device behavior and/or driver behavior for devices. The issued alert is stored in the storage database, along with other information including any one or more of: location of the device when the alert was issued, time of the day, day of the week and/or date when the alert was issued, device identifier, operator of the device, etc. The severity of the issued alert is also stored in the one or more storage databases. This alert as well as severity of the generated alert information along with routing information for that device provides historical information for that device. The historical information for a device may further include any one or more of: the device's\vehicle's location (latitude/longitude, address etc.), routing information for the device, device status, e.g., moving/idle/stopped, state of vehicle over the course of time, sensor readings, etc. which helps identify patterns for that device. The historical information of the device may also help identify an event that may generate an alert, e.g., if a device is going over a pre-defined or pre-determined threshold speed limit for x # times in a row would indicate an event of speeding, or if a devices location has changed multiple times over a pre-defined or pre-determined period of time e.g., one minute, 2 minutes etc., then that device is considered as moving. Thus, historical information of a device may include any one or more of: issued alert, location of the device when the alert was issued, time of the day, day of the week, date when the alert was issued, severity of the issued alert, location of the device, routing information for the device, status of the device, state of device over the course of time, sensor reading for the device, duration of time spent by the device at a specific location, speed of the device, acceleration/deceleration of the device, ignition status of the device, fuel level of the device, battery level of the device, plugged/unplugged status of the device, duration of time for which no device information is received, device identifier and operator of the device.
The device information received by the one or more storage databases may thus include any one or more of: current status of the device, historical information for the device, location information of the device indexed by time and other device information including a device identifier, operator of the device, location of the device, duration of time spent by the device at a specific location, speed of the device, acceleration/deceleration of the device, ignition status of the device, fuel level of the device, battery level of the device, plugged/unplugged status of the device and duration of time for which no device information is received, etc. The current status of the device may include any one or more of: a device identifier, operator of the device, current location of the device, current state of the device (moving/idle/stopped), current sensor data, current speed of the device, acceleration/deceleration of the device, current ignition status of the device, current fuel level of the device, current battery level of the device, current plugged/unplugged status of the device and duration of time for which no device information is received, etc.
The analytics engine 108 correlates historical data for a device with the current status data for that device to determine the overall state of the device. For example, a device is considered speeding when x consecutive readings of speed are over a pre-defined or pre-determined threshold speed limit. Another example is if the device has not moved for x-amount of time, it is considered as idling. In most cases this historical data used for evaluating state of the device is stored in cache (along with the data store) for immediate retrieval. The correlation of historical data for a device with the current status data for that device includes compiling device status information for one or more mobile devices based on any one or more of: device identifier, device operator, trip identifier, location coordinates and alert information. This data is stored in a storage database and presented in the User Interface provided by the mobile application and/or web application in real time or near real time. This stored state information may be used to generate reports and other views in the mobile or web user interface by a report service 112, which generates reports by compiling the relevant information retrieved from the one or more databases, to provide a holistic representation of the state of the one or more vehicles belonging to a particular fleet.
The main logic for retrieving data is handled on the client which may be a mobile application or a web application. The logic is as follows: Current location and/or other data described above for desired vehicles, which may be specific vehicles or all vehicles belonging to a particular fleet, is retrieved from the data store. This may be done by retrieving data from the server or a data storage, which may be a physical data storage or may be cloud based data storage, by using representational state transfer (REST) webservices that will in turn obtain data from microservice via message queues. The microservices are responsible for retrieving data from a data store. For example, a client may request data from server through the client facing REST services using message: GET ASSET Location (api/fleet/assets), and the server may provide data using the response including AssetID, Latitude and longitude. This is passed back as a JSON OBJECT, as shown below using location data example.
New data may be posted or existing data may be updated into the data storage 106 directly or via adapter 116 as described above. Since the use of REST webservices is based on API, no user interface and/or human interaction may be involved in retrieving data from the server. The REST API services retrieve data through microservices. Microservices may help retrieve different information via smaller queries, generally performing a single function, from NO-SQL data structures or distributed databases, e.g., Cassandra, MongoDB etc. This retrieved information may then be compiled in a report format, based on user requests.
To present color coded data, a configuration file containing color code mapping to states, which may also be stored in the database 106, is used by the reporting service 112, which retrieves the state information from the database 106 and assigns color codes based on the mapping stored in configuration file.
To present data in a map, the report service 112 retrieves data via APIs as described above and then renders it on a map, which may be provided by a commercial mapping product. All states for the devices of interest are determined via the real-time event processing by the analytics engine 108 and rules engine 110, and then stored in the database 106. Additionally, the system may present color coded data in a map using the processes described above.
All data, including geofence, for places associated with the fleet are retrieved from the data store using REST web services via microservices as described above. The received device data e.g., vehicle locations are compared to the geofence data to determine the following: (a) Count of vehicles associated with a given place; (b) Counts of vehicles with no last known location; (c) Counts of vehicles not in a specific location (in transit); (d) When the vehicles count doesn't match with the number of vehicles in the fleet, there will be “**” next to the total count of vehicles on both top and bottom of the status summary. Once the results are obtained, they may be compiled in a desired format and rendered to the mobile and/or web interface as desired by the user.
Moving devices either directly or via monitoring devices installed in them, send various data to a database as they perform their jobs. This data may be processed further by extracting information for relevant fields using application programming interface (API) keys to read data contained in specific data fields.
In an embodiment, the data may be containerized and stored based on a subscription identifier. The data may be accessed through APIs using API keys and user authentication to securely transmit the data. Management of data received from these devices and access to application specific data to be used by specific applications is described in a related U.S. patent application Ser. No. 14/207,378, entitled, “MANAGEMENT OF DATA FEEDS FROM DEVICES AND PUBLISHING AND CONSUMPTION OF DATA” filed Mar. 12, 2014 and is herein incorporated by reference in its entirety.
In another embodiment, device data sent directly from the devices to the storage database may also be used, where the data may be accessed through APIs using API keys and user authentication to securely transmit the data.
In yet another embodiment, the device data is sent to a data processor, e.g., an adapter 116, where it is processed and then sent to the storage database 106 to be used by the analytics engine.
Various data are collected from the moving devices either directly or via monitoring devices installed in them, as they perform their jobs. The gathered data may include route information along with the device records, for example, device identifier, start location of the route, destination location for the route, location of the device at time t=0 . . . n, time of the day for the travel, day of the week for the travel, time taken for or duration of the travel, distance covered during the travel, etc. The system may further involve usage of a computer to determine proximity to a location of interest, e.g., starting location, ending location, locations on route etc., among a vast number of such locations on a map using radius of proximity. The gathered data may further include fuel level, coolant temperature/level, speed, location, radius for geofence, accidents, odometer readings, time of the day, duration of travel, voltage level of monitoring device, ignition status of the IoT device, power level/battery status, monitoring device status, e.g., plugged/unplugged, vehicle deceleration etc. The devices may also report On-Board Diagnostics version 2 Diagnostic Trouble Code (OBDII DTC), J1939 (which is a standard for communication among vehicle components by Society of Automotive Engineers (SAE)), fault, battery voltage and faults regarding other components such as lamps. Backend systems may receive device status as ignition on and off or changes in ignition status, idle time, e.g., when ignition is on but no movement is recorded in terms of location with respect to time, e.g., GPS movement.
This gathered data is analyzed by the processing component of the system such as an analytics engine, by comparing the parameters of the gathered data with the threshold conditions provided to the system. If any of the parameters of the gathered data exceed the pre-determined or pre-defined threshold parameters, an alert may be issued by the monitoring system. The method and system for issuing alerts is described in U.S. application Ser. No. __/___,___, entitled “ISSUING ALERTS FOR IoT DEVICES”, filed on Jun. 21, 2018 (Attorney Docket No. 4016.915BS) and is herein incorporated by reference in its entirety.
For example, an alert may be issued for an IoT or mobile device as it goes around performing a job assigned to it, regarding geofencing, device behavior and/or driver behavior for devices. The issued alert is stored in the storage database, along with other information including any one or more of: location of the device when the alert was issued, time of the day, day of the week and/or date when the alert was issued, device identifier, operator of the device, etc. The severity of the issued alert is also stored in the one or more storage databases. This alert as well as severity of the generated alert information along with routing information for that device provides historical information for that device. The historical information for a device may further include any one or more of: the device's\vehicle's location (latitude/longitude), routing information for the device, status, e.g., moving/idle/stopped, state of vehicle over the course of time, sensor readings, etc. which helps identify patterns for that device. The historical information of the device may also help identify an event that may generate an alert, e.g., if a device is going over a pre-defined or pre-determined threshold speed limit for x # times in a row would indicate an event of speeding, or if a devices location has changed multiple times over a pre-defined or pre-determined period of time e.g., one minute, then that device is considered as moving. Thus, the historical information of a device may include any one or more of: issued alert, location of the device when the alert was issued, time of the day, day of the week, date when the alert was issued, severity of the issued alert, location of the device, routing information for the device, status of the device, state of device over the course of time, sensor reading for the device, duration of time spent by the device at a specific location, speed of the device, acceleration/deceleration of the device, ignition status of the device, fuel level of the device, battery level of the device, plugged/unplugged status of the device, duration of time for which no device information is received, device identifier and operator of the device.
The device information received by the one or more storage databases may thus include any one or more of: current status of the device, historical information for the device, location information of the device indexed by time and other device information including a device identifier, operator of the device, location of the device, duration of time spent by the device at a specific location, speed of the device, acceleration/deceleration of the device, ignition status of the device, fuel level of the device, battery level of the device, plugged/unplugged status of the device and duration of time for which no device information is received, etc. The current status of the device may include any one or more of: a device identifier, operator of the device, current location of the device, current state of the device (moving/idle/stopped), current sensor data, current speed of the device, acceleration/deceleration of the device, current ignition status of the device, current fuel level of the device, current battery level of the device, current plugged/unplugged status of the device and duration of time for which no device information is received.
The historical data for a device with the current status data for that device is correlated to determine the overall state of the device via steps 206 and 208 as described above. For example, a device is considered speeding when x consecutive readings of speed are over a pre-defined or pre-determined threshold speed limit. Another example is if the device has not moved for x-amount of time, it is considered as idling. In most cases this historical data used for evaluating state of the device is stored in cache (along with the data store) for immediate retrieval. The correlation of historical data for a device with the current status data for that device includes compiling device status information for one or more mobile or IoT devices or for a particular mobile or IoT device may be based on any one or more of: device identifier, device operator, trip identifier, location coordinates and alert information. This data is stored in a storage database via step 208 and presented in the User Interface provided by the mobile application and/or web application in real time or near real time. This stored state information may be used to generate reports and other views in the mobile or web user interface by a report service, which generates reports by compiling the relevant information retrieved from the one or more databases, to provide a holistic representation of the state of the one or more vehicles belonging to a particular fleet in visual format, for example, a report; a table; a map; color coded graphs, icons etc. based on criticality of the determined state via step 210.
The main logic for retrieving data is handled on the client which may be a mobile application or a web application. The logic is as follows: Current location and/or other data described above for desired vehicles, which may be specific vehicles or all vehicles belonging to a particular fleet, is retrieved from the data store. This may be done by retrieving data from the server or a data storage, which may be a physical data storage or may be cloud based data storage. The process for retrieving the data by the reporting service using representational state transfer (REST) webservices that will in turn obtain data from microservice via message queues is described in detail above in the description accompanying
As illustrated, this page displays alerts triggered by devices or drivers. There are optional filters on a left side panel to select the view of alerts on list form and on the map. Some guideline for key information in the alert page may include 1. Timestamp—Indicates the local time the alert was triggered; 2. Alert Type—Indicates the name of the triggered alert, which typically describes the vehicle behavior associated with the alert; 3. Severity—indicates how severe is the alerts as set by the user. Red indicates critical, Orange indicates warning, Blue indicates information; 3. Vehicle—Name of the vehicle that triggered the alert; 4. Driver—Name of vehicle driver when the alert was triggered; 5. Value—Field value that caused the alert to trigger; 6. Location—Displays the location on the map where the alert event occurred; 7. Calendar Range: select the time range to filter for specific alerts on specific dates; 8. Filter by Severity: select the alert type severity critical, warning or information to list only those specific alerts land view on the map; 9. Filter by Alert Type: select the type of alert to list only those specific alerts land view on the map; 10. Filter by Vehicle: enter a vehicle ID to search for specific alerts for that one vehicle; 11. Alert Counts: View the total number of alerts by severity and type, and updated counts when filter by any of the options.
In an embodiment, the users may be allowed to modify the colors associated with states of the IoT devices. The users may also be allowed to assign a severity level to a particular alert state, e.g., critical, warning, etc., which in turn may have a color associated with it. The states of the device may be determined based on device data analytics using historical data for a device and correlating it with the current data received from that device. The correlation of historical data for a device with the current status data for that device includes compiling device status information for one or more mobile or IoT devices based on any one or more of: device identifier, device operator, trip identifier, location coordinates and alert information. This is achieved by using data analytics and machine learning to identify an anomalous state and by allowing the user to define the new state and associate the assigned state with a color code, which may also be chosen by the user. For example, if a vehicle typically visits a certain location on a certain day of the week, or at a certain time of the day, and then deviates from that pattern, such deviation from the pattern observed using historical information may be classified as an anomalous state, or if a sensor typically has a standard value and if a sensor reading deviates from that value, it would be classified as an anomalous state for that device.
FIGS. 4E1 and 4E2 illustrate an exemplary user interface depicting discovered places or locations of interest. As shown in
Memory elements 504a-b can include local memory employed during actual execution of the program code, bulk storage, and cache memories that provide temporary storage of at least some program code in order to reduce the number of times the code must be retrieved from bulk storage during execution. As shown, input/output or I/O devices 508a-b (including, but not limited to, keyboards, displays, pointing devices, etc.) are coupled to the data processing system 500. I/O devices 508a-b may be coupled to the data processing system 500 directly or indirectly through intervening I/O controllers (not shown).
In
Embodiments of the process described herein can take the form of an entirely software implementation, or an implementation containing both hardware and software elements. Embodiments may be implemented in software, which includes, but is not limited to, application software, firmware, resident software, microcode, etc.
The steps described herein may be implemented using any suitable controller or processor, and software application, which may be stored on any suitable storage location or computer-readable medium. The software application provides instructions that enable the processor to cause the receiver to perform the functions described herein.
Furthermore, embodiments may take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium may be an electronic, magnetic, optical, electromagnetic, infrared, semiconductor system (or apparatus or device), or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include DVD, compact disk-read-only memory (CD-ROM), and compact disk-read/write (CD-R/W).
Any theory, mechanism of operation, proof, or finding stated herein is meant to further enhance understanding of the present invention and is not intended to make the present invention in any way dependent upon such theory, mechanism of operation, proof, or finding. It should be understood that while the use of the words “preferable”, “preferably” or “preferred” in the description above indicates that the feature so described may be more desirable, it nonetheless may not be necessary and embodiments lacking the same may be contemplated as within the scope of the invention, that scope being defined by the claims that follow. In addition, it should be understood that while the use of words indicating a sequence of events such as “first” and “then” shows that some actions may happen before or after other actions, embodiments that perform actions in a different or additional sequence should be contemplated as within the scope of the invention as defined by the claims that follow.
As used herein, the term “communication” is understood to include various methods of connecting any type of computing or communications devices, servers, clusters of servers, using wired and/or wireless or cellular communications networks to enable processing and storage of signals and information, and where these services may be accessed by applications available through a number of different hardware and software systems, such as but not limited to a web browser terminal, mobile application (i.e., app) or similar, and regardless of whether the primary software and data is located on the communicating device or are stored on servers or locations apart from the devices.
As used herein the terms “device”, “appliance”, “terminal”, “remote device”, “wireless asset”, etc. are intended to be inclusive, interchangeable, and/or synonymous with one another and other similar communication-based equipment for purposes of the present invention, even though one will recognize that functionally each may have unique characteristics, functions and/or operations which may be specific to its individual capabilities and/or deployment.
Similarly, it is envisioned by the present invention that the term “wireless network” includes networks using one or more communication architectures or methods, including but not limited to: Code division multiple access (CDMA), Global System for Mobile Communications (GSM) (“GSM” is a trademark of the GSM Association), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), 4G LTE, 5G, wireless local area network (WIFI) and Ethernet.
Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the present invention.
Under 35 USC 119(e), this application claims priority to U.S. Provisional Application Ser. No. 62/523,756, entitled “VISUALIZATION: ICON, COLOR CODING AND HISTORICAL ROUTING INFORMATION FOR IoT DEVICES”, filed on Jun. 22, 2017 and U.S. Provisional Application Ser. No. 62/565,523, entitled “VISUALIZATION: ICON, COLOR CODING AND HISTORICAL ROUTING INFORMATION FOR IoT DEVICES”, filed on Sep. 29, 2017 and is related to U.S. application Ser. No. __/___,___, entitled “ISSUING ALERTS FOR IoT DEVICES”, filed on Jun. 21, 2018 (Attorney Docket No. 4016.915BS), all of which are herein incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62523756 | Jun 2017 | US | |
| 62565523 | Sep 2017 | US |
