Microsoft Technology Licensing LLC’s (hereinafter “Microsoft”) appeal against an order dated September 29, 2020, by which its Indian Patent Application No. 1783/CHENP/2012, was refused by the Controller of Patents as being obvious and lacking inventive step has been allowed by the Madras High Court (hereinafter “MHC”). The MHC directed narrowing of claims to clearly define the inventive feature and overcome refusal of Patent application due to lack of inventive step.
The appellant, Microsoft, filed the Indian Patent Application No. 1783/CHENP/2012 for an invention titled ‘Message Communication of Sensor and other Data’. Pursuant to a request for examination, the first examination report (FER) was issued on June 27, 2019. The appellant filed a response thereto on December 27, 2019. Along with such response, revised claims were filed. The hearing was conducted on July 14, 2020, and eventually by order dated September 29, 2020, the application was rejected.
During the appeal proceedings, the appellant submitted that computers and other machines are often equipped with sensors, such as an accelerometer, light sensor, etc., to detect various aspects of the environment. Further, the appellant submitted that the computer’s operating system provides an application programming interface (API) that allows applications to read sensor values, but such sensor interfaces complicate the design of the software because they typically involve complex control flow loops that respond to events. The appellant also submitted that the invention is aimed at providing a solution to this problem by a simple light weight messaging system[1].
The appellant also submitted that the invention[2] envisages a sensor service whereby applications that want to receive sensor values subscribe to sensor notifications through the sensor service. The sensor service determines what messages should be generated basis triggers such as changes in sensor values or passage of time. These lightweight messages do not require coding. The appellant also emphasised that contrary to the present invention, prior art methods envisaged that the sensor readings would be incorporated into the application’s run time loop and that the application would be required to include code to initialise and instantiate the API, and to manage the data from the API.
The Court noted that the assessment of inventive step of a claimed invention as per Section 2(1)(ja)[3] of the Patents Act is a two-step process:
- identification of feature(s), if any, that involve technical advancement over prior knowledge or having economic significance or both; and
- determination of whether the technical advance or economic significance or both of the said feature(s) makes the invention not obvious to a person skilled in the art.
The Court also noted the centrality of the person skilled in the art (PSITA) in the process of assessment of inventive step. Accordingly, the Court noted that the PSITA for the present case would be a software engineer with understanding of hardware/ computer electronics. As regards the level of skill of PSITA, the Court noted that as in Rhodia Operations v. Assistant Controller of Patents & Designs[4], the level of skill of the PSITA is above average and she possesses the skill set to do the job well. The Court also noted that she is not omniscient, and that ingenuity or inventiveness cannot be attributed to her since the object of the exercise is to determine whether the claimed invention contains an inventive step.
The Court further noted that for assessing the inventive step, the details must be reviewed from the eyes of a PSITA to see if the prior art basis which the application has been refused, provides enough motivation to a person skilled in the art to arrive at the claimed invention.
With regard to the case in hand, the Court further noted that, both the claimed invention and the cited prior art deal, with transmission of sensor data to a subscribing application. In the cited prior art, the transmission is triggered by an event of interest[5]. The cited prior art provides for the subscription of sensor data and the publication thereof upon occurrence of an event of interest, but there is no indication therein that the ‘published data’ is in an easy-to-read form[6].
As per the Court, the solution provided by the claimed invention is, therefore, the conversion of raw sensor data into messages that are transmitted to the subscribing application and may be easily read by such application. As per the Court, the Controller was correct in stating that, both the cited prior art and the claimed invention provide for the transmission of sensor data to a subscribing application, but the Court held that what the Controller ignored is the difference in the manner in which such data is transmitted.
Basis the above conclusion, the Court, therefore, dealt with the question of whether the delta between the cited prior art and the claimed invention would be obvious to a person skilled in the art. In order to ascertain whether the prior art contains teaching, suggestion or motivation to lead the PSITA to the claimed invention, it is important to closely examine the problem that the prior art sets out to solve. The Court noted that when the PSITA would read the prior art, the PSITA would note that the problem that the prior art addresses is data management by filtering sensor data and publishing it for consumption by the subscribing application when pre-set events of interest occur. The PSITA would also note that there is nothing in the prior art that addresses the problem of complexity in the communication of data from sensors to the subscribing applications.
The Court therefore found merit in the invention. However, it held that to define the claims more clearly and to highlight that the problem is resolved by the claimed invention – that the transmission of sensor data is in a form that is easy to process by the subscribing application, the claims should be revised to indicate the same:
| Refused Claims | Revised claims considered allowable by the MHC |
| 1. A method of providing information to an application (116), the method comprising: receiving from said application (116) a subscription request; using a sensor interface (110) to obtain a reading from a sensor, said sensor interface that provides a mechanism through which sensor values are readable by application that use said sensor interface; creating a message (114) based on a set of one or more readings, wherein said set comprises said reading; and providing said message (114) to said application (116). | A method of providing information to an application (116), the method comprising: receiving from said application (116) a subscription request; using a sensor interface (110) to obtain a reading from a sensor, said sensor interface that provides a mechanism through which sensor values are readable by application that use said sensor interface; creating a light-weight easy-to-read message (114) based on a set of one or more readings, wherein the said set comprises the said reading; and providing the said message (114) to the said application (116). |
| 9. A machine (108) for using sensor data, the machine comprising: a processor (402); a date remembrance component (404); a sensor; and a service component (112) that is stored in said data remembrance component and that is executable on said processor (402), said service component using a sensor interface (110) to obtain a reading from said sensor, said sensor interface being provided by an operating system that is present at said machine (108), said service component generating a message (114) based on information that comprises a set of sensor readings, said set of sensor readings (202- 206) comprising said reading, said service component receiving a subscription request from an application that executes on said machine, said service component providing said message to said application based on said service component having received set subscription request from said application.” | 9. A machine (108) for using sensor data, the machine comprising: a processor (402); a date remembrance component (404); a sensor; and a service component (112) that is stored in said data remembrance component and that is executable on said processor (402), said service component using a sensor interface (110) to obtain a reading from said sensor, said sensor interface being provided by an operating system that is present at said machine (108), said service component generating a light-weight easy-to-read message (114) based on information that comprises a set of sensor readings, said set of sensor readings (202-206) comprising said reading, said service component receiving a subscription request from an application that executes on said machine, said service component providing said message to said application based on said service component having received set subscription request from said application.” |
For further information, please contact:
Swati Sharma, Partner, Cyril Amarchand Mangaldas
swati.sharma@cyrilshroff.com
[1] Paragraph [0004], of the specification: “Sensor data, and other kinds of data, may be provided to an application (or other type of program) through a simple lightweight messaging mechanism. In one example, a sensor service uses a sensor interface (such as a sensor API) to read sensor values. Programs that want to receive sensor values may subscribe to sensor notifications through the sensor service. The sensor service may determine, based on various triggers (example, changes in sensor values, passage of time, et cetera), to generate messages that communicate sensor values to the subscribing program(s). For example, an application might subscribe to receive accelerometer readings. The sensor service could use a sensor API to poll the accelerometer periodically for its current readings, and could generate a message whenever the accelerometer values change. This message could then be sent to the subscribing application. Since applications are typically built to handle messages and other types of interrupts received from external sources, the application can process the messages using these kinds of messagehandling mechanism. Designing the application to receive and process the messages may be less complex than designing the application to read sensor values directly through the sensor interface.”
[2] Independent claims 1 and 9:
” 1. A method of providing information to an application (116), the method comprising:
receiving from said application (116) a subscription request;
using a sensor interface (110) to obtain a reading from a sensor, said sensor interface that provides a mechanism through which sensor values are readable by application that use said sensor interface; creating a message (114) based on a set of one or more readings, wherein said set comprises said reading; and
providing said message (114) to said application (116).
9. A machine (108) for using sensor data, the machine comprising:
a processor (402);
a date remembrance component (404);
a sensor; and
a service component (112) that is stored in said data remembrance component and that is executable on said processor (402, said service component using a sensor interface (110) to obtain a reading from said sensor,
said sensor interface being provided by an operating system that is present at said machine (108), said service component generating a message (114) based on information that comprises a set of sensor readings, said set of sensor readings (202-206) comprising said reading, said service component receiving a subscription request from an application that executes on said machine, said service component providing said message to said application based on said service component having received set subscription request from said application.”
[3] “Inventive step” means a feature of an invention that involves technical advance as compared to the existing knowledge or having economic significance or both and that makes the invention not obvious to a person skilled in the art
[4] https://www.livelaw.in/pdf_upload/rhodia-operations-v-assistant-controller-of-patents-and-designs-523373-523590.pdf
[5] The abstract of prior art is as under:
“A wireless sensor network comprises a plurality of nodes that communicate over wireless communication links. At least one of the plurality of nodes receive sensor data from a sensor. A subscription for an event of interest occurring in the wireless sensor network is installed in the wireless sensor network. A publisher node
included in the plurality of nodes determines when the event of interest occurs and, when the event of interest occurs, publishes data related to the event of interest for a subscriber node included in the plurality of nodes.”
[6] The independent claims of significance in prior art are set out below: “1. A wireless sensor network comprising: A plurality of nodes that communicate over wireless communication links, wherein at least one of the plurality of nodes receive sensor data from the sensor; wherein a subscription for an event of interest occurring in the wireless sensor network is installed in the wireless sensor networks; wherein a publisher note included in the plurality of nodes determines when the event of interest occurs and, when the event of interest occurs, publishes data related to the event of interest for a subscriber note included in the plurality of nodes.
8. A wireless sensor node, comprising: a wireless transceiver to communicate over wireless communication link; a sensor interface to receive sensor data from a sensor; wherein when the wireless sensor node receives, from the wireless communication link, request comprising an event filter associated with an event of interest, the wireless sensor node filters the sensor data in order to determine when the event of interest occurs; and wherein when the event of interest occurs, the wireless sensor node transmits event data related to the event of interest to a requesting node over the wireless communication link.
