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 .
Claims 1-20 are pending in this office action.
Claims 1-20 are amended.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 on 01/20/2026 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
NB: Examiner is encouraging the applicant’s representative for an interview using the information provided at the bottom of this office action for scheduling the interview.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al US20170177330A1 in view of Wang et al US20230393840A1 and Panicker et al US20160266894A1.
As per claim 1, Yu discloses a method comprising:
receiving, by an electronic device, an updated program image comprising a complete set of program code files:
[0029]”In the example shown in FIG. 1, the comparison engine 120 operates on two versions of the target program, for example, which may be under development, and thus may undergo changes or revisions between versions. The target program includes program version A 150 and program version B 160, where version A 150 is an earlier version of the target program, and version B 160 is a later version of the same target program. In other words, there may be one or more changes, additions, or deletions made (e.g., by the developers) between version A 150 and version B 160. The versions 150, 160 may, but need not be, consecutive versions”;
storing, in the electronic device, the file system comprising the complete set of program code files of the updated program image received:
[0009]“The memory may also include a source database storing one of the first compiled version and the second compiled version. The comparison engine may also be configured to retrieve the one of the first compiled version and the second compiled version from the source database prior to the comparing”.
identifying, by the electronic device, an updated program code file in the mounted file system that is modified with respect to a first installed program code file in the electronic device:
[0027]“The comparison system may indicate differences in the structure of the method between versions (e.g., additional arguments, or a change in type). The comparison system may indicate differences in the operations of the method between versions (e.g., though the structure may be the same, the operations within the method may have changed).”;
wherein the updated program image comprises first information indicating that the updated program code file in the updated program image is updated with respect to the first installed program code file:
[0029] “ The target program includes program version A 150 and program version B 160, where version A 150 is an earlier version of the target program, and version B 160 is a later version of the same target program. In other words, there may be one or more changes, additions, or deletions made (e.g., by the developers) between version A 150 and version B 160. The versions 150, 160 may, but need not be, consecutive versions.”;
identifying, by the electronic device, a non-updated program code file in the system, the non-updated program code file not modified with respect to a second installed program code file in the electronic device:
[0055] “At operation 330, the comparison engine 120 identifies the operations signature 212A for the current method being examined (e.g., the OSarray_A element) and the operations signature 212B of the associated method identified at operation 322 (e.g., the OSarray_B element) and compares these two operations signatures 212A, 212B together. If the OSarray_A element does not match the OSarray B element, then this method is identified as a changed method at operation 332. If they do match, then this method is identified as unaltered at operation 334. Once the current method of compiled version A 154 has been evaluated (e.g., disposition determined at operations 326, 332, or 334), the comparison engine 120 loops to operation 320, looking for the next method in the SSarray_A until each method in that array has been processed”;
wherein the updated program image comprises second information indicating that the non-updated program code file in the updated program image is not modified with respect to the second installed program code file:
[0055] “At operation 330, the comparison engine 120 identifies the operations signature 212A for the current method being examined (e.g., the OSarray_A element) and the operations signature 212B of the associated method identified at operation 322 (e.g., the OSarray_B element) and compares these two operations signatures 212A, 212B together. If the OSarray_A element does not match the OSarray B element, then this method is identified as a changed method at operation 332. If they do match, then this method is identified as unaltered at operation 334. Once the current method of compiled version A 154 has been evaluated (e.g., disposition determined at operations 326, 332, or 334), the comparison engine 120 loops to operation 320, looking for the next method in the SSarray_A until each method in that array has been processed”;
But not explicitly:
Receive the updated program image from a deployment server over a network,
a complete set of program code files used in booting the electronic device, the complete set of program code files arranged in a file system;
mounting, in the electronic device, the file system comprising the complete set of program code files of the updated program image received from the deployment server over the network:
And performing, by the electronic device, an in-service upgrade of the first installed program code file in the electronic device with the updated program code file from the updated program image during a live operation of the electronic device.
Wang discloses:
Receive the updated program image from a deployment server over a network,
a complete set of program code files used in booting the electronic device, the complete set of program code files arranged in a file system:
[0004] “According to the upgrade object, OTA may be divided into Software OTA (SOTA) and Firmware OTA (FOTA). SOTA is for application software/APP upgrade, and FOTA is for upgrading system firmware such as bootloader, kernel, rootfs, or the like”;
[0036] “The server side 20 may generate an update data package based on the update files, and sending the update data package to the client side 10, and the client side updates the to-be-updated file package based on the downloaded data package. The interaction between the client side 10 and the server side 20 takes place over a network 30”.
[0061]”In a practical application, after completing mounting of the root file system where the to-be-updated file is located and before changing the root directory to the root file system, the file update device may virtually merge the directory of the to-be-updated file package and the directory of the update data package to obtain the temporary file package”;
mounting, in the electronic device, the file system comprising the complete set of program code files of the updated program image received from the deployment server over the network:
[0049] “Before downloading the update data package, the file update device determines the target disk partition where the to-be-updated data package is located, and downloads the update data package to the determined target disk partition. In an embodiment, the target disk partition is the root file system (rootfs).
[0051]”In an example, the directory of the update data package includes a directory 1 and a directory 2. Here, the directory 1 includes a file 1 and a file 2, and the directory 2 includes a file 3.”;
Wang also discloses:
identifying, by the electronic device, an updated program code file in the mounted file system that is modified with respect to a first installed program code file in the electronic device:
[0063]“In the embodiment of the disclosure, verification methods for verification of the temporary file package may include performing some functions of the temporary file package such as file reading and writing, service detection, or the like, and the version information of the temporary file package may also be compared with the corresponding version information of the to-be-updated file package to determine whether to perform an upgrade. “;
wherein the updated program image comprises first information indicating that the updated program code file in the updated program image is updated with respect to the first installed program code file:
[0067]”When the update method is replacing, the to-be-updated file is overwritten with the update file with the same file name; when the update method is maintaining, the to-be-updated file is not modified; when the update method is adding, the update file is added to the to-be-updated file package; and when the update method is deleting, the to-be-updated file is deleted.”;
identifying, by the electronic device, a non-updated program code file in the mounted file system, the non-updated program code file not modified with respect to a second installed program code file in the electronic device:
[0101]“Here, the update method which the file 4011 corresponds to is replacing, then the file 4011 in the directory 403 is replaced with the file 4011 in the directory 402; the update method which the file 4012 corresponds to is maintaining, then the file 4012 is maintained unchanged”;
wherein the updated program image comprises second information indicating that the non-updated program code file in the updated program image is not modified with respect to the second installed program code file;
[0067]”When the update method is replacing, the to-be-updated file is overwritten with the update file with the same file name; when the update method is maintaining, the to-be-updated file is not modified; when the update method is adding, the update file is added to the to-be-updated file package; and when the update method is deleting, the to-be-updated file is deleted”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Wang into teachings of Yu for enabling live firmware update or upgrade to the embedded networking device, while reducing additional storage space overhead specifically in low-cost IoT (Internet of Things) smart devices, where the impact of additional consumption of storage space is relatively large. [Wang 0116].
But not explicitly
And performing, by the electronic device, an in-service upgrade of the first installed program code file in the electronic device with the updated program code file from the updated program image during a live operation of the electronic device.
Panicker discloses:
performing, by the electronic device, an in-service upgrade of the first installed program code file in the electronic device with the updated program code file from the updated program image during a live operation of the electronic device:
[0009] “For the live update or upgrade to the firmware of the embedded networking device, a new version of the firmware that includes new features/enhancements to improve the product functionality or fix bugs encountered in previous versions of the firmware is installed seamlessly on the embedded networking device to replace the current version of the firmware on one or more cores at a time. During the live firmware updating or upgrading process, various software applications running on other cores of the embedded networking device continue to perform packet processing operations without any interruption”;
[0020]”In some embodiments, the firmware management module 104 is configured to perform an upgrade in a more seamless fashion by switching and updating/upgrading the firmware of the multi-core embedded networking device 102 one core at a time, wherein each core is shut down and a new updated firmware starts on the core in a systematic process. Since the remaining core(s) of the multi-core embedded networking device 102 continue to operate without reset during the firmware update on other cores, such gradual switch-over does not result in any down time of the embedded networking device 102 and the entire firmware upgrade process is performed in a manner that is transparent to the external network device”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Panicker into teachings of Yu and Wang for enabling live firmware update or upgrade to the embedded networking device, and to allow flexible packet processing capabilities of the applications without experiencing any down-time on the embedded networking device deployed in, e.g., a cloud-based data center. [Panicker 0010].
As per claim 2, the rejection of claim 1 is incorporated and furthermore Yu discloses:
wherein the identifying of the first non-updated program code file in the mounted file system that is not modified with respect to the second installed program code file in the electronic device comprises comparing the first non-updated program code file of the updated program image to the second installed program code file stored in the electronic device:
[0027]”The comparison system generates structure signatures and operations signatures for each version of each method in the target application (e.g., the class file, or multiple files included in the application). Once generated, the comparison system identifies each individual method present in the target application, identifies the structure and operations signatures for each version of the method, and compares the structure and operations signatures to determine if there are differences in the method between versions. The comparison system may indicate differences in the structure of the method between versions (e.g., additional arguments, or a change in type). The comparison system may indicate differences in the operations of the method between versions (e.g., though the structure may be the same, the operations within the method may have changed)”;
See also wang [0087-0088] where the comparaison of file take place for difference determination.
As per claim 3, the rejection of claim 1 is incorporated and furthermore Yu discloses:
wherein the identifying of the updated program code file and the identifying of the non-updated program code file are based on comparing information of program code files in the complete set of program code files of the upgrade file system mounted in the electronic device to information of program code files of a previous complete set of program code files in the previously installed file system.
[0027] The comparison system generates structure signatures and operations signatures for each version of each method in the target application (e.g., the class file, or multiple files included in the application). Once generated, the comparison system identifies each individual method present in the target application, identifies the structure and operations signatures for each version of the method, and compares the structure and operations signatures to determine if there are differences in the method between versions. The comparison system may indicate differences in the structure of the method between versions (e.g., additional arguments, or a change in type). The comparison system may indicate differences in the operations of the method between versions (e.g., though the structure may be the same, the operations within the method may have changed)”;
But not explicitly:
wherein the file system of the updated program image is an upgrade file system, and wherein the first and second installed program code files are stored in a previously installed file system previously mounted in the electronic device:
Wang discloses:
wherein the file system of the updated program image is an upgrade file system, and wherein the first and second installed program code files are stored in a previously installed file system previously mounted in the electronic device:
[0088] “In an example, as shown in FIG. 4, the directory of the update data package is a directory 402, the directory of the to-be-updated file package is a directory 403, and the directory 402 and directory 403 are virtually merged into a mount directory 401.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Wang into teachings of Yu and Panicker implement a comparison system and methods that enable software developers to compare two revisions of a software program or application (a “target application”) to determine differences between the two revisions. The comparison system identifies differences at a logical level relative to the programming language (e.g., at a method level), rather than merely comparing bytes of source code text to determine which lines have changed. The comparison system thus is able to alert the developer as to which logical structures or blocks (e.g., Java methods, functions, classes) within the source code have changed (e.g., been added to, deleted, or modified) from one version to the next.. [Yu 0023].
As per claim 4, the rejection of claim 3 is incorporated and furthermore Yu discloses:
traversing the mounted upgrade file system and retrieving the program code files of the updated program image from the mounted upgrade file system the retrieved program code files comprising the updated program code file and the non-updated program code file:
[0034]“FIG. 2 shows the compiled versions 154, 164 of program version A 150 and version B 160. In the example embodiment, program version A 150 and version B 160 each include multiple methods 156 and 166, respectively. In other words, the source code version A 152 and version B 162 each contain source code for the methods 156, 166, and the compiledversions 154, 164 each also include sections of compiled code for methods 156, 166, as illustrated in FIG. 2.
comparing the retrieved program code files including the updated and non-updated program code files of the updated program image to installed program code files in the previously installed file system:
[0035] The comparison engine 120 compares program versions 150 and 160 based on the compiled versions of the methods 156, 166. More specifically, for each method 156, 166 of the compiled versions 154, 164, the comparison engine 120 generates a structure signature 210 and an operations signature 212. For example, the comparison engine 120 generates a structure signature 210A and an operations signature 212A for method 156A, as well as a structure signature 210B and an operations signature 212B for the associated method 166A. The structure signatures 210 are constructed from elements or attributes of the programming block definitions for the associated method 156, 166 (e.g., the class or method definitions). The operations signatures 212 are constructed from the operations within the programming blocks (e.g., the operations that are executed when the method 156, 166 is called during runtime). The comparison engine 120 then compares the programming blocks (e.g., associated methods 156A, 166A) by comparing the structure signatures 210 and operations signatures 212 of the associated pairs of programming blocks. Generation of the structure signatures 210 and operations signatures 212 are described in greater detail below.
based on the comparing, identifying the first updated program code file that is modified and the non-updated program code file that is not modified:
[0046] When the comparison engine 120 compares two related methods (e.g., method 156A and its associated counterpart in compiled version B 164, method 166A), the comparison engine 120 compares the method signatures of each counterpart method (e.g., structure signature 210A and 210B, the resultant values from the method digests). Due to the nature of generating method signatures, as well as how the structure attributes string is generated, if any of the attributes of the method 156, 166 change from compiled version A 154 to compiled version B 164, the resultant structure signatures 210A, 210B of the two methods 156A and 166A will be different. Thus, the comparison engine 120 may identify that method 156A, 166A as changing between program version A 150 and program version B 160 based on alterations in the method structures”;
See also Wang [0088] for traversing [0100] for comparing and identifying modified files:
As per claim 5, the rejection of claim 1 is incorporated and furthermore Yu does not explicitly disclose:
wherein the mounting of the upgrade file system comprises mounting the upgrade file system of the updated program image at a first point in a file system hierarchy of the electronic device, and wherein the previously installed file system is mounted at a second point of the file system hierarchy.
Wang discloses:
wherein the mounting of the upgrade file system comprises mounting the upgrade file system of the updated program image at a first point in a file system hierarchy of the electronic device:
[0076] “ Here, the target disk space is the underlying file system rootfs, both the update data package and the to-be-updated file package are located in rootfs, and are located in different space regions, so that the directory of the update data package and the directory of the to-be-updated file package are separate directories”;
and wherein the previously installed file system is mounted at a second point of the file system hierarchy:
[0088]“In an example, as shown in FIG. 4, the directory of the update data package is a directory 402, the directory of the to-be-updated file package is a directory 403, and the directory 402 and directory 403 are virtually merged into a mount directory 401.”
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Wang into teachings of Yu and Panicker for enabling live firmware update or upgrade to the embedded networking device, while reducing additional storage space overhead specifically in low-cost IoT (Internet of Things) smart devices, where the impact of additional consumption of storage space is relatively large. [Wang 0116].
As per claim 6, the rejection of claim 1 is incorporated and furthermore Yu does not explicitly disclose:
wherein the in-service upgrade of the first installed program code file is performed without rebooting the electronic device:
Panicker discloses:
wherein the in-service upgrade of the first installed program code file is performed without rebooting the electronic device:
[0009] A new approach is proposed that contemplates systems and methods to support performing a live update or upgrade of a firmware of an embedded networking device, e.g., a Network Interface Card (NIC), to a successful completion without resetting the embedded networking device’”
[0020] “Since the remaining core(s) of the multi-core embedded networking device 102 continue to operate without reset during the firmware update on other cores, such gradual switch-over does not result in any down time of the embedded networking device 102 and the entire firmware upgrade process is performed in a manner that is transparent to the external network device”.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Panicker into teachings of Yu and Wang for enabling live firmware update or upgrade to the embedded networking device, and to allow flexible packet processing capabilities of the applications without experiencing any down-time on the embedded networking device deployed in, e.g., a cloud-based data center. [Panicker 0010].
As per claim 7, the rejection of claim 1 is incorporated and furthermore Yu does not explicitly disclose:
wherein the mounting of the file system comprises mounting a root file system comprising the complete set of program code files of the updated program image;
Wang discloses:
wherein the mounting of the file system comprises mounting a root file system comprising the complete set of program code files of the updated program image;
[0076]“Here, the target disk space is the underlying file system rootfs, both the update data package and the to-be-updated file package are located in rootfs, and are located in different space regions, so that the directory of the update data package and the directory of the to-be-updated file package are separate directories”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Wang into teachings of Yu and Panicker for enabling live firmware update or upgrade to the embedded networking device, while reducing additional storage space overhead specifically in low-cost IoT (Internet of Things) smart devices, where the impact of additional consumption of storage space is relatively large. [Wang 0116].
As per claim 8, the rejection of claim 1 is incorporated and furthermore Yu does not explicitly disclose:
wherein the updated program image comprises service information identifying a service, the method comprising: restarting, based on the service information in the updated program image, the service in the electronic device; and executing the restarted service in the electronic device, the restarted service using machine-readable instructions of the first updated program code file instead of machine- readable instructions of the first installed program code file;
Wang discloses:
wherein the updated program image comprises service information identifying a service, the method comprising: restarting, based on the service information in the updated program image, the service in the electronic device; and executing the restarted service in the electronic device, the restarted service using machine-readable instructions of the first updated program code file instead of machine- readable instructions of the first installed program code file;
[0020] In some embodiments, the firmware management module 104 is configured to perform an upgrade in a more seamless fashion by switching and updating/upgrading the firmware of the multi-core embedded networking device 102 one core at a time, wherein each core is shut down and a new updated firmware starts on the core in a systematic process. Since the remaining core(s) of the multi-core embedded networking device 102 continue to operate without reset during the firmware update on other cores, such gradual switch-over does not result in any down time of the embedded networking device 102 and the entire firmware upgrade process is performed in a manner that is transparent to the external network device.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Wang into teachings of Yu and Panicker for enabling live firmware update or upgrade to the embedded networking device, while reducing additional storage space overhead specifically in low-cost IoT (Internet of Things) smart devices, where the impact of additional consumption of storage space is relatively large. [Wang 0116].
As per claim 9, the rejection of claim 2 is incorporated and furthermore Yu discloses:
wherein the comparing comprises comparing a signature of the non-updated program code file of the updated program image to a signature of the second installed program code file, wherein the signature of the non- updated program code file is part of the second information:
Fig. 2 and [0046]“When the comparison engine 120 compares two related methods (e.g., method 156A and its associated counterpart in compiled version B 164, method 166A), the comparison engine 120 compares the method signatures of each counterpart method (e.g., structure signature 210A and 210B, the resultant values from the method digests)”;
As per claim 10, the rejection of claim 1 is incorporated and furthermore Yu discloses:
wherein the identifying of the updated program code file in the mounted file system that is modified with respect to the first installed program code file comprises comparing a signature of the updated program code file of the updated program image to a signature of the first installed program code file stored in the electronic device, wherein the signature of the updated program code file is part of the first information.
[0046]”When the comparison engine 120 compares two related methods (e.g., method 156A and its associated counterpart in compiled version B 164, method 166A), the comparison engine 120 compares the method signatures of each counterpart method (e.g., structure signature 210A and 210B, the resultant values from the method digests). Due to the nature of generating method signatures, as well as how the structure attributes string is generated, if any of the attributes of the method 156, 166 change from compiled version A 154 to compiled version B 164, the resultant structure signatures 210A, 210B of the two methods 156A and 166A will be different. Thus, the comparison engine 120 may identify that method 156A, 166A as changing between program version A 150 and program version B 160 based on alterations in the method structures”;
As per claim 11, the rejection of claim 1 is incorporated and furthermore Yu does not explicitly disclose:
wherein the electronic device is a switch of a network, and the live operation comprises forwarding data packets by the switch,
and wherein the in-service upgrade of the first installed program code file is performed while the switch forwards data packets;
Panicker discloses:
wherein the electronic device is a switch of a network, and the live operation comprises forwarding data packets by the switch,
[0014] In some embodiments, the embedded networking device 102 is configured to service and offload network packet traffic for an external network device over the network. While the embedded networking device 102 is processing the packet traffic, the firmware management module 104 is configured to support live update and upgrade of the firmware of the embedded networking device 102 by utilizing hot reset features of the driver of the embedded networking device 102 as described below”;
and wherein the in-service upgrade of the first installed program code file is performed while the switch forwards data packets:
[0009]”During the live firmware updating or upgrading process, various software applications running on other cores of the embedded networking device continue to perform packet processing operations without any interruption.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Panicker into teachings of Yu and Wang for enabling live firmware update or upgrade to the embedded networking device, and to allow flexible packet processing capabilities of the applications without experiencing any down-time on the embedded networking device deployed in, e.g., a cloud-based data center. [Panicker 0010].
As per claim 12, the rejection of claim 1 is incorporated and furthermore Yu discloses:
wherein the updated program image is without any program patch updates.
[0032] and [0027]“ The target program includes program version A 150 and program version B 160, where version A 150 is an earlier version of the target program, and version B 160 is a later version of the same target program. In other words, there may be one or more changes, additions, or deletions made (e.g., by the developers) between version A 150 and version B 160. The versions 150, 160 may, but need not be, consecutive versions.”;
See also Wang [0130];
As per claim 13, the rejection of claim 9 is incorporated and furthermore Yu discloses:
wherein the signature of the non- updated program code file comprises a hash of a content of the non-updated program code file or a checksum calculated from the content of the non-updated program code file.
[0026] “ those values. Next, the comparison system generates an “operations signature” for each version of the method as well. The operations of the method are included in the bytecode, and include one or more operations which would be performed upon execution of the method. The comparison system performs a hash on all of the instructions of the method, thereby generating the operations signature for each version of the method.”;
[0045]“The comparison engine 120 then generates a message digest (e.g., structure signature 210A, as an MD5 digest) from this combined attributes string.”;
Claims 14, 15, 17 , 18 are the electronic device claims corresponding to method claims 1, 8, 3 , 9 and rejected under the same rational set forth in connection with the rejection of claims 1, 8, 3, 9 above.
As per claim 16, the rejection of claim 14 is incorporated and furthermore Yu discloses:
wherein the first information and the second information are part of a manifest in the updated program image:
[0045] “To generate the structure signatures 210 for a particular method 156, 166, the comparison engine 120 combines one or more of the structure attributes of that method 156, 166 and then generates a method signature, or type signature, of the combined attributes. The method signature includes the function's return type, the number of arguments, the types of arguments, and/or errors it may pass back. For example, for the example method “increment”, the comparison engine 120 may perform string concatenation on the structure attributes of the method name, the access flag, the return type, the number of arguments, the argument name(s), and the argument types to generate a byte array such as: “increment public int 001nint”. The comparison engine 120 then generates a message digest (e.g., structure signature 210A, as an MD5 digest) from this combined attributes string”;
As per claim 19, Yu discloses a non-transitory machine-readable storage medium comprising instructions that upon execution cause an electronic device to:
receive, at the electronic device, an updated program image:
[0029]”In the example shown in FIG. 1, the comparison engine 120 operates on two versions of the target program, for example, which may be under development, and thus may undergo changes or revisions between versions. The target program includes program version A 150 and program version B 160, where version A 150 is an earlier version of the target program, and version B 160 is a later version of the same target program. In other words, there may be one or more changes, additions, or deletions made (e.g., by the developers) between version A 150 and version B 160. The versions 150, 160 may, but need not be, consecutive versions”;
wherein the updated program image further comprises service information identifying a service of the electronic device:
[0029] “The target program includes program version A 150 and program version B 160, where version A 150 is an earlier version of the target program, and version B 160 is a later version of the same target program.
identify an updated program code file in the mounted upgrade file system that is modified with respect to a first installed program code file in a previously installed file:
[0027]“The comparison system may indicate differences in the structure of the method between versions (e.g., additional arguments, or a change in type). The comparison system may indicate differences in the operations of the method between versions (e.g., though the structure may be the same, the operations within the method may have changed).”;
the previously installed file system comprising a previous complete set of program code files:
[0033] Components of program versions 150, 160 (e.g., source code versions 152, 162, or compiled code versions 154, 164) may be stored in the source database 140, and may be accessed by the comparison engine 120 or identified by a programmer during operation. Further, while only a single source code file is shown in FIG. 1 (e.g., with two associated versions 152, 162), it should be understood that the systems and methods described herein may operate on target programs having multiple source code files, compiled versions, and/or greater or fewer methods”
wherein the identifying of the updated program code file comprises comparing
first information of the the updated program code file in the mounted upgrade file system to information of the first installed program code file in the previously installed file system:
[0055] “At operation 330, the comparison engine 120 identifies the operations signature 212A for the current method being examined (e.g., the OSarray_A element) and the operations signature 212B of the associated method identified at operation 322 (e.g., the OSarray_B element) and compares these two operations signatures 212A, 212B together. If the OSarray_A element does not match the OSarray B element, then this method is identified as a changed method at operation 332. If they do match, then this method is identified as unaltered at operation 334. Once the current method of compiled version A 154 has been evaluated (e.g., disposition determined at operations 326, 332, or 334), the comparison engine 120 loops to operation 320, looking for the next method in the SSarray_A until each method in that array has been processed”;
identify a non-updated program code file in the mounted upgrade file system, the non-updated program code file not modified with respect to a second installed program code file in the electronic device, wherein the identifying of the non-updated program code file comprises comparing second information indicating that of the non-updated program code file in the mounted upgrade file system to information of the second installed program code file in the previously installed file system:
[0055] “At operation 330, the comparison engine 120 identifies the operations signature 212A for the current method being examined (e.g., the OSarray_A element) and the operations signature 212B of the associated method identified at operation 322 (e.g., the OSarray_B element) and compares these two operations signatures 212A, 212B together. If the OSarray_A element does not match the OSarray B element, then this method is identified as a changed method at operation 332. If they do match, then this method is identified as unaltered at operation 334. Once the current method of compiled version A 154 has been evaluated (e.g., disposition determined at operations 326, 332, or 334), the comparison engine 120 loops to operation 320, looking for the next method in the SSarray_A until each method in that array has been processed”;
But not explicitly:
Receiving from a deployment server over a network, the updated program image comprising a complete set of program code files used in booting the electronic device:
the complete set of program code files arranged in an upgrade file system,
mount the upgrade file system comprising the complete set of program code files of the updated program image in the electronic device;
perform an in-service upgrade of the first installed program code file using the updated program code file; and
restart, based on the service information in the updated program image, the service to use machine-readable instructions of the updated program code file in place of machine- readable instructions of the first installed program code file.
Wang discloses:
Receiving from a deployment server over a network, the updated program image comprising a complete set of program code files used in booting the electronic device:
the complete set of program code files arranged in an upgrade file system,
[0004] “According to the upgrade object, OTA may be divided into Software OTA (SOTA) and Firmware OTA (FOTA). SOTA is for application software/APP upgrade, and FOTA is for upgrading system firmware such as bootloader, kernel, rootfs, or the like”;
[0036] “The server side 20 may generate an update data package based on the update files, and sending the update data package to the client side 10, and the client side updates the to-be-updated file package based on the downloaded data package. The interaction between the client side 10 and the server side 20 takes place over a network 30”.
[0061]”In a practical application, after completing mounting of the root file system where the to-be-updated file is located and before changing the root directory to the root file system, the file update device may virtually merge the directory of the to-be-updated file package and the directory of the update data package to obtain the temporary file package”;
mount the upgrade file system comprising the complete set of program code files of the updated program image in the electronic device;
[0049] “Before downloading the update data package, the file update device determines the target disk partition where the to-be-updated data package is located, and downloads the update data package to the determined target disk partition. In an embodiment, the target disk partition is the root file system (rootfs).
[0051]”In an example, the directory of the update data package includes a directory 1 and a directory 2. Here, the directory 1 includes a file 1 and a file 2, and the directory 2 includes a file 3.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Wang into teachings of Yu for enabling live firmware update or upgrade to the embedded networking device, while reducing additional storage space overhead specifically in low-cost IoT (Internet of Things) smart devices, where the impact of additional consumption of storage space is relatively large. [Wang 0116].
But not explicitly:
perform an in-service upgrade of the first installed program code file using the updated program code file; and
restart, based on the service information in the updated program image, the service to use machine-readable instructions of the updated program code file in place of machine- readable instructions of the first installed program code file.
Panicker discloses:
perform an in-service upgrade of the first installed program code file using the updated program code file; and
[0009] “For the live update or upgrade to the firmware of the embedded networking device, a new version of the firmware that includes new features/enhancements to improve the product functionality or fix bugs encountered in previous versions of the firmware is installed seamlessly on the embedded networking device to replace the current version of the firmware on one or more cores at a time. During the live firmware updating or upgrading process, various software applications running on other cores of the embedded networking device continue to perform packet processing operations without any interruption”;
restart, based on the service information in the updated program image, the service to use machine-readable instructions of the updated program code file in place of machine- readable instructions of the first installed program code file
[0020]”In some embodiments, the firmware management module 104 is configured to perform an upgrade in a more seamless fashion by switching and updating/upgrading the firmware of the multi-core embedded networking device 102 one core at a time, wherein each core is shut down and a new updated firmware starts on the core in a systematic process. Since the remaining core(s) of the multi-core embedded networking device 102 continue to operate without reset during the firmware update on other cores, such gradual switch-over does not result in any down time of the embedded networking device 102 and the entire firmware upgrade process is performed in a manner that is transparent to the external network device”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Panicker into teachings of Yu and Wang for enabling live firmware update or upgrade to the embedded networking device, and to allow flexible packet processing capabilities of the applications without experiencing any down-time on the embedded networking device deployed in, e.g., a cloud-based data center. [Panicker 0010].
Claim 20 is the non-transitory machine-readable storage medium claim corresponding to method claim 3 and rejected under the same rational set forth in connection with the rejection of claim 3 above.
Pertinent arts:
US 12293177 B1 :
The first manifest may include a human and/or system readable document that summarizes the file contents and/or other type of data of the first version of the network application. For example, the first manifest may include information describing at least the files, the paths to the files, the sizes of the files, hash details for the files, any updates to the files, and/or any other information associated with the first version of the network application.
US20130290945A1:
The information handling system includes one or more devices coupled together to route information between the one or more devices and other devices coupled thereto based on routing information stored in the one or more devices. an in-service software upgrade on non-redundant systems such that the upgrade is near hitless and stateful switchover may be achieved;
US10936300B1:
The update can be verified, and then the device is caused to exit management mode and resume a typical workflow. If the update is not successful, or not all of the BIOS update is able to be done using a live update process, then a conventional BIOS update can be performed that includes a reboot or restart of the device in order for the update to take effect.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4:30).
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, Wei Y Mui can be reached at 571-270-2738. 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.
/BRAHIM BOURZIK/ Examiner, Art Unit 2191
/WEI Y MUI/ Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights