Patent Description:
Physical condition sensors are associated with high levels of arithmetic computation in order to derive calculated results information based on raw physical sensor data, as well as to compensate for changes in external factors.

Such sensors and sensor systems may typically include one or more sensing elements and one or more application specific integrated circuits (ASICs), and may also include one or more computational circuits (e.g., a multiplier, a floating-point-unit, etc.). Sensor systems may be implemented as a system on a chip.

The sensing elements (e.g., a gas sensor, a temperature sensor, a pressure sensor, a movement sensor, a magnetic field sensor, an accelerometer, a gyroscope, etc., and various combinations thereof), in operation, sense a target physical parameter or condition to be sensed (e.g., gas concentration, temperature, pressure, movement, orientation with respect to a magnetic field, acceleration, orientation with respect to a gravitational field, etc.).

The ASIC may typically comprise one or more analog front ends, one or more analog-to-digital (A/D) converters, and one or more digital front ends. The analog front ends drive the sensing elements and measure characteristics or changes in characteristics indicative of target parameters or changes in target parameters to be sensed (e.g., capacitance, voltage and current variations or various combinations thereof).

The A/D converters convert signals generated by the analog front end to digital signals, and may filter and amplify signals generated by the analog front end. The digital front end provides digitalized measured data (e.g., through one or more interfaces, such as an I2C or SPI interface) to an application (e.g., executing on host processor of a mobile device). The digital front end may perform digital filtering, first-in-first-out buffering, interrupt and other digital processing functions on the digitized measured data. Additional processing circuits (e.g., processor cores, floating-point processors, etc.) may be included to facilitate performing more complex tasks. For example, machine learning cores may be embedded in a sensor to recognize, for example, user activities. A host processor may send a request to receive data to a sensor, and may configure the sensor to process sensor data in various manners (e.g., by setting configuration registers; etc.).

However, such electronic devices require high hardware resources, typically not available in most electronic devices. For example, a microcontroller can be integrated into the digital interface of the detection device to provide additional hardware resources. However, this solution is unable to provide sufficient hardware resources to perform complex functions required in specific applications.

Furthermore, the integration of additional hardware resources into the detection devices implies an excessive cost increase and a high difficulty in designing the detection devices themselves.

<CIT> discloses a finger sensing apparatus wherein communication from the fingerprint sensor to the host processor is a direct communication.

<CIT> discloses a method and an apparatus for distributing sensor data using a communication from the sensor to a sensor node to the gateway to a number of service providers that receive a copy of the sensor data stream from the gateway.

The problem therefore arises of providing an architecture of a system comprising a sensor as a service and a related operating method capable of overcoming the disadvantages of the prior art.

According to the invention, a device, a system and a method are provided, according to the attached claims.

For a better understanding of the present invention some embodiments thereof are now described, purely by way of non-limiting example, with reference to the attached drawings, wherein:.

In the following description, the sizes and relative positions of elements in the drawings are not necessarily drawn to scale. For example, the shapes of various elements and angles are not drawn to scale, and some of these elements are enlarged and positioned to improve drawing legibility.

The present disclosure is directed to, techniques for providing generated sensor results information directly from an integrated sensor device (such as a system-on-chip or "SoC" device) to an application, using remote processing resources (e.g., cloud processing resources), for example, in combination with local processing resources, such as processing resources embedded in a sensor device. For example, rather than providing raw physical sensor data to an external application processor for processing, an integrated sensor device on a chip may access one or more remote processing resources to perform such processing, via one or more interfaces through which the calculated/generated results information may be provided. For example, as part of providing sensor services to an application, a sensor device and a remote server may exchange communications using defined protocols (e.g., encryption). The application may pass such encrypted communications using defined protocols between the integrated sensor device and the remote server without decrypting of the encrypted communications by the application.

As used herein, "sensor" may refer to any component that generates electrical and/or electronic signals indicative of one or more substances and/or physical conditions present in its immediate surroundings, and may include as non-limiting examples: a humidity sensor, particle detector, gas sensor, chemical sensor, biochemical sensor, radioisotope sensor, infrared sensor, air quality sensor, water quality sensor, thermal sensor, organic compound detector, magnetic field sensor, pressure sensor, an accelerometer, etc., and various combinations thereof. It will be appreciated that while many examples herein are provided with respect to a "gas sensor," any other sensor, as well as various combinations of sensors and of types of sensors, may be used in accordance with the techniques presented herein.

In general, the figures and the following description refer to a system comprising: a host processor, which in operation, executes an application that generates sensor-service-authorization requests and sensor-service requests; an integrated sensor device integrated into a chip, which includes: sensing circuitry integrated into the chip, wherein the sensing circuitry, in operation, generates sensor data related to one or more physical conditions; processing circuitry integrated into the chip and coupled to the sensing circuitry, wherein the processing circuitry, in operation, determines a type of a sensor-service request received from the host processor; in response to determining the received sensor-service request is of a first type, generates results information in response to the sensor-service request of the first type based on generated sensor data and transmits the results information to the host processor; in response to determining the sensor-service request is of a second type: initiates remote-server processing based on the sensor-service request of the second type; and generates a response to the sensor-service request of the second type based on a response to the initiated remote-server processing.

The remote-server processing may include allocating memory and computational resources to the request; managing priorities based on request type; etc., and various combinations thereof.

The system may comprise encryption circuitry, which, in operation, encrypts communications from the integrated sensor device to the remote server and decrypts communication from the remote server to the integrated sensor device.

The encryption circuitry may be integrated into the chip.

The processing circuity, in operation, may respond to a received sensor-service-authorization request by requesting remote-server verification that the application is authorized to receive sensor services.

The application may pass encrypted communications between the integrated sensor device and the remote server without decrypting the encrypted communications.

The processing circuitry, in operation, may respond to failure to receive verification that the application is authorized by denying access to sensor services to the application.

The first type of request may comprise requests directed to functions embedded in the integrated sensor device.

The functions embedded in the integrated sensor device may include: the generating results information; compensating for environmental factors; initiating periodic remote-server reauthorization; or combinations thereof.

Authorizations may expire (e.g., periodically after a threshold period of time; after a threshold number of uses, etc.) and the integrated sensor device may initiate remote-server reauthorization in response to expiration or in anticipation of expiration of an authorization.

The second type of request my comprise requests directed to cloud-based functionality.

The cloud-based functionality may include: sensor diagnostic functionality; sensor aging compensation functionality; sensor environmental factor compensation functionality; dashboard functionality; artificial intelligence classification based on sensor data; artificial intelligence classification based on results information; or combinations thereof.

The environmental factors include temperature, pressure, illumination, sensor location, sensor position, sensor orientation, long-term sensor drift, or combinations thereof.

The system may comprise a remote server, which, in operation, generates responses to the sensor-service request of the second type.

The integrated sensor device may be a first integrated sensor device, and the system may comprise a second integrated sensor device, wherein the remote server, in operation, may generate a response to the sensor-service request of the second type based on sensor data generated by the first integrated sensor device and sensor data generated by the second integrated sensor device.

The sensing circuitry may include a humidity sensor, a chemical sensor, a biochemical compound sensor, a radioisotope sensor, an infrared sensor, an air quality sensor, a water quality sensor, a thermal sensor, an organic compound detector, or combinations thereof.

A device may comprise: sensing circuitry integrated into a chip, wherein the sensing circuitry, in operation, generates sensor data related to one or more physical conditions; processing circuitry integrated into the chip and coupled to the sensing circuitry, wherein the processing circuitry, in operation, processes received sensor-session requests and received sensor-service requests, wherein the processing a received sensor-service request includes: determining a type of the received sensor-service request; in response to determining the received sensor-service request is of a first type, generating results information in response to the received sensor-service request of the first type based on generated sensor data; in response to determining the received sensor-service request is of a second type: initiating remote-server processing based on the received sensor-service request of the second type; and generating a response to the received sensor-service request of the second type based on a received response to the initiated remote-server processing.

The device may comprise: encryption circuitry integrated into the chip, wherein the encryption circuitry, in operation, encrypts communications from the processing circuitry to a remote server and decrypts communication from the remote server to the processing circuitry.

The application may pass encrypted communications between the processing circuitry and the remote server without decrypting the encrypted communications.

The processing circuity, in operation, may respond to a received sensor-session request by requesting remote-server verification that an application associated with the received sensor-session request is authorized to receive sensor services.

The processing circuitry, in operation, may respond to failure to receive verification that the application is authorized by denying sensor-service requests associated with the application.

The first type of request may comprise requests directed to functions embedded in the device.

The functions embedded in the device may include: the generating results information; compensating for environmental factors; initiating periodic remote-server reauthorization of an application associated with a service-request; or combinations thereof.

Authorizations may expire (e.g., periodically after a threshold period of time; after a threshold number of uses, etc.) and the processing circuitry may initiate remote-server reauthorization in response to expiration or in anticipation of expiration of an authorization.

The second type of request may comprise requests directed to cloud-based functionality.

In the following description, a method comprises: processing, using processing circuitry integrated into a sensing-device chip, sensor-session-authorization requests; and processing, using the processing circuitry integrated into a sensing-device chip, sensor-service requests received from an application executing on a host processor, the received sensor-service requests including sensor service requests of a first type and sensor-service requests of a second type, wherein the processing of a received sensor-service request includes: determining a type of the received sensor-service request; in response to determining the received sensor-service request is of the first type, generating results information in response to the sensor-service request of the first type based on sensor data generated by sensing circuitry integrated into the sensing-device chip and transmitting the results information to the host processor; in response to determining the received sensor-service request is of the second type: initiating remote-server processing based on the sensor-service request of the second type; and generating a response to the sensor-service request of the second type based on a response to the initiated remote-server processing.

The method may comprise: encrypting communications from the processing circuitry of the sensing-device chip to the remote server and decrypting communication from the remote server to the sensing-device chip.

The application may pass encrypted communications between the sensing-device chip and the remote server without decrypting the encrypted communications.

Processing a received sensor-service-authorization request may comprise requesting remote-server verification that an application associated with the received sensor-service-authorization request is authorized to receive sensor services.

Authorizations may expire (e.g., periodically after a threshold period of time; after a threshold number of uses, etc.) and the sensing-device chip may initiate remote-server reauthorization in response to expiration or in anticipation of expiration of an authorization.

The received sensor-service request of the second type may request sensor-services providing: sensor diagnostic functionality; sensor aging compensation functionality; sensor environmental factor compensation functionality; dashboard functionality; artificial intelligence classification functionality based on sensor data; artificial intelligence classification functionality based on results information; or combinations thereof.

In the following description, a non-transitory computer-readable medium's contents configure processing circuitry of a sensing-device chip to perform a method, the method comprising: processing sensor-session-authorization requests; and processing sensor-service requests received from an application executing on a host processor, the received sensor-service requests including sensor service requests of a first type and sensor-service requests of a second type, wherein the processing of a received sensor-service request includes: determining a type of the received sensor-service request; in response to determining the received sensor-service request is of the first type, generating results information in response to the sensor-service request of the first type based on sensor data generated by sensing circuitry integrated into the sensing-device chip and transmitting the results information to the host processor; in response to determining the received sensor-service request is of the second type: initiating remote-server processing based on the sensor-service request of the second type; and generating a response to the sensor-service request of the second type based on a response to the initiated remote-server processing.

The sensing-device chip may request authorization of the application from the remote server. Authorizations may expire (e.g., periodically after a threshold period of time; after a threshold number of uses, etc.) and the sensing-device chip may initiate remote-server reauthorization in response to expiration or in anticipation of expiration of an authorization.

The contents of the non-transitory computer-readable medium may comprise instructions which, when executed by the processing circuitry, cause the processing circuitry to perform the method.

In the drawings, <FIG> depicts a functional block diagram of a known configuration for system <NUM>, including a sensor device <NUM>, which may be implemented as a system on a chip, and a host system <NUM>. The sensor device <NUM> as illustrated includes one or more sensing elements <NUM>, one or more application specific integrated circuits (ASICs) <NUM>, and one or more interfaces <NUM>.

The one or more sensing elements <NUM> (which may comprise, e.g., a gas sensor, a temperature sensor, a pressure sensor, a movement sensor, a magnetic field sensor, an accelerometer, a gyroscope, etc., and various combinations thereof), in operation, sense one or more target parameters to be sensed (e.g., one or more indications of gas concentration, temperature, pressure, movement, orientation with respect to a magnetic field, acceleration, orientation with respect to a gravitational field, etc.).

The ASICs <NUM> may typically comprise one or more analog front ends <NUM>, one or more analog-to-digital (A/D) converters <NUM>, and one or more digital front ends <NUM>. The analog front ends <NUM> drive the sensing elements <NUM> and measure characteristics or changes in characteristics indicative of target parameters or changes in target parameters to be sensed (e.g., capacitance, voltage and current variations or various combinations thereof).

The A/D converters <NUM> convert signals generated by the analog front ends <NUM> to digital signals, and may filter and amplify signals generated by the analog front ends <NUM>. The digital front ends <NUM> provide digitalized measured data (e.g., through one or more interfaces, such as an I2C or SPI interface) to an application (e.g., stored in a memory <NUM> and executing on host processor <NUM> of a host system <NUM>, such as a mobile device).

The digital front ends <NUM> may perform digital filtering, first-in-first-out buffering, interrupt and other digital processing functions on the digitized measured data. Additional processing circuits <NUM> (e.g., processor cores, floating-point processors, etc.) may be included to facilitate performing more complex tasks. For example, machine-learning cores may be embedded in a sensor <NUM> to recognize, for example, user activities. The host processor <NUM> may send a request via an application interface <NUM> and an interface <NUM> of the sensor <NUM> to receive data from the sensor <NUM>, and may configure the sensor <NUM> to process sensor data in various manners (e.g., by setting configuration registers in the sensor; etc.). As illustrated, the host system <NUM> includes additional interfaces, such as network interfaces <NUM>, and other functional circuits <NUM> (e.g., controllers to control other devices based on received sensor information; power supplies; bus systems; etc.).

<FIG> depicts a functional block diagram of a configuration for system <NUM>, including a sensor device <NUM>, which may be implemented as a system on a chip, a host system <NUM>, such as the host system <NUM> of <FIG>, and a remote server <NUM>. The sensor <NUM>, in operation, provides data sensing as a service to the host system <NUM>. As compared to the sensor <NUM> of <FIG>, the sensor <NUM> of <FIG> includes sensor service management circuitry <NUM>.

The sensor service management circuitry, as illustrated, includes a resource manager <NUM>, a session manager <NUM>, a priority manager <NUM>, a request manager <NUM>, additional processing cores <NUM> to handle sensor data processing tasks, a processing manager <NUM>, a communication manager <NUM> and cryptographic circuitry <NUM>. Usage data may be communicated to the remote server <NUM>, which may also handle authentication functions. As compared to the system <NUM> of <FIG>, the system <NUM> requires substantial additional processing resources and memory in the sensor device <NUM>, which require additional space, power and other resources, and thus may not be practical to implement in a competitive marketplace.

In addition, an application executing on the host system <NUM> initiates sensor service sessions by communicating with the remote server <NUM>, and may perform or facilitate performance of other tasks as well (e.g., authentication, tracking of sessions, firmware updates, etc.).

<FIG> depicts a functional block diagram of a configuration for system <NUM>, including a sensor device <NUM>, which may be implemented as a system on a chip, a host system <NUM>, such as the host system <NUM> of <FIG>, and a remote server <NUM>, such as a cloud server. As compared to the sensor <NUM> of <FIG>, the sensor <NUM> and the remote or cloud server <NUM> of <FIG> collectively provide sensed data as a service to the host system <NUM>, with the host system <NUM> generally operating as it were communicating with a standard sensor, as discussed in more detail below. The sensor service circuitry <NUM> of the sensor <NUM> is simplified, as illustrated, including processing circuitry or cores <NUM> (which may be substantially simplified as compared to the processing circuitry <NUM> of <FIG>), to handle sensor data processing tasks, a communication manager or circuitry <NUM> and cryptographic circuitry <NUM>. The sensor <NUM> may be viewed as one sensor of a pair of symbiotic sensors, with the remote or cloud server <NUM> including another symbiotic sensor <NUM> of the pair as well as sensor-as-a-service management circuitry <NUM>.

The sensor <NUM> is more practical to implement as part of a system of providing sensed data as a service due to the simplification of the circuitry and the reduced resource needs of the sensor <NUM>. The sensor <NUM>, in operation, performs local functions, by using the processing circuitry <NUM>, and has an embedded interpreter or communication circuit <NUM> and a cryptographic circuit <NUM>, to coordinate with the symbiotic sensor <NUM> and sensor-as-a-service management circuitry <NUM> of the remote server <NUM>.

The communication circuitry <NUM> implements one or more communication protocols to communicate with the host system <NUM> (e.g., in clear) and with the remote (cloud) server <NUM> (e.g., via messages encrypted/decrypted by the cryptographic circuitry <NUM>) and with the sensor-as-a-service management circuitry <NUM> and/or the ASIC <NUM> (e.g., in clear).

The cryptographic circuitry <NUM> may employ standard or proprietary encryption schemes using public or private keys in various manners to encrypt/decrypt messages exchanged between the local sensor <NUM> and the remote server <NUM>. The cryptographic circuitry may be external to the sensor <NUM> (e.g. a separate chip or part of the host system).

A sensor-specific key (public or private) may be embedded in the sensor <NUM>.

The processing circuitry <NUM> and/or the ASIC <NUM> executes service requests (alone or in coordination with symbiotic sensor <NUM> of the remote server <NUM>) and provides unencrypted results to the host system <NUM> through the communication circuitry <NUM>.

Elements of the system <NUM> may be combined or split in various manners. For example, all or part of the sensor service circuitry <NUM> may be integrated into the ASIC <NUM>.

<FIG> is a conceptual diagram illustrating example functions provided by and communications between the host system <NUM>, the sensor <NUM> and the remote server <NUM> of <FIG> in an embodiment. As illustrated, the host <NUM> sends a service request to the remote server <NUM>, for example under control of an application executing on the host. The remote server <NUM> enables the sensor <NUM> to provide sensor services to the host system <NUM>, possibly by send an encrypted enable message to the sensor <NUM> through the host <NUM>. The host <NUM> communicates with the sensor <NUM> during execution of the sensor services, for example, using unencrypted communications, and the sensor <NUM> communicates with the remote server <NUM>, for example using encrypted communications (which may be routed through the host <NUM>, e.g., without decryption by the host), to provide and manage the services in a symbiotic manner with the remote server <NUM>. The sensor <NUM> may, for example, provide basic embedded functions, which may be standard sensor functions such as generating raw data, and advanced embedded functions, such as compensating for environmental conditions. The remote or cloud server <NUM> may provide basic cloud functions, such as sensor-as-a-service management operations, and advanced cloud functions, such as advanced sensor services such as machine learning analysis of raw data and results based on the analysis, algorithm updates, etc. The host system <NUM> provides the results to the application executing on the host system <NUM>.

The basic and advanced sensor services may be distributed between the sensor <NUM> and the remote or cloud server <NUM> in various manners. <FIG> is another conceptual diagram illustrating an example distribution of functions provided the sensor <NUM> and the remote server <NUM> of <FIG>. As illustrated, the sensor <NUM> provides sampling rate (ODR) management, health analysis, and filtering, value added algorithms, and compensation calibration services. The remote server provides artificial intelligence-based services and controls execution of cooperative algorithms (e.g., all or part of the compensation calibration services). Examples of sensor services that may be provided (e.g., by the sensor <NUM> and the remote server <NUM> working together in a symbiotic manner) include one or more of the following:.

<FIG> is a conceptual diagram illustrating a system <NUM> that may employ one or more sensors <NUM> and a remote server <NUM> to control actuators <NUM> operating on physical objects <NUM> (e.g., automotive control systems actuating components of an automobile, such as a cruise control system or a crash avoidance system of an automobile).

An application programming interface (API) key may be employed. <FIG> illustrates a method <NUM> of providing sensor usage as a service using an API key, which may be performed using, for example, the system <NUM> of <FIG>. For convenience, the method <NUM> will be described with reference to the host system <NUM>, the sensor <NUM> and the remote server <NUM> of <FIG>. The method <NUM> may be performed using other systems. The method <NUM> begins at <NUM> and proceeds to <NUM>. At <NUM>, the host system (e.g., an application board in an automotive control system) obtains an application programming interface key (API key), for example from a remote server <NUM> associated with the sensor <NUM>. This may be performed, for example, when the host system <NUM> (e.g., application board) is manufactured or initialized. The API key may, for example, be associated with an account associated with the host system, and the remote server <NUM> may determine authorized activities and details associated with providing the authorized activities based on stored information associated with the account. In another example, the API may indicate (e.g., through embedded flags or fields of the API) authorized activities and details associated with providing authorized activities. The method <NUM> proceeds from <NUM> to <NUM>.

At <NUM>, the method <NUM> provides the API key to applications executing on the host system <NUM>, which are authorized to obtain sensor data as a service. This may be performed when the host system is manufactured, or each time an application is initialized (e.g., the API key may be stored in a secure manner by the host system <NUM> and provided to an authorized application as needed), etc. The method proceeds from <NUM> to <NUM>.

At <NUM>, the method <NUM> sends a service request to obtain sensor services. For example, the application executing on the host system <NUM> may send a service request including the API key to the sensor <NUM>. The service requests may include requests to receive services associated with basic functions (BEF) embedded in the sensor <NUM>, requests to receive services associated with advanced embedded functions (AEF) embedded in the sensor <NUM>, requests to receive services associated with cloud based functions (CEF), requests to receive services associated with cloud advanced functions (CAF), and requests to receive services associated with various combinations of BEF, AEF, CEF and CAF functions. The method <NUM> proceeds from <NUM> to <NUM>.

At <NUM>, the method <NUM> determines one or more type of services associated with the service request. For example, the sensor <NUM> may determine whether the requested services are types of services which may be provided without coordinating with the remote server <NUM> to provide the requested services (e.g., a request directed to only BEF services in an embodiment), or are instead types of services which require coordination with the remote server <NUM> to provide the requested services (e.g., a request directed to any combination including AEF, CEF or CAF services in an embodiment). This may be done, for example, by interpreting the service request, e.g. using an interpreter, using a look-up table, etc. Coordination may be employed, for example, when it is desired to track the usage of the services (e.g., AEF services in an embodiment), when it is desired to confirm authorization to perform a particular type of service (e.g., AEF, CEF, CAF and certain types of BEF services in an embodiment), when it is desired to use processing services on the remote server to provide the requested services in whole or in part (e.g., CEF or CAF services in an embodiment); etc., and various combinations thereof. Some service requests may be handled locally by the sensor <NUM>, for example, when authorization or tracking of usage of a particular service is not necessary or desired, and the sensor <NUM> is capable of responding to the request without coordinating with the server <NUM>.

When it is determined at <NUM> that service of the service request should be coordinated by the sensor <NUM> and the remote server <NUM>, the method <NUM> proceeds to <NUM>, where the request is serviced by the sensor <NUM> in coordination with the server <NUM>. The method <NUM> proceeds from <NUM> to <NUM>.

When it is not determined at <NUM> that service of the service request should be coordinated by the sensor <NUM> and the remote server <NUM>, the method <NUM> proceeds to <NUM>, where the request is serviced by the sensor <NUM>. The method <NUM> proceeds from <NUM> to <NUM>.

At <NUM>, the method <NUM> determines whether to continue processing service requests. When it is determined at <NUM> to continue to process service requests, the method <NUM> proceeds from <NUM> to <NUM>, to wait for another service request. When it is not determined at <NUM> to continue to process service requests, the method <NUM> proceeds from <NUM> to <NUM>, where the method <NUM> may stop or may perform other processing, such as updating sensor usage tracking information associated with the API key.

The method <NUM> may contain additional acts not shown, may omit illustrated acts, may perform acts in various orders or in parallel, etc. For example, additional acts may be performed to periodically compensate for an age of the sensor, to provide software updates to the sensor <NUM>, to periodically confirm an API key remains valid, etc. Cryptographic operations may be performed, for example, to exchange encrypted messages securely between the sensor <NUM> and the server <NUM>, while providing results information in clear to an application executing on the host <NUM>.

<FIG> and <FIG> are conceptual diagrams for illustrating an example method of communications between an interpreter of a local sensor and an interpreter of a remote symbiotic sensor executing on a remote server, and between the local sensor and an application executing on a host device. As illustrated:.

Communications between the local sensor and the remote symbiotic sensor in the cloud are secure, and the response (e.g., an indication (ok) to proceed with the service request, or an indication (ko) the request is invalid) is sent in clear to the application.

<FIG> is a conceptual diagram for illustrating encryption of communications between a local sensor (e.g., sensor <NUM> of system <NUM> of <FIG>) and a symbiotic sensor (e.g., symbiotic sensor <NUM> executing in the remote server <NUM> of <FIG>) via a host processor (e.g., host system <NUM> of <FIG>). The local sensor <NUM> stores a sensor-as-a-server (SaaS) public key, the server <NUM> stores an SaaS private key, and provides an API key to the host processor. The API key is used to identify an account associated with the host processor, and the SaaS public key and the SaaS private key are used to secure communications between the local sensor <NUM> and the symbiotic sensor <NUM> and SaaS management circuitry <NUM> of the remote server <NUM>.

<FIG> is a functional block diagram illustrating an embodiment of the system <NUM> of <FIG> for providing sensor data and results as a service, showing details of the symbiotic sensor <NUM>. As illustrated, the symbiotic sensor <NUM> includes communication circuitry <NUM>, SaaS processing circuitry <NUM>, cryptographic circuitry <NUM>, and a symbiotic sensor processing core <NUM>.

The communication circuitry <NUM> implements one or more communication protocols to securely communicate with one or more local sensors <NUM> (e.g., via messages encrypted/decrypted by the cryptographic circuitry <NUM>).

The cryptographic circuitry <NUM> may employ standard or proprietary encryption schemes using public or private keys in various manners to encrypt/decrypt messages exchanged between the local sensor <NUM> and the remote server <NUM>. The cryptographic circuitry may be external to the symbiotic sensor <NUM> (e.g. a separate chip) or part of the remote server. For example, a private key may be embedded in the symbiotic sensor <NUM>.

The SaaS processing circuitry <NUM> and/or the symbiotic sensor processing core <NUM> executes service requests (generally in coordination with sensor <NUM>) and provides encrypted results to the sensor <NUM> via the communication circuitry <NUM> and the cryptographic circuitry <NUM>.

<FIG> is a functional block diagram illustrating an embodiment of the system <NUM> of <FIG> for providing sensor data and results as a service, showing details of the SaaS management circuitry <NUM> of an embodiment. As illustrated, the SaaS management circuitry <NUM> is embedded in the remote server <NUM> and includes a security manager <NUM>, a function manager <NUM>, a session manager <NUM>, a priority manager <NUM>, external resources <NUM>, cryptographic circuitry <NUM> and resource management circuitry <NUM>.

Here, the elements of the symbiotic sensor <NUM> and the SaaS management circuitry 386of the are distributed in multiple servers in various configurations.

<FIG> is a conceptual diagram illustrating BEF, AEF, CBF and CAF functionality for providing gas sensor access as a service, and for convenience will be discussed with reference to <FIG>.

As illustrated, the BEF functionality includes generating raw data of the gas channel, and may be performed, for example, by the sensing elements <NUM> and the ASIC <NUM> of the sensor <NUM>.

The AEF functionality includes temperature and humidity compensation, ODR control and application of filters, and may be performed, for example, by the processing circuitry <NUM> of the sensor <NUM>. Authorization from the remote server <NUM>, or tracking of the use of such services, may be performed in some embodiments.

The CBF functionality includes Al classification of the sensor data (e.g., as indicating a particular gas as a particular concentration level), and may be performed by the symbiotic sensor <NUM>, with the results provided by the sensor <NUM> to the host <NUM>.

The CAF functionality includes an AI toolbox (e.g., forming a gas library for AI classification of gas data, see, e.g., <FIG> and <FIG>), a dashboard for data monitoring (e.g., in real time; notifications; updates, etc., see, e.g., <FIG>); cooperative algorithms for detecting outliers; gas-sensor diagnosis (e.g., control of self-diagnosis; providing of test data, etc.), and may be performed the symbiotic sensor <NUM> in combination with the SaaS management circuitry, and in coordination with the sensor <NUM>.

As discussed above, <FIG> and <FIG> are conceptual diagrams illustrating example data of an AI gas classification library, and <FIG> illustrates an example dashboard that may be employed to facilitate cloud management of a SaaS system. For example, controlling ANN selectivity, updates, etc., in a cloud dashboard.

<FIG> are example timing diagrams illustrating functionality and communications between a sensor, a host and a remote server of an embodiment. In <FIG>, an example session is illustrated. The session is opened by an application providing an API key to a sensor, which works with the server to open the session. While the session is running, functionality for the session is provided by the sensor and the server, for example, by executing routines and algorithms to provide the desired functionality (e.g., generating and processing or sensor data and corresponding results). When the session closes, the server tracks usage of the service, e.g., for control and billing purposes.

<FIG> illustrates an example timing diagram associated with BEF functionality. In the example of <FIG>, BEF functionality may be provided in a conventional manner, with an application executing on a host processor communicating with the sensor in clear, without involving communication with the remote or cloud server. In some embodiments, BEF functionality usage may be reported and/or authorized using communication with the remote server.

<FIG> illustrates an example timing diagram associated with functionality which in an embodiment requires opening of a session between a sensor and a remote or cloud server as part of providing SaaS service (e.g., AEF, BCF, ACF such as ODR control, FIFO control, offline data storage, filtering, interrupts, additional sensing for multi-sensor systems, etc.). As illustrated, an application executing on a host device requests a session in clear from a sensor (and may include an API key in the request). In response, the sensor generates an encrypted request asking for authorization of a session, and sends the encrypted request to a remote server (e.g., through a link established via the host device). The remote server determines whether the application is authorized to receive the requested services (e.g., based on an API key associated with the request).

When the remote server determines the application is authorized to receive the requested services, the server sends an encrypted authorization confirmation to the sensor. The sensor responds to receipt of the authorization message by sending a session open message in clear to the application. In response, the application sends a service request (e.g., an AEF request), in clear to the sensor. If the application is not authorized (e.g., there is no account associated with the application) or for another reason the session is not authorized at the time of the request (e.g., the sensor has expired or needs updating, etc.), a session authorization confirmation is not sent. As shown in <FIG>, error processing may occur. For example, an encrypted authorization declined message, which may indicate a reason for the rejection, is sent to the sensor instead of an encrypted authorization confirmation. The sensor may indicate the rejection to the application in clear, possibly including a reason for the rejection.

<FIG> illustrates an example timing diagram associated with providing AEF functionality as part of providing SaaS service. As illustrated, a session is opened, as discussed above with reference to <FIG>. Dashed message lines indicate the providing of AEF functionality by the sensor to the application. The sensor or the remote server may initiate a renewal of the session authorization, for example, periodically, and the application may send a request to end the session, as shown by the solid message lines. Messages may be exchanged to confirm closure of the session. As noted above, error processing may occur, for example, as part of opening, closing or renewing a session.

<FIG> illustrates an example timing diagram associated with providing CBF functionality as part of providing SaaS service. As illustrated, a session is opened, as discussed above with reference to <FIG>. Dashed message lines indicate the providing of CBF functionality by the remote server to the application, with messages between the sensor and the server being encrypted and the sensor providing results in clear to the application. The sensor or the remote server may initiate a renewal of the session authorization, for example, periodically, and the application may send a request to end the session, as shown by the solid message lines. Message may be exchanged to confirm closure of the session. As noted above, error processing may occur, for example as part of opening, renewing or closing a session.

<FIG> illustrates an example timing diagram associated with providing CAF functionality as part of providing SaaS service. As illustrated, a session is opened, as discussed above with reference to <FIG>. Dashed message lines indicate the providing of CAF functionality by the remote server to the application, with messages between the sensor and the server being encrypted and the sensor providing results in clear to the application. The sensor or the remote server may initiate a renewal of the session authorization, for example, periodically, and the application may send a request to end the session, as shown by the solid message lines. Message may be exchanged to confirm closure of the session. As noted above, error processing may occur, for example, as part of opening, renewing or closing a session.

<FIG> illustrates an example timing diagram associated with the closing of a session between a sensor and a remote or cloud server as part of providing SaaS service (e.g., AEF, BCF, ACF such as ODR control, FIFO control, offline data storage, filtering, interrupts, additional sensing for multi-sensor systems, etc.) to an application executing on a host. As illustrated, an application executing on a host device requests a session closure in clear from a sensor (and may include an API key in the request). In response, the sensor generates an encrypted request asking for closure of a session, and sends the encrypted request to a remote server (e.g., through a link established via the host device). The remote server determines whether the application is authorized to close the session (e.g., based on an API key associated with the request), and if so, sends a closure confirmation to the sensor.

If the application is not authorized (e.g., there is no account associated with the application) or for another reason the application is not authorized at the time of to close the session (e.g., the application is associated with a different sensor), a session closure confirmation is not sent. Error processing may occur (e.g., an encrypted error message indicating a reason for the rejection may be sent to the sensor instead of an encrypted closure confirmation). The sensor may indicate the reason for the rejection to the application in clear. As illustrated, session tracking information (e.g., billing data), is sent to the application in clear.

Some embodiments may take the form of or comprise computer program products. For example, according to one embodiment there is provided a computer readable medium comprising a computer program adapted to perform one or more of the methods or functions described above. The medium may be a physical storage medium, such as for example a Read Only Memory (ROM) chip, or a disk such as a Digital Versatile Disk (DVD-ROM), Compact Disk (CD-ROM), a hard disk, a memory, a network, or a portable media article to be read by an appropriate drive or via an appropriate connection, including as encoded in one or more barcodes or other related codes stored on one or more such computer-readable mediums and being readable by an appropriate reader device.

Claim 1:
A device, comprising:
sensing circuitry (<NUM>) integrated into a chip, wherein the sensing circuitry is configured to, in operation, generate sensor data related to one or more physical conditions; and
processing circuitry (<NUM>) integrated into the chip and coupled to the sensing circuitry, wherein the processing circuitry is configured to, in operation, process received sensor-session requests and received sensor-service requests, wherein the processing a received sensor-service request includes:
determining a type of the received sensor-service request;
in response to determining the received sensor-service request is of a first type, generating results information in response to the received sensor-service request of the first type based on generated sensor data;
in response to determining the received sensor-service request is of a second type:
initiating remote-server processing based on the received sensor-service request of the second type; and
generating a response to the received sensor-service request of the second type based on a received response to the initiated remote-server processing,
wherein:
the sensing circuitry (<NUM>) is configured to receive the sensor-session requests from an application executing on a host device in clear,
initiating remote-server processing comprises:
in response to the received sensor-service request, generating an encrypted request asking for authorization of a session; and
sending the encrypted request to a remote server (<NUM>; <NUM>) through a link established via the host device;
generating a response comprises:
upon receiving an encrypted authorization confirmation from the remote server, sending a session open message in clear to the application; and
receiving a service request in clear from the application.