DETAILED ACTION
Remarks
Applicant’s amendment and response dated 12/08/2025 has been provided in response to the 9/08/2028 Office Action which rejected claims 1-10, wherein claims 1, 2, 5, 6, 9, and 10 have been amended. Thus, claims 1-10 remain pending in this application and have been fully considered by the examiner.
Applicant's arguments have been fully considered but they are not persuasive.
Accordingly, the rejection of the claims over the prior art in the previous office action is maintained and THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Response to Arguments
Applicant's arguments filed 12/08/2025 have been fully considered but they are not persuasive.
In response to Applicant’s arguments regarding claim 1 that “The rejection cited French col. 6, lines 6-10 as disclosing: extracts OS information, hardware information, software information. (See Office Action, page 6.) In the above-noted portion, French discloses: The target device may be scanned for at least one hardware configuration. The target device may be scanned for at least one software configuration. An architecture of the target device may be determined. At least one network policy for the target device may be determined ... Applicant respectfully submits that the above portion of French does not disclose or suggest that the above scanning involves extracting OS information. For example, the noted portion discloses (1) scanning for at least one hardware configuration and (2) scanning for at least one software configuration. However, French does not disclose or suggest that (1) the scanning for at least one hardware configuration or (2) the scanning for at least one software configuration involves extracting OS information. Further regarding extracts OS information, hardware information, software information -- the rejection additionally cited French col. 9, lines 50-56. (See Office Action, page 6.) In the above-noted portion, French discloses:
... boot server 107 may be able to examine configuration files of target devices attached to the network and determine the OS of each target device. Boot server 107 may also be able to examine one or more inventory databases 116 of hardware scan information or other such configuration information corresponding to one or more target devices ...
Applicant respectfully submits the above portion of French does not disclose or suggest that the above scanning involves extracting OS information from a first signal that is received from the first robot. With respect to determining the OS of a target device, the noted portion of French discloses examining a configuration file of the target device. According to French, the configuration file is included in an inventory database 116. (See, e.g., French, col. 8, lines 40-48.) As such, French discloses determining the OS of target device by examining a corresponding configuration file that is included in an inventory database 116. Applicant respectfully submits that such determining, as disclosed in French, is not analogous to extracting OS information from a first signal that is received from the target device (e.g., the first robot).” see pages 9-10 of Applicant’s remarks, the examiner respectfully disagrees.
The Hickman and French references were used in combination to teach the limitations as
claimed. In particular, Hickman was cited to teach a first signal that is received from the first robot (see e.g. Fig.1 and associated text, e.g. col.20 lines 54-57), French was cited to teach “based on absence of the software image, the controller extracts the OS information, the hardware information, and the software information” (see e.g. col.6 lines 6-10 and col.9 lines 50-56), and the Applicant should please note that one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Also, for further clarification, French discloses that “boot server 107 may also comprise or be in communication with one or more software processes (daemon) that monitor hardware and software scan data reported by one or more target devices; the daemon may create a boot definition from the scan data reported by the target device which may be used to define the target device” (See e.g. col.11 lines 26-36), which would include the operating system of the target device, “boot server 107 may also comprise or be in communication with one or more storage units or databases, 106, 116, 126. In one embodiment of the invention, the database may be provided with tables that may be used by boot server 107 (or a daemon of boot server 107) to map the installed hardware and software on the target device as reported by hardware and/or software scans” (see e.g. col.11 lines 36-42), and also that “the boot server or the server daemon may receive a boot report from the target device. In one embodiment of the invention, this report is received after the initial NBP on the target device transfers execution to scan code which scans the hardware and software installed on the target device. The boot report may comprise a report detailing the hardware and/or software scan results. The boot report may also be any suitable report to boot server 107 or server daemon that describes the hardware and software profile of the target device. The boot report may take the form of, for example, a UDP transfer of the scan results of the target device (see e.g. col.15 lines 45-56), which would include the operating system of the target device. As such, the combination of references teaches the limitations as claimed and the rejection of record is maintained.
Claim Rejections - 35 USC § 103
5. 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.
6. Claims 1, 2, and 4-10 are rejected under 35 U.S.C. 103 as being unpatentable over Hickman et al. (US Patent 8,380,349 B1) in view of French et al. (US Patent US 6,988,193 B2).
As to claim 1, Hickman teaches a cloud server (e.g. cloud 102) connected to at least one robot (e.g. robot client 118, See Figs.1, 12, 14 and associated text, e.g. col.20 lines 15-28: Method 1200, shown in FIG. 12, presents an embodiment of a method that, for example, could be used with the systems 100 and 400, and may be performed by a device, such as another device illustrated in FIGS. 1-4, or components of the device. The various blocks of method 1200 may be combined into fewer blocks, divided into additional blocks, and/or removed based upon the desired implementation. In addition, each block may represent a module, a segment, or a portion of program code, which includes one or more instructions executable by a processor for implementing specific logical functions or steps in the process. The program code may be stored on any type of computer readable medium, for example, such as a non-transitory storage device including a disk or hard drive), the cloud server comprising:
a communicator configured to transmit and receive data to and from the at least one robot and an external device (See e.g. col.6 lines 65-col.7 line 4: communication links between client devices and the cloud 102 may include wired connections, such as a serial or parallel bus. Communication links may also be wireless links, such as link 120, which may include Bluetooth, IEEE 802.11 (IEEE 802.11 may refer to IEEE 802.11-2007, IEEE 802.11n-2009, or any other IEEE 802.11 revision), or other wireless based communication links; and col.26 lines 51-53:The cloud 1406 is configured to receive data, such as robot identifiers and location inputs, from a robot 1402 and/or a computing device 1404); and
a controller (See e.g. col.2 lines 50-53: The system may also include program instructions stored on the non-transitory computer-readable medium and executable by at least one processor and col.6 lines 6-9: The cloud platform 106 may include a frontend of the cloud and may be coupled to the cloud service 104 to perform functions to interact with client devices) wherein:
the controller receives a first signal including operating system (OS) information of a first robot among the at least one robot, hardware information of the first robot, and software information of the first robot, from the first robot (see e.g. col.20 lines 54-57: The robot may also send information about the robot and/or the robot's environment to the server, cloud, or the like. For example, a robot may send a robot identifier, which identifies the robot; and col.20 line 63- col.21 lines 1-5:The robot may also send to the server, cloud, or the like, information indicating or associated with one or more robot capabilities. Information about the robot capabilities may identify one or more specific characteristics of a robot. For example, information about the robot capabilities may include one or more of an amount of memory on the robot, an amount of available memory on the robot, available processing power at the robot, processing power of the robot, remaining battery life at the robot, latency between the robot and receiving device, etc.), and
based on presence of a software image (e.g. specific computer-executable instructions) related to the first signal, the controller transmits the software image to the first robot (see e.g. col.21 lines 49-52: the method 1200 includes compare the received data to a manifest. The comparison of the received data to the manifest may be performed by a server, cloud, or the like, col.22 lines 4-14: At block 1208, the method 1200 includes determine instructions for the robot. The instructions may be computer instructions that are executable by the robot. The instructions may be determined based at least in part on the data from the manifest; Specific computer-executable instructions may be instructions that a robot having a specific operating system, processor type, robot identifier, etc., may perform).
Hickman teaches the first robot and the first signal (see Fig.1 and associated text, e.g. col.20 lines 54-57), but not specifically teach based on absence of the software image, the controller extracts the OS information, the hardware information, and the software information, the controller creates a software image based on the extracted OS information, the extracted hardware information, and the extracted software information and the controller transmits the created software image.
In an analogous art of generating software, however, French teaches based on presence of a software image (e.g. target device-specific configuration file), the controller (e.g. boot server 107) transmits the software image to a target device (see Fig.4. and associated text, e.g. col.14 lines 29-33 and lines 37-40: boot server 107 may look for an initial target device-specific configuration file. In one embodiment of the invention, this target device-specific configuration file is indicated by or included in the target device definition the controller transmits the software image to the first robot; If such a target device-specific configuration file is found, the method may proceed to block 430. At block 430, the target device-specific configuration file may be transferred to the target device, based on absence of a software image (e.g. target device-specific configuration file, see e.g. col.5 line 65-col.6 line 3: A request for a boot file from at least one target device is received. A boot server in communication with the plurality of target devices is contacted. The boot server may determine if the target device is defined. If the target device is not defined, the target device definition for the target device is created at the boot server), the controller (e.g. boot server 107) extracts OS information, hardware information, and software information (see e.g. col.6 lines 6-10: The target device may be scanned for at least one hardware configuration. The target device may be scanned for at least one software configuration. An architecture of the target device may be determined. At least one network policy for the target device may be determined and col.9 lines 50-56: boot server 107 may be able to examine configuration files of target devices attached to the network and determine the OS of each target device. Boot server 107 may also be able to examine one or more inventory databases 116 of hardware scan information or other such configuration information corresponding to one or more target devices), the controller creates a software image based on the extracted OS information, the extracted hardware information, and the extracted software information (see e.g. col.6 lines 10-13: The target device definition may be created based on one or a combination of: the hardware configuration, the software configuration, the architecture and the network policy and the controller transmits the created software image (See e.g. col.6 lines 14-17: The configuration file may be transferred to the target device. The target device definition may be stored).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hickman to incorporate/implement the limitations as taught by French in order to provide a more efficient method/system of creating software for various devices specifically defined by the device’s hardware as needed.
As to claim 2, Hickman also teaches a memory configured to store information related to the at least one robot (see e.g. col.1 lines 64-col.2 line 14: Any of the methods described herein may be provided in a form of instructions stored on a non-transitory, computer readable medium, that when executed by a computing device, cause the computing device to perform functions of the method; The computer readable medium may include non-transitory computer readable medium, for example, such as computer-readable media that stores data for short periods of time like register memory, processor cache and Random Access Memory (RAM). The computer readable medium may also include non-transitory media, such as secondary or persistent long term storage, like read only memory (ROM), optical or magnetic disks, compact-disc read only memory (CD-ROM), for example) and col.21 lines 60-63: a manifest may be stored on the server; the manifest may be created based on inputs from one or more robots), wherein, based on presence of the software image related to the first signal in the memory, the stored software image related to the first signal is transmitted to the first robot (see e.g. col.22 lines 4-14: At block 1208, the method 1200 includes determine instructions for the robot. The instructions may be computer instructions that are executable by the robot. The instructions may be determined based at least in part on the data from the manifest; Specific computer-executable instructions may be instructions that a robot having a specific operating system, processor type, robot identifier, etc., may perform).
As to claim 4, Hickman also teaches wherein the controller includes a robot profile register (e.g. processor/code of the processor of the cloud performing the function of storing robot manifests, and a robot software converter (e.g. processor/code of the processor of the cloud performing the function of modifying the executable instructions, the robot software converter requests a profile of the first robot from the robot profile register and the robot profile register transmits the profile to the robot software converter (see e.g. col.6 lines 14-17: The database 110 may represent storage capabilities by the cloud 102, and thus, may be accessed by any of the cloud service 104, the cloud platform 106, and/or the infrastructure 108, col.21 lines 60-63: a manifest may be stored on the server; the manifest may be created based on inputs from one or more robots, col.22 lines 4-18 : the method 1200 includes determine instructions for the robot; The instructions may be computer instructions that are executable by the robot. The instructions may be determined based at least in part on the data from the manifest; One or more specific and/or generic computer-executable instructions may be combined to accomplish a task and col.28 lines 25-27: The cloud 1406, computing device 1404, and/or robot 1402 may have the ability to modify computer-executable instructions).
As to claim 5, Hickman also teaches wherein the robot software converter creates the software image based on the transmitted profile; and the created software image is transmitted to the first robot (see e.g. col.28 lines 23-32: the generic or specific computer-executable instructions may be modified in order to be executed by the robot 1402. The cloud 1406, computing device 1404, and/or robot 1402 may have the ability to modify computer-executable instructions. Modifications may be performed based on a robot's 1402 processor type, amount of installed memory, storage space, type of operating system, type of sensors available to the robot 1402, what type of wheels are installed on the robot 1402, what direction(s) the robot 1402 is able to move, etc. and lines 50-53: the cloud 1406, or even the computing device 1404 or robot 1402, may modify the computer-executable instructions based on the mobility of the robot 1402, for example).
As to claim 6, Hickman also teaches wherein, based on that the software image related to the first signal is present in the memory but does not satisfy a specification condition, the controller converts the software image related to the first signal to be suitable for the specification condition and transmits the converted software image to the first robot (see e.g. col.28 lines 41-55: a robot 1402 may need to move around an obstacle. The computer-executable instructions for performing this task may require the robot 1402 to make a sharp ninety degree left turn to avoid the obstacle. This requirement may presuppose that the robot 1402 that is going to execute the computer-executable instructions has omni wheels that allow the robot 1402 to move laterally to the left. The robot 1402, however, may only have wheels on a rigid axle. These more rigid wheels may be unable to perform the step of making a sharp ninety degree left turn. Accordingly, the cloud 1406, or even the computing device 1404 or robot 1402, may modify the computer-executable instructions based on the mobility of the robot 1402, for example. This may result in the robot 1402 moving backward two feet and slowly making a soft ninety degree turn to the left, for example).
As to claim 7, Hickman also teaches wherein, based on being connected to a second robot having a different capability from the first robot (See e.g. Figs. 2B and 2C and associated text), the controller receives OS information of the second robot, hardware information of the second robot, and software information of the second robot, from the communicator (see Fig.12 and associated text, e.g. col.20 lines 54-57: The robot may also send information about the robot and/or the robot's environment to the server, cloud, or the like. For example, a robot may send a robot identifier, which identifies the robot; and col.20 line 63- col.21 lines 1-5:The robot may also send to the server, cloud, or the like, information indicating or associated with one or more robot capabilities. Information about the robot capabilities may identify one or more specific characteristics of a robot. For example, information about the robot capabilities may include one or more of an amount of memory on the robot, an amount of available memory on the robot, available processing power at the robot, processing power of the robot, remaining battery life at the robot, latency between the robot and receiving device, etc.), converts work information of the second robot based on the received OS information of the second robot, the received hardware information, and the received software information of the second robot (See e.g. col.22 lines 42-49: the robot capability may indicate the amount of available memory on the robot, available processing power at the robot, remaining battery life at the robot, etc. Using this information, for example, a server, cloud, or the like may determine that a robot having a limited amount of memory may only be capable of performing a certain number of computer-executable instructions at one time), and transmits the converted work information to the second robot (see e.g. col.22 lines 53-64: the robot may not be able to process the entire set of instructions due to processing limitations, memory limitations, or the like. Therefore, a subset of the instructions may be sent to the robot; if the robot is limited to 16 kilobytes of memory, and the optimal instructions require 25 kilobytes of memory, then any number of the optimal instructions up to, but not exceeding, the 16 kilobyte memory limitation may be sent to the robot. Once more memory becomes available, additional instructions may be sent to the robot).
As to claim 8, Hickman also teaches wherein the controller converts the work information to assign a priority to a robot located on a specific path (See e.g. col.30 lines 53-61: The cloud 1406 may determine computer-executable instructions that may allow the robot 1402 to navigate around the table and may also determine a priority for one or more of the computer-executable instructions. For example, a first priority may be given to stopping the robot 1402 to avoid any immediate damage to the robot. A second priority may be given to having the robot 1402 turn ninety degrees clockwise).
As to claim 9, Hickman also teaches wherein, based on being connected to a third robot having a different capability from the first robot (See e.g. Figs: 2B, 2C, and 4 and associated text), the controller receives OS information of the third robot, hardware information of the third robot, and software information of the third robot, from the communicator (see Fig.12 and associated text, e.g. col.20 lines 54-57: The robot may also send information about the robot and/or the robot's environment to the server, cloud, or the like. For example, a robot may send a robot identifier, which identifies the robot; and col.20 line 63- col.21 lines 1-5:The robot may also send to the server, cloud, or the like, information indicating or associated with one or more robot capabilities. Information about the robot capabilities may identify one or more specific characteristics of a robot. For example, information about the robot capabilities may include one or more of an amount of memory on the robot, an amount of available memory on the robot, available processing power at the robot, processing power of the robot, remaining battery life at the robot, latency between the robot and receiving device, etc.); based on updating of a first function of the first robot, the controller updates a first function of the third robot to be same as the first function of the first robot based on the OS information of the third robot, the hardware information of the third robot, and the software information of the third robot and the controller transmits a second signal including information related to the first function of the third robot to the third robot (see e.g. col.11 lines 30-42: robots may share 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 builds a map of an area, 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 a map, and the knowledge of "Bob" can be downloaded onto another robot to receive knowledge of the map).
As to claim 10, the limitations of method claim 10 are substantially similar to the limitations of server claim 1, and therefore, it is rejected for the reasons stated above.
7. Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Hickman et al. (US Patent 8,380,349 B1) in view of French et al. (US Patent US 6,988,193 B2), as applied to claim 1 above, and further in view of Christensen (US Patent Application Publication 2018/0373551 A1).
As to claim 3, Hickman teaches the controller (See e.g. col.2 lines 50-53) and the first robot (see e.g. Fig.1 and associated text), but does not specifically teach based on the extracted OS information, the extracted hardware information, and the extracted software information, create a software image or transmit the created software image.
In an analogous art of generating software, however, French teaches based on the extracted OS information, the extracted hardware information, and the extracted software information, create a software image and transmit the created software image (see French: e.g. col.6 lines 10-13: The target device definition may be created based on one or a combination of: the hardware configuration, the software configuration, the architecture and the network policy and lines 14-17: The configuration file may be transferred to the target device. The target device definition may be stored).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hickman to incorporate/implement the limitations as taught by French in order to provide a more faster and efficient method/system of creating operating environments that can run a wide variety of applications in order to complete a wide variety of computing tasks.
Hickman in view of French does not specifically teach wherein the controller creates a docker file from a docker file template or creates a software image based on the created docker file.
In an analogous art, however, Christensen teaches wherein a controller (see e.g. Fig.1, 130 and associated text, e.g. [0024]- example system 100 may also include one or more physical processors, such as physical processor 130), creates a docker file from a docker file template (e.g. configuration file, see Fig.3 and associated text, e.g. [0035]- a container may be a DOCKER container, [0038]- At step 304, one or more of the systems described herein may create a dynamic template that may include at least one variable parameter and that defines at least a portion of an operating environment of the container, [0043]- creation module 106 may use information gathered by identification module 104 about an application, container, and/or host computing system to create the dynamic template, [0049] At step 308, one or more of the systems described herein may process the dynamic template to create a configuration file that may include the value of the variable parameter, [0050]- a configuration file may be a DOCKER-COMPOSE.YML file for a DOCKER container) and creates a software image (e.g. container) based on the created docker file (see e.g. [0056]- at step 310, one or more of the systems described herein may trigger a container initialization system to create, based on the configuration file, the container such that the container isolates a user space of the application from other software on a host system while sharing a kernel space with the other software and [0057]- The term “container initialization system,” as used herein, generally refers to any application, module, script, and/or code capable of executing a container; the container initialization system may be the DOCKER container engine).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hickman to incorporate/implement the limitations as taught by French in order to provide a more efficient method/system of creating software for various devices specifically defined by the device’s hardware as needed.
Conclusion
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM EST.
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, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192