Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-18 are pending in Instant Application.
Priority
Examiner acknowledges Applicant’s claim to priority benefits of EP22211749.1 filed 12/06/2022.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 12/05/2023 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered if signed and initialed by the Examiner.
Claim Rejections - 35 USC § 101
Claims 1-11 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
The language of claims 1-11 raises a question as to whether the claims are directed merely to an abstract idea that is not tied to a technological art, environment or machine which would result in a practical application producing a concrete, useful, and tangible result to form the basis of statutory subject matter under 35 U.S.C. 101.
The applicant claims “a data provision apparatus”, “a device-side data communication unit”, but does not define within the body of the claim the hardware in which the invention runs. Thus, absent recitation of the server or some other hardware, claims 1-11 are not limited to a tangible embodiment, instead being sufficiently broad to encompass software, per se.
Furthermore in the application in Paragraph 50 of the specification states that “a possible implementation for the structure or architecture of the web-based working device system with some individual components that may be partially or wholly designed using hardware or software, depending on requirements.” And in Para.11, “the data provision apparatus may in this case comprise, in a manner known per se, further services implemented in software and/or hardware, such as object memories, programming interfaces, microservices and/or SQL (Structured-Query-Language) or noSQL databases.” in which the claims recite “apparatus” and “units” can be considered as software.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims, 1-5, 8-9, 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over Pi-Sunyer (U.S. patent Application: 20150370615) in view of Suzuki (U.S. patent Application: 20070047567).
As per Claim 1, Pi-Sunyer discloses a web-based working device system, comprising:
at least one working device (Pi-Sunyer, Para.110, a system 140 where an API may be used to access and/or control one or more smart devices. In the illustrated example, a person may desire to access a number of smart home devices 10, such as a first smart home device (e.g. thermostat 10A) and second smart home devices (e.g., Smoke and/or CO detector 10B).);
a data provision apparatus for providing device information data and operational setting data relating to the working device (Pi-Sunyer, Para.142, The client may then make API calls to the device service 84 including the access token to retrieve and/or input data into the data model. For example, the client may request to see the current temperature and/or the target_temperature using an API call and the access token which provides thermostat read permissions. As a result, the current temperature and/or the target_temperature may be returned by the device service 84 and displayed on the client site/app 308, Para.239, a device identifier (device_id:String) may be associated with the thermostat 10A and/or detector 10B. The device_id element holds the unique identifier of the particular device, Para.114, the smart home devices 10A and/or 10B may occasionally transmit device operation status parameters 156 or other data based on the device operation status parameters 156 through the device service 84 and the proper application service (e.g., first application service 146 and/or second application service 152) to the proper applications (e.g., first application 142 and/or second application 148).);
a device-side data communication unit and a long-range data exchange connection between the device-side data communication unit and the data provision apparatus (Pi-Sunyer, Para.63, Through the Internet 62, the smart devices can communicate with a central server or a cloud-computing system 64. The central server or cloud-computing system 64 can be associated with a manufacturer, support entity, or service provider associated with the device.);
a device app with read/write access to the operational setting data relating to the working device in the data provision apparatus (Pi-Sunyer, Para.170, if the client 318 is designed to set device values or status, the developer may choose a “read/write” permission for those elements and choose a scope including read/write permissions to the associated element paths, Para.159, The client application 352 can now make resource requests from the data model via the device service 84 providing the access token as a request parameter to the API 90 and/or the device service 84 (event 10 380). The device service 84 and/or the API 90 may analyze the access token and return the requested resources from the data model based on the permissions granted to the client application 352 (event 11 382).);
a user terminal for user-side operation of the device app (Pi-Sunyer, Para.104, a person may interact with smart thermostats, lighting systems, alarm systems, entertainment systems, and a variety of other electronic devices. To interact with some of these electronic devices, a person may communicate a command using an application program running on another electronic device. For instance, a person may control the temperature setting on a smart thermostat using an application program running on a smartphone. The application program may communicate with a secure online service that interacts with that thermostat.);
a service app with read access to the device information data in the data provision apparatus (Para.15, a system 180 that uses an API 90 to access one or more device services 84 to request data from, control, and/or store data that may be useful to the smart devices, in accordance with an embodiment, Para.99, the APIs 90 allow applications executed by the third parties to initiate specific data processing tasks that are executed by the central server or the cloud-computing system 64, as well as to receive dynamic updates to the home data 82 and the derived home data 88.) and with write access to the operational setting data relating to the working device that are provided by the data provision apparatus, wherein the write access requires a user-side access enable via the device app (Pi-Sunyer, Para.118, target temperature, the desired temperature, typically set by the user may be modified using the API 90. From the API 90, applications can write the target_temperature as part of a larger process, Para.135, if the client 182 sends a request to write a new target_temperature to a thermostat 10A that is one degree above the current target temperature, but then immediately sends another request that cancels the prior request (e.g., reduces the target_temperature down one degree), the requests may be cancelled out without waking the thermostat 10A (assuming both requests are received by the device service 84 in a buffer window prior to the thermostat 10A wake). In some embodiments, the buffer window may be 2-3 seconds.);
a service terminal for service-side operation of the service app (Para.113, the device service 84 may serve as the point of contact that application programs may use to access the smart home devices 10A and/or 10B. The device service 84 then may communicate information and/or commands provided by the applications to the smart home devices 10A and/or 10B, enabling coordination between the applications and the devices 10A and/or 10B.).
However Pi-Sunyer does not disclose temporary write access to the operational setting data relating to the working device.
Suzuki discloses temporary write access to the operational setting data relating to the working device (Suzuki , Para.90, the user of a lower level is authorized to change the management setting information in the temporary mode (S57: Yes), the process goes to a step of S58 to overwrite only the currently used management setting information in the management setting memory 12b with the changed management setting information without changing the management setting data for the restoring operation 53a in the EEPROM 53 as a changing operation in the temporary mode.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Pi-Sunyer with the teachings as in Suzuki. The motivation for doing so would have been for providing an improved network management system configured to efficiently prevent a trouble that might be caused for such a reason that a precedent user of a network forgets to restore management settings for the network that have temporarily been changed, when a next user utilizes the network. (Suzuki, Para.8).
As per Claim 2, Pi-Sunyer in view of Suzuki discloses the web-based working device system according to claim 1, wherein the device-side data communication unit is located in the working device or is formed by a communication intermediate station which is assigned a short-range data exchange connection to the working device (Pi-Sunyer Para.35, The network interface 18 may include a component that enables the device 10 to communicate between devices. As such, the network interface 18 may enable the device 10 to communicate with other devices 10 via a wired or wireless network. The network interface 18 may include a wireless card or some other transceiver connection to facilitate this communication, Para.51, the smart-home environment 30 may include a pool heater monitor 34 that communicates a current pool temperature to other devices within the smart-home environment 30 or receives commands for controlling the pool temperature.).
With respect to Claim 14 is substantially similar to Claim 2 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 3, Pi-Sunyer in view of Suzuki discloses the web-based working device system according to claim 1, wherein the write access of the service app to the operational setting data relating to the working device includes an access request from the service app to the device app for the working device, wherein the access request requires user-side enable (Para.118, target temperature, the desired temperature, typically set by the user may be modified using the API 90. From the API 90, applications can write the target_temperature as part of a larger process, Para.135, if the client 182 sends a request to write a new target_temperature to a thermostat 10A that is one degree above the current target temperature, but then immediately sends another request that cancels the prior request (e.g., reduces the target_temperature down one degree), the requests may be cancelled out without waking the thermostat 10A (assuming both requests are received by the device service 84 in a buffer window prior to the thermostat 10A wake). In some embodiments, the buffer window may be 2-3 seconds, Para.33, The user-interface components 14 may also include one or more buttons (e.g., up and down buttons), a keypad, a number pad, a switch, a microphone, and/or a camera (e.g., to detect gestures). In one embodiment, the user-interface component 14 may include a click-and-rotate annular ring component that may enable the user to interact with the component by rotating the ring (e.g., to adjust a setting) and/or by clicking the ring inwards (e.g., to select an adjusted setting or to select an option).).
However Pi-Sunyer does not disclose temporary write access.
Suzuki discloses temporary write access (Suzuki , Para.90, the user of a lower level is authorized to change the management setting information in the temporary mode (S57: Yes), the process goes to a step of S58 to overwrite only the currently used management setting information in the management setting memory 12b with the changed management setting information without changing the management setting data for the restoring operation 53a in the EEPROM 53 as a changing operation in the temporary mode.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Pi-Sunyer with the teachings as in Suzuki. The motivation for doing so would have been for providing an improved network management system configured to efficiently prevent a trouble that might be caused for such a reason that a precedent user of a network forgets to restore management settings for the network that have temporarily been changed, when a next user utilizes the network. (Suzuki, Para.8).
The same motivation that was utilized for combining Pi-Sunyer and Suzuki as set forth in claim 1 is equally applicable to claim 3.
As per Claim 4, Pi-Sunyer in view of Suzuki discloses the web-based working device system according to claim 3, wherein the access request is a token-based access request and is selectable via a jump in the service app to the device app (Pi-Sunyer, Para.142, The resource access permission page 304, which is described in detail below, may display the permission and one or more justifications for the permission entered when the client was registered in the data model. If the user accepts the permission requested for the client, an authorization code may be returned from the authorization server to the user, which passes the authorization code to the client, and the client exchanges the authorization code and a client secret for an access token. The client may then make API calls to the device service 84 including the access token to retrieve and/or input data into the data model. For example, the client may request to see the current temperature and/or the target_temperature using an API call and the access token which provides thermostat read permissions.).
With respect to Claim 15 is substantially similar to Claim 4 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 5, Pi-Sunyer in view of Suzuki discloses the web-based working device system according to claim 3, wherein the device information data comprise device identification data which are used by the service app to identify the working device for at least one of the access request to the device app and the write access to the operational setting data relating to the working device that are provided by the data provision apparatus (Pi-Sunyer, Para.223, Each of the devices and/or structures has an associated unique identifier, which enables the API calls to be accurately routed to the proper device object, Para.239, a device identifier (device_id:String) may be associated with the thermostat 10A and/or detector 10B. The device_id element holds the unique identifier of the particular device, Para.99, the APIs 90 allow applications executed by the third parties to initiate specific data processing tasks that are executed by the central server or the cloud-computing system 64, as well as to receive dynamic updates to the home data 82 and the derived home data 88, Para.250, the device service 84 responds with a data object including data objects from the data model (e.g., a metadata data object, a devices data object, a structures data object) based on the request and scopes associated with the access token. Further, in some embodiments the clients 182 may perform a function in addition to displaying the returned data in a page, such as controlling a setting on the API client device based on the data, executing a control action on the API client device based on the data, and the like.).
However Pi-Sunyer does not disclose temporary write access.
Suzuki discloses temporary write access (Suzuki , Para.90, the user of a lower level is authorized to change the management setting information in the temporary mode (S57: Yes), the process goes to a step of S58 to overwrite only the currently used management setting information in the management setting memory 12b with the changed management setting information without changing the management setting data for the restoring operation 53a in the EEPROM 53 as a changing operation in the temporary mode.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Pi-Sunyer with the teachings as in Suzuki. The motivation for doing so would have been for providing an improved network management system configured to efficiently prevent a trouble that might be caused for such a reason that a precedent user of a network forgets to restore management settings for the network that have temporarily been changed, when a next user utilizes the network. (Suzuki, Para.8).
The same motivation that was utilized for combining Pi-Sunyer and Suzuki as set forth in claim 1 is equally applicable to claim 5.
As per Claim 8, Pi-Sunyer in view of Suzuki discloses the web-based working device system according to claim 1, wherein the user terminal is a smart device (Pi-Sunyer, Para.111, the second application 148 may be a third party home-automation application that may be running on a portable electronic device, such as a personal mobile device. The second application 148 may generate device request messages 150, such as commands to control or request information from the smart home devices 10A and/or 10B. The second application service 152 may interface with the device service 84 by way of an API, as mentioned above.).
As per Claim 11, Pi-Sunyer in view of Suzuki discloses the web-based working device system according to claim 1, wherein the long-range data exchange connection is an Internet connection (Pi-Sunyer, Para.12, controlling and/or accessing the smart home environment using services over the internet, in accordance with an embodiment;).
With respect to Claim 13 is substantially similar to Claim 11 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 9, Pi-Sunyer in view of Suzuki discloses the web-based working device system according to claim 1, wherein the at least working device is an autonomous working device or a gardening or forestry tool or a construction working device or a DIY device (Pi-Sunyer, Para.77, the air monitor/purifier service robot 69 can be configured to detect whether a household pet is moving toward the currently settled location of the occupant (e.g., using on-board sensors and/or by data communications with other smart-home sensors along with rules-based inferencing/artificial intelligence techniques), and if so, the air purifying rate is immediately increased in preparation for the arrival of more airborne pet dander).
As per Claim 12, Pi-Sunyer discloses a data access method for accessing operational setting data relating to a working device that are provided by a data provision apparatus via a service app, the method comprising the steps of:
transmitting, on a user side, a service request comprising identification information and service request information for the working device (Pi-Sunyer, Para.142, The client may then make API calls to the device service 84 including the access token to retrieve and/or input data into the data model. For example, the client may request to see the current temperature and/or the target_temperature using an API call and the access token which provides thermostat read permissions. As a result, the current temperature and/or the target_temperature may be returned by the device service 84 and displayed on the client site/app 308, Para.239, a device identifier (device_id:String) may be associated with the thermostat 10A and/or detector 10B. The device_id element holds the unique identifier of the particular device, Para.114, the smart home devices 10A and/or 10B may occasionally transmit device operation status parameters 156 or other data based on the device operation status parameters 156 through the device service 84 and the proper application service (e.g., first application service 146 and/or second application service 152) to the proper applications (e.g., first application 142 and/or second application 148).);
receiving, on a service side, the service request, and sending an access request from the service app to a relevant device app for write access to the operational setting data relating to the working device that are provided by the data provision apparatus (Pi-Sunyer, Para.111, a first application 142 sends a first device request message 144 targeted to a smart home device 10 (e.g., the smart home device 10A) into cloud service(s) 145 and, more specifically, to a first application service 146. A second application 148 may be used to issue a second device request message 150 targeted to a smart home device 10 (e.g., the smart home device 10A) to a second application service 152 also among the cloud service(s) 145, Para.144, the smart home devices 10A and/or 10B may occasionally transmit device operation status parameters 156 or other data based on the device operation status parameters 156 through the device service 84 and the proper application service (e.g., first application service 146 and/or second application service 152) to the proper applications (e.g., first application 142 and/or second application 148).);
wherein the access request is received on the user side via the device app and the requested write access to the operational setting data relating to the working device that are provided by the data provision apparatus is enabled (Pi-Sunyer, Para.118, target temperature, the desired temperature, typically set by the user may be modified using the API 90. From the API 90, applications can write the target_temperature as part of a larger process, Para.135, if the client 182 sends a request to write a new target_temperature to a thermostat 10A that is one degree above the current target temperature, but then immediately sends another request that cancels the prior request (e.g., reduces the target_temperature down one degree), the requests may be cancelled out without waking the thermostat 10A (assuming both requests are received by the device service 84 in a buffer window prior to the thermostat 10A wake). In some embodiments, the buffer window may be 2-3 seconds.),
wherein the operational setting data relating to the working device in the data provision apparatus is changable by the service app by write access during the enabled write access corresponding to the service request information (Pi-Sunyer, Para.118, target temperature, the desired temperature, typically set by the user may be modified using the API 90. From the API 90, applications can write the target_temperature as part of a larger process, Para.135, if the client 182 sends a request to write a new target_temperature to a thermostat 10A that is one degree above the current target temperature, but then immediately sends another request that cancels the prior request (e.g., reduces the target_temperature down one degree), the requests may be cancelled out without waking the thermostat 10A (assuming both requests are received by the device service 84 in a buffer window prior to the thermostat 10A wake). In some embodiments, the buffer window may be 2-3 seconds.);
However Pi-Sunyer does not disclose temporary write access to the operational setting data relating to the working device and the enabled temporary write access is automatically terminated after a predefined enable period has expired.
Suzuki discloses temporary write access to the operational setting data relating to the working device (Suzuki , Para.90, the user of a lower level is authorized to change the management setting information in the temporary mode (S57: Yes), the process goes to a step of S58 to overwrite only the currently used management setting information in the management setting memory 12b with the changed management setting information without changing the management setting data for the restoring operation 53a in the EEPROM 53 as a changing operation in the temporary mode.) and wherein the enabled temporary write access is automatically terminated after a predefined enable period has expired (Suzuki , Para.34, when the user wishes to temporarily change the management setting information for some operations, the changed management setting information, which is unnecessary after completing the aforementioned operations, is desired to be immediately restored to the previous condition. In this case, a predetermined time period may be set such that the management setting information changed by the input operation to perform the aforementioned operations can be maintained for the predetermined time period, and thereafter, the changed information is automatically restored to predetermined management setting information before being changed. Optionally, the management setting information restoring system may be configured to judge that the predetermined restoring condition is satisfied in response to the predetermined time period elapsing after the management setting information has been changed by the management setting information changing system.).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Pi-Sunyer with the teachings as in Suzuki. The motivation for doing so would have been for providing an improved network management system configured to efficiently prevent a trouble that might be caused for such a reason that a precedent user of a network forgets to restore management settings for the network that have temporarily been changed, when a next user utilizes the network. (Suzuki, Para.8).
As per Claim 16, Pi-Sunyer in view of Suzuki discloses the data access method according to claim 12, wherein the service app uses device identification data as device information data for identifying the working device for at least one of the access request to the device app and the temporary write access to the operational setting data relating to the working device that are stored in the data provision apparatus (Para.124, a system 180 that uses an API 90 to access one or more device services 84 to request data from, control, and/or store data that may be useful to the smart devices (e.g., thermostat 10A, smoke and/or CO detector 10B, and/or other device 10C). As discussed above, the system 180 may be useful to enable one or more clients 182 (e.g., third-party client and/or a principle client of the device service 84) to: provide data 184 for use in the device services 84 (e.g., to a data store (e.g., data warehouse 185), to storage of one or more of the smart devices, and/or to a data model of the device service 84), provide a request 186 to control one or more of the smart devices via the device service 84, and/or to receive data 188 from one or more of the smart devices via the device service 84, Para.113, the device service 84 may serve as the point of contact that application programs may use to access the smart home devices 10A and/or 10B. The device service 84 then may communicate information and/or commands provided by the applications to the smart home devices 10A and/or 10B, enabling coordination between the applications and the devices 10A and/or 10B.).
Claims 10 is rejected under 35 U.S.C. 103 as being unpatentable over Pi-Sunyer (U.S. patent Application: 20150370615) in view of Suzuki (U.S. patent Application: 20070047567) and further in view of Gustavsson et al., “hereinafter Gustavsson”( U.S. patent Application: 20180129199).
As per Claim 10, Pi-Sunyer in view of Suzuki discloses the web-based working device system according to claim 9,
However Pi-Sunyer in view of Suzuki does not disclose at least one working device is a robotic lawnmower or a chainsaw.
Gustavsson (20180129199) discloses at least one working device is a robotic lawnmower or a chainsaw (Para.10, the robotic work tool is a robotic lawnmower.).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Pi-Sunyer, Suzuki with the teachings as in Gustavsson. The motivation for doing so would have been for executing a mobile application for controlling a robotic work tool according to above, wherein the controller is configured to: receive an error signal through said wireless communication interface from said robotic work tool; display an error status on the display; disable functions relating to an operating state; receive a reset signal through said wireless communication interface from said robotic work tool; and in response thereto enable the functions relating to an operating state.
Allowable Subject Matter
Claims 6, 7, 17, 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NORMIN ABEDIN whose telephone number is (571)270-5970. The examiner can normally be reached Monday to Friday from 10 am to 6 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Vivek Srivastava can be reached at 5712727304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NORMIN ABEDIN/Primary Examiner, Art Unit 2449