JP2015507774A - Sensor API framework for cloud-based applications - Google Patents

Abstract

An apparatus and method for a framework that applies an API (Application Programming Interface) to a web-based server application on the Internet or in the cloud is presented. This API allows server applications to retrieve sensor data from a mobile device via a low power sensor core processor on the mobile device. This API eliminates the effort and costs associated with developing and facilitating new mobile device client applications. This API framework includes APIs that web-based applications can use to fetch sensor data from one or more specific sensors on a mobile device.

Description

Cross-reference of related applications This application is entitled “Sensor API Framework for Cloud Based Applications” filed on November 9, 2011, assigned to the assignee of the present application and incorporated herein by reference in its entirety. We claim the benefit of US Patent Application No. 13 / 292,578 and the priority to it.

  The present disclosure relates generally to apparatus and methods for wireless communication, and more particularly to providing sensor data from a mobile device to a plurality of web-based applications.

  A web-based application, sometimes referred to as a server application that currently requests sensor data from a mobile device, has a corresponding client application running on the mobile device. Some of these client applications run continuously on the mobile device. Such client applications on mobile devices are becoming increasingly popular as a wide range of sensors are embedded in mobile devices and are of increasing public interest to leverage sensor data in innovative ways. Usage is increasing. These multiple client applications are from different sources and are communicating with different servers, each of which can consume a large amount of power and processing cycles from the mobile device. Unless these multiple client applications are from a common vendor, they do not cooperate with each other as a whole and query the sensors randomly and redundantly. Even if a single coordinated response is sufficient, the sensor may be interrupted by duplicate requests. In addition, web developers and researchers interested in mobile sensor data must write a single client application for each server application and for each mobile device platform, which increases development costs and development time. Becomes longer. From the user's point of view, it is necessary for the user to install multiple client applications for each of the different servers that require sensor data and to recharge the battery more frequently.

  Thus, reducing the number of client applications running on mobile devices, coordinating sensor requests, minimizing or eliminating code development on mobile device platforms, and / or providing sensor data to server applications There should be a platform that reduces power consumption.

  Provides a common API (application programming interface) that couples sensor data from one or more sensors to multiple server applications via a low duty cycle processor, thereby reducing the load on high power consumption application processors Disclosed are mobile devices and methods of operation on mobile devices.

  In accordance with some aspects, a mobile device for providing a common API (Application Programming Interface), a modem coupled to a wireless antenna, and a first power level coupled to the modem for a certain duration. A consuming client application processor, comprising a sensor core client and a sensor driver coupled to the sensor core client, consuming a second power level for the duration, and the second level being lower than the first power level A mobile device comprising a sensor core processor coupled to a modem and comprising a common API and a sensor coupled to communicate with a sensor driver of the sensor core processor is disclosed.

  According to some aspects, a method for providing a common API (Application Programming Interface) on a mobile device, wherein a first request for sensor data is received from a first web-based server application using a common API. Receiving a second request for sensor data using a common API from a second web-based server application unrelated to the first web-based server application; and a second for sensor data on the sensor core processor; Processing a request and a second request and bypassing the client application processor; receiving at a sensor core processor sensor data from a sensor; and a first response including sensor data in the first request It discloses a step of trust, a step of returning a different second response to the first request including the sensor data to the second request for sensor data, the method comprising.

  In accordance with some aspects, a mobile device for providing a common API (Application Programming Interface) 170 for receiving a first request for sensor data using a common API from a first web-based server application Means for receiving a second request for sensor data using a common API from a second web-based server application unrelated to the first web-based server application, and a sensor on the sensor core processor Means for processing the first and second requests for data and bypassing the client application processor; means for receiving sensor data from the sensor in the sensor core processor; and sensor data in the first request Return with first response containing And means for, the first request including the sensor data to the second request for sensor data discloses a mobile device and means for replying with a different second response.

  According to some aspects, a device comprising a processor and a memory, the memory comprising software instructions for receiving a first request for sensor data using a common API from a first web-based server application. Software instructions for receiving a second request for sensor data using a common API from a second web-based server application unrelated to the first web-based server application, and for sensor data on the sensor core processor Software instructions for processing the first and second requests and bypassing the client application processor, software instructions for receiving sensor data from the sensor in the sensor core processor, and sensor data in the first request Include Disclosed is a device that includes software instructions for replying with a response of 1 and software instructions for replying with a second response that is separate from the first request that includes sensor data in a second request for sensor data To do.

  In accordance with some aspects, a non-transient computer readable storage medium having program code stored thereon, the first request for sensor data using a common API from a first web-based server application A program code for receiving a second request for sensor data using a common API from a second web-based server application unrelated to the first web-based server application, and a sensor Program code for processing the first and second requests for sensor data on the core processor and bypassing the client application processor; program code for receiving sensor data from the sensor in the sensor core processor; 1 Program code for replying to the request with the first response including the sensor data, and replying with the second response different from the first request including the sensor data to the second request for the sensor data A non-transient computer readable storage medium comprising program code is disclosed.

  Other aspects will be readily apparent to those skilled in the art from the following detailed description, wherein the various aspects are shown and described by way of illustration. The drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

  Embodiments of the present invention will be described by way of example only with reference to the drawings.

FIG. 1 illustrates components of a known system that includes a server application running in the cloud and a dedicated client application running on the client application processor of the mobile device. FIG. 2 illustrates components of a mobile device that provides sensor data via a client application processor. FIG. 3 illustrates components of a mobile device that uses a sensor core processor and bypasses a client application processor to provide sensor data in accordance with some embodiments of the present invention. FIG. 4 illustrates an API framework according to some embodiments of the present invention. FIG. 2 illustrates components of a system including a server application operating in the cloud and a dedicated sensor core client operating on the sensor core processor of the mobile device. FIG. 4 illustrates various API messages according to some embodiments of the present invention. FIG. 4 shows a flow diagram according to some embodiments of the invention.

  The detailed description presented below in connection with the appended drawings is intended as a description of various aspects related to the present disclosure and is not intended to represent the only aspects by which the present disclosure may be practiced. Absent. Each aspect described in this disclosure is provided merely as an example or as an example of this disclosure, and should not necessarily be construed as preferred or advantageous over other aspects. This detailed description includes specific details for the purpose of providing a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the present disclosure. Acronyms and other descriptive terms may be used merely for convenience and clarity, but these are not intended to limit the scope of the present disclosure.

  The mobile devices described herein may be implemented in conjunction with various wireless communication networks such as a wireless wide area network (WWAN), a wireless local area network (WLAN), a wireless personal area network (WPAN), and so on. The terms “network” and “system” are often used interchangeably. WWAN includes code division multiple access (CDMA) networks, time division multiple access (TDMA) networks, frequency division multiple access (FDMA) networks, orthogonal frequency division multiple access (OFDMA) networks, single carrier frequency division multiple access (SC-FDMA). ) Network, Long Term Evolution (LTE), etc. A CDMA network may implement one or more radio access technologies (RAT) such as cdma2000, wideband CDMA (W-CDMA), and so on. cdma2000 includes IS-95, IS-2000 and IS-856 standards. A TDMA network may implement Global System for Mobile Communications (GSM), Digital Advanced Mobile Phone System (D-AMPS), or some other RAT. GSM and W-CDMA are documented by a consortium named “3rd Generation Partnership Project” (3GPP). cdma2000 is described in a document by a consortium named “3rd Generation Partnership Project 2” (3GPP2). 3GPP and 3GPP2 documents are publicly available. The WLAN may be an IEEE 802.11x network, and the WPAN may be a Bluetooth® network, IEEE 802.11x, or some other type of network. These techniques may also be implemented in conjunction with some combination of WWAN, WLAN and / or WPAN.

  A satellite positioning system (SPS) is typically a transmitter arranged to allow an entity to determine its location on the surface of the earth or over the earth based at least in part on the signal received from the transmitter. Including systems. Such transmitters typically transmit signals that are marked with a repetitive pseudo-random noise (PN) code of a specified number of chips and that are transmitted to ground control stations, user equipment and / or spacecraft. May be placed. In one particular example, such a transmitter may be placed on a satellite vehicle (SV) that orbits the earth. SV within a Global Navigation Satellite System (GNSS) population such as Global Positioning System (GPS), Galileo, GLONASS or Compass (for example, using a different PN code for each satellite, such as GPS, or Signals marked with a PN code distinguishable from other SVs transmitted by other SVs in the population (using the same code at different frequencies as in GLONASS) may be transmitted. The techniques presented herein in accordance with certain aspects are not limited to global systems for SPS (eg, GNSS). For example, the techniques provided herein include various regional systems such as the Quasi-Zenith Satellite System (QZSS) over Japan, the Indian Regional Navigation Satellite System (IRNSS) over India, Beidou over China, and / or one or Applicable to various augmentation systems (e.g., satellite-type augmentation system (SBAS)) that may be associated with or otherwise enabled with multiple global and / or regional navigation satellite systems Can be used in By way of example and not limitation, SBAS may include, for example, wide area augmentation system (WAAS), European geostationary satellite navigation augmentation service (EGNOS), multipurpose satellite augmentation system (MSAS), GPS geostationary supplementary navigation or GPS and Geo complementary navigation system (GAGAN), etc. And / or such reinforcement systems that provide integrity information, differential correction, and the like. Thus, as used herein, an SPS may include one or more global and / or regional navigation satellite systems and / or augmentation systems in any combination, and an SPS signal may be an SPS signal, an SPS-like signal, and Other signals associated with one or more such SPS may be included.

  As used herein, mobile device 100 is sometimes referred to as a mobile phone, mobile phone or other wireless communication device, personal communication system (PCS) device, personal navigation device (PND), personal information management (PIM), personal digital Refers to a mobile station (MS) or user equipment (UE) capable of receiving wireless communications and / or navigation signals such as an assistant (PDA), laptop or other suitable mobile device. The term “mobile station” is also a device that communicates with a personal navigation device (PND), such as a short-range wireless connection, an infrared connection, a wired connection or other connection, that is satellite signal reception performed in that device or PND Or assistance data reception and / or location related processing). In addition, a “mobile station” may be a satellite signal reception or an assistance that is performed on the device, in a server or in another device related to the network, via the Internet, WiFi (registered trademark) or other network. It is intended to include all devices, including wireless communication devices, computers, laptops, etc., capable of communicating with a server, whether data reception and / or location related processing. Any operable combination of the above is also considered a mobile device 100.

  Cloud 300, which may be the public Internet or the private Internet, may be accessed through a wireless base station or access point that has an Internet gateway. The base station provides Internet access through its data service provision. Similarly, the access point provides Internet access via a WiFi signal.

  A framework for applying an API (Application Programming Interface) to the web-based server application 200 on the Internet or in the cloud 300 is presented. This API allows the server application 200 to retrieve sensor data from the mobile device 100 via the low power sensor core processor on the mobile device 100. This API eliminates the effort and costs associated with developing and facilitating new mobile device client applications. This API framework includes APIs that can use web-based applications to fetch sensor data from one or more specific sensors on the mobile device 100.

  Instead of a web-based application sending a request for sensor data from one or more specified sensors on the mobile device 100, the mobile device 100 can trigger an action based on certain conditions (threshold Instructions (such as base-based triggers, time-based triggers or calculation-based triggers) may be received via the API. A web-based application may set future triggers by having the mobile device 100 execute a customized script via the API. Web-based applications may register to request sensor data either immediately or periodically (possibly requiring explicit permission from the user), or set future triggers on sensor data May be.

  FIG. 1 illustrates components of a known system that includes a cloud-based application and a dedicated client application 130 (eg, 131, 132, 133) that runs on the client application processor 120 of the mobile device 100. The cloud-based application is a web-based server application 200 (eg, 201, 202, 203) that operates in the cloud 300. The client application 130 transmits sensor data to the server application 200 via the client application processor 120. Currently, to send sensor data from a particular sensor 160 (e.g., accelerometer 162) to a server application 200 (e.g., server B application 202), the mobile device 100 can have a single client application 130 (e.g., The client B application 132) must be executed continuously. The client application 130 follows the vendor-specific protocol 171 and consumes power while waiting for a request for sensor data from the server application 200. Since the server application 200 is unrelated to other server applications 200, requests for sensor data are not cooperative.

  FIG. 2 shows the components of the mobile device 100 that provide sensor data via the client application processor 120. The mobile device 100 processes sensor data requests via a dedicated client application 130 (eg, 131, 132, 133) running on the client application processor 120. A dedicated client application 130 (eg, 131, 132, 133) is required for the server application 200 (eg, 201, 202, 203).

  For example, as shown in FIG. 1, client A application 131 and client B application 132 are running on client application processor 120 and wait for requests from server A application 201 and server B application 202, respectively. When the client application receives a request, the request is sent to the sensor core processor 140, and then a particular sensor 160 or sensor set (e.g., global positioning satellite (GPS) receiver 161, accelerometer 162, gyroscope 163, Polling or interrupting a magnetometer 164, temperature sensor 165, pressure sensor 166, proximity sensor 167 and / or ambient light sensor (ALS168). A particular sensor 160 or sensor set may also include a microphone and / or camera. When the sensor core processor 140 responds to the client application with sensor data, the client application responds to the original request with this sensor data. Thus, the client application processor 120 operates various client applications 130 and consumes power while waiting for new requests from that particular server application 200 and while waiting for sensor data.

  FIG. 3 illustrates components of mobile device 100 that use sensor core processor 140 and bypass client application processor 120 to provide sensor data in accordance with some embodiments of the present invention. The mobile device 100 operates with a common API 170 at the interface between the sensor core processor 140 and the server application 200 and bypasses the client application processor 120. In some embodiments, the sensor core processor 140 operates in a low power mode. For example, the sensor core processor 140 may operate at a lower clock rate and / or have a longer sleep time compared to the client application processor 120, or may operate on a lower grade processor. In this scheme, the client application processor 120 consumes a first power level for a certain duration, and the sensor core processor 140 consumes a second power level for this duration, where the second The power level is lower than the first power level. The sensor core processor 140 executes the sensor core client 141 using a common API for communication with various server applications 200. The sensor core client 141 serves as a means for receiving a request for sensor data and a means for replying to the request, each using a common API. The sensor core processor 140 also executes a sensor driver 150. The sensor driver 150 may include a GPS driver 151 that serves as a means for communicating with the GPS receiver 161. The sensor driver 150 may include an accelerometer driver 152 that serves as a means for communicating with the accelerometer 162. The sensor driver 150 may include a gyroscope driver 153 that serves as a means for communicating with the gyroscope 163. Sensor driver 150 may include a magnetometer driver 154 that serves as a means for communicating with magnetometer 164. Similarly, sensor driver 150 may include a driver for each single sensor that serves as a means for receiving sensor data from the sensor. The sensor driver 150 is tuned to communicate with the specified hardware implementation of each sensor 160.

  The sensor core processor 140 uses a common API request and waits for a request from the server application 200 sent via the modem 110. Modem 110 is coupled to the air interface via wireless antenna 111. Server application 200 may push the request to mobile device 100. The sensor core processor 140 may be less responsive than the client application processor 120, however, sensor data reception in the server application 200 is often not time critical. Other client applications 130 that require an immediate response may still run on the client application processor 120, but power consumption is not reduced as is the case with the client application 130 running on the sensor core processor 140. In some embodiments, the sensor core processor 140 may execute a less computationally intensive application while the more computationally intensive application runs on the client application processor 120. This configuration allows trigger calculation and sensor data upload to be performed on the low power processor while the power intensive application processor remains in sleep mode.

  FIG. 4 illustrates an API framework according to the present invention. The API framework includes an application layer 10, a high level operating system (HLOS20) and a low level operating system (LLOS30). This API framework facilitates cloud-based mobile application development and provides a simple web-based API for retrieving sensor information from the mobile device 100.

  Server-based applications communicate with the top level of the API framework in the application layer 10. The sensor communicates with the API framework from below with LLOS30. Within the mobile device 100, the entire API framework runs on a low power sensor core processor, such as sensor core processor 140. The integrated application operates at the application layer 10 and acts as a client by returning sensor data as required by multiple, unrelated, unrelated and unrelated cloud or web-based server applications 200.

  The sensor driver on the mobile device 100 resides below the application layer 10 and the HLOS 20 and is under the control of the LLOS 30. In some embodiments, mobile device 100 includes a sensor driver 150 coupled to LLOS 30. In other embodiments, the sensor driver 150 is a part or a complete part of the LLOS 30.

  FIG. 5 shows components of a system that includes a server application 200 (eg, 201, 202, 203) operating within the cloud 300 and a dedicated sensor core client 141 operating on the sensor core processor 140 of the mobile device 100. The system transmits sensor data via a single sensor driver 150 running on the sensor core processor 140. The sensor core client 141 may serve as a means for processing requests for sensor data. Sensor core client 141 may coordinate overlapping or conflicting sensor data requests such that two single requests for sensor data invoice a single call to sensor driver 150. Thus, sensor 160 is not interrupted by duplicate requests when a coordinated single response is sufficient.

  The sensor core processor 140 receives a request from the modem 110 from a single unrelated server application 200 (but through the common API 170) (see FIGS. 3 and 4). These requests may wait until the sensor core processor 140 makes a round from the duty cycle non-activation period (sleep mode) to the duty cycle activation period (operation mode). The total duty cycle includes one non-activation period and one adjacent activation period. The duty cycle mode of operation, in which the sleep mode is favored over the mode of operation, is often a low power duty cycle mode. The sensor core processor 140 saves power by operating in a low power duty cycle mode. The sensor core client 141 receives sensor data from the sensor 160 using the sensor driver 150, and returns a report of sensor data to the requesting server application 200 via the common API 170. In this manner, the mobile device 100 provides sensor data using the sensor core processor 140 and bypassing the client application processor 120.

  FIG. 6 illustrates various API messages in accordance with the present invention. The common API message includes both a request for sensor information and a response including sensor data. The sensor data request includes a request for sensor data and an indication or address where to return the data. (a) shows that the sensor data request 301 is a simple request for sensor data from a specific sensor and includes a return IP address. (b) indicates that the sensor data request 302 is a request for sensor data from a variable sensor and includes a return IP address. The sensor data request 302 is accompanied by an instruction regarding the sensor data type 303. For example, the sensor data type 303 can indicate data from an accelerometer. (c) indicates that the sensor data request 304 is a request for sensor data from a plurality of sensors and includes a return IP address. In the sensor data request 304, instructions regarding the first sensor data type 305 and the second sensor data type 306 are attached. (d) indicates that the sensor data request 307 is a request for sensor data at a certain point in the future and includes a return IP address. A schedule 308 is attached to the sensor data request 307. For example, the schedule 308 may indicate that the sensor data is periodically requested and / or started at a particular point in time. In response to the sensor data request, the integrated client application may send a sensor data response. (e) shows that the sensor data response 310 corresponds to the sensor data request 301, 302 or 307. The sensor data response 310 includes the indicated IP address as the destination address. Sensor raw data 311 is attached to the sensor data response 310. Alternatively, the integrated client application may process the raw sensor data and return this processed sensor data. (f) shows that the sensor data response 312 corresponds to the sensor data request 304. The sensor data response 312 includes the designated IP address as a destination address. The sensor data response 312 is attached with sensor raw data 313 from the first type of sensor and sensor raw data 314 from the second type of sensor.

  In some embodiments, the sensor data request may include instructions that indicate a triggerability calculation or triggerability event. The triggerability calculation may or may not be satisfied. If a triggering condition is met, one or more sensor readings or sensor data from the same sensor and / or different sensors will trigger the mobile device 100 to The trigger commands to send data as sensor data from one or more of them. For example, the mobile device 100 is based on data from a second sensor (e.g., a temperature sensor that indicates that the temperature is below a certain amount) Send a sensor data response message containing data from. The triggering event may be based on the location. For example, if the GPS sensor indicates that the mobile device 100 has entered or exited a certain boundary, the mobile device 100 may report its temperature.

  Mobile device 100 may send measurements from multiple sensors based on certain sensors triggering certain criteria. Mobile device 100 may send measurements from one sensor based on a combination of measurements from multiple sensors triggering certain criteria. This trigger may be a range or some value and may include hysteresis to reduce reporting overlap. For example, the mobile device 100 may indicate that the temperature sensor indicates a temperature outside a certain range over a period of time, the humidity sensor indicates a humidity above a certain value, and the acceleration that the accelerometer 162 is below a certain set threshold. Send GPS data based on the indicated case.

  Similarly, the mobile device 100 may send data from multiple sensors or all sensors based on the multiple sensors meeting the criteria. For example, the mobile device 100 may determine that some type of sensor has instructed the patient from the biosensor that an emergency has occurred, and this emergency is then identified as the biosensor and GPS in the sensor data response message. It can be reported in the form of data from sensors. In addition, some sensors may be included within the mobile device 100 itself, while other sensors may be included in a personal area network (PAN) that is remote from and in communication with the mobile device 100.

  The triggerability calculation is triggered by one or more sensors. The triggerability calculation can also be triggered or conditioned by a timer or absolute time. For example, a sensor may report its data after a condition has been met and also after some time has passed since a previous event, such as a previous report. The mobile device 100 may periodically check (eg, every 30 minutes) whether certain sensor conditions are met and report sensor data if met. The mobile device 100 may check whether certain sensor conditions are met according to a schedule (eg, daily at 8 am, noon and 5 pm) and report sensor data if met.

  FIG. 7 shows a flowchart 400 according to some embodiments of the invention. This method is performed within the mobile device 100 and provides a common API 170 to multiple server applications 200. In step 410, the mobile device 100 receives a first request for sensor data using a common API 170 from a first web-based application (eg, server A application 201). In step 420, the mobile device 100 receives a second request for sensor data, also using a common API 170, from a second web-based application (eg, server B application 202) that is unrelated to the first web-based application. .

  In step 430, the mobile device 100 processes the first and second requests for sensor data using the sensor core client 141 on the sensor core processor 140 and bypassing the client application processor 120. In step 440, the mobile device 100 receives sensor data from the sensor at the sensor core processor. In step 450, the mobile device 100 replies to the first request with a first response that includes sensor data and bypasses the client application processor 120. In step 460, the mobile device 100 replies with a second response to the request for the second sensor data. This second response is separate from the first request and includes sensor data and also bypasses the client application processor 120. Step 450 and step 460 may be performed independently, sequentially or overlapping each other.

  The technique described in this specification can be realized by various means depending on the application. For example, these techniques can be implemented in hardware, firmware instructions, software instructions, or some combination thereof. In a hardware implementation, the processing unit can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gates It may be implemented in an array (FPGA), processor, controller, microcontroller, microprocessor, electronic device, other electronic unit designed to perform the functions described herein, or combinations thereof.

  For firmware and / or software implementations, the techniques may be implemented by modules (eg, procedures, functions, etc.) that perform the functions described herein. In implementing the techniques described herein, any machine-readable medium that tangibly embodies the instructions may be used. For example, software code may be stored in a non-transitory computer readable storage medium such as memory and executed by a processor unit. The memory may be implemented within the processor unit or may be implemented outside the processor unit. As used herein, the term “memory” refers to any type of long-term, short-term, volatile, non-volatile or other memory, such as any specific type of memory or a specific number of memories, or It is not intended to limit the particular type of medium on which the memory is stored.

  When implemented in firmware and / or software, the functionality may be stored as one or more instructions or code on a computer-readable medium. Examples include computer readable media encoded with a data structure and computer readable media encoded with a computer program. Computer-readable media includes physical computer storage media. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or instructions or data structures with desired program code. Can include any other medium that can be used for storage in the form of and accessible by a computer, and as used herein, a disk and a disc are: Includes compact disc (CD), laser disc (registered trademark), optical disc, digital multipurpose disc (DVD), floppy disc (registered trademark) and Blu-ray disc, where the disk is usually a magnetic data On the other hand, the disc reproduces data optically using a laser. Combinations of the above should also be included within the scope of computer-readable media.

  In addition to being stored on a computer readable medium, instructions and / or data may be provided as signals on a transmission medium included within the communication device. For example, the communication device may include a transceiver having a signal indicating instructions and data. These instructions and data are configured to implement the functions outlined in the claims for one or more processors. That is, the communication device includes a transmission medium along with a signal indicating information to perform the disclosed function. The transmission medium included in the communication device at the first time point may include a first portion of information to perform the disclosed function, while the transmission medium included in the communication device at the second time point includes the disclosed function. May include a second portion of information to perform.

  The above description of aspects of the disclosure is provided to enable any person skilled in the art to make and use the disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects without departing from the spirit or scope of the disclosure.

10 Application layer
20 High Level Operating System (HLOS)
30 Low Level Operating System (LLOS)
100 mobile devices
111 Wireless antenna
110 modem
120 client application processor
130 client applications
131 Client A application
132 Client B application
133 Client C application
140 Sensor core processor
141 Sensor Core Client

Claims (31)

A mobile device for providing a common API (application programming interface),
A modem coupled to a wireless antenna;
A client application processor coupled to the modem that consumes a first power level for a duration;
The modem comprising a sensor core client and a sensor driver coupled to the sensor core client, consuming a second power level for the duration, and wherein the second power level is lower than the first power level A sensor core processor coupled to and comprising the common API;
A mobile device comprising a sensor coupled to communicate with the sensor driver of the sensor core processor.   The mobile device of claim 1, wherein the sensor includes a plurality of sensors and the sensor driver includes a corresponding plurality of sensor drivers each coupled to communicate with a respective one of the plurality of sensors.   The mobile device of claim 1, wherein the sensor comprises a global positioning satellite (GPS) receiver. The sensor includes a plurality of sensors, and the plurality of sensors includes an accelerometer;
The mobile device of claim 1, comprising a gyroscope.   The mobile device of claim 1, wherein the sensor comprises a magnetometer.   The mobile device of claim 1, wherein the sensor comprises a pressure sensor.   The mobile device of claim 1, wherein the sensor comprises a proximity sensor.   The mobile device of claim 1, wherein the sensor comprises an ambient light sensor (ALS).   The mobile device of claim 1, wherein the sensor comprises a microphone.   The mobile device of claim 1, wherein the sensor comprises a camera.   The mobile device of claim 1, wherein the modem comprises a code division multiple access (CDMA) modem.   The mobile device of claim 1, wherein the client application processor is configured to execute a plurality of client applications.   The mobile device of claim 1, wherein the sensor core client includes a sleep mode and an operation mode.   The mobile device of claim 1, wherein the sensor core processor includes a duty cycle mode of operation and the duration includes a full duty cycle. A method for providing a common API (application programming interface) in a mobile device,
Receiving a first request for sensor data from a first web-based server application using a common API;
Receiving a second request for sensor data using a common API from a second web-based server application unrelated to the first web-based server application;
Processing the first request and the second request for sensor data on a sensor core processor and bypassing a client application processor;
Receiving sensor data from a sensor in the sensor core processor;
Replying to the first request with a first response including the sensor data;
Returning a second request for sensor data in a second response different from the first request including the sensor data.   The method of claim 15, wherein the first request for sensor data includes an indication of a triggering event.   The method of claim 16, wherein the triggering event comprises a certain condition from a second sensor that provides data separate from the sensor data.   The method of claim 15, further comprising executing a sensor core client on the sensor core processor.   16. The method of claim 15, wherein the sensor data from the sensor includes sensor data from a plurality of sensors.   21. The method of claim 19, wherein the sensor comprises a global positioning satellite (GPS) receiver. The plurality of sensors are
An accelerometer,
20. The method of claim 19, comprising a gyroscope.   The method of claim 19, wherein the sensor comprises a magnetometer.   The method of claim 19, wherein the sensor comprises a pressure sensor.   The method of claim 19, wherein the sensor comprises a proximity sensor.   The method of claim 19, wherein the sensor comprises an ambient light sensor (ALS).   The method of claim 19, wherein the sensor comprises a microphone.   The method of claim 19, wherein the sensor comprises a camera.   20. The method of claim 19, further comprising executing a sensor core client for each of the plurality of sensors on the sensor core processor. A mobile device for providing a common API (application programming interface),
Means for receiving a first request for sensor data using the common API from a first web-based server application;
Means for receiving a second request for sensor data using the common API from a second web-based server application unrelated to the first web-based server application;
Means for processing the first request and the second request for sensor data on a sensor core processor and bypassing a client application processor;
Means for receiving sensor data from a sensor in the sensor core processor;
Means for replying to the first request with a first response including the sensor data;
Means for returning in a second response separate from the first request including the sensor data in a second request for the sensor data. A device comprising a processor and a memory, the memory comprising:
Software instructions for receiving a first request for sensor data from a first web-based server application using a common API (application programming interface);
Software instructions for receiving a second request for sensor data using the common API from a second web-based server application unrelated to the first web-based server application;
Software instructions for processing the first request and the second request for sensor data on a sensor core processor and bypassing a client application processor;
Software instructions for receiving sensor data from a sensor in the sensor core processor;
Software instructions for replying to the first request with a first response including the sensor data;
And a software instruction for replying to the second request for the sensor data with a second response different from the first request including the sensor data. A non-transient computer readable storage medium having program code stored thereon,
Program code for receiving a first request for sensor data from a first web-based server application using a common API (application programming interface);
Program code for receiving a second request for sensor data using the common API from a second web-based server application unrelated to the first web-based server application;
Program code for processing the first request and the second request for sensor data on a sensor core processor and bypassing a client application processor;
In the sensor core processor, program code for receiving sensor data from the sensor;
A program code for replying to the first request with a first response including the sensor data;
A non-transitory computer-readable storage medium comprising: a program code for returning a second request for the sensor data in a second response different from the first request including the sensor data.

Images