DETAILED ACTION
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 .
Response to Arguments
This office action is in response to amendments filed 08/03/2026. Claims 1, 3-17, 19-22 are pending.
Applicant’s arguments and amendments to the claims with respect to prior art rejections of Claims 1, 3-17, 19-20 under 35 USC 102/103 have been fully considered and are persuasive. The rejections of Claims 1, 3-17, 19-20 under 35 USC 102/103 have been withdrawn. However, upon further consideration, a new rejection is made in view of Wedewer et al (US 20120254108, hereinafter Wedewer)
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.
Claim(s) 1, 3-8, 17, 19-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wolter et al ( US 20200344293, hereinafter Wolter) in view of Wedewer et al (US 20120254108, hereinafter Wedewer)
Regarding Claim 1, Wolter teaches:
a control system (see at least " FIG. 1 is a block diagram illustrating an example robotic control system 100. " in par. 0030 ) comprising:
a robot controller configured to control a robot (see at least "For another example, one or more low-level controllers, such as the low-level controllers 130 and/or 140, may be implemented by one or more processors located on robots, such as processors 232, 242 of robots 230, 240. Further, databases for maintaining persistent and consistent records of intents and/or statuses of the controllers, such as the databases 160, may be implemented on the cloud computing system, such as in data 218, 228 of server computers 210, 220, and on the robots, such as in data 238, 248 of robots 230, 240." in par. 0041); and
a computation circuitry configured to communicate with the robot controller (see at least " For another example, one or more low-level controllers, such as the low-level controllers 130 and/or 140, may be implemented by one or more processors located on robots, such as processors 232, 242 of robots 230, 240. Further, databases for maintaining persistent and consistent records of intents and/or statuses of the controllers, such as the databases 160, may be implemented on the cloud computing system, such as in data 218, 228 of server computers 210, 220, and on the robots, such as in data 238, 248 of robots 230, 240." in par. 0041) ,
wherein the robot controller is implemented on circuitry physically independent from the computation circuitry (see at least " For example, using an Internet socket, the client computer 250 can connect to a service operating on remote server computers 210, 220 through an Internet protocol suite. " in par. 0054) ,
wherein the robot controller comprises a first memory in which state information of the robot is stored (see at least "each robot 230, 240 may be configured similarly to server computers 210, 220, with processors 232, 242, memories 234, 244, instructions 236, 246, and data 238, 248." in par. 0048), and
wherein the computation circuitry comprises: a second memory a content of which is synchronized with a content of the first memory (see at least “Still further, in some instances the one or more databases 160 may include both databases implemented on the cloud computing system and locally implemented on the robot, which may be synchronized to maintain a consistent record of the intents and states of the controllers.” In par. 0039 and "As shown, the server computer 210 may contain one or more processor 212, memory 214, and other components typically present in general purpose computers. The memory 214 can store information accessible by the processors 212, including instructions 216 that can be executed by the processors 212. Memory can also include data 218 that can be retrieved, manipulated or stored by the processors 212. The memory 214 may be a type of non-transitory computer readable medium capable of storing information accessible by the processors 212," in par. 0042),
wherein the first memory and the second memory are physically independent hardware memory devices (see at least " For example, using an Internet socket, the client computer 250 can connect to a service operating on remote server computers 210, 220 through an Internet protocol suite. " in par. 0054); and
a processor configured to execute an application that performs a computation related to control of the robot based on the content of the second memory that is synchronized with the content of the first memory independently of a request from the application. (see at least "Still further, in some instances the one or more databases 160 may include both databases implemented on the cloud computing system and locally implemented on the robot, which may be synchronized to maintain a consistent record of the intents and states of the controllers.” In par. 0039 and “For example, the controllers may be applications that can run on one or more processors, such as processors 212, 222 on a cloud system, or processors 232, 242 on robots.” In par. 0066 and “For instance, a controller may have a poll-based communication interface for interacting with the databases (where the controller lists and watches all resources and checks for differences)” in par. 0076 and “In this regard, the server adaptor 522 may use a poll-based communication interface when interacting with the database server(s) 530. For example, in instances where the server controller 520 is running on the robot, the server controller 520 may watch the database server running on the robot.” In par. 0082)
Wolter does not appear to explicitly teach all of the following, but Wedewer does teach:
wherein the robot controller is configured to periodically synchronize the content of the first memory with the content of the second memory via network communication independently of a request from the application, and wherein the computation circuitry is configured to periodically synchronize the content of the second memory with the content of the first memory via the network communication independently of a request from the application. (see at least " The synchronization for backups from the robot to the cloud storage service may take place on a configurable periodic basis, such as an hour or a day. This can be considered a scheduled synchronization because the synchronization is scheduled to take place on a synchronized basis. By default, the setting may be synchronization once per day. The scheduled synchronization can also check for updates that can be sent from the cloud to the robotic device. If there are any updates that need to be sent back to robot, the cloud-to-robot data will then be retrieved and synchronized." in par. 0023)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter to incorporate the teachings of Wedewer wherein the robot storage and cloud storage are synchronized on a default schedule independent from a specific request from an application. The motivation to incorporate the teachings of Wedewer would be to ensure the latest data is used and ensure no data is lost or corrupted (see par. 0014)
Regarding Claim 3, Wolter as modified by Wedewer (references to Wolter) teaches:
the control system according to claim 1,
wherein the computation circuitry is further configured to execute at least one of writing and reading of data to and from the second memory based on a request from the application. (see at least “Further in this regard, the server adaptor 522 may need to convert from using a request based communication interface to receive the status from the server controller 520 to a poll based communication interface to update the status of the database server 530. The server adaptor 522 may then update 551 the translated status of the database server(s) 530. For example, in instances where the server controller 520 is running on the robot, the server adaptor 522 may write the translated status to the database server running on the robot.” In par. 0086)
Regarding Claim 4, Wolter as modified by Wedewer (references to Wolter) teaches:
the control system according to claim 3, wherein the computation circuitry is further configured to:
store one or more applications including the application (see at least “For example, the controllers may be applications that can run on one or more processors, such as processors 212, 222 on a cloud system, or processors 232, 242 on robots.” In par. 0066) ;
notify, to one of the one or more applications, the content of the second memory associated with the one of the one or more applications (see at least "While watching for updates, the server adaptor 522 may receive a notification 545 of the updated intent. The server adaptor 522 may translate 546 the updated intent from a programming language of the database to a programming language of the server controller 520…For example, the server adaptor 522 may send the intent via a remote procedural call (RPC) method to the server controller 520. Based on the intent, the server controller 520 may actuate one or more mechanical and/or electrical components, or may send commands to another controller." in par. 0085).
Regarding Claim 5, Wolter as modified by Wedewer (references to Wolter) teaches:
the control system according to claim 3,
wherein the computation circuitry comprises an API corresponding to control of the robot, and is configured to, in response to receiving the request from the application via the API, write data corresponding to the request in the second memory. (see at least " In some instances, higher-level controllers of the robot may be deployed on the cloud, while the lower-level controllers of the robot may be deployed on the robot. The controllers may interact with each other through declarative APIs, which may define message format and other rules for the controllers.” In par. 0025 and “Referring to FIG. 5B, the client controller 510 may change 552 the intent for the server controller 520. For example, the client controller 510 may change the intent of the “move” object previously created to a new target position, or create a new object with the new intent. For instance, the client controller 510 may write a new intent based on the updated status. For example, the client controller 510 may determine that no box exists on shelf A, thus may change the intent to “pick up a box from shelf B.” For another instance, the client controller 510 may change the intent based on other factors, such as based on a new intent from a controller with a higher hierarchy than client controller 510, based on a user input, or based on detecting an emergency. The client adaptor 512 may translate 553 the received intent, and change 554 the intent of the database server(s) 530. For example, in instances where the client controller 510 is running on the cloud, the client adaptor 512 may write the changed intent to the database server running on the cloud.” In par. 0089)
Regarding Claim 6, Wolter as modified by Wedewer (references to Wolter) teaches:
the control system according to claim 3,
wherein the robot controller is further configured to write at least the state information of the robot in the first memory (see at least "Further, databases for maintaining persistent and consistent records of intents and/or statuses of the controllers, such as the databases 160, may be implemented on the cloud computing system, such as in data 218, 228 of server computers 210, 220, and on the robots, such as in data 238, 248 of robots 230, 240." in par. 0041) , and
wherein the computation circuitry is configured to, in response to the request from the application, acquire the state information from the second memory without transmitting a request for the state information to the robot controller, and to pass the state information to the application. (see at least "In order to resolve these issues, the one or more databases 160 may be configured to store and update the current states of the robotic control system 100, such as intents and statuses of the controllers in the robotic control system 100. Controllers in the robotic control system 100 may be configured to access the states stored in the database to control the robot. As such, in case of intermittent connectivity or failure at one of the controllers which may cause loss of the intents and statuses at the controller, other controllers and the failed controller upon recovery may be configured to access the databases 160 for the lost intents and statuses. To further protect the system from memory loss, the databases 160 may include one or more databases implemented on a cloud computing system. Still further, in some instances the one or more databases 160 may include both databases implemented on the cloud computing system and locally implemented on the robot, which may be synchronized to maintain a consistent record of the intents and states of the controllers. " in par. 0039 )
Regarding Claim 7, Wolter as modified by Wedewer (references to Wolter) teaches:
the control system according to claim 6,
wherein the robot controller is configured to write the state information in a first write area of the first memory (see at least "Further, databases for maintaining persistent and consistent records of intents and/or statuses of the controllers, such as the databases 160, may be implemented on the cloud computing system, such as in data 218, 228 of server computers 210, 220, and on the robots, such as in data 238, 248 of robots 230, 240." in par. 0041) , and
wherein the computation circuitry is configured to:
acquire the state information from a first read area of the second memory corresponding to the first write area, and pass the state information to the application (see at least “In order to resolve these issues, the one or more databases 160 may be configured to store and update the current states of the robotic control system 100, such as intents and statuses of the controllers in the robotic control system 100. Controllers in the robotic control system 100 may be configured to access the states stored in the database to control the robot. As such, in case of intermittent connectivity or failure at one of the controllers which may cause loss of the intents and statuses at the controller, other controllers and the failed controller upon recovery may be configured to access the databases 160 for the lost intents and statuses. To further protect the system from memory loss, the databases 160 may include one or more databases implemented on a cloud computing system. Still further, in some instances the one or more databases 160 may include both databases implemented on the cloud computing system and locally implemented on the robot, which may be synchronized to maintain a consistent record of the intents and states of the controllers. Additionally, the databases 160 may be further configured to store any other type of additional information, such as reference information (e.g., maps, images, information on other robots, etc.), which may be accessed by the controllers 110, 120, 130, 140 during operation." in par. 0039); and
write data based on the request from the application in a second write area different from the first read area in the second memory. (see at least "At some point as shown, the client controller 510 may “write” 542 an “intent” to the client adaptor 512. For instance, the client controller 510 may create an object and define the object's schema, such as a “move” object shown in FIG. 4A. For instance, the client controller 510 may do so by requesting to create or manipulate a “move” object, where various properties of the “move” object may be defined in the central repository. Further as shown in FIG. 4A, the intent may include desired states, such as to move to a target position. The client adaptor 512 may translate 543 the intent from a language of the client controller 510 to a language of the database.” in par. 0083 and “The database server(s) 530 may update one or more databases with the received intent. For example, where both controllers 510, 520 are running on the cloud, the database server on the cloud may update the cloud database with the received intent. For another example, where both controllers 510, 520 are running on the robot, the database server on the robot may update the robot database with the received intent. Still further, in instances where the client controller 510 is running on the cloud and the server controller 520 is running on the robot, the database server on the cloud may update the cloud database while the database server on the robot may update the robot database.” In par. 0084)
Regarding Claim 8, Wolter as modified by Wedewer (references to Wolter) teaches:
the control system according to claim 7,
wherein the data written based on the request from the application is control data generated by the application, and wherein the robot controller is further configured to read the control data from the first memory and generate a control command executable inside the robot controller for controlling the robot based on the read control data. (see at least "The low-level controllers 130 and 140 may be, for example, a wheel actuator and an arm actuator, respectively. For instance, the mid-level controller 120 may send a message to the low-level controller 130 that sets an intent of the low-level controller 130 to “rotate wheels 3 times.” For another instance, the mid-level controller 120 may also send a message to the low-level controller 130 that sets an intent of the low-level controller 140 to “extend arm.” in par. 0033 and “The low-level controllers 130, 140 may be configured to actuate mechanical and/or electrical components of the robot. For example, low-level controller 130 may actuate the wheels to rotate in order to reach shelf A, and the low-level controller 140 may actuate the arm to extend in order to pick up a box from shelf A.” in par. 0034 and “For example, the controllers may be applications that can run on one or more processors, such as processors 212, 222 on a cloud system, or processors 232, 242 on robots.” In par. 0066)
Regarding Claim 17, Wolter as modified by Wedewer also teaches:
A control method, comprising:
Implementing, step by step, each function of the system of Claim 1 (see Claim 1 analysis for rejection of the system)
Regarding Claim 19, Wolter as modified by Wedewer also teaches:
A method for implementing, step by step, each function of the system of Claim 3 (see Claim 3 analysis for rejection of the system)
Regarding Claim 20, Wolter as modified by Wedewer (references to Wolter) teaches:
A method for implementing, step by step, each function of the system of Claim 4 (see Claim 4 analysis for rejection of the system)
Regarding Claim 21, Wolter as modified by Wedewer (references to Wolter) teaches:
The control system according to claim 1,
wherein the computation circuitry is further configured to communicate with the robot indirectly via the robot controller. (see at least Continuing the warehouse example, the Enterprise Resource Management controller (high-level controller 110) may be configured to determine tasks that need to be completed by the fleet in the warehouse, such as “picking up a box from shelf A.” For example, the high-level controller 110 may also be configured to determine availabilities of various robots in the fleet for completing the task, and to select an available robot for the task. The high-level controller 110 may be configured to send a message to the mid-level controller 120 that controls the selected robot.” In par. 0031 and “The mid-level controller 120 may be, for example, a motion planner of the selected robot. For example, the message may “set” a desired state or “intent” of the mid-level controller 120 to “picking up a box from shelf A.” The mid-level controller 120 may be configured to receive sensor data from one or more sensors 150 in order to determine a current state, such as a current position, of the robot. Based on the current position, the mid-level controller 120 may be configured to determine a route for the robot in order to reach shelf A. The mid-level controller 120 may be configured to send one or more messages including instructions based on the determined route to one or more low-level controllers, such as low-level controllers 130 and 140.”in par. 0032 " For example, one or more high-level controllers, such as the high-level controller 110, and one or more mid-level controllers, such as the mid-level controller 120, may be implemented by one or more processors in a cloud computing system, such as by processors 212, 222 of server computers 210, 220." in par. 0041)
Regarding Claim 22, Wolter as modified by Wedewer (references to Wolter) teaches:
The control system according to claim 1,
wherein the computation circuitry is directly connected to the robot controller and indirectly connected to the robot, and wherein the robot controller is directly connected to the computation circuitry and to the robot. (see at least “For example, the client controller 510 may be the high-level controller 110 and the server controller 520 may be the mid-level controller 120 shown in FIG. 1. For another example, the client controller 510 may be the mid-level controller 120 and the server controller 520 may be the low-level controller 130 shown in FIG. 1.” In par. 0078 and " The client controller 510 and server controller 520 may be both running on a cloud computing system, such as on processors 212, 222, or both running on a robot, such as on processors 232, 242. Alternatively, the client controller 510 may be running on the cloud computing system while the server controller 520 may be running on the robot. As described below, where either or both client and server controllers are running the cloud computing system, states of both controllers may be stored and updated on a cloud database. In instances where both client and server controllers are running on the robot, states of the controllers may be stored and updated on a cloud database on a best effort basis, such as at regular intervals." in par. 0079 )
Claim(s) 9-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wolter et al ( US 20200344293, hereinafter Wolter) in view of Wedewer et al (US 20120254108, hereinafter Wedewer) and Francis (US 8380652, hereinafter Francis).
Regarding Claim 9, Wolter as modified by Wedewer teaches:
the control system according to claim 8,
Wolter as modified by Wedewer does not appear to explicitly teach all of the following, but Francis does teach:
wherein the robot controller is further configured to:
store a plurality of local commands, sequentially interpret each of the plurality of local commands into the control command (see at least "Higher level reasoning in block 604 then involves obtaining relational information as to the pertinent task steps necessary to effect "cleaning" This may be a subroutine from past cleaning experiences, which may be resident in the robot's memory, or drawn from some other relational resource (which could be another robot, for instance), or obtained from the cloud, as shown in block 608." And “A task sequencer program shown at block 614 could then be engaged to execute an output function for performing the task steps sequentially of cleaning the selected floor.” In col. 13 lines 7-30 ); and
control a motion of the robot based on both the control command interpreted from the first memory and the control command interpreted from the plurality of local commands. (see at least " Higher level reasoning then involves obtaining relational information as to the pertinent task steps necessary to effect "cleaning," including when to execute (block 700). This may be a subroutine from past "cleaning" experiences, which may be resident in the robot's memory, or drawn from some other relational resource (which could be another robot, for instance, a database, or the cloud). In a like manner, higher level reasoning involves obtaining relational information for pertinent task steps necessary for "walking," including when to execute (block 704). For instance, the robot may obtain electronic data from a user device as to where the "walking" is to take place, and when "walking" is typically effected.” In col. 13 lines 39-50 and “In some examples, the robot may determine which of the two, or more, potentially conflicting commands to execute, or to prioritize the execution of the two (or a plurality of commands) where prioritization is not provided in the command framework.” In col. 18 lines 4-8)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter as modified by Wedewer to incorporate the teachings of Francis wherein the robot receives and interprets command sequences both locally and from the cloud or remote user devices and resolves conflicting commands by scheduling more important tasks first. The motivation to incorporate the teachings of Francis would be enable the robot to prioritize actions that lead to more benefits or less harm to a situation (see col. 4 lines 54-60), which improves efficiency.
Regarding Claim 10, Wolter as modified by Wedewer teaches:
the control system according to claim 9, wherein the robot controller is further configured to:
Wolter as modified by Wedewer does not appear to explicitly teach all of the following, but Francis does teach:
prohibit input of the control command interpreted from the first memory while the robot is operating based on the control command interpreted from the plurality of local commands; and prohibit input of the control command interpreted from the plurality of local commands while the robot is operating based on the control command interpreted from the first memory. (see at least “As mentioned, robots (or any client computing device) may interact with the cloud and users to perform any number of functions. That includes attempting to respond to a situation or scenario where the robot has received potentially, or actually, conflicting commands which would otherwise call for simultaneous execution. In some examples, a method and system is described whereby the robot may autonomously resolve the conflict, as by concluding that one command can take precedence over the other, i.e., relaxing one or more constraints that would otherwise dictate the robot's response to a command. Example functions are described below.” col. 11 lines 21-31)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter as modified by Wedewer to incorporate the teachings Francis wherein the robot controller identifies conflicting commands requesting simultaneous execution and resolves the conflict. The motivation to incorporate the teachings of Francis would be enable the robot to prioritize actions that lead to more benefits or less harm to a situation (see col. 4 lines 54-60), which improves efficiency.
Regarding Claim 11, Wolter as modified by Wedewer and Francis teaches:
the control system according to claim 9,
wherein the application is configured to:
Wolter as modified by Wedewer does not appear to explicitly teach all of the following, but Francis does teach:
generate data to be used in control based on one of the plurality of local commands (see at least "Higher level reasoning in block 604 then involves obtaining relational information as to the pertinent task steps necessary to effect "cleaning" This may be a subroutine from past cleaning experiences, which may be resident in the robot's memory, or drawn from some other relational resource (which could be another robot, for instance), or obtained from the cloud, as shown in block 608." And “A task sequencer program shown at block 614 could then be engaged to execute an output function for performing the task steps sequentially of cleaning the selected floor.” In col. 13 lines 7-30 ); and
request the computation circuitry to write generated data in the second memory (see at least " A robot, such as a robot described and illustrated in FIGS. 2A-C, may connect to a network of computers (e.g., the cloud), and may request data or processing to be performed by the cloud. In one example, the robot may include a number of sensors and mechanical actuators that may generally provide motor control for the robot. The sensor inputs to the robot, such as camera feeds, vision sensors, touch sensors and other clothing probes, may be provided to the cloud, which can process these outputs to the cloud to enable the robot to extract information and perform functions. The cloud may process a camera feed, for example, to determine a location of a robot, perform object recognition as for an article of clothing, or to indicate a navigation pathway for the robot.” In col. 9 lines 23-35) , and
wherein the robot controller is configured to control the motion of the robot based on the generated data read from the first memory and the one of the plurality of local commands. (see at least " Higher level reasoning then involves obtaining relational information as to the pertinent task steps necessary to effect "cleaning," including when to execute (block 700). This may be a subroutine from past "cleaning" experiences, which may be resident in the robot's memory, or drawn from some other relational resource (which could be another robot, for instance, a database, or the cloud). In a like manner, higher level reasoning involves obtaining relational information for pertinent task steps necessary for "walking," including when to execute (block 704). For instance, the robot may obtain electronic data from a user device as to where the "walking" is to take place, and when "walking" is typically effected.” In col. 13 lines 39-50 and “In some examples, the robot may determine which of the two, or more, potentially conflicting commands to execute, or to prioritize the execution of the two (or a plurality of commands) where prioritization is not provided in the command framework.” In col. 18 lines 4-8)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter as modified by Wedewer to incorporate the teachings Francis wherein the robot controller requests cloud processing to determine navigation commands and identifies conflicting commands requesting simultaneous execution and resolves the conflict. The motivation to incorporate the teachings of Francis would be enable the robot to prioritize actions that lead to more benefits or less harm to a situation (see col. 4 lines 54-60), which improves efficiency.
Regarding Claim 12, Wolter as modified by Wedewer teaches:
the control system according to claim 9, wherein the robot controller comprises:
Wolter as modified by Wedewer does not appear to explicitly teach all of the following, but Francis does teach:
a local control mode in which the robot controller controls the motion of the robot based on the control command interpreted from the plurality of local commands and an application control mode in which the robot controller controls the motion of the robot based on the control command interpreted from a computation result by the application that is stored in the first memory. (see at least " As an example, using the object recognition application of FIG. 5, the robot may execute software to perform immediate function calls, such as OrientObject( ) which may return information associated with an object (e.g., placing it right-side up), or RotateObject( ) which may cause the robot to pick up the object and obtain further views/sensory inputs. These immediate functions could be done through local processing within the robot, or by enabling function calls and operation through the cloud, which may facilitate control and operation of the robot without having to control or tie-up more limited computational capacities of the robot, for example." in col. 15 lines 48-59 )
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter as modified by Wedewer to incorporate the teachings Francis wherein the robot controller processes some less computationally complex high-level commands locally while more detailed command processing is done in the cloud. The motivation to incorporate the teachings of Francis would be to more efficiently use the computational capacities of the robot (see co. 15 lines 48-49)
Regarding Claim 13, Wolter as modified by Wedewer and Francis teaches:
the control system according to claim 12,
Wolter does not appear to explicitly teach all of the following, but Wedewer does teach:
wherein the robot controller is further configured to generate a response corresponding to the data read from the first memory and write the response in the first memory (see at least "A synchronization request can be sent with the data to a robotic synchronization service on the robotic device, as in block 220. Alternatively, the synchronization request can be sent and the data can be sent independently. As a result of this synchronization request, the data can also be stored on the robotic device's storage system, as in block 230." in par. 0038) , and
wherein the computation circuitry is configured to read the response from the second memory, which has been synchronized from the first memory and to pass the response to the application that has requested to write the data in the second memory. (see at least " FIG. 3 illustrates a further example of synchronizing information captured via an application 304. The application may obtain a picture or photo that is sent to a datastore API 306 in the robotic device with a request to store the picture. This request can be forwarded to the robot's application 308 and the picture can be stored in a robotic device datastore 310. A notification can also be sent to subscribers for the local data stream and one of those can be synchronization service 312 for the robotic device. The robotic device can add the file to the synchronization list, and the service can wake up. The file can be examined and the version can be validated. A request can be made to the cloud as to whether the file can be synched. Then the file can be sent for synchronization to the cloud synchronization service 314. Then the file can be stored in the cloud storage service 316 and the appropriate cleanup can take place. If the file is not the most current version, then the current version of the file can be sent to the robotic device to be synchronized and stored on the robotic device. " in par. 0049)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter as modified by Wedewer and Francis to incorporate the teachings of Wedewer wherein an application requests syncing data between the robot and the cloud to make sure both have the most up to date version of a file. The motivation to incorporate the teachings of Wedewer would be to improve conflict resolution between versions of data stored in the robot memory and cloud memory (see par. 0030)
Regarding Claim 14, Wolter as modified by Wedewer and Francis teaches:
the control system according to claim 12,
Wolter as modified by Wedewer does not appear to explicitly teach all of the following, but Francis does teach:
wherein the computation circuitry is configured to: queue, in a request storage, a plurality of requests from one or more applications including the application (see at least " The cloud 102 may represent a networked computer architecture, and in one example, the cloud service 104 represents a queue for handling requests from client devices." in col. 5 line 66 to col. 6 line 2) ;
sequentially dequeue the plurality of requests from the request storage and write data corresponding to the dequeued request in the second memory. (see at least " More particularly, but without limitation, the robot may determine which commands of the two conflicting commands to perform, or determine to do none, using contextual/situational data obtained from the environment of the robotic apparatus, and/or a user, making the determination through processing in a cloud computing system." in col. 14 lines 9-14 )
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter as modified by Wedewer to incorporate the teachings Francis wherein the cloud queues requests for robot action from applications and determines a sequential order and timing for the actions to be performed based on their priorities. The motivation to incorporate the teachings of Francis would be to finish tasks in a more efficient order based on contextual information of the tasks and the environment (see col. 14 lines 40-59)
Regarding Claim 15, Wolter as modified by Wedewer and Francis teaches:
the control system according to claim 14,
Wolter as modified by Wedewer does not appear to explicitly teach all of the following, but Francis does teach:
wherein the computation circuitry is configured to, in response to reading a response from the second memory, dequeue, from the request storage, a request subsequent to a request corresponding to the response. (see at least " In some examples, the robot may assess a first benefit associated with performing a first command of the plurality of commands, and assess a second benefit associated with performing a second command of the plurality of commands. Based upon these assessments, the robot can then determine whether the second benefit exceeds the first benefit, and if so, set the time of execution for the first command to a suspended state. The foregoing method and system may further include obtaining sensory input data over time via at least one sensory device of the robotic system during the suspended state of the first command, and in response to the sensory input data, determining whether the first constraint is no longer in conflict, and if not, executing the first command." in col. 15 lines 6-17)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter as modified by Wedewer to incorporate the teachings Francis wherein the cloud queues requests for robot action from applications and sequentially performs a plurality of actions based on contextual information. The motivation to incorporate the teachings of Francis would be to finish tasks in a more efficient order based on contextual information of the tasks and the environment (see col. 14 lines 40-59)
Regarding Claim 16, Wolter as modified by Wedewer and Francis teaches:
the control system according to claim 14,
Wolter as modified by Wedewer does not appear to explicitly teach all of the following, but Francis does teach:
wherein the computation circuitry is configured to, if the request is a request for reading the state information of the robot, read the state information from the second memory without queuing the request, and to pass the state information to the application that has made the request. (see at least " In this manner, each robot 402, 404, 406 and 408 shares experiences with each other to enable learned behaviors. Robot 402 makes an assessment or determination based upon the observed object and/or user, which is then shared with the other robots 404, 406, and 408 (through the cloud 410). Each robot 402, 404, 406, and 408 will have access to real-time up to date data. One or more of these other robots may then proceed to perform some further function, such as picking up the object, and performing a task with the object. In another example, the robot 404 can download data indicating images seen by the other robots 402, 406, and 408 to help the robot 404 better identify an object using various views (e.g., in instances in which the robots 402, 406, and 408 have captured images of the objects from a different perspective)." in col. 10 lines 22-35 and “Thus, in some examples, robots may share new or learned behaviors through the cloud 410. The cloud 410 may have a server that stores robot learned activities or behaviors resulting in a shared knowledge-base of behaviors and heuristics for object interactions (e.g., a robot "app store"). Specifically, a given robot may perform actions and build a compendium related to an article of clothing, and then the robot can upload the data to the cloud 410 to share this knowledge with all other robots. In this example, a transportation of the given robot's "consciousness" can be made through the cloud 410 from one robot to another (e.g., robot "Bob" builds up a "map" of some clothing, and the knowledge of "Bob" can be downloaded onto another robot to receive knowledge of the "map").” In col. 11 lines 3-16)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system taught by Wolter as modified by Wedewer to incorporate the teachings Francis wherein robots can request sensor data from the cloud that comes from other robots. The motivation to incorporate the teachings of Francis would be enable faster adaptation by sharing data and learned experiences between the robots through a shared knowledge-base in the cloud (see col. 10 lines 45-48).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DYLAN M KATZ whose telephone number is (571)272-2776. The examiner can normally be reached Mon-Thurs. 8:00-6:00.
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, Abby Lin can be reached on (571) 270-3976. 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.
/DYLAN M KATZ/Examiner, Art Unit 3657
