WO2016166596A1

WO2016166596A1 - System and method for aggregating and acting on signals from one ormore remote sources in real time using a configurable platform instance

Info

Publication number: WO2016166596A1
Application number: PCT/IB2016/000554
Authority: WO
Inventors: Douglas A. STANDLEY; Matthew R. DODGE; Randall E. BYE
Original assignee: Societal Innovations Ipco Limited
Priority date: 2015-04-17
Filing date: 2016-04-15
Publication date: 2016-10-20

Abstract

An improved system and method are disclosed for receiving sensor readings from one or more devices and processing the readings in real time to create an output. For example, the method may include, for each of multiple devices, calculating a value based on the sensor readings obtained from the device for which the value is being calculated. Each of the values that satisfies at least one defined parameter is identified. All of the values that satisfy the defined parameter are aggregated to form an aggregated value. A defined action is executed based on the aggregated value. The steps of receiving, calculating, identifying, aggregating, and executing occur in real time without storing the sensor readings, the values, or the aggregated value.

Description

SYSTEM AND METHOD FOR AGGREGATING AND ACTING ON SIGNALS FROM ONE OR MORE REMOTE SOURCES IN REAL TIME USING A CONFIGURABLE PLATFORM INSTANCE CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a Patent Cooperation Treaty Application of U.S. Provisional Application No. 62/148,811, filed April 17, 2015, entitled SYSTEM AND METHOD FOR RECEIVING AND PROCESSING SIGNALS FROM ONE OR MORE SOURCES IN REAL TFME USING A CONFIGURABLE PLATFORM INSTANCE (Atty. Dkt. No. SNVS-32587) and U.S. Provisional Application No. 62/156,754, filed May 4, 2015, entitled SYSTEM AND METHOD FOR AGGREGATING AND ACTING ON SIGNALS FROM MULTIPLE REMOTE SOURCES IN REAL TFME USING A CONFIGURABLE PLATFORM INSTANCE

(Atty. Dkt. No. SNVS-32588), the specifications of which are incorporated by reference herein in their entirety.

BACKGROUND

[0002] The proliferation of devices has resulted in the production of a tremendous amount of data that is continuously increasing. Current processing methods are unsuitable for processing this data. Accordingly, what is needed are systems and methods that address this issue.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] For a more complete understanding, reference is now made to the following description taken in conjunction with the accompanying Drawings in which:

[0004] For a more complete understanding, reference is now made to the following description taken in conjunction with the accompanying Drawings in which:

[0005] FIG. 1A illustrates one embodiment of a neutral input/output (NIO) platform with customizable and configurable processing functionality and configurable support functionality;

[0006] FIG. IB illustrates one embodiment of a data path that may exist within a NIO platform instance based on the NIO platform of FIG. 1 A;

[0007] FIGS. 1C and ID illustrate embodiments of the NIO platform of FIG. 1A as part of a stack;

[0008] FIG. IE illustrates one embodiment of a system on which the NIO platform of FIG. 1 A may be run;

[0009] FIG. 2 illustrates a more detailed embodiment of the NIO platform of FIG. 1 A; [0010] FIG. 3 A illustrates another embodiment of the NIO platform of FIG. 2;

[0011] FIG. 3B illustrates one embodiment of a NIO platform instance based on the NIO platform of FIG. 3 A;

[0012] FIG. 4 illustrates one embodiment of a workflow that may be used to create and configure a NIO platform;

[0013] FIGS. 5A and 5B illustrate embodiments of an environment within which real time processing of information may be performed using a NIO platform;

[0014] FIGS. 6A-6D illustrate embodiments of various configurations of the NIO platform of FIGS. 5 A and 5B;

[0015] FIG. 7 illustrates one embodiment of an environment within which a NIO platform is to process sensor data;

[0016] FIG. 8A illustrates one embodiment of a configuration of the NIO platform of FIG.

7;

[0017] FIG. 8B illustrates one embodiment of the NIO platform of FIG. 8A configured with shake detection services;

[0018] FIG. 8C illustrates one embodiment of a graph with acceleration values relative to a shake threshold that may be provided by the shake detection services of FIG. 8B;

[0019] FIGS. 9A-9C illustrate embodiments of a graphical user interface (GUI) that may be used to display acceleration information processed by the NIO platform of FIG. 7;

[0020] FIG. 10 illustrates one embodiment of multiple services that the NIO platform of

FIG. 7 may be configured to run to provide information for the GUI of FIGS. 9A-9C;

[0021] FIGS. 11-18 illustrate embodiments of the services of FIG. 10;

[0022] FIGS. 19-23 illustrate embodiments of methods that may be used with or by the

NIO platform of FIG. 5;

[0023] FIG. 24 illustrates one embodiment of an environment within which a NIO platform is to process sensor data;

[0024] FIGS. 25A-25C illustrate embodiments of configurations of the NIO platform of FIG. 24 with shake detection and aggregation services;

[0025] FIG. 26 illustrates one embodiment of a graph with aggregated acceleration values converted to decibels that may be provided by the services of FIGS. 25A-25C; [0026] FIG. 27 illustrates one embodiment of multiple services that the NIO platform of FIG. 24 may be configured to run to provide information for the graph of FIG. 26;

[0027] FIGS. 28 and 29 illustrate embodiments of some services of FIG. 27; and

[0028] FIGS. 30-34 illustrate embodiments of methods that may be used with or by the NIO platform of FIG. 24.

DETAILED DESCRIPTION

[0029] The present disclosure is directed to a system and method for aggregating and acting on signals from one or more remote sources in real time using a configurable platform instance. It is understood that the following disclosure provides many different embodiments or examples. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.

[0030] The present disclosure describes various embodiments of a neutral input/output (NIO) platform that includes a core that supports one or more services. While the platform itself may technically be viewed as an executable application in some embodiments, the core may be thought of as an application engine that runs task specific applications called services. The services are constructed using defined templates that are recognized by the core, although the templates can be customized to a certain extent. The core is designed to manage and support the services, and the services in turn manage blocks that provide processing functionality to their respective service. Due to the structure and flexibility of the runtime environment provided by the NIO platform's core, services, and blocks, the platform is able to asynchronously process any input signal from one or more sources in real time.

[0031] Referring to FIG. 1A, one embodiment of a NIO platform 100 is illustrated. The NIO platform 100 is configurable to receive any type of signal (including data) as input, process those signals, and produce any type of output. The NIO platform 100 is able to support this process of receiving, processing, and producing in real time or near real time. The input signals can be streaming or any other type of continuous or non-continuous input.

[0032] When referring to the NIO platform 100 as performing processing in real time and near real time, it means that there is no storage other than possible queuing between the NIO platform instance's input and output. In other words, only processing time exists between the NIO platform instance's input and output as there is no storage read and write time, even for streaming data entering the NIO platform 100.

[0033] It is noted that this means there is no way to recover an original signal that has entered the NIO platform 100 and been processed unless the original signal is part of the output or the NIO platform 100 has been configured to save the original signal. The original signal is received by the NIO platform 100, processed (which may involve changing and/or destroying the original signal), and output is generated. The receipt, processing, and generation of output occurs without any storage other than possible queuing. The original signal is not stored and deleted, it is simply never stored. The original signal generally becomes irrelevant as it is the output based on the original signal that is important, although the output may contain some or all of the original signal. The original signal may be available elsewhere (e.g., at the original signal's source), but it may not be recoverable from the NIO platform 100.

[0034] It is understood that the NIO platform 100 can be configured to store the original signal at receipt or during processing, but that is separate from the NIO platform's ability to perform real time and near real time processing. For example, although no long term (e.g., longer than any necessary buffering) memory storage is needed by the NIO platform 100 during real time and near real time processing, storage to and retrieval from memory (e.g., a hard drive, a removable memory, and/or a remote memory) is supported if required for particular applications.

[0035] The internal operation of the NIO platform 100 uses a NIO data object (referred to herein as a niogram). Incoming signals 102 are converted into niograms at the edge of the NIO platform 100 and used in intra-platform communications and processing. This allows the NIO platform 100 to handle any type of input signal without needing changes to the platform's core functionality. In embodiments where multiple NIO platforms are deployed, niograms may be used in inter-platform communications.

[0036] The use of niograms allows the core functionality of the NIO platform 100 to operate in a standardized manner regardless of the specific type of information contained in the niograms. From a general system perspective, the same core operations are executed in the same way regardless of the input data type. This means that the NIO platform 100 can be optimized for the niogram, which may itself be optimized for a particular type of input for a specific application.

[0037] The NIO platform 100 is designed to process niograms in a customizable and configurable manner using processing functionality 106 and support functionality 108. The processing functionality 106 is generally both customizable and configurable by a user. Customizable means that at least a portion of the source code providing the processing functionality 106 can be modified by a user. In other words, the task specific software instructions that determine how an input signal that has been converted into one or more niograms will be processed can be directly accessed at the code level and modified. Configurable means that the processing functionality 106 can be modified by such actions as selecting or deselecting functionality and/or defining values for configuration parameters. These modifications do not require direct access or changes to the underlying source code and may be performed at different times (e.g., before runtime or at runtime) using configuration files, commands issued through an interface, and/or in other defined ways.

[0038] The support functionality 108 is generally only configurable by a user, with modifications limited to such actions as selecting or deselecting functionality and/or defining values for configuration parameters. In other embodiments, the support functionality 108 may also be customizable. It is understood that the ability to modify the processing functionality 106 and/or the support functionality 108 may be limited or non-existent in some embodiments.

[0039] The support functionality 108 supports the processing functionality 106 by handling general configuration of the NIO platform 100 at runtime and providing management functions for starting and stopping the processing functionality. The resulting niograms can be converted into any signal type(s) for output(s) 104.

[0040] Referring to FIG. IB, one embodiment of a NIO platform instance 101 illustrates a data path that starts when the input signal(s) 102 are received and continues through the generation of the output(s) 104. The NIO platform instance 101 is created when the NIO platform 100 of FIG. 1A is launched. A NIO platform may be referred to herein as a "NIO platform" before being launched and as a "NIO platform instance" after being launched, although the terms may be used interchangeably for the NIO platform after launch. As described above, niograms are used internally by the NIO platform instance 101 along the data path. [0041] In the present example, the input signal(s) 102 may be filtered in block 110 to remove noise, which can include irrelevant data, undesirable characteristics in a signal (e.g., ambient noise or interference), and/or any other unwanted part of an input signal. Filtered noise may be discarded at the edge of the NIO platform instance 101 (as indicated by arrow 112) and not introduced into the more complex processing functionality of the NIO platform instance 101. The filtering may also be used to discard some of the signal's information while keeping other information from the signal. The filtering saves processing time because core functionality of the NIO platform instance 101 can be focused on relevant data having a known structure for post-filtering processing. In embodiments where the entire input signal is processed, such filtering may not occur. In addition to or as alternative to filtering occurring at the edge, filtering may occur inside the NIO platform instance 101 after the signal is converted to a niogram.

[0042] Non-discarded signals and/or the remaining signal information are converted into niograms for internal use in block 114 and the niograms are processed in block 116. The niograms may be converted into one or more other formats for the output(s) 104 in block 118, including actions (e.g., actuation signals). In embodiments where niograms are the output, the conversion step of block 118 would not occur.

[0043] Referring to FIG. 1C, one embodiment of a stack 120 is illustrated. In the present example, the NIO platform 100 interacts with an operating system (OS) 122 that in turn interacts with a device 124. The interaction may be direct or may be through one or more other layers, such as an interpreter or a virtual machine. The device 124 can be a virtual device or a physical device, and may be standalone or coupled to a network.

[0044] Referring to FIG. ID, another embodiment of a stack 126 is illustrated. In the present example, the NIO platform 100 interacts with a higher layer of software 128a and/or a lower layer of software 128b. In other words, the NIO platform 100 may provide part of the functionality of the stack 126, while the software layers 128a and/or 128b provide other parts of the stack's functionality. Although not shown, it is understood that the OS 122 and device 124 of FIG. 1C may be positioned under the software layer 128b if the software 128b is present or directly under the NIO platform 100 (as in FIG. 1C) if the software layer 128b is not present.

[0045] Referring to FIG. IE, one embodiment of a system 130 is illustrated. The system 130 is one possible example of a portion or all of the device 124 of FIG. 1C. The system 130 may include a controller (e.g., a processor/central processing unit ("CPU")) 132, a memory unit 134, an input/output ("I/O") device 136, and a network interface 138. The components 132, 134, 136, and 138 are interconnected by a data transport system (e.g., a bus) 140. A power supply (PS) 142 may provide power to components of the system 130 via a power transport system 144 (shown with data transport system 140, although the power and data transport systems may be separate).

[0046] It is understood that the system 130 may be differently configured and that each of the listed components may actually represent several different components. For example, the CPU 132 may actually represent a multi -processor or a distributed processing system; the memory unit 134 may include different levels of cache memory, main memory, hard disks, and remote storage locations; the I/O device 136 may include monitors, keyboards, and the like; and the network interface 138 may include one or more network cards providing one or more wired and/or wireless connections to a network 146. Therefore, a wide range of flexibility is anticipated in the configuration of the system 130, which may range from a single physical platform configured primarily for a single user or autonomous operation to a distributed multi- user platform such as a cloud computing system.

[0047] The system 130 may use any operating system (or multiple operating systems), including various versions of operating systems provided by Microsoft (such as WINDOWS), Apple (such as Mac OS X), UNIX, and LINUX, and may include operating systems specifically developed for handheld devices (e.g., iOS, Android, Blackberry, and/or Windows Phone), personal computers, servers, and other computing platforms depending on the use of the system 130. The operating system, as well as other instructions (e.g., for telecommunications and/or other functions provided by the device 124), may be stored in the memory unit 134 and executed by the processor 132. For example, if the system 130 is the device 124, the memory unit 134 may include instructions for providing the NIO platform 100 and for performing some or all of the methods described herein.

[0048] The network 146 may be a single network or may represent multiple networks, including networks of different types, whether wireless or wireline. For example, the device 124 may be coupled to external devices via a network that includes a cellular link coupled to a data packet network, or may be coupled via a data packet link such as a wide local area network (WLAN) coupled to a data packet network or a Public Switched Telephone Network (PSTN). Accordingly, many different network types and configurations may be used to couple the device 124 with external devices.

[0049] Referring to FIG. 2, a NIO platform 200 illustrates a more detailed embodiment of the NIO platform 100 of FIG. 1A. In the present example, the NIO platform 200 includes two main components: service classes 202 for one or more services that are to provide the configurable processing functionality 106 and core classes 206 for a core that is to provide the support functionality 108 for the services. Each service corresponds to block classes 204 for one or more blocks that contain defined task specific functionality for processing niograms. The core includes a service manager 208 that will manage the services (e.g., starting and stopping a service) and platform configuration information 210 that defines how the NIO platform 200 is to be configured, such as what services are available when the instance is launched.

[0050] When the NIO platform 200 is launched, a core and the corresponding services form a single instance of the NIO platform 200. It is understood that multiple concurrent instances of the NIO platform 200 can run on a single device (e.g., the device 124 of FIG. 1C). Each NIO platform instance has its own core and services. The most basic NIO platform instance is a core with no services. The functionality provided by the core would exist, but there would be no services on which the functionality could operate. Because the processing functionality of a NIO platform instance is defined by the executable code present in the blocks and the services are configured as collections of one or more blocks, a single service containing a single block is the minimum configuration required for any processing of a niogram to occur.

[0051] It is understood that FIG. 2 illustrates the relationship between the various classes and other components. For example, the block classes are not actually part of the service classes, but the blocks are related to the services. Furthermore, while the service manager is considered to be part of the core for purposes of this example (and so created using the core classes), the core configuration information is not part of the core classes but is used to configure the core and other parts of the NIO platform 200.

[0052] With additional reference to FIGS. 3A and 3B, another embodiment of the NIO platform 200 of FIG. 2 is illustrated as a NIO platform 300 prior to being launched (FIG. 3A) and as a NIO platform instance 302 after being launched (FIG. 3B). FIG. 3A illustrates the NIO platform 300 with core classes 206, service classes 202, block classes 204, and configuration information 210 that are used to create and configure a core 228, services 230a-230N, and blocks 232a-232M of the NIO platform instance 302. It is understood that, although not shown in FIG. 3B, the core classes 206, service classes 202, block classes 204, and configuration information 210 generally continue to exist as part of the NIO platform instance 402.

[0053] Referring specifically to FIG. 3B, the NIO platform instance 302 may be viewed as a runtime environment within which the core 228 creates and runs the services 230a, 230b, and 23 ON. Each service 230a-230N may have a different number of blocks. For example, service 230a includes blocks 232a, 232b, and 232c. Service 230b includes a single block 232d. Service 230N includes blocks 232e, 232f, and 232M.

[0054] One or more of the services 230a-230N may be stopped or started by the core 228. When stopped, the functionality provided by that service will not be available until the service is started by the core 228. Communication may occur between the core 228 and the services 230a- 23 ON, as well as between the services 230a-230N themselves.

[0055] In the present example, the core 228 and each service 230a-230N is a separate process from an operating system/hardware perspective. Accordingly, the NIO platform instance 302 of FIG. 3B would have N+l processes running, and the operating system may distribute those across multi-core devices as with any other processes. It is understood that the configuration of particular services may depend in part on a design decision that takes into account the number of processes that will be created. For example, it may be desirable from a process standpoint to have numerous but smaller services in some embodiments, while it may be desirable to have fewer but larger services in other embodiments. The configurability of the NIO platform 300 enables such decisions to be implemented relatively easily by modifying the functionality of each service 230a-230N.

[0056] In other embodiments, the NIO platform instance 302 may be structured to run the core 228 and/or services 230a-230N as threads rather than processes. For example, the core 228 may be a process and the services 230a-230N may run as threads of the core process.

[0057] Referring to FIG. 4, a diagram 400 illustrates one embodiment of a workflow that runs from creation to launch of a NIO platform 402 (which may be similar or identical to the NIO platform 100 of FIG. 1A, 200 of FIG. 2A, 400 of FIG. 4A, and/or 900 of FIGS. 9A and 9B). The workflow begins with a library 404. The library 404 includes core classes 206 (that include the classes for any core components and modules in the present example), a base service class 202, a base block class 406, and block classes 204 that are extended from the base block class 406. Each extended block class 204 includes task specific code. A user can modify and/or create code for existing blocks classes 204 in the library 404 and/or create new block classes 204 with desired task specific functionality. Although not shown, the base service class 202 can also be customized and various extended service classes may exist in the library 404.

[0058] The configuration environment 408 enables a user to define configurations for the core classes 206, the service class 202, and the block classes 204 that have been selected from the library 404 in order to define the platform specific behavior of the objects that will be instantiated from the classes within the NIO platform 402. The NIO platform 402 will run the objects as defined by the architecture of the platform itself, but the configuration process enables the user to define various task specific operational aspects of the NIO platform 402. The operational aspects include which core components, modules, services and blocks will be run, what properties the core components, modules, services and blocks will have (as permitted by the architecture), and when the services will be run. This configuration process results in configuration files 210 that are used to configure the objects that will be instantiated from the core classes 206, the service class 202, and the block classes 204 by the NIO platform 402.

[0059] In some embodiments, the configuration environment 408 may be a graphical user interface environment that produces configuration files that are loaded into the NIO platform 402. In other embodiments, the configuration environment 408 may use a REST interface (such as the REST interface 908, 964 disclosed in FIGS. 9A and 9B of PCT/IB2015/001288, filed on May 21, 2015, and entitled SYSTEM AND METHOD FOR FULLY CONFIGURABLE REAL TFME PROCESSING, which is incorporated by reference herein in its entirety) of the NIO platform 402 to issue configuration commands to the NIO platform 402. Accordingly, it is understood that there are various ways in which configuration information may be created and produced for use by the NIO platform 402.

[0060] When the NIO platform 402 is launched, each of the core classes 206 are identified and corresponding objects are instantiated and configured using the appropriate configuration files 210 for the core, core components, and modules. For each service that is to be run when the NIO platform 402 is started, the service class 202 and corresponding block classes 204 are identified and the services and blocks are instantiated and configured using the appropriate configuration files 210. The NIO platform 402 is then configured and begins running to perform the task specific functions provided by the services. [0061] Referring to FIG. 5A, one embodiment of an environment 500 is illustrated with a NIO platform 502 that may be used to obtain and process signals from one or more sources in real time. The NIO platform 502 (which may be similar or identical to the NIO platform 100 of FIG. 1A, 200 of FIG. 2, 300 of FIG. 3 A, and/or 402 of FIG. 4) is coupled to a device 504 and a device 512. It is understood that the devices 504 and 512 may represent any signal sources and the NIO platform 502 is able to asynchronously process signals from multiple sources.

[0062] Although the NIO platform 502 is illustrated as being coupled to the devices 504 and 512 without any intervening servers, it is understood that one or more servers may be present. If such servers are not present but functionality provided by a server is needed (e.g., web services functionality), the server's functionality may be provided by the NIO platform 502. For example, the NIO platform 502 may use a web server module (such as the web server module 950 disclosed in FIG. 9B of PCT/IB2015/001288) to run any needed web services. In such embodiments, one service on the NIO platform 502 may manage the web server and another service may interact with the web server service. Alternatively, a single service may both manage the web server and consume signals from the web server.

[0063] The device 504 provides an API 506. The device 504 may include one or more internal signal sources 508 (e.g., device components such as sensors, applications, and/or user interfaces that generate signals within the device 504) and/or may be coupled to one or more external signal sources 510. The signals are sent to or retrieved by the NIO platform 502 via the API 506.

[0064] In the present example, the NIO platform 502 is able to obtain signals from the device 504 via the API 506 without requiring the installation of any applications or other software on the device 504. For example, a user of the device 504 may direct a browser of the device 504 to a website on which a web service is running, and the web service may then access the API 506. In other embodiments, the device 504 may be configured to log into or otherwise access the NIO platform 502, or the device 504 may have a network address that is entered into the NIO platform 502 via a mechanism such as a configuration file or an auto-discovery process, and the API 506 may then be accessed at the network address.

[0065] The device 504 may be accessed via an application 514. The device 504 may include one or more internal signal sources 516 and/or may be coupled to one or more external signal sources 518. The signals are sent to or retrieved by the NIO platform 502 via the application 514 and/or using various interfaces or processes. For example, the application 514 may access the internal signal source(s) using an API, and may then send the signals to the NIO platform 502 using UDP, TCP/IP, or another suitable protocol. The application 514 may be installed on the device 504 to obtain the signals for the NIO platform 502, and/or may have other functionality.

[0066] The NIO platform 502 may produce one or more outputs 519 via its own functionality or by sending information to a server. Examples of outputs 519 include sending to a website 520 (e.g., using an HTTP POST command), sending an email 522, sending a text message 524, sending to a feed 526, making a telephone call 528, leaving a voicemail 530, sending an actuation signal 532, sending to a display 534, storing in a database 536, and/or other outputs 538, which may include sending to another NIO platform. The NIO platform 502 may also send output to one or more of the devices from which signals are received, such as the devices 502 and 512. Although the illustrated outputs involve sending information, it is understood that an output may also include preparing and holding information for retrieval.

[0067] Referring to FIG. 5B, one embodiment of an environment 550 is illustrated. In the present example, the NIO platform 502 of FIG. 5A is located on a device 552, which may be similar or identical to one of the devices 504 and 512. For example, the NIO platform 502 may be run as an application on the device 552 and may interface with an operating system on the device 552, or may be embedded in a chipset of the device 552. The NIO platform 502 may access one or more internal signal sources 554 (e.g., via an API or an application) and/or one or more external signal sources 556. The external signal sources 556 may couple directly to the NIO platform 502 (e.g., via a communication interface provided by the device 552 for use by the NIO platform 502) and/or may be received by the device 552 and forwarded to or otherwise made available to the NIO platform 502. The NIO platform 502 may act on the signals itself and/or may send the signals to a destination for further processing or use.

[0068] Referring to FIG. 6A, one embodiment of the NIO platform 502 of FIGS. 5A and 5B is illustrated. As previously described, a NIO platform uses one or more services that in turn use blocks to perform specific tasks. Due to the architecture of the NIO platform, there is a great deal of flexibility in how the tasks are organized into various services and blocks. Accordingly, in FIG. 6A, the basic functionality of the NIO platform 502 is illustrated with a data reception/transformation section 602 that receives signals from sources 508 and/or 510, a processing section 604, and a transformation/delivery section 606 that delivers or makes available any output 519. As configured, the NIO platform 502 may process signals from one or more sources.

[0069] In operation, the data reception/transformation section 602 receives input signals 508/510 and transforms the signals into niograms. The niograms are passed to the processing section 604 and processed. The processed niograms are passed to the transformation/delivery section 606, which transforms the niograms (if needed) into a format suitable for whatever delivery mechanisms have been selected and then delivers the information as output 519. This occurs in real time without any data storage (other than queuing if needed).

[0070] Although the data reception/transformation section 602, the processing section 604, and the transformation/delivery section 606 may be a single service, they will generally be separate services. Furthermore, each of those services may be split into multiple services. For example, if the received signals are of different types, multiple services may be used for the data reception/transformation section 602, with each service handling a particular input signal type. Relatively complex sections, such as the processing section 604, may also be further divided into multiple services that handle various processing tasks. If the outputs are of different types, multiple services may be used for the transformation/delivery section 606, with each service handling a particular output type.

[0071] Referring to FIGS. 6B-6D, various embodiments of the NIO platform 502 of FIG. 6A are illustrated. There are different ways to configure the NIO platform 502 to handle cases where signals from multiple sources are to be received by a single instance of the NIO platform 502 and processed in the same or similar manner. FIGS. 6B-6D illustrate various configurations of the NIO platform 502 that may be used to handle such situations. It is understood that if different types of signals and/or signals from different sources are to be processed differently, then separate services will likely be used to handle at least certain portions of the processing for the various signals (as discussed with respect to FIG. 6B).

[0072] Referring specifically to FIG. 6B, one embodiment of the NIO platform 502 of FIG. 6A is illustrated with an alternate configuration. In this configuration, the NIO platform 502 is configured to provide two separate versions of the data reception/transformation section 602, the processing section 604, and the transformation/delivery section 606. This enables the NIO platform 502 to handle each signal source separately as though the NIO platform 502 was only receiving signals from that source. For example, a separate service may be used for each copy of each section.

[0073] In some embodiments, niograms may be sent from a service in one processing chain to a service in another processing chain in addition to or as an alternative to a service in the current chain. For example, output from the data reception/transformation section 602a will generally pass to the processing section 604a. However, the NIO platform 502 may be configured so that output from a service within the data reception/transformation section 608 is sent to a service within the processing section 604b and/or the transformation/delivery section 606b in addition to or instead of the processing section 604a. Services may also be configured to return a niogram to a previous service. This flexibility enables signals to be handled by a particular service and then passed to any other service if needed based on various properties of the signal and/or other criteria. In this manner, signals may be merged with other types of signals or split apart, and processing may occur as desired.

[0074] It is noted that the NIO platform of FIG. 6B may also be used to process different types of signals and/or signals from different sources that are to be processed differently, with each processing chain formed by sections 602, 604, and 606 configured with different services to provide the desired functionality. Signals may be passed back and forth between the services as described previously.

[0075] Referring specifically to FIG. 6C, one embodiment of the NIO platform 502 of FIG. 6A is illustrated with an alternate configuration. In the present example, the NIO platform 502 is configured to receive two separate sets of signals from signal sources 508a/510a and 508b/510b that are to be processed the same way. The input signals are identical and there is no need for separate services to handle the processing of different signal types.

[0076] In this example, the reception/transformation section 602 may be provided by a single service. For each incoming signal, the service will receive the signal, transform it, and send it on to the processing section 604. Niograms created for the signals may include information identifying the particular source, which allows signals to be handled on a per source basis if needed while still processing all niograms in the same basic manner. For example, if the signals are to be sent for display, the individual tagging by source enables the display to illustrate each source separately as outputs 519a and 519b, even though they were processed in the same processing section 604. [0077] With additional reference to FIG. 6D, one embodiment of the NIO platform 502 of FIG. 6A is illustrated with yet another alternate configuration. The NIO platform 502 may be configured to use a separate data reception/transformation section 602a and 602b for each of the signal sources, which provides each signal source with its own input into the NIO platform 502. For example, the signal sources may require different types of connections (e.g., may have different APIs or may use different communication protocols). The data reception/transformation sections 602a and 602b may be provided as separate services that both feed into a service provided by the processing section 604. Outputs 519a and 519b may be distinguished as needed using, for example, identifying information in the niograms created by the data reception/transformation sections 602a and 602b.

[0078] Referring to FIG. 7, one embodiment of an environment 700 is illustrated with the NIO platform 502 of FIG. 5A coupled to one or more servers 702 and 704. In the present example, the servers 702 and 704 are shown as separate servers, but it is understood that the servers may be the same server or servers and may be operating in a cloud environment. The server 702 is running one or more web services 706. The server 704 provides the NIO platform 502 with various outputs 519 via web services 708 and/or other applications.

[0079] In other embodiments, one or more of the servers 702 and 704 may not be present and the functionality provided by the absent server(s) (if needed) may be provided by the NIO platform 502. For example, the NIO platform 502 may use the previously referenced web server module to provide any needed web server functionality.

[0080] Although the NIO platform 502 can process any type of incoming signal, the NIO platform 502 is configured to process sensor data in the present embodiment. Accordingly, the NIO platform 502 is in communication with the device 504 that provides the API 506 that can be used to access internal signal sources 508. For purposes of example, the internal signal sources 508 are sensors. The sensors 508 (and the sensors 510), may be any type of sensors, including sensors used to detect acceleration (e.g., accelerometers), orientation (e.g., gyroscopes), location (e.g., global positioning system (GPS) receivers), motion, temperature, ambient light levels, color, sound, electrical current, battery life, acidity, flame, various types of labels (e.g., bar codes or RFID tags), and/or any other type of sensor. The sensors 508 may provide their information in raw or processed form. [0081] Accordingly, the web service 706 is able to obtain sensor data for the NIO platform 502 via the API 506. In the present example, this may occur without requiring the installation of any applications or other software on the device 504 by the NIO platform 502. For example, a user of the device 504 may direct a browser (not shown) of the device 504 to a website on which the web service 706 is running, and the web service 706 may then access the API 506. In other embodiments, the device 504 may be configured to log into or otherwise access the NIO platform 502, an application may be installed on the device 504 to provide data to the NIO platform 502, or the device 504 may have a network address that is identified and entered into the NIO platform 502 via a mechanism such as a configuration file or an auto-discovery process, and the API 506 may then be accessed. Accordingly, the particular manner in which the sensor data is obtained by the NIO platform 502 may vary depending on the particular characteristics of the device 504 and/or the configuration of the NIO platform 502.

[0082] The NIO platform 502 forms part of a real time processing chain for the sensor data that may be viewed as including the server 702, the NIO platform 502, and the server 704. In operation, the web service 706 forwards (e.g., streams) the sensor data to the NIO platform 502 for processing. The NIO platform 502 processes the data and sends the processed output to the web service 708 for output. The data is not stored during the real time processing that occurs within the real time processing chain, although the data may be stored if desired. For example, the NIO platform 502 may be configured to store the data at any time during processing for a reason such as later analysis or retrieval, but this does not affect the data that is being processed in real time.

[0083] Referring to FIG. 8A, one embodiment of the NIO platform 502 is illustrated in the environment 700 of FIG. 7. As previously described, a NIO platform uses one or more services that in turn use blocks to perform specific tasks. Due to the architecture of the NIO platform, there is a great deal of flexibility in how the tasks are organized into various services and blocks. Accordingly, in FIG. 8A, the basic functionality of the NIO platform 502 is illustrated with a data reception/transformation section 802 that receives sensor information from the device 504 via the web services server 702, a processing section 804, and a transformation/delivery section 806 that delivers processed information to the web services server 704.

[0084] The data reception/transformation section 802 receives sensor data from the web services server 702 and transforms the data into niograms. The niograms are passed to the processing section 804 and processed. The processed niograms are passed to the transformation/delivery section 806, which transforms the niograms (if needed) into a format suitable for whatever delivery mechanisms have been selected and then delivers the information to the web services server 704.

[0085] Referring to FIG. 8B, one embodiment of the NIO platform 502 of FIG. 8A is illustrated after being configured to process a particular type of sensor data in a particular way. More specifically, the NIO platform 502 is configured to receive sensor data from the device 504 and to determine whether the device 504 has been shaken or otherwise vibrated using one or more services 808 configured for shake detection.

[0086] Referring to FIG. 8C, a graph 810 illustrates one embodiment of sensor data representing a shake that may be detected and displayed by the shake detection services 808 of FIG. 8B. The graph 810 provides a line 812 that represents sensor data from the device 504. The graph 810 includes an x-axis 814 representing time and a y-axis 816 representing acceleration. The x-axis 814 begins at a time tO and runs through time tcurrent. The y-axis 816 represents an acceleration range from zero to a maximum acceleration ACCMAX of the device 504. In other embodiments, it is understood that acceleration may be shown as a vector and/or the maximum acceleration ACCx may be omitted or may scale based on various criteria. A shake threshold 818 indicates a detection level where a detected acceleration is viewed as a "shake."

[0087] In the present example, the acceleration line 812 begins at time tl and remains flat along the y-axis 816 until time t2, indicating that the NIO platform 502 started receiving incoming sensor information at time tl, but no acceleration has been detected. At time t2, acceleration is detected as the line 812 moves up the y-axis 806. At time t3, the acceleration passes the shake threshold 818, indicating that a shake has been detected. At time t4, the line 812 moves below the shake threshold 818. At time t5, the line 812 returns to the value indicating that no acceleration is taking place. It is noted that the "no acceleration" value may be normalized to zero in some embodiments.

[0088] To construct the graph 810 in real time, the NIO platform 502 obtains acceleration data from one or more accelerometers on the device 504. This data is processed and plotted as the line 812, with the processing including a determination of whether a particular acceleration value has passed the shake threshold 818. If the shake threshold 818 is exceeded, other defined actions may be taken by the NIO platform 502.

[0089] It is understood that the detection level represented by the shake threshold 818 may not represent the acceleration needed to indicate an actual shake of the device 504, but may simply indicate that a defined level of acceleration has been detected. In addition, it is understood that detected acceleration values may be used for additional calculations, such as whether vibration is occurring and/or characteristics of such vibrations, such as duration and magnitude. Furthermore, while the present example uses acceleration as an example, it is understood that the real time processing NIO platform 502 can be configured to process any time-varying disturbance that may be detected using information from sensors 508.

[0090] Referring to FIG. 9A, one embodiment of a GUI 900 illustrates a webpage or other display that may be created using sensor information that is processed in real time by the shake detection services 808 of the NIO platform 502 of FIG. 8B. As described previously, the web services server 702 obtains sensor data from the device 504 and streams that data to the NIO platform 502. The shake detection services 808 process the data in real time and send one or more outputs to the web services server 704 for display via the GUI 900.

[0091] The GUI 900 includes a graph pane 902 that is currently empty as no data is being received by the NIO platform 502. In some embodiments, the graph pane 902 may display text to indicate that there is no data being received. An action triggers pane 904 may be used to indicate various triggers and actions taken when a trigger occurs. In the present example, the GUI 900 is to display acceleration from a device and the NIO platform 502 will take certain actions depending on the number of shakes that are detected. Accordingly, a shake/action pane 906 details each action that will be taken after the indicated number of shakes are detected. Five detected shakes will result in a tweet being sent via a specified account. Ten detected shakes will result in a text being sent to one or more specified destinations. Twenty detected shakes will results in an email being sent to one or more specified destinations. Thirty detected shakes will result in a voice call being placed to one or more specified destinations. The actions may be performed only once (e.g., send a tweet only after the first five shakes) or may be performed each time the trigger occurs (e.g., send a tweet after every set of five shakes).

[0092] The action triggers pane 904 also includes a maximum (max) force pane 908 that indicates a certain number of G forces. If a shake exceeds the identified number of G forces, an identifier associated with the device from which the shake was detected will be sent by the NIO platform 502 to a display.

[0093] A button 912 may be used to enable/disable data storage, and the amount of data stored is shown in pane 914. Also shown are the total number of detected shakes in pane 916 and the max detected force in pane 918. In the present example, the GUI 900 is provided via a browser window, so all information is shown with a starting point at the time that either the GUI 900 is opened or when a device begins sending data to the NIO platform 502. In other embodiments, the GUI 900 may be configured to provide some data persistence. A reset button 919 can be used to reset the values and graph.

[0094] Referring to FIG. 9B, one embodiment of the GUI 900 is illustrated after the NIO platform 502 has been receiving data from the device 504, processing that data, and sending resulting information for display by the GUI 900. In the present example, the graph pane 902 is displaying a line 920 that represents acceleration information from the device 504. Horizontal lines 922 represent increments of one G, with each line numbered to indicate the Gs represented by that line.

[0095] The bottom of the graph pane 902 indicates time and currently displays the current time tC at the right side and earlier times tC-1 - tC-13 to the left. It is understood that the graph pane 902 may vary dynamically depending on the incoming information. For example, if no data is received for a certain amount of time, the time increments may be enlarged so that at least a portion of the line 920 remains visible. The vertical scaling of the line 920 may also be dynamically altered to adjust to changes in the maximum force detected. For example, if a maximum force of ten Gs is detected, the vertical scaling may adjust to show the full line 920. Similarly, if no data is being received or only low levels of acceleration are being detected, the vertical scaling may adjust to show a more detailed view of the line 920.

[0096] The log pane 910 is displaying log results that indicate the occurrence of particular defined events. For example, each time a shake is detected, the text "Shake detected." is displayed. Also displayed are events from the shake/action pane 906, such as the actions taken upon the occurrence of five and ten shakes. As new information may be added to the log pane 910 at the top, older information is pushed down and then out of the log pane entirely. By counting the number of shakes after the ten shake action, it is clear that there have been a total of fourteen shakes. This total is reflected in the total shakes pane 916. [0097] The max force pane 918 indicates that the maximum force exerted by the highest of the fourteen shakes is 7.4 Gs. This coincides with the spike in the line 920 around time tc-n. If the maximum force occurred earlier and is not shown by the currently displayed portion of the line 920, the max force pane 918 will display the correct maximum force. In other words, the value displayed by the max force pane 918 may not be shown by the line 920 if enough time has elapsed since the maximum force was recorded.

[0098] Referring to FIG. 9C, one embodiment of the GUI 900 is illustrated with data from multiple devices being represented. In the present example, the line 920 of FIG. 9B is illustrated for a device identified as ID1 (e.g., the device 504) and a line 924 is illustrated for a device identified as ID2 (e.g., the device 512). The devices may be associated with their lines 920 and 924 by a legend or similar aid as shown in the lower right corner of the GUI 900. In some embodiments, the sensor data from the devices may be normalized.

[0099] The log pane 910 reflects the use of multiple devices, with each shake being linked to the corresponding device. The actions may be based on the shakes detected for a single ID (e.g., thirty shakes must be detected for a single ID before a call is made) or may be based on a combination of shakes from multiple IDs. The ID displayed according to the max force level of six Gs will first be ID1 (when line 902 spikes around time tc-n). Between times tc-6 and tc-5, ID2 will be displayed as the max force as line 924 crosses the six G threshold. The IDs may be selectable to limit the GUI 900 to data from a single ID even when sensor data from multiple devices is being processed. Data storage has been enabled via actuation of the button 912 and 3.9 kilobytes of data have been stored. Data storage may be disabled by actuation of the button 912.

[0100] It is understood that the GUI 900 is only one example of how the sensor data from the device 504 may be used and/or represented by the NIO platform 502. For example, sensor information obtained from mobile and/or fixed devices with accelerometers may be used to monitor vibrations for earthquake detection, for equipment health, for motion detection, and for many other different applications. In another example, the shakes/vibrations may be converted to decibels to simulate clapping or other sound based signals, and the decibels may be displayed graphically and/or played as sounds in real time. As any type of sensor data and combinations of different types of sensor data may be processed by the NIO platform 502, the GUI 900 may be used to display any desired information produced by the NIO platform 502. Furthermore, actions may include actuations, such as sounding sirens connected to warning systems and/or shutting down machines when certain triggers are detected.

[0101] Referring to FIG. 10, one embodiment of the NIO platform 502 is illustrated with specific services for implementing various functions for shake detection processing and producing outputs based on the results of the processing. In the present example, the NIO platform 502 is configured to provide outputs that include sending information to various socket IO rooms used to populate the GUI 900 of FIGS. 9A-9C. The configuration includes a mobile service 1002, a counter service 1004, and a shake alerts service 1006, a max force service 1008, a database (DB) service 1010, a DB size service 1012, a display service 1014, and a notifications service 1016. Various publication channels and/or other outputs are shown below their respective services, and channel subscriptions are shown above their respective services where applicable.

[0102] The mobile service 1002 handles input (e.g., acceleration data) from the device 504, calculates acceleration, and publishes to one or more channels for consumption by other services. The counter service 1004 subscribes to a publication channel used by the mobile service 1002 and detects whether a calculated acceleration value is considered a "shake" (e.g., is over the shake threshold 3218) and publishes any detected shakes to one or more channels for consumption by other services. The counter service 1004 may also debounce the shakes so a device does not register multiple shakes in a relatively simultaneous manner. The shake alerts service 1006 subscribes to a publication channel used by the counter service 1004 and determines whether or not to perform some action based on received input (e.g., send a tweet or an email).

[0103] The max force service 1008 subscribes to a publication channel used by the mobile service 1002 and determines the maximum force of a shake relative to previous shakes and publishes any shake that is determined to be a maximum shake. The DB service 1010 subscribes to a publication channel used by the mobile service 1002 and stores to a database. The DB size service 1012 queries the database used by the DB service 1010 and streams the total size of the data.

[0104] The display service 1014 subscribes to a publication channel used by counter service 1004 and determines if something should appear on a display. If something should appear on the display, the display service 1014 sends the request to be displayed on the display. The notifications service 1016 subscribes to a publication channel used by the counter service 1004 and the shake alerts service 1006. The notifications service 1016 stores received notifications in a database and also streams them for display.

[0105] Referring to FIG. 11, one embodiment of the mobile service 1002 is illustrated. In the present example, the mobile service 1002 includes multiple blocks, including a mobile post handler block 1102, a calculate acceleration block 1104, a pub mobile raw block 1106, a join mobile block 1108, a logger block 1110, a mobile socket block 1112, and a pub mobile block 1114.

[0106] The mobile post handler block 1102 receives the incoming sensor data to the NIO platform 502 and converts the data into niograms. For example, the mobile post handler block 1102 may receive values such as 2.4, -1.6, and 1.9 that represent acceleration along the x, y, and z axes of the device 504. Other information, such as gyroscope and/or location information, may also be received. The output from the mobile post handler block 1102 is directed to the calculate acceleration block 1104.

[0107] The calculate acceleration block 1104 calculates the acceleration using the values provided by the mobile post handler block 1102. For example, using a formula such as math.sqrt($Xaccel**2 + $Yaccel**2 + $Zaccel**2), the values 2.4, -1.6, and 1.9 will result in an acceleration value of 3.45. The resulting acceleration value is directed to the pub mobile raw block 1106 and the join mobile block 1108.

[0108] The pub mobile raw block 1106 publishes the acceleration value to a channel named "Pub Mobile Raw." The join mobile block 1108 is able to convert data into a different format. For example, a niogram received from the calculate acceleration block 1 104 may have dynamic fields with values such as { "user": "DDI", "accel": 3.45 }. The join mobile block 1108 may consolidate these into a format such as { "ID1": 3.45 }. The join mobile block 1108 may also combine the data from multiple niograms into a single niogram. For example, if other niograms are received, such as { "user": "IDl", "accel": 1.26 } and { "user": "ID1", "accel": 4.91 }, the join mobile block 1108 is able to combine them into { "IDl": [3.45, 1.26, 4.91] }. Alternatively, the join mobile block 1108 is able to drop one or more values. For example, if the join mobile block 1108 is configured to retain only the most recent value, the values of 3.45 and 1.26 would be dropped and the resulting niogram would include only { "DDI": 4.91 }. [0109] The resulting niogram is directed to the logger block 1110, the mobile socket block 1112, and the pub mobile block 1114. The logger block 1110 writes the values to a log. The mobile socket block 1112 writes the values to a socket IO room named "mobile." The pub mobile block 1114 publishes the niogram to a channel named "Pub Mobile." Note that this is a different channel than the Pub Mobile Raw channel that is used for the calculated acceleration values without the consolidation performed by the join mobile block 1108.

[0110] Referring to FIG. 12, one embodiment of the counter service 1004 is illustrated. In the present example, the counter service 1004 includes multiple blocks, including a sub mobile raw block 1202, a filter shake threshold block 1204, a debounce shakes block 1206, a pub shake block 1208, a global shake counter block 1210, a format shake count block 1212, a shake count socket block 1214, a pub shake count block 1216, an is reset count block 1218, a remove notifications block 1220, a remove signals block 1222, a format shake message block 1224, and a pub notifications block 1226.

[0111] The sub mobile raw block 1202 subscribes to the Mobile Raw channel. The filter shake threshold block 1204 receives an acceleration value from the sub mobile raw block 1202 and determines whether the value exceeds the defined shake threshold. For example, the filter shake threshold block 1204 may perform a calculation such as $accel > SHAKE THRESHOLD. For example, if the SHAKE THRESHOLD is defined as two, only acceleration values above two will register as shakes and lower values are discarded.

[0112] The debounce shakes block 1206 receives the output of the filter shake threshold block 1204 and starts a timer to prevent multiple shakes from the same device from registering too rapidly. For example, filtering by ID with a two second interval would prevent a single device from registering multiple shakes less than two seconds apart. The output of the debounce shakes block 1206 is directed to the pub shake block 1208, the global shake counter block 1210, and the format shake message block 1224.

[0113] The pub shake block 1208 publishes the debounced values to the channel named "Shake." The global shake counter block 1210 increments the total shake count. The output of the global shake counter block 1210 is directed to the format shake count block 1212 and the is reset count block 1218. The format shake count block 1212 formats the cumulative count, with its output directed to the shake count socket block 1214 and pub shake count block 1216. The shake count socket block 1214 streams its output to a socket 10 room named "shake count." The pub shake count block 1216 publishes the count to a channel named "Shake Count."

[0114] The is reset count block 1218 is used to determine whether the global count has been reset. More specifically, the global shake counter block 1210 can be reset using a reset command (e.g., issued via the previously referenced REST API) that sets the count to zero. In the present example, this command can be issued by actuating the reset button 919. The is reset count block filters the output of the global shake counter block 1210 and, if the output is a zero (indicating that the count has been reset), notifies the remove notifications block 1220 and the remove signals block 1222. When notified, the remove notifications block 1220 deletes the notifications from the database, and the remove signals block 1222 removes the values from the database.

[0115] The format shake message block 1224 formats a message with text (e.g., "$ID shake detected"), the acceleration value, and the time. The output is directed to the pub notifications block 1226, which publishes the information to the "Notifications" channel.

[0116] Referring to FIG. 12, one embodiment of the shake alert service 1006 is illustrated. In the present example, the shake alert service 1006 includes multiple blocks, including filter cumulative count blocks 1304, 1310, 1316, and 1322 with count filters of five, ten, twenty, and 30, respectively, a send tweet block 1306, a format tweet message block 1308, a send text block 1312, a format text message block 1314, a send email block 1318, a format email message block 1320, a send voice block 1324, a format voice message block 1326, an add time block 1328, and a pub notifications block 1330.

[0117] The filter cumulative count block 1304 produces output when the cumulative shake count is equal to five. The output is directed to the send tweet block 1306 and the format tweet message block 1308. The send tweet block 1306 sends a tweet via twitter containing a defined message (e.g., "Five shakes have been detected."). The format tweet message block 1308 formats the message that appears in the log pane 910 of FIGS. 9A-9C.

[0118] The filter cumulative count block 1310 produces output when the cumulative shake count is equal to ten. The output is directed to the send text block 1312 and the format text message block 1314. The send text block 1312 sends a text containing a defined message (e.g., "Ten shakes have been detected "). The format text message block 1314 formats the message that appears in the log pane 910 of FIGS. 9A-9C. [0119] The filter cumulative count block 1316 produces output when the cumulative shake count is equal to twenty. The output is directed to the send email block 1318 and the format email message block 1320. The send email block 1318 sends an email containing a defined message (e.g., "Twenty shakes have been detected."). The format email message block 1320 formats the message that appears in the log pane 910 of FIGS. 9A-9C.

[0120] The filter cumulative count block 1322 produces output when the cumulative shake count is equal to thirty. The output is directed to the send voice block 1324 and the format voice message block 1326. The send voice block 1324 places a call containing a defined message (e.g., "Thirty shakes have been detected."). The format voice message block 1326 formats the message that appears in the log pane 910 of FIGS. 9A-9C.

[0121] The outputs of the format tweet message block 1308, format text message block 1314, format email message block 1320, and format voice message block 1326 are directed to the add time block 1328, which timestamps the messages. The output of the add time block 1328 is directed to the pub notifications block 1330, which publishes the message to the "Notifications" channel.

[0122] Referring to FIG. 14, one embodiment of the max force service 1008 is illustrated. In the present example, the max force service 1008 includes multiple blocks, including a sub mobile raw block 1402, a get max force block 1404, a max force reset block 1406, a format max force block 1408, and a max force socket block 1410.

[0123] The sub mobile raw block 1402 subscribes to the Mobile Raw channel. The get max force block 1404 receives the acceleration data and determines whether the acceleration data has a higher value than a current max. The output of the get max force block 1404 is directed to the format max force block 1408, which returns the current max to the get max force block 1404 and also sends the current max to the max force socket block 1410 to stream to a Socket IO room named "max force." The max force reset block 1406 can be reset using the reset button 919, and its output is directed to the get max force block 1404 and format max force block 1408 for calculations after reset occurs.

[0124] Referring to FIG. 15, one embodiment of the DB service 1010 is illustrated. In the present example, the DB service 1010 includes multiple blocks, including a sub mobile block 1502, an add timestamp block 1504, and a DB mobile block 1506. The sub mobile block 1502 subscribes to the Mobile channel. The add timestamp block 1504 adds a timestamp to the data and the DB mobile block 1506 inserts the time stamped data into a database.

[0125] Referring to FIG. 16, one embodiment of the DB size service 1012 is illustrated. In the present example, the DB size service 1012 includes multiple blocks, including a DB stats block 1602, a format DB size block 1604, and a DB size socket block 1606. The DB stats block 1602 queries the DB for the current size. The DB size format block 1604 receives the current size and formats if needed (e.g., converts megabytes to kilobytes). The DB size socket block 1606 streams the size value to a socket IO room named "DB size."

[0126] Referring to FIG. 17, one embodiment of the display service 1014 is illustrated. In the present example, the display service 1014 includes multiple blocks, including a sub shake block 1702, a filter display block 1704, and a post shakes block 1706. The sub shake block 1702 subscribes to the Shake channel. The filter display block 1704 filters the shake data for values higher than a defined threshold (e.g., the threshold of six Gs in FIGS. 9A-9C). The post shakes block 1706 streams any values above the threshold to a display.

[0127] Referring to FIG. 18, one embodiment of the notifications service 1016 is illustrated. In the present example, the notifications service 1016 includes multiple blocks, including a sub notifications block 1802, a mobile notifications block 1804, and a shake log socket block 1806. The sub notifications block 1802 subscribes to the Notifications channel. The mobile notifications block 1804 inserts the data into a database. The shake log socket 1806 streams the data to a socket IO room named "shake log."

[0128] Referring to FIG. 19, a method 1900 illustrates one embodiment of a process that may be executed by the NIO platform 502 of FIG. 5 A. In step 1902, signals are received from a signal source. In step 1904, the signals are processed in real time. In step 1906, output is produced in real time. Each step of the method 1900 may be executed asynchronously on different signals, with a particular step being executed multiple times in parallel depending on the input volume. In this manner, a single instance of the NIO platform 502 can process multiple signals from the signal source using a single chain of services and their corresponding blocks.

[0129] Referring to FIG. 20, a method 2000 illustrates one embodiment of a process that may be used to provide the services needed for the method 1900 of FIG. 19. In step 2002, at least one input service is provided to receive input from a signal source. In step 2004, at least one processing service is provided to process the input in real time. In step 2006, at least one output service is provided to produce output in real time. As described previously, the NIO platform 502 includes a core that will launch the provided services.

[0130] Referring to FIG. 21, a method 2100 illustrates one embodiment of a process that may be used to configure services needed for the method 1900 of FIG. 19. In step 2102, at least one input service is configured to receive input from a signal source. In step 2104, at least one processing service is configured to process the input in real time. In step 2106, at least one output service is configured to produce output in real time.

[0131] Referring to FIG. 22, a method 2200 illustrates one embodiment of a process that may be executed by the NIO platform 502 of FIG. 7 to process sensor information in real time. In step 2202, sensor information is received from a device. In step 2204, an acceleration value is calculated based on the received sensor information. In step 2206, a determination is made in real time as to whether the acceleration value exceeds a defined threshold. If the acceleration value does not exceed the defined threshold, the method 2200 returns to step 2202. If the acceleration value does exceed the defined threshold, the method 2200 continues to step 2208. In step 2208, a defined action is executed in real time. Each step of the method 2200 may be executed asynchronously on different signals, with a particular step being executed multiple times in parallel depending on the input volume.

[0132] Referring to FIG. 23, a method 2300 illustrates one embodiment of a process that may be executed by the NIO platform 502 of FIG. 7 to process sensor information in real time. In step 2302, sensor information is asynchronously obtained from multiple signal sources. In step 2304, an acceleration value is asynchronously calculated for each signal source based on the sensor information received for that source. In step 2306, the acceleration values are asynchronously sent for display after they are calculated.

[0133] Referring to FIG. 24, one embodiment of an environment 2400 is illustrated with the NIO platform 502 of FIG. 5 configured to aggregate signals received from multiple devices 504a-504d. The signals are received via server(s) 702 although, as previously described, the NIO platform 502 may not use or require server(s) 702 and/or 704 in other embodiments. The NIO platform 502 may act on the signals prior to aggregation and/or after aggregation. The signals may be of different types or of the same type. If needed, the NIO platform 502 may convert signals into other signal types prior to aggregation or after aggregation. [0134] In the present example, the server 702 is configured with multiple network addresses, including an address 2402 (also referred to as Address #1) and an address 2404 (also referred to as Address #2). The server 702 is communicating with the devices 504a and 504b using the address 2402 and with the devices 504c and 504d using the address 2404. The addresses 2402 and 2404 are different addresses from the perspective of the devices 504a-504d. For example, the addresses 2402 and 2404 may be different IP addresses or may be the same IP address but different ports. The use of different network addresses provides a way for the NIO platform 502 to distinguish between devices or groups of devices based on which address they are using to connect to the server 702.

[0135] It is understood that in other embodiments a single address may be provided and a different process may be used to distinguish between devices. For example, a device identifier may be used identifying a specific device (e.g., a cookie, a phone number, an electronic serial number (ESN), or an International Mobile Equipment Identity (EVIEI) number). In another example, a selection may be made by the device on a webpage provided by the server 702 that associates the device with a particular group. Accordingly, the NIO platform 502 may use various methods to distinguish between signals received from different devices and/or to associate the signals received from different devices with a particular group.

[0136] Although not shown, incoming signals may be aggregated in a single group in some embodiments. For example, the signals resulting in lines 920 and 924 of FIG. 9C may be combined by the NIO platform 502 and represented using a single line by the GUI 900. Accordingly, it is understood that while the following examples describe aggregating received signals into multiple groups, similar processes may be used to aggregate received signals into a single group.

[0137] Referring to FIGS. 25A-25C, various embodiments of the NIO platform 502 of FIG. 24 are illustrated. There are different ways to configure the NIO platform 502 to handle cases where signals from multiple sources are to be received and aggregated by a single instance of the NIO platform 502 and processed in the same or similar manner. While FIGS. 25A-25C illustrate various configurations of the NIO platform 502 that may be used to handle such situations, it is understood that other configurations may be used.

[0138] For purposes of illustration, the shake detection functionality introduced previously is used. Accordingly, in each of FIGS. 25A-25C, the basic functionality of the NIO platform 502 is illustrated with a data reception/transformation section 2502 that receives sensor information from the devices 504a-504d via the web services server 702, a shake detection section 2504, an aggregation section 2506, and a transformation/delivery section 2508 that delivers processed information to the web services server 704.

[0139] Although the data reception/transformation section 2502, the shake detection section 2504, the aggregation section 2506, and the transformation/delivery section 2508 may be a single service, they will generally be separate services. Furthermore, each of those services may be split into multiple services. For example, if the signals are received at different network addresses, multiple services may be used for the data reception/transformation section 2502, with each service handling a particular address. Relatively complex sections, such as the shake detection section 2504 and the aggregation section 2506, may also be further divided into multiple services that handle various processing tasks. If the outputs are of different types or are intended for different destinations, multiple services may be used for the transformation/delivery section 2508, with each service handling a particular output type or destination.

[0140] Referring specifically to FIG. 25 A, one embodiment of the NIO platform 502 of FIG. 24 is illustrated with a particular configuration. In this configuration, the NIO platform 502 is configured with a single data reception/transformation section 2502, shake detection section 2504, aggregation section 2506, and transformation/delivery section 2508. This configuration may be used, for example, for treating all incoming signals as part of a single group for purposes of aggregation. In other embodiments, signals may be aggregated into different groups using one or more identifiers.

[0141] Referring specifically to FIG. 25B, one embodiment of the NIO platform 502 of FIG. 24 is illustrated with an alternate configuration. In this configuration, the NIO platform 502 is configured to provide separate data reception/transformation sections 2502a and 2502b that are associated with Address #1 and Address #2, respectively. The data reception/transformation sections 2502a and 2502b feed into separate shake detection sections 2504a and 2504b, respectively. Both shake detection sections 2504a and 2504b then feed into a single aggregation section 2506, which may aggregate the signals from the data reception/transformation sections 2502a and 2502b separately or together. The aggregation section 2506 feeds into the transformation/delivery section 2508. [0142] Referring specifically to FIG. 25C, one embodiment of the NIO platform 502 of FIG. 24 is illustrated with an alternate configuration. In this configuration, the NIO platform 502 is configured to provide separate data reception/transformation sections 2502a and 2502b that are associated with Address #1 and Address #2, respectively. The data reception/transformation sections 2502a and 2502b feed into separate shake detection sections 2504a and 2504b, respectively. Both shake detection sections 2504a and 2504b then feed into separate aggregation sections 2506a and 2506b, respectively. The aggregation sections 2506a and 2506b feed into the transformation/delivery section 2508.

[0143] Referring to FIG. 26, one embodiment of a graph 2600 includes panes 2602 and 2604. The graph 2600 may be part of a GUI such as the GUI 900 of FIG. 9A. In the present example, the graph 2600 is intended to display decibel information that is a real time representation of detected shakes. Accordingly, the graph 2600 includes a y-axis 2606 representing decibels, an x-axis 2608 that corresponds to the pane 2602 and represents time, and an x-axis 2610 that corresponds to the pane 2604 and represents the same time frame as that of the x-axis 2608.

[0144] For purposes of example, the pane 2602 illustrates sensor information received via Address #1 with a line 2612 and the pane 2604 illustrates sensor information received via Address #2 with a line 2614. The lines 2612 and 2614 are created when the NIO platform 262 receives sensor information and processes that information in real time to convert the sensor information into decibel values. This enables acceleration information to be used to represent a noise level. It is understood that the relationship between the acceleration information and noise level can be calculated in many different ways. Furthermore, it is understood that other types of sensor information can be used as an alternative to, or in addition to, the acceleration information, and other types of outputs may be calculated and represented via the graph 2600 and/or other appropriate output processes.

[0145] For purposes of illustration, the panes 2602 and 2604 represent different teams or contestants. Supporters of one team or contestant can log into the web services server at Address #1 with their devices and supporters of the other team or contestant can log into the web services server at Address #2 with their devices. By shaking their respective devices or otherwise creating acceleration, each supporter can "cheer" for their team or contestant. The NIO platform 262 determines whether a device has simply moved or has been shaken to indicate a cheer, aggregates any cheers with other supporters' cheers in real time, and produces output that is used to illustrate the aggregate totals via the lines 2612 and 2614.

[0146] As illustrated, the line 2612 begins at time tl and ends at time t2, indicating the time during which sensor data representing shakes has been received at Address #1 (e.g., when the users of devices logged into Address #1 are "cheering"). The line 2614 begins at time tO and continues to the present time tcurrent, indicating the time during which sensor data representing shakes has been received at Address #2 (e.g., when the users of devices logged into Address #2 are "cheering"). It is noted that the dips in line 2614 correspond loosely to the peaks in line 2612 and vice versa, which may be thought of as correlating to the back and forth cheering that frequently occurs during a competition as the advantage changes from one side to the other and back again.

[0147] Referring to FIG. 27, one embodiment of the NIO platform 502 is illustrated with specific services for implementing various functions for shake detection and aggregation and for producing outputs based on the aggregation. The configuration includes a mobile service 2702, a counter service 2704, an aggregate service 2706, and a display service 2706. Various publication channels and/or other outputs are shown below their respective services, and channel subscriptions are shown above their respective services where applicable. Although not shown, the configuration may include some or all of the services and service interactions of FIG. 10, including the ability to send information to various socket IO rooms used to populate the GUI 900 of FIG. 9 with aggregation information for the graph 2600.

[0148] The mobile service 2702 handles input (e.g., acceleration data) from the devices 504a-504d, calculates acceleration, and publishes to one or more channels for consumption by other services. The counter service 2704 subscribes to a publication channel used by the mobile service 2702 and detects whether a calculated acceleration value is considered a "shake" and publishes any detected shakes to one or more channels for consumption by other services. The aggregation service 2706 subscribes to a publication channel used by the counter service 2704 and converts the shakes into decibels, aggregates them, and publishes the decibels to one or more channels for consumption by other services. The display service 2708 subscribes to a publication channel used by the aggregation service 2706 and sends the decibels to be displayed on a display. [0149] The mobile service 2702 and the display service 2708 have been discussed previously and are not described in detail in the present embodiment. It is understood that the mobile service 2702 and the display service 2708 have been simplified for the present embodiment as illustrated by the reduced number of publication and subscription channels present in FIG. 27.

[0150] Referring to FIG. 28, one embodiment of the counter service 2704 is illustrated. In the present example, the counter service 2704 is a simpler example of the counter service 1004 of FIG. 10 and includes multiple blocks, including a sub mobile raw block 2802, a normalize block 2804, a filter shake threshold block 2806, and a pub shake block 2808.

[0151] The sub mobile raw block 2802 subscribes to the Mobile Raw channel of the mobile service 2702. The normalize block 2804 normalizes the received acceleration values if needed to adjust for different devices, different sensor types, and/or other differences. The filter shake threshold block 2806 receives an acceleration value from the normalize block 2804 and determines whether the value exceeds the defined shake threshold. Any values that do not exceed the defined shake threshold are discarded and any values that do exceed the defined shake threshold are passed to the next block. The pub shake block 2808 publishes the values to the channel named "Shake."

[0152] Referring to FIG. 29, one embodiment of the aggregation service 2706 is illustrated. In the present example, the aggregation service 2706 includes multiple blocks, including a sub shake 2902, a convert to decibels block 2904, an aggregate block 2906, and a pub aggregate block 2908. The sub shake block 2902 subscribes to the Shake channel of the counter service 2704. The convert to decibels block 2904 converts a received shake to a decibel value. The aggregate block 2906 aggregates the decibel value with other corresponding decibel values. The pub aggregate block 2908 publishes the values to a channel named "Aggregate."

[0153] Referring to FIG. 30, a method 3000 illustrates one embodiment of a process that may be executed by the NIO platform 502 of FIG. 24. The method 3000 enables the NIO platform 502 to receive and process signals (e.g., sensor information) in real time. The processing may include normalization, conversion of the signals into other signal types, and/or aggregation of signals from multiple devices. The method 3000 illustrates the processing of information as the information is received from a single device. [0154] In step 3002, sensor information is received from a device, either directly or through an intermediary such as the web services server 702 of FIG. 24. In step 3004, at least one value is calculated using the sensor information. In step 3006, the value is normalized if needed. For example, if sensor information from a particular device is defined as the baseline and the received sensor information is from such a device, the sensor information would not need to be normalized. If the received sensor information is not from the baseline device, the sensor information may be normalized. It is understood that any defined parameter or set of parameters may be used to normalize the sensor information. Furthermore, while the calculated value is normalized in the present embodiment, the normalization may be performed on the obtained sensor information prior to the calculations of step 3004 or later in the method 3000 in other embodiments.

[0155] In step 3008, a determination is made as to whether the value satisfies one or more defined parameters. If the value does not satisfy the defined parameters, the method 3000 moves to step 3010 and discards the value. The method 3000 then returns to step 3002 to process the next received sensor information. If the value does satisfy the defined parameters, the method 3000 continues to step 3012. In step 3012, the value is converted into another type of value if needed.

[0156] In step 3014, at least one of the original or converted values is aggregated with values (if available) from other devices to create one or more aggregate values. It is understood that aggregating the value with values from other devices requires that such values from other devices are available. If such values from other devices are not available, such aggregation would not occur and the value may be passed on by itself. In step 3016, one or more defined actions are executed in real time based on the aggregate value.

[0157] Referring to FIG. 31, a method 3100 illustrates one embodiment of a process that may be executed by the NIO platform 502 of FIG. 24 to process acceleration information and convert that information for output in real time. In step 3102, sensor readings are obtained from a mobile device in real time. In the present example, the sensor readings represent acceleration information. In step 3104, an acceleration value is calculated using the sensor readings. In step 3106, a determination may be made as to whether the acceleration value exceeds a defined acceleration threshold. If the acceleration value does not exceed the acceleration threshold, the method 3100 returns to step 3102 to process the next received sensor readings. If the acceleration value does exceed the threshold, the method 3100 continues to step 3108. In step 3108, the acceleration value is converted into a decibel value. In step 3110, the decibel value is output.

[0158] Referring to FIG. 32, a method 3200 illustrates one embodiment of a process that provides a more detailed example of obtaining a value for use in step 3104 of FIG. 31. In step 3202, multiple readings are obtained from a mobile device. In step 3204, a particular reading is selected from the multiple readings. The particular reading may be selected in many ways, such as selecting the highest reading or the most recent reading. In step 3206, the selected reading is used to calculate the acceleration value.

[0159] Referring to FIG. 33, a method 3300 illustrates one embodiment of a process that provides a more detailed example of obtaining a value for use in step 3104 of FIG. 31. In step 3302, multiple readings are obtained from a mobile device. In step 3304, some or all of the readings are averaged to produce an average value. In step 3306, the average value is used to calculate the acceleration value.

[0160] Referring to FIG. 34, a method 3400 illustrates one embodiment of a process that may be executed by the NIO platform 502 of FIG. 24. The method 3400 is a more specific example of the method 3000 of FIG. 30 with the NIO platform 502 configured to receive and process acceleration information in real time. The processing includes normalization, conversion of the signals into other signal types, aggregation of signals from multiple devices. The method 3400 illustrates the processing of information as the information is received from a single device.

[0161] In step 3402, acceleration information is received from a mobile device, either directly or through an intermediary such as the web services server 702 of FIG. 24. In step 3404, some or all of the acceleration information is used to calculate an acceleration value. In step 3406, the acceleration value is normalized if needed. In step 3408, a determination is made as to whether the acceleration value exceeds a defined acceleration threshold. If the acceleration value does not exceed the acceleration threshold, the method 3400 moves to step 3410 and discards the acceleration value. The method 3400 then returns to step 3402 to process the next received acceleration information. If the acceleration value does exceed the acceleration threshold, the method 3400 continues to step 3412. In step 3412, the acceleration value is converted into a decibel value. In step 3414, the decibel value is aggregated with other decibel values (if available) from other devices to create an aggregate value. In step 3416, the aggregate value is sent for display.

[0162] While the preceding description shows and describes one or more embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the present disclosure. For example, various steps illustrated within a particular flow chart may be combined or further divided. In addition, steps described in one diagram or flow chart may be incorporated into another diagram or flow chart. Furthermore, the described functionality may be provided by hardware and/or software, and may be distributed or combined into a single platform. Additionally, functionality described in a particular example may be achieved in a manner different than that illustrated, but is still encompassed within the present disclosure. Therefore, the claims should be interpreted in a broad manner, consistent with the present disclosure.

[0163] For example, in one embodiment, a system for processing a plurality of sensor readings in real time includes a processor; a memory coupled to the processor; and a plurality of instructions stored in the memory for execution by the processor for a platform instance having a core configured to interact with an operating system, wherein the core is configured to run at least a first service that is configured to run a plurality of blocks, wherein each block operates independently from the other blocks in an asynchronous manner and includes a set of platform specific instructions that enable the block to operate within the platform instance and a set of task specific instructions that enable the block to perform a specific task, and wherein the plurality of blocks are configured with task specific instructions for: receiving a plurality of sensor readings from a plurality of devices; calculating, for each of the devices, a value based on the sensor readings received from the device for which the value is being calculated; identifying each of the values that meets at least one defined parameter; aggregating all of the values that meet the defined parameter to form an aggregate value; and executing a defined action based on the aggregate value, wherein the steps of receiving, calculating, identifying, aggregating, and executing occur in real time without storing the sensor readings, the values, or the aggregate value.

[0164] In some embodiments, the steps of receiving, calculating, and identifying occur asynchronously for each of the devices. [0165] In some embodiments, the task specific instructions further include repeatedly performing the steps of receiving, calculating, identifying, aggregating, and executing.

[0166] In some embodiments, the task specific instructions further include: determining, for each of the sensor readings, whether the sensor reading needs to be normalized; and normalizing the sensor reading if the sensor reading needs to be normalized.

[0167] In some embodiments, the system may further include at least one web service, wherein the web service is configured to obtain the sensor readings via an application programming interface (API) provided by each of the devices.

[0168] In some embodiments, the web service is not part of the platform instance.

[0169] In some embodiments, the web service is part of the platform instance.

[0170] In some embodiments, the platform instance is configured to run the web service as a second service simultaneously with the first service.

[0171] In some embodiments, the platform instance is configured to run the web service as part of the first service.

[0172] In some embodiments, the at least one web service provides a first network address and a second network address, and each of the devices can log into either of the first and second network addresses.

[0173] In some embodiments, the at least one defined parameter includes a first parameter representing the first network address and a second parameter representing the second network address.

[0174] In some embodiments, the at least one defined parameter includes a third parameter representing a threshold for the sensor readings.

[0175] In another embodiment, a method for processing sensor data in real time includes receiving a plurality of sensor readings from a plurality of devices; calculating, for each device, a value based on the sensor readings received from the device for which the value is being calculated; identifying each of the values that satisfies at least one defined parameter; aggregating all of the values that satisfy the defined parameter to form an aggregate value; and executing a defined action based on the aggregate value, wherein the steps of receiving, calculating, identifying, aggregating, and producing occur in real time without storing the sensor readings, the values, or the aggregate value. [0176] In some embodiments, the steps of receiving, calculating, and identifying occur asynchronously for each of the devices.

[0177] In some embodiments, the method further includes repeatedly performing the steps of receiving, calculating, identifying, aggregating, and executing.

[0178] In some embodiments, the method further includes determining, for each of the sensor readings, whether the sensor reading needs to be normalized; and normalizing the sensor reading if the sensor reading needs to be normalized.

[0179] In some embodiments, the method further includes providing at least one web service, wherein the sensor readings are obtained by the web service via an application programming interface (API) provided by each of the devices.

[0180] In some embodiments, the at least one defined parameter represents a threshold for the sensor readings.

[0181] In another embodiment, a system for processing a plurality of sensor readings in real time includes a platform instance having a core configured to interact with an operating system, wherein the core is configured to run at least a first service that is configured to run a plurality of blocks, wherein each block operates independently from the other blocks in an asynchronous manner and includes a set of platform specific instructions that enable the block to operate within the platform instance and a set of task specific instructions that enable the block to perform a specific task, and wherein the plurality of blocks are configured with task specific instructions for: receiving a plurality of sensor readings from a plurality of devices; calculating, for each device, a value based on the sensor readings received from the device for which the value is being calculated; determining whether each value passes a threshold test, wherein values that do not pass the threshold test are discarded; assigning each value that passes the threshold test to one of a plurality of value sets; aggregating, for each value set, all of the values assigned to the value set; and executing a defined action for each of the value sets, wherein the steps of receiving, calculating, determining, assigning, aggregating, and executing occur in real time without storing the sensor readings, the values, or the aggregated value.

[0182] In some embodiments, the sensor readings for each device are obtained via one of a plurality of network addresses and wherein each of the value sets represents a different one of the plurality of network addresses.

[0183] In some embodiments, each of the values is an acceleration value. [0184] In some embodiments, the task specific instructions further include converting each acceleration value that passes the threshold test into a decibel value.

[0185] In some embodiments, the devices are mobile devices.

[0186] In some embodiments, the sensor readings are obtained via an application programming interface (API) provided by each of the devices.

[0187] In another embodiment, a system for processing a plurality of sensor readings in real time includes a computing environment with an operating system running thereon; and a configurable platform instance having a core that is configured to interact with the operating system, wherein the core is configured to run at least a first service that is configured to run a plurality of blocks, wherein each block operates independently from the other blocks in an asynchronous manner and includes a set of platform specific instructions that enable the block to operate within the platform instance and a set of task specific instructions that enable the block to perform a specific task within the platform instance, and wherein the plurality of blocks are configured with task specific instructions for: receiving a plurality of sensor readings from at least one sensor of a device; calculating an acceleration value of the device using the sensor readings; determining whether the acceleration value exceeds a defined threshold; and executing a defined action only if the acceleration value exceeds the defined threshold, wherein the steps of receiving, calculating, determining, and executing occur in real time without storing the sensor readings or the acceleration value.

[0188] In some embodiments, the system further includes a web service, wherein the web service is configured to obtain the plurality of sensor readings from the at least one sensor of the device via an application programming interface (API) of the device.

[0189] In some embodiments, the web service is not part of the platform instance.

[0190] In some embodiments, the web service is part of the platform instance.

[0191] In some embodiments, the platform instance is configured to run the web service as a second service simultaneously with the first service.

[0192] In some embodiments, the platform instance is configured to run the web service as part of the first service.

[0193] In some embodiments, the task specific instructions further include sending the acceleration value for display on a viewing screen. [0194] In some embodiments, the task specific instructions further include storing at least one of the sensor readings and the acceleration value.

[0195] In some embodiments, the defined action includes initiating a communication.

[0196] In some embodiments, the defined action includes actuating a remote device.

[0197] In some embodiments, the task specific instructions further include converting the acceleration value to a decibel value.

[0198] In some embodiments, the defined action includes sending the decibel value for display on a viewing screen.

[0199] In some embodiments, the task specific instructions further include: detecting a type of mobile device; and normalizing the sensor readings based on the type of mobile device.

[0200] In some embodiments, the task specific instructions further include placing the sensor readings into an internal data structure used by the platform instance before the calculating, determining, and executing are performed.

[0201] In some embodiments, the device is a mobile device.

[0202] In some embodiments, the computing environment includes at least one server.

[0203] In some embodiments, the computing environment is running on the device.

[0204] In another embodiment, a method for obtaining and processing sensor data in real time includes receiving, by a configurable platform instance operating within a computing environment, a plurality of sensor readings from at least one sensor of a device, wherein the sensor readings are obtained via an application programming interface (API) of the device; calculating, by the platform instance, an acceleration value of the device using the sensor readings; determining, by the platform instance, whether the acceleration value exceeds a defined threshold; and executing, by the platform instance, a defined action only if the acceleration value exceeds the defined threshold, wherein the platform instance uses a plurality of blocks to perform the receiving, calculating, determining, and executing occur in real time without storing the sensor readings or the acceleration value, and wherein the plurality of blocks are managed by at least one service running on the platform instance.

[0205] In some embodiments, the method further includes sending, by the platform instance, the acceleration value for display on a viewing screen.

[0206] In some embodiments, the method further includes storing, by the platform instance, at least one of the sensor readings and the acceleration value. [0207] In some embodiments, the defined action includes initiating a communication.

[0208] In some embodiments, the defined action includes actuating a remote device.

[0209] In some embodiments, the method further includes converting, by the platform instance, the acceleration value to a decibel value.

[0210] In some embodiments, the defined action includes sending the decibel value for display on a viewing screen.

[0211] In some embodiments, the method further includes: detecting, by the platform instance, a type of the device; and normalizing, by the platform instance, the sensor readings based on the type of the device.

[0212] In another embodiment, a method for processing a plurality of sensor readings in real time includes providing a platform instance having at least one service running a plurality of blocks, wherein each block operates independently from the other blocks in an asynchronous manner, and wherein each block includes a set of platform specific instructions that enable the block to operate within the platform instance and a set of task specific instructions that enable the block to perform a specific task; obtaining, by a web service residing on a web server, a plurality of sensor readings from at least one sensor of a device, wherein the sensor readings are obtained by the web service via an application programming interface (API) of the device; streaming, by the web service, the sensor readings to the at least one service; calculating, by the at least one service, an acceleration value of the device based on the sensor readings; determining, by the at least one service, an action to be taken based on the acceleration value; and taking, by the at least one service, the action, wherein the obtaining, streaming, calculating, determining, and taking occur in real time.

[0213] In another embodiment, a device includes a processor; and a memory coupled to the processor and containing instructions for execution by the processor, the instructions for: running a configurable platform instance that is stored in the memory and interacts with an operating system that is controlling the device; receiving, by the platform instance, a plurality of sensor readings from at least one sensor; calculating, by the platform instance, an acceleration value using the sensor readings; determining, by the platform instance, whether the acceleration value exceeds a defined threshold; and executing, by the platform instance, a defined action if the acceleration value exceeds the defined threshold, wherein the platform instance uses a plurality of blocks to perform the receiving, calculating, determining, and executing occur in real time without storing the sensor readings or the acceleration value, and wherein the plurality of blocks are managed by at least one service running on the platform instance.

[0214] In some embodiments, the instructions further comprise sending, by the platform instance, the acceleration value for display on a viewing screen.

[0215] In some embodiments, the instructions further comprise storing, by the platform instance, at least one of the sensor readings and the acceleration value.

[0216] In some embodiments, the defined action includes initiating a communication.

[0217] In some embodiments, the defined action includes actuating a remote device.

[0218] In some embodiments, the instructions further comprise converting, by the platform instance, the acceleration value to a decibel value.

[0219] In some embodiments, the defined action includes sending the decibel value for display on a viewing screen.

[0220] In some embodiments, the instructions further comprise: detecting, by the platform instance, a type of the at least one sensor; and normalizing, by the platform instance, the sensor readings based on the type.

[0221] In some embodiments, the at least one sensor is located on the device.

[0222] In some embodiments, the at least one sensor is external to the device.

[0223] In another embodiment, a device includes a processor; and a memory coupled to the processor and containing instructions for execution by the processor, the instructions for: running a configurable platform instance that is stored in the memory and interacts with an operating system that is controlling the device, wherein the platform instance has at least one service running a plurality of blocks, wherein each block operates independently from the other blocks in an asynchronous manner, and wherein each block includes a set of platform specific instructions that enable the block to operate within the platform instance and a set of task specific instructions that enable the block to perform a specific task; obtaining, by a web service residing on a web server, a plurality of sensor readings from at least one sensor; streaming, by the web service, the sensor readings to the at least one service; calculating, by the at least one service, an acceleration value based on the sensor readings; determining, by the at least one service, an action to be taken based on the acceleration value; and taking, by the at least one service, the action, wherein the obtaining, streaming, calculating, determining, and taking occur in real time.

[0224] In some embodiments, the at least one sensor is located on the device. [0225] In some embodiments, the sensor readings are obtained by the web service via an application programming interface (API) of the device.

[0226] In some embodiments, the at least one sensor is external to the device.

[0227] In some embodiments, the web server is provided as a service running on the platform instance.

Claims

WHAT IS CLAIMED IS:

1. A system for processing a plurality of sensor readings from multiple devices in real time, the system characterized by:

a processor;

a memory coupled to the processor; and

a plurality of instructions stored in the memory for execution by the processor for

a platform instance having a core configured to interact with an operating system, wherein the core is configured to run at least a first service that is configured to run a plurality of blocks, wherein each block operates independently from the other blocks in an asynchronous manner and includes a set of platform specific instructions that enable the block to operate within the platform instance and a set of task specific instructions that enable the block to perform a specific task, and wherein the plurality of blocks are configured with task specific instructions for:

receiving a plurality of sensor readings from a plurality of devices;

calculating, for each of the devices, a value based on the sensor readings received from the device for which the value is being calculated;

identifying each of the values that meets at least one defined parameter; aggregating all of the values that meet the defined parameter to form an aggregate value; and

executing a defined action based on the aggregate value, wherein the steps of receiving, calculating, identifying, aggregating, and executing occur in real time without storing the sensor readings, the values, or the aggregate value.

2. The system of claim 1 wherein the steps of receiving, calculating, and identifying occur asynchronously for each of the devices.

3. The system of any one of claims 1 or 2 wherein the task specific instructions further include repeatedly performing the steps of receiving, calculating, identifying, aggregating, and executing.

4. The system of any one of claims 1 through 3 wherein the task specific instructions further include:

determining, for each of the sensor readings, whether the sensor reading needs to be normalized; and

normalizing the sensor reading if the sensor reading needs to be normalized.

5. The system of any one of claims 1 through 4 further characterized by at least one web service, wherein the web service is configured to obtain the sensor readings via an application programming interface (API) provided by each of the devices.

6. The system of claim 5 wherein the web service is not part of the platform instance.

7. The system of claim 5 wherein the web service is part of the platform instance.

8. The system of claim 7 wherein the platform instance is configured to run the web service as a second service simultaneously with the first service.

9. The system of claim 7 wherein the platform instance is configured to run the web service as part of the first service.

10. The system of claim 5 wherein the at least one web service provides a first network address and a second network address, and wherein each of the devices can log into either of the first and second network addresses.

11. The system of claim 10 wherein the at least one defined parameter includes a first parameter representing the first network address and a second parameter representing the second network address.

12. The system of claim 11 wherein the at least one defined parameter includes a third parameter representing a threshold for the sensor readings.

13. A method for processing sensor data in real time, the method characterized by:

receiving a plurality of sensor readings from a plurality of devices;

calculating, for each device, a value based on the sensor readings received from the device for which the value is being calculated;

identifying each of the values that satisfies at least one defined parameter;

aggregating all of the values that satisfy the defined parameter to form an aggregate value; and

executing a defined action based on the aggregate value, wherein the steps of receiving, calculating, identifying, aggregating, and producing occur in real time without storing the sensor readings, the values, or the aggregate value.

14. The method of claim 13 wherein the steps of receiving, calculating, and identifying occur asynchronously for each of the devices.

15. The method of any one of claims 13 or 14 further characterized by repeatedly performing the steps of receiving, calculating, identifying, aggregating, and executing.

16. The method of any one of claims 13 through 15 further characterized by:

normalizing the sensor reading if the sensor reading needs to be normalized.

17. The method of any one of claims 13 through 16 further characterized by providing at least one web service, wherein the sensor readings are obtained by the web service via an application programming interface (API) provided by each of the devices.

18. The method of any one of claims 13 through 17 wherein the at least one defined parameter represents a threshold for the sensor readings.