DETAILED ACTION
The Office Action is in response to amendments filed 1/16/2026.
Claims 1-3, 5-8, 10-11, 12, and 15-19 are currently amended.
Claims 1-20 are currently pending.
The rejection of claims 1-11 and 15-18 under 35 U.S.C. 112(b) are withdrawn in view of the applicant’s amendments to claims 1-3, 5-8, 10-11, and 15-19.
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 .
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5-6, 12, 15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20250045047 A1 hereinafter "S" in view of US 20110239195 A1 hereinafter “Lin”.
With regards to claim 1, S teaches
A computer implemented method, comprising: identifying a change to code in a code base; (S [0036], “Dynamic module offset linkage protocol 230 may also dynamically link overflow offsets, which may be associated with overflow update data when an update to a particular driver or file exceeds the allotted size in the module. Dynamic module offset linkage protocol 230 may handle the overflow offsets by injecting the overflow update data during the load time of the module based on offset values in segment offset table 202. For example, if the driver or file mentioned above is updated, and the update is stored in reserved space 275-2, dynamic module offset linkage protocol 230 may also track the update in reserved space 275-2 at load time via segment offset table 202. This is because dynamic offset linkage protocol 230 can track updates in a modified region of flash memory 235 by identifying delta changes between the current payload stored for BIOS 225 and the BIOS firmware update based on offsets in segment offset table 202.”)
generating a build payload that identifies, as payload items, the underlying item and the related item, [wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated;] (S [0063-64], “FIG. 9 shows a method 900 which is a continuation of method 800 of FIG. 8. Method 900 typically starts at block 905 wherein a firmware comparison tool may compare the binaries of the current version and the new version of the system firmware and identify any modified module(s) or sector(s) between the two versions. The firmware comparison tool may also calculate a hash of the modified module(s) or sector(s) and sign the modified module(s) or sector(s). The method may proceed to block 910 where a modified module collector may collect the modified module(s) or sector(s) including a module that contains the payload hash and signatures. The modified module(s) or sector(s) reflects the deltas between the current version and the new version of the system firmware. The modified module collector may also collect the modified module(s) or sector(s) module dependency list if any [that identifies, as payload items, the underlying item and the related item]. The method may proceed to block 915 where a payload packager may bundle the collected module(s) or sector(s) as a binary file. The bundle may also include offset definitions in a segment offset table, wherein the offset definitions are based on the deltas depicted in the modified modules or sectors. The method may proceed to block 920 where the modified module collector may collect the other firmware update(s) for the platform or information handling system. These collected firmware updates may also be bundled as another binary file(s). The method may proceed to block 925 where the payload packager may create a payload file system package based on the binary files and sign the created payload package [generating a build payload]. The process of converting the raw firmware binary file(s) into the payload file system package may be performed at runtime. The method may proceed to block 930 where the payload packager may publish the payload package for download by the user”) and
generating a build artifact corresponding to the build payload. (S [0037], “FIG. 3 shows a diagram of a flash file structure 300 that is configured to support modular flash memory updates. Flash file structure 300 may be a layout of a firmware update payload package for updating one or more firmware images in the flash memory. In this example, the firmware file update includes updates to BIOS 225, an embedded controller 320, a management engine 325, etc. The aforementioned firmware updates may be arranged according to a payload layout 305. Payload header 310 may include information associated with the firmware update payload. For example, payload header 310 may include a globally unique identifier of the payload, identifier and number of firmware images, size, and version of each firmware image, etc. Each firmware image may include updates to a collection of firmware routines, device drivers, and/or other software programs. A particular firmware is typically assigned a revision or version number identifying the collection of routines or files included in the firmware which is typically a newer version than the firmware image previously published and/or used by a consumer.”)
S teaches generating a build payload that identifies, as payload items, the underlying item and the related item, but does not teach: identifying a change to code in a code base;
identifying an underlying item in the code base that is modified by the change;
prior to generating a build artifact, accessing a data source that tracks relationships among items in the code base to identify a related item in the code base that changes is likely to change based on the identified change to the underlying item, wherein the data source records at least one of:
calls between items in the code base:
item production by items in the code base: or
dependencies between items in the code base;
[generating a build payload that identifies, as payload items, the underlying item and the related item,] wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated;
However, in an analogous art Lin teaches identifying a change to code in a code base; (Lin [0018], “The example system 200 includes a software build service 202 and multiple developer computer devices 204, such as computer devices local to each developer that may author source code and contribute buildable units to a large-scale software build project. The software build service 202 includes a software build project 206, such as any type of large-scale software development project that can involve many developers working in parallel to generate buildable units 208 of the software build project. As described with reference to FIG. 1, the software build project 206 may also be represented and/or implemented as a buildable unit (e.g., buildable unit 104). The multiple buildable units 208 can be allocated for independent development among multiple developers, and then provided or uploaded to the software build service 202 that generates the software build project 206 from the buildable units. Any one or combination of the buildable units 208 may be represented and/or implemented as any of the various examples of buildable units described with reference to FIG. 1. Additionally, any of the buildable units 208 may include authored source code 210, source code metadata 212, and/or file access metadata 214.”)
identifying an underlying item in the code base that is modified by the change; (Lin [0019], “The buildable units 208 of the software build project 206 may then be generated by one or many developers that contribute buildable units for the software build project on the single developer computer device. As source code and source code metadata is developed and changed, the source code and metadata can be reliably exchanged between disparate computing systems and devices that may or may not be networked for data communication. As described above, a buildable unit 208 of a software build project may include files, sub-files, a directory and its contents (e.g., files and sub-files), a group of directories and the contents, and/or any combination thereof Dependencies between the various buildable units 208 of the software build project can be determined from file access pattern analysis implemented by the software build service 202.”)
prior to generating a build artifact, (Lin [0060], “At block 614, the multiple buildable units that are received from the multiple developers are compiled to generate a version of the software build project. For example, the build project compiler 236 at the software build service 202 links and compiles the multiple buildable units 208 to generate a version of the software build project 206. In another example, the build project compiler 330 at the developer computer device 302 links and compiles the software build project 308 based on the dependency hierarchy of the buildable units 306.”) accessing a data source that tracks relationships among items in the code base (Lin [0023-24], “When the source code 220 is authored at the developer computer device 218, source code metadata 228 is also generated and can include file access metadata 230 that identifies each instance of a file access for the particular buildable unit 222. All of the file accesses developed in the authored source code 220 can be logged, such as in a trace file. The source code metadata 228 is then provided or uploaded from the developer computer device 218 to the software build service 202 and is saved as the file access metadata 214 when source code metadata is received from one or more of the developer computer devices 204 [accessing a data source]. The software build service 202 can then generate a relational graph 232 of the buildable units 208 that are associated based on the file accesses listed in the file access metadata 214. The relational graph 232 is a representation of the software build project 206. Additionally, the software build service 202 can generate a dependency hierarchy 234 from the relational graph 232, and the dependency hierarchy 234 identifies dependencies between the buildable units 208 of the software build project [among items in the code base]. In various embodiments, the software build service 202 represents any techniques that may be implemented to support running a number `n` invocations of the build project across a number `m` build types and merging all of the `n:m` permutations into a single large relational graph of the buildable units.”) to identify a related item in the code base that changes based on the identified change to the underlying item, (Lin [0058], “At block 610, dependent buildable units are identified that have a dependency relationship with a buildable unit for execution at a developer computer device where the buildable unit is developed. For example, the dependent buildable units 224 (i.e., dependent with respect to buildable unit 222 at computer device 218) are identified at the software build service 202 from the dependency hierarchy 234. The dependent buildable units 224 can be identified as child buildable units that are dependent on the buildable unit 222 for execution and/or as parent buildable units from which the buildable unit 222 is dependent on for execution. In another example, the dependent buildable units 316 at the developer computer device 302 are identified as buildable units that have a dependency relationship with the buildable unit 314 for execution. The dependent buildable units 316 can be identified as child buildable units that are dependent on the buildable unit 314 for execution and/or as parent buildable units from which the buildable unit 314 is dependent on for execution.”) [Examiner’s Note: Hierarchy is tracked for dependency before the build project is linked and compiled for a final build artifact] wherein the data source records at least one of:
calls between items in the code base:
item production by items in the code base: or
dependencies between items in the code base; (Lin [0035], “The example architecture 400 also includes a trace analyzer 408 that is implemented to obtain data from a build trace 410, such as the process tree rooted by the top level build process with an edge connecting a process to its parent process, and additional information about each process (e.g., PID, command line, directory) and file operations (e.g., file name, access mode, status). In an implementation, the build dependencies can be determined as follows: associate each process with the set of files it reads; associate each process with the set of files it writes to; and if a first process reads a file which is written by a second process, create a dependency edge to the second process. A first buildable unit is identified as depending on a second buildable unit if there is a child process associated with the first buildable unit which has a dependency edge to a child process associated with the second buildable unit.”)
[…] wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated; (Lin [0040-41], “Embodiments of dependence-based software builds provide for a partial build in which a developer can reliably build any buildable unit or set of buildable units from scratch. With the knowledge of buildable unit dependencies, the build process 404 can transitively determine all the input dependencies for each of the dependents, and only a subset of the source project may be necessary to construct a buildable unit of the software build project. Embodiments of dependence-based software builds also provide for an efficient and accurate incremental build. The incremental build capability enables rebuilding only the subset of the source project which is actually impacted by a change while producing accurate output [wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated]. When a subset of the source project has previously been built on a given machine and some source code changes are made, subsequent rebuilds are fast and reliable. With the dependency graph 402 and a build trace 410, updates to a buildable unit can be detected and rebuilt. Further, partial build and incremental build scenarios can be combined together. For example, a developer can incrementally rebuild a component after project files have been modified and transitively rebuild all of its consumers incrementally.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Lin into the teachings of S. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of utilizing the dependency information to assist in analysis and refactoring authored source code and changes to source code files (Lin [0014]).
With regards to claim 2, the rejection of claim 1 is incorporated.
S further teaches identifying items used to compile the payload items, wherein generating the build payload comprises identifying, as additional payload items, the items used to compile the payload items. (S [0055], "The dynamic linkage sections may include a dynamic linkage database may include details that include information associated with the driver that has been split into at least two parts, such as the location of the reserved space in the other portion where the second part of the driver is stored. During an update of the driver, if the update process detects that the firmware update payload includes a driver that is split across multiple modules due to size restrictions, the processor may look for the dynamic linkage database and retrieve the information associated with the location of the data that are stored in other modules. The update process may also determine the dependencies of the driver that is split and flash the module(s) associated with the dependencies.") [Examiner's Note: By determining all the dependencies and information the database is able to identify the items to compile the payload]
With regards to claim 5, the rejection of claim 2 is incorporated.
S does not teach: wherein accessing the data source to identify a related item comprises: identifying a path in a source tree corresponding to the code base, the path including a representation of the underlying item.
However, in an analogous art Lin teaches wherein accessing the data source to identify a related item comprises: identifying a path in a source tree corresponding to the code base, the path including a representation of the underlying item (Lin [0035-36], “The example architecture 400 also includes a trace analyzer 408 that is implemented to obtain data from a build trace 410, such as the process tree [in a source tree corresponding to the code base] rooted by the top level build process with an edge connecting a process to its parent process, and additional information about each process (e.g., PID, command line, directory) and file operations (e.g., file name, access mode, status) [identifying a path]. In an implementation, the build dependencies can be determined as follows: associate each process with the set of files it reads; associate each process with the set of files it writes to; and if a first process reads a file which is written by a second process, create a dependency edge to the second process. A first buildable unit is identified as depending on a second buildable unit if there is a child process associated with the first buildable unit which has a dependency edge to a child process associated with the second buildable unit. The dependency graph 402 is a simplified example to show a resultant dependency between two buildable units, BU1 and BU2. The two buildable units are associated with various processes P1, P2, and P3. Each process is associated with a set of files, such as input files F1 and F3, an output file F5, and intermediate files F2 and F4. The dependency relationships are denoted by the dashed arrows. For example, process P3 depends on process P2 through file F4, and process P2 depends on process P1 through file F2. Accordingly, buildable unit BU2 has dependency on buildable unit BU1 [the path including a representation of the underlying item].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Lin into the teachings of S. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of utilizing the dependency information to assist in analysis and refactoring authored source code and changes to source code files (Lin [0014]).
With regards to claim 6, the rejection of claim 1 is incorporated.
S further teaches wherein accessing a data source to identify a related item comprises: identifying dependent code used by the underlying item. (S [0056], "During the flashing of the BIOS firmware, if the processor detects that the module being processed includes a driver that is split across multiple modules in the flash memory, the processor may look for a dynamic module offset linkage database in the firmware update payload or the flash memory update payload and retrieve associated details. For example, the processor may get information on which module contains the rest of the driver and collect that packet or module and flash that module as well. This module may also be referred to as a dependency of the current module being processed.")
With regards to claim 12, S teaches
at least one processor; and
memory storing computer executable instructions which, when executed by the at least one processor, cause the at least one processor to perform steps, comprising: (S [0070], "While the computer-readable medium is shown to be a single medium, the term "computer-readable medium" includes a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term "computer-readable medium" shall also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the methods or operations disclosed herein.") detecting a change to code in a code base; (S [0036], "Dynamic module offset linkage protocol 230 may also dynamically link overflow offsets, which may be associated with overflow update data when an update to a particular driver or file exceeds the allotted size in the module. Dynamic module offset linkage protocol 230 may handle the overflow offsets by injecting the overflow update data during the load time of the module based on offset values in segment offset table 202. For example, if the driver or file mentioned above is updated, and the update is stored in reserved space 275-2, dynamic module offset linkage protocol 230 may also track the update in reserved space 275-2 at load time via segment offset table 202. This is because dynamic offset linkage protocol 230 can track updates in a modified region of flash memory 235 by identifying delta changes between the current payload stored for BIOS 225 and the BIOS firmware update based on offsets in segment offset table 202.")
generating a build payload that identifies, as payload items, the underlying item and the related item, [wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated;] (S [0063-64], "FIG. 9 shows a method 900 which is a continuation of method 800 of FIG. 8. Method 900 typically starts at block 905 wherein a firmware comparison tool may compare the binaries of the current version and the new version of the system firmware and identify any modified module(s) or sector(s) between the two versions. The firmware comparison tool may also calculate a hash of the modified module(s) or sector(s) and sign the modified module(s) or sector(s). The method may proceed to block 910 where a modified module collector may collect the modified module(s) or sector(s) including a module that contains the payload hash and signatures. The modified module(s) or sector(s) reflects the deltas between the current version and the new version of the system firmware. The modified module collector may also collect the modified module(s) or sector(s) module dependency list if any [that identifies, as payload items, the underlying item and the related item]. The method may proceed to block 915 where a payload packager may bundle the collected module(s) or sector(s) as a binary file. The bundle may also include offset definitions in a segment offset table, wherein the offset definitions are based on the deltas depicted in the modified modules or sectors. The method may proceed to block 920 where the modified module collector may collect the other firmware update(s) for the platform or information handling system. These collected firmware updates may also be bundled as another binary file(s). The method may proceed to block 925 where the payload packager may create a payload file system package based on the binary files and sign the created payload package [generating a build payload]. The process of converting the raw firmware binary file(s) into the payload file system package may be performed at runtime. The method may proceed to block 930 where the payload packager may publish the payload package for download by the user")
outputting the build payload to a build system for generation of a build artifact corresponding to the build payload. (S [0058-29], "The method may proceed to block 720 where the processor retrieves other firmware updates from the flash memory update payload package [corresponding to the build payload]. For example, the processor may retrieve embedded controller 320 and management engine 325 of the flash memory update payload of FIG. 3 In particular, method 800 may generate or build a flash memory update package according to a flash file structure, sign the generated package, and upload it to an update site for users to download and update their platforms [outputting the build payload to a build system]. In building the flash memory update package, the method may interpolate a user's flash memory offsets with offsets of a new system firmware payload and generate a write-only flash memory offset map to support a dynamic flash update at a sector level. In addition, the method may also determine module dependencies for each module or driver of the new system firmware payload. The method may include the dependency modules along with the modified modules in the flash memory update package. An artificial intelligence engine may generate a dynamic offset linkage database, similar to payload offset table 402 of FIG. 4 in the system firmware payload. The dynamic offset linkage database may enable scaling of delta updates across modules or firmware volumes within an image such that module size extension is accommodated without corruption [for generation of a build artifact].")
S teaches generating a build payload that identifies, as payload items, the underlying item and the related item but does not teach identifying a change to code in a code base;
identifying an underlying item in the code base that is modified by the change;
prior to generating a build artifact, accessing a data source that tracks relationships among items in the code base to identify a related item in the code base that changes is likely to change based on the identified change to the underlying item, wherein the data source records at least one of:
calls between items in the code base:
item production by items in the code base: or
dependencies between items in the code base;
[generating a build payload that identifies, as payload items, the underlying item and the related item,] wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated;
However, in an analogous art Lin teaches identifying a change to code in a code base;
identifying an underlying item in the code base that is modified by the change;
prior to generating a build artifact, (Lin [0060], “At block 614, the multiple buildable units that are received from the multiple developers are compiled to generate a version of the software build project. For example, the build project compiler 236 at the software build service 202 links and compiles the multiple buildable units 208 to generate a version of the software build project 206. In another example, the build project compiler 330 at the developer computer device 302 links and compiles the software build project 308 based on the dependency hierarchy of the buildable units 306.”) accessing a data source that tracks relationships among items in the code base (Lin [0023-24], “When the source code 220 is authored at the developer computer device 218, source code metadata 228 is also generated and can include file access metadata 230 that identifies each instance of a file access for the particular buildable unit 222. All of the file accesses developed in the authored source code 220 can be logged, such as in a trace file. The source code metadata 228 is then provided or uploaded from the developer computer device 218 to the software build service 202 and is saved as the file access metadata 214 when source code metadata is received from one or more of the developer computer devices 204 [accessing a data source]. The software build service 202 can then generate a relational graph 232 of the buildable units 208 that are associated based on the file accesses listed in the file access metadata 214. The relational graph 232 is a representation of the software build project 206. Additionally, the software build service 202 can generate a dependency hierarchy 234 from the relational graph 232, and the dependency hierarchy 234 identifies dependencies between the buildable units 208 of the software build project [among items in the code base]. In various embodiments, the software build service 202 represents any techniques that may be implemented to support running a number `n` invocations of the build project across a number `m` build types and merging all of the `n:m` permutations into a single large relational graph of the buildable units.”) to identify a related item in the code base that changes based on the identified change to the underlying item, (Lin [0058], “At block 610, dependent buildable units are identified that have a dependency relationship with a buildable unit for execution at a developer computer device where the buildable unit is developed. For example, the dependent buildable units 224 (i.e., dependent with respect to buildable unit 222 at computer device 218) are identified at the software build service 202 from the dependency hierarchy 234. The dependent buildable units 224 can be identified as child buildable units that are dependent on the buildable unit 222 for execution and/or as parent buildable units from which the buildable unit 222 is dependent on for execution. In another example, the dependent buildable units 316 at the developer computer device 302 are identified as buildable units that have a dependency relationship with the buildable unit 314 for execution. The dependent buildable units 316 can be identified as child buildable units that are dependent on the buildable unit 314 for execution and/or as parent buildable units from which the buildable unit 314 is dependent on for execution.”) [Examiner’s Note: Hierarchy is tracked for dependency before the build project is linked and compiled for a final build artifact] wherein the data source records at least one of:
calls between items in the code base:
item production by items in the code base: or
dependencies between items in the code base; (Lin [0035], “The example architecture 400 also includes a trace analyzer 408 that is implemented to obtain data from a build trace 410, such as the process tree rooted by the top level build process with an edge connecting a process to its parent process, and additional information about each process (e.g., PID, command line, directory) and file operations (e.g., file name, access mode, status). In an implementation, the build dependencies can be determined as follows: associate each process with the set of files it reads; associate each process with the set of files it writes to; and if a first process reads a file which is written by a second process, create a dependency edge to the second process. A first buildable unit is identified as depending on a second buildable unit if there is a child process associated with the first buildable unit which has a dependency edge to a child process associated with the second buildable unit.”)
[…] wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated; (Lin [0040-41], “Embodiments of dependence-based software builds provide for a partial build in which a developer can reliably build any buildable unit or set of buildable units from scratch. With the knowledge of buildable unit dependencies, the build process 404 can transitively determine all the input dependencies for each of the dependents, and only a subset of the source project may be necessary to construct a buildable unit of the software build project. Embodiments of dependence-based software builds also provide for an efficient and accurate incremental build. The incremental build capability enables rebuilding only the subset of the source project which is actually impacted by a change while producing accurate output [wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated]. When a subset of the source project has previously been built on a given machine and some source code changes are made, subsequent rebuilds are fast and reliable. With the dependency graph 402 and a build trace 410, updates to a buildable unit can be detected and rebuilt. Further, partial build and incremental build scenarios can be combined together. For example, a developer can incrementally rebuild a component after project files have been modified and transitively rebuild all of its consumers incrementally.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Lin into the teachings of S. This combination of teachings would have resulted in a system to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of utilizing the dependency information to assist in analysis and refactoring authored source code and changes to source code files (Lin [0014]).
With regards to claim 15, the rejection of claim 12 is incorporated.
S further teaches identifying items used to compile the payload items, wherein generating the build payload comprises identifying, as additional payload items, the items used to compile the payload items. (S [0055], "The dynamic linkage sections may include a dynamic linkage database may include details that include information associated with the driver that has been split into at least two parts, such as the location of the reserved space in the other portion where the second part of the driver is stored. During an update of the driver, if the update process detects that the firmware update payload includes a driver that is split across multiple modules due to size restrictions, the processor may look for the dynamic linkage database and retrieve the information associated with the location of the data that are stored in other modules. The update process may also determine the dependencies of the driver that is split and flash the module(s) associated with the dependencies.") [Examiner's Note: By determining all the dependencies and information the database is able to identify the items to compile the payload]
With regards to claim 17, the rejection of claim 12 is incorporated.
S does not teach: wherein accessing the data source to identify a related item comprises: identifying a path in a source tree corresponding to the code base, the path including a representation of the underlying item.
However, in an analogous art Lin teaches wherein accessing the data source to identify a related item comprises: identifying a path in a source tree corresponding to the code base, the path including a representation of the underlying item (Lin [0035-36], “The example architecture 400 also includes a trace analyzer 408 that is implemented to obtain data from a build trace 410, such as the process tree [in a source tree corresponding to the code base] rooted by the top level build process with an edge connecting a process to its parent process, and additional information about each process (e.g., PID, command line, directory) and file operations (e.g., file name, access mode, status) [identifying a path]. In an implementation, the build dependencies can be determined as follows: associate each process with the set of files it reads; associate each process with the set of files it writes to; and if a first process reads a file which is written by a second process, create a dependency edge to the second process. A first buildable unit is identified as depending on a second buildable unit if there is a child process associated with the first buildable unit which has a dependency edge to a child process associated with the second buildable unit. The dependency graph 402 is a simplified example to show a resultant dependency between two buildable units, BU1 and BU2. The two buildable units are associated with various processes P1, P2, and P3. Each process is associated with a set of files, such as input files F1 and F3, an output file F5, and intermediate files F2 and F4. The dependency relationships are denoted by the dashed arrows. For example, process P3 depends on process P2 through file F4, and process P2 depends on process P1 through file F2. Accordingly, buildable unit BU2 has dependency on buildable unit BU1 [the path including a representation of the underlying item].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Lin into the teachings of S. This combination of teachings would have resulted in a system to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of utilizing the dependency information to assist in analysis and refactoring authored source code and changes to source code files (Lin [0014]).
With regards to claim 18, the rejection of claim 12 is incorporated.
S further teaches wherein accessing a data source to identify a related item comprises: identifying dependent code used by the underlying item. (S [0056], "During the flashing of the BIOS firmware, if the processor detects that the module being processed includes a driver that is split across multiple modules in the flash memory, the processor may look for a dynamic module offset linkage database in the firmware update payload or the flash memory update payload and retrieve associated details. For example, the processor may get information on which module contains the rest of the driver and collect that packet or module and flash that module as well. This module may also be referred to as a dependency of the current module being processed.")
With regards to claim 19, S teaches
A computer system, comprising: at least one processor; (S [0070], "While the computer-readable medium is shown to be a single medium, the term "computer-readable medium" includes a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term "computer-readable medium" shall also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the methods or operations disclosed herein.")
a change aggregation system, implemented by the at least one processor, detecting a change to code in a code base; (S [0036], "Dynamic module offset linkage protocol 230 may also dynamically link overflow offsets, which may be associated with overflow update data when an update to a particular driver or file exceeds the allotted size in the module. Dynamic module offset linkage protocol 230 may handle the overflow offsets by injecting the overflow update data during the load time of the module based on offset values in segment offset table 202. For example, if the driver or file mentioned above is updated, and the update is stored in reserved space 275-2, dynamic module offset linkage protocol 230 may also track the update in reserved space 275-2 at load time via segment offset table 202. This is because dynamic offset linkage protocol 230 can track updates in a modified region of flash memory 235 by identifying delta changes between the current payload stored for BIOS 225 and the BIOS firmware update based on offsets in segment offset table 202.")
generating a build payload that identifies, as payload items, the underlying item and the related item, [wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated;] (S [0063-64], "FIG. 9 shows a method 900 which is a continuation of method 800 of FIG. 8. Method 900 typically starts at block 905 wherein a firmware comparison tool may compare the binaries of the current version and the new version of the system firmware and identify any modified module(s) or sector(s) between the two versions. The firmware comparison tool may also calculate a hash of the modified module(s) or sector(s) and sign the modified module(s) or sector(s). The method may proceed to block 910 where a modified module collector may collect the modified module(s) or sector(s) including a module that contains the payload hash and signatures. The modified module(s) or sector(s) reflects the deltas between the current version and the new version of the system firmware. The modified module collector may also collect the modified module(s) or sector(s) module dependency list if any [that identifies, as payload items, the underlying item and the related item]. The method may proceed to block 915 where a payload packager may bundle the collected module(s) or sector(s) as a binary file. The bundle may also include offset definitions in a segment offset table, wherein the offset definitions are based on the deltas depicted in the modified modules or sectors. The method may proceed to block 920 where the modified module collector may collect the other firmware update(s) for the platform or information handling system. These collected firmware updates may also be bundled as another binary file(s). The method may proceed to block 925 where the payload packager may create a payload file system package based on the binary files and sign the created payload package [generating a build payload]. The process of converting the raw firmware binary file(s) into the payload file system package may be performed at runtime. The method may proceed to block 930 where the payload packager may publish the payload package for download by the user")
and output the build payload to a build system for generation of a build artifact corresponding to the build payload. (S [0058-29], "The method may proceed to block 720 where the processor retrieves other firmware updates from the flash memory update payload package [corresponding to the build payload]. For example, the processor may retrieve embedded controller 320 and management engine 325 of the flash memory update payload of FIG. In particular, method 800 may generate or build a flash memory update package according to a flash file structure, sign the generated package, and upload it to an update site for users to download and update their platforms [outputting the build payload to a build system]. In building the flash memory update package, the method may interpolate a user's flash memory offsets with offsets of a new system firmware payload and generate a write-only flash memory offset map to support a dynamic flash update at a sector level. In addition, the method may also determine module dependencies for each module or driver of the new system firmware payload. The method may include the dependency modules along with the modified modules in the flash memory update package. An artificial intelligence engine may generate a dynamic offset linkage database, similar to payload offset table 402 of FIG. 4 in the system firmware payload. The dynamic offset linkage database may enable scaling of delta updates across modules or firmware volumes within an image such that module size extension is accommodated without corruption [for generation of a build artifact].")
S teaches generating a build payload that identifies, as payload items, the underlying item and the related item but does not teach a change aggregation system, implemented by the at least one processor, detecting a change to code in a code base;
A change location identification system identifying an underlying item in the code base that is modified by the change;
A recursive payload generator, prior to generating a build artifact, accessing a data source that tracks relationships among items in the code base to identify a related item in the code base that changes based on the detected change to the underlying item, wherein the data source records at least one of:
calls between items in the code base:
item production by items in the code base: or
dependencies between items in the code base;
[generating a build payload that identifies, as payload items, the underlying item and the related item,] wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated;
However, in an analogous art Lin teaches a recursive payload generator prior to generating a build artifact, (Lin [0060], “At block 614, the multiple buildable units that are received from the multiple developers are compiled to generate a version of the software build project. For example, the build project compiler 236 at the software build service 202 links and compiles the multiple buildable units 208 to generate a version of the software build project 206. In another example, the build project compiler 330 at the developer computer device 302 links and compiles the software build project 308 based on the dependency hierarchy of the buildable units 306.”) accessing a data source that tracks relationships among items in the code base (Lin [0023-24], “When the source code 220 is authored at the developer computer device 218, source code metadata 228 is also generated and can include file access metadata 230 that identifies each instance of a file access for the particular buildable unit 222. All of the file accesses developed in the authored source code 220 can be logged, such as in a trace file. The source code metadata 228 is then provided or uploaded from the developer computer device 218 to the software build service 202 and is saved as the file access metadata 214 when source code metadata is received from one or more of the developer computer devices 204 [accessing a data source]. The software build service 202 can then generate a relational graph 232 of the buildable units 208 that are associated based on the file accesses listed in the file access metadata 214. The relational graph 232 is a representation of the software build project 206. Additionally, the software build service 202 can generate a dependency hierarchy 234 from the relational graph 232, and the dependency hierarchy 234 identifies dependencies between the buildable units 208 of the software build project [among items in the code base]. In various embodiments, the software build service 202 represents any techniques that may be implemented to support running a number `n` invocations of the build project across a number `m` build types and merging all of the `n:m` permutations into a single large relational graph of the buildable units.”) to identify a related item in the code base that changes based on the identified change to the underlying item, (Lin [0058], “At block 610, dependent buildable units are identified that have a dependency relationship with a buildable unit for execution at a developer computer device where the buildable unit is developed. For example, the dependent buildable units 224 (i.e., dependent with respect to buildable unit 222 at computer device 218) are identified at the software build service 202 from the dependency hierarchy 234. The dependent buildable units 224 can be identified as child buildable units that are dependent on the buildable unit 222 for execution and/or as parent buildable units from which the buildable unit 222 is dependent on for execution. In another example, the dependent buildable units 316 at the developer computer device 302 are identified as buildable units that have a dependency relationship with the buildable unit 314 for execution. The dependent buildable units 316 can be identified as child buildable units that are dependent on the buildable unit 314 for execution and/or as parent buildable units from which the buildable unit 314 is dependent on for execution.”) [Examiner’s Note: Hierarchy is tracked for dependency before the build project is linked and compiled for a final build artifact] wherein the data source records at least one of:
calls between items in the code base:
item production by items in the code base: or
dependencies between items in the code base; (Lin [0035], “The example architecture 400 also includes a trace analyzer 408 that is implemented to obtain data from a build trace 410, such as the process tree rooted by the top level build process with an edge connecting a process to its parent process, and additional information about each process (e.g., PID, command line, directory) and file operations (e.g., file name, access mode, status). In an implementation, the build dependencies can be determined as follows: associate each process with the set of files it reads; associate each process with the set of files it writes to; and if a first process reads a file which is written by a second process, create a dependency edge to the second process. A first buildable unit is identified as depending on a second buildable unit if there is a child process associated with the first buildable unit which has a dependency edge to a child process associated with the second buildable unit.”)
[…] wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated; (Lin [0040-41], “Embodiments of dependence-based software builds provide for a partial build in which a developer can reliably build any buildable unit or set of buildable units from scratch. With the knowledge of buildable unit dependencies, the build process 404 can transitively determine all the input dependencies for each of the dependents, and only a subset of the source project may be necessary to construct a buildable unit of the software build project. Embodiments of dependence-based software builds also provide for an efficient and accurate incremental build. The incremental build capability enables rebuilding only the subset of the source project which is actually impacted by a change while producing accurate output [wherein the build payload omits items that are unaffected by the change such that a full build of the code base is not generated]. When a subset of the source project has previously been built on a given machine and some source code changes are made, subsequent rebuilds are fast and reliable. With the dependency graph 402 and a build trace 410, updates to a buildable unit can be detected and rebuilt. Further, partial build and incremental build scenarios can be combined together. For example, a developer can incrementally rebuild a component after project files have been modified and transitively rebuild all of its consumers incrementally.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Lin into the teachings of S. This combination of teachings would have resulted in a system to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of utilizing the dependency information to assist in analysis and refactoring authored source code and changes to source code files (Lin [0014]).
Claims 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over S in view of Lin as applied to claims 2 and 12 above, and further in view of US 20140282459 Al hereinafter "Hey".
With regards to claim 3, the rejection of claim 2 is incorporated.
The combination of S and Lin does not teach: identifying items generated by the payload items when the payload items are compiled,
wherein generating the build payload comprises identifying, as additional payload items, the items generated by the payload items when the payload items are compiled.
However, in an analogous art Hey teaches identifying items generated by the payload items when the payload items are compiled, (Hey [0027-28], "In some embodiments, patch process 10 may communicate with, interact with, and/or include a component or module of a source control or software version control application (e.g., source control application 54) Various changes made to the software source code may be identified and tracked, such that each revision or change to the software source code may be identified. As such, source control application 54 may document and identify changes, or revisions, that are made to the source code of one or more software products, when the changes were made, the nature or impact of such changes, the source code that was changed, as well as various other information [identifying items generated by the payload items]. As such, changes to the software (c.g., to the software source code) that take place over time may be documented using source control application 54. Various information in addition to source code changes or revisions may also be documented or tracked by, or using, source control application 54. In an embodiment, the data associated with, generated by, and/or collected by source control application may be stored, e.g., on storage device 16 associated with server computer 12, which executes source control application, and/or another suitable storage device. In an embodiment, patch process 10 may communicate with, interact with and/or include a component or module of a build output system (e.g., build output system 56). Build output system 56 may generally manage one or more built versions of one or more software products. For example, source code associated with a software product, a version of a software product, and/or a portion of a software product may be compiled to produce executable or machine usable software code. [when the payload items are compiled]")
wherein generating the build payload comprises identifying, as additional payload items, the items generated by the payload items when the payload items are compiled. (Hey [0046-47], "For example, payload aggregator 162 may aggregate the located containers and built files into an appropriate payload file structure that may be suitable for packaging as a software patch [the items generated by the payload items when the payload items are compiled]. Further, in response to determining 116 that at least one of the one or more built files cannot be directly applied to a deployment of the software product, payload aggregator 162 may merge 120 the at least one or the one or more built files into a container associated with the deployment of the software product. That is, for example, the one or more files that cannot be directly applied to the deployment of the software product may be merged into one or more compressed archives, e.g., which may be applied to the deployed software product. In an embodiment, merging 120 the one or more built files into a container associated with the deployment of the software product may include obtaining the original corresponding container of the product level, unzipping (e.g., uncompressing) the container, and replacing the original file of the product level with the built file corresponding to the defect change-set and/or the overlapping change-set. Generating 108 the software patch may also include packaging 122 the payload file structure into an installable software patch. For example, payload packager 164 may prepare the payload file structure provided by payload aggregator 162 for installation. In an embodiment, packaging 122 the payload file structure may include, for example, compressing the payload, generating a "readme" file with instructions, generating an installation script, and/or using a separate tool (e.g., a counterpart tool which may be used to install the patch). Accordingly, payload packager 164 may package 122 the payload file structure based on a format required for the patch to be installed on the deployed product level of the software product of the customer for whom the patch is being generated 108 [identifying, as additional payload items, the items].")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hey into the teachings of S in view of Lin. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, and repeatedly executing the continuous integration over time for an updated application, as in Hey. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of remedying defects in a software product while including any binaries, resources, or previous changes as required in the deployment if they are impacted in any way (Hey [0015]).
With regards to claim 16, the rejection of claim 12 is incorporated.
The combination of S and Lin does not teach: identifying items generated by the payload items when the payload items are compiled,
wherein generating the build payload comprises identifying, as additional payload items, the items generated by the payload items when the payload items are compiled.
However, in an analogous art Hey teaches identifying items generated by the payload items when the payload items are compiled, (Hey [0027-28], "In some embodiments, patch process 10 may communicate with, interact with, and/or include a component or module of a source control or software version control application (e.g., source control application 54) Various changes made to the software source code may be identified and tracked, such that each revision or change to the software source code may be identified. As such, source control application 54 may document and identify changes, or revisions, that are made to the source code of one or more software products, when the changes were made, the nature or impact of such changes, the source code that was changed, as well as various other information [identifying items generated by the payload items]. As such, changes to the software (c.g., to the software source code) that take place over time may be documented using source control application 54. Various information in addition to source code changes or revisions may also be documented or tracked by, or using, source control application 54. In an embodiment, the data associated with, generated by, and/or collected by source control application may be stored, e.g., on storage device 16 associated with server computer 12, which executes source control application, and/or another suitable storage device. In an embodiment, patch process 10 may communicate with, interact with and/or include a component or module of a build output system (e.g., build output system 56). Build output system 56 may generally manage one or more built versions of one or more software products. For example, source code associated with a software product, a version of a software product, and/or a portion of a software product may be compiled to produce executable or machine usable software code. [when the payload items are compiled]")
wherein generating the build payload comprises identifying, as additional payload items, the items generated by the payload items when the payload items are compiled. (Hey [0046-47], "For example, payload aggregator 162 may aggregate the located containers and built files into an appropriate payload file structure that may be suitable for packaging as a software patch [the items generated by the payload items when the payload items are compiled]. Further, in response to determining 116 that at least one of the one or more built files cannot be directly applied to a deployment of the software product, payload aggregator 162 may merge 120 the at least one or the one or more built files into a container associated with the deployment of the software product. That is, for example, the one or more files that cannot be directly applied to the deployment of the software product may be merged into one or more compressed archives, e.g., which may be applied to the deployed software product. In an embodiment, merging 120 the one or more built files into a container associated with the deployment of the software product may include obtaining the original corresponding container of the product level, unzipping (e.g., uncompressing) the container, and replacing the original file of the product level with the built file corresponding to the defect change-set and/or the overlapping change-set. Generating 108 the software patch may also include packaging 122 the payload file structure into an installable software patch. For example, payload packager 164 may prepare the payload file structure provided by payload aggregator 162 for installation. In an embodiment, packaging 122 the payload file structure may include, for example, compressing the payload, generating a "readme" file with instructions, generating an installation script, and/or using a separate tool (e.g., a counterpart tool which may be used to install the patch). Accordingly, payload packager 164 may package 122 the payload file structure based on a format required for the patch to be installed on the deployed product level of the software product of the customer for whom the patch is being generated 108 [identifying, as additional payload items, the items].")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hey into the teachings of S in view of Lin. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, and repeatedly executing the continuous integration over time for an updated application, as in Hey. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of remedying defects in a software product while including any binaries, resources, or previous changes as required in the deployment if they are impacted in any way (Hey [0015]).
Claim 4 are rejected under 35 U.S.C. 103 as being unpatentable over S in view of Lin in view of Hey as applied to claim 3 above, and further in view of US 20250123830 Al hereinafter "Bouley".
With regards to claim 4, the rejection of claim 3 is incorporated.
The combination of S, Lin, and Hey does not teach: recursively identifying, as recursively identified items, additional related items based on the payload items and the additional payload items, and wherein generating the build payload includes identifying as additional payload items, the recursively identified items.
However, in an analogous art Bouley teaches recursively identifying, as recursively
identified items, additional related items based on the payload items and the additional
payload items, and wherein generating the build payload includes identifying as additional
payload items, the recursively identified items. (Bouley [0034-35], "the deployment service
103 may analyze compatibility between configurations included in a configurations package to
generate the solution. In some embodiments, the deployment service 103 may modify the
configurations included in a configurations package to ensure compatibility between
configurations. In some embodiments, the deployment service 103 may modify the
configurations included in a configurations package to generate the executable solutions in an
execution environment [recursively identifying, as recursively identified items, additional related items based on the payload items and the additional payload items,]. In some embodiments, the deployment service 103 may generate executable code from the configuration package 120. In some embodiments, the deployment service 103 may facilitate a user to publish the generated configuration package, for example, at a marketplace 130. As shown in FIG. 1A, the published configuration package may be deployed by partner customers of the computation platform 100A. FIG. 1B is a diagram illustrating a computational platform 100B for generating configuration packages. As shown in FIG. 1B, the computational platform 100B may facilitate functionalities that treat configuration packages 120 as recursive entities. In some embodiments, configuration packages 120 have the capacity to encompass other configuration packages 120, and they can, in turn, be encompassed within other configuration packages 120 [wherein generating the build payload includes identifying as additional payload items, the recursively identified items]. It is essential to note that configuration packages 120 are designed to adhere to logical constraints, preventing scenarios where a configuration package 120 contains itself, i.e., preventing self referential recursiveness") [Examiner's Note: by modifying the configuration the system is
identifying the proper items for deployment]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Bouley into the teachings of S in view of Lin and further in view of Hey. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, and repeatedly executing the continuous integration over time for an updated application, as in Hey, and recursively identifying additional items for inclusion into the deployed configurable package, as in Bouley. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of generating a package for deployment that adheres to expected configuration and can extend adaptability by recursive inclusion (Bouley [0067]).
Claim 7 are rejected under 35 U.S.C. 103 as being unpatentable over S in view of Lin as applied to claim 1 above, and further in view of US 20230334240 A1 hereinafter "Shin".
With regards to claim 7, the rejection of claim 1 is incorporated.
S teaches identifying a set of changes made to the codebase since the prior build time. (S [0037], "Payload header 310 may include information associated with the firmware update payload. For example, payload header 310 may include a globally unique identifier of the payload, identifier and number of firmware images, size, and version of each firmware image, etc. Each firmware image may include updates to a collection of firmware routines, device drivers, and/or other software programs. A particular firmware is typically assigned a revision or version number identifying the collection of routines or files included in the firmware which is typically a newer version than the firmware image previously published and/or used by a consumer.") [Examiner's Note: Each payload contains update information that includes data that is used to identify previous sets of patches and changes therein]
The combination of S and Lin does not teach: identifying a prior build time at which a prior build artifact was generated;
However, in an analogous art Shin teaches identifying a prior build time at which a prior build artifact was generated; (Shin [0019], "Aspects of the present disclosure address the above and other deficiencies by providing techniques for fine-grained version histories of electronic documents at a platform. As a user provides edits to an electronic document, a platform (e.g., a collaborative document platform) can obtain information associated with each edit. In some embodiments, the obtained information can include an indication of a type of a respective edit made to the document (e.g., an addition, a removal, and/or a modification of a text object, a drawing object, an image object, etc.), coordinates associated with a section of the document that includes the respective cdit, a timestamp associated with a time at which the respective edit was provided [identifying a prior build time at which a prior build artifact was generated], and, in some embodiments, an identifier associated with the user that provided the respective edit. The platform can generate a mapping between the edit type, the coordinates, the timestamp and/or the user identifier and can store the generated mapping at a memory associated with the platform. In some embodiments, the platform can maintain an edit data structure that stores mappings associated with each edit made to the electronic document. The platform can update the edit data structure to include the generated mapping, in some embodiments.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Shin into the teachings of S in view of Lin. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, wherein the identified changes are specifically differences as detected in comparison to the previous version of software, as in Shin. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining the state of a document by documenting the iterations of edits made between the version time periods (Shin [0021]).
Claim 8 are rejected under 35 U.S.C. 103 as being unpatentable over S in view of Lin in view of Shin as applied to claim 7 above, and further in view of Hey.
With regards to claim 8, the rejection of claim 7 is incorporated.
The combination of S, Lin, and Shin does not teach: repeating, for each change in the set of changes, steps of identifying an underlying item, accessing a data source, and generating the build payload.
However, in an analogous art Hey teaches repeating, for each change in the set of changes, steps of identifying an underlying item, accessing a data source, and generating the build payload. (Hey [0027], "In some embodiments, patch process 10 may communicate with, interact with, and/or include a component or module of a source control or software version control application (e.g., source control application 54). As is generally know, a source control application (e.g., source control application 54) may generally manage and track changes to
software source code. Various changes made to the software source code may be identified and
tracked, such that each revision or change to the software source code may be identified. As
such, source control application 54 may document and identify changes, or revisions, that are
made to the source code of one or more software products, when the changes were made, the
nature or impact of such changes, the source code that was changed, as well as various other
information [steps of identifying an underlying item, accessing a data source, and generating the
build payload]. As such, changes to the software (e.g., to the software source code) that take place over time may be documented using source control application 54 [repeating, for each
change in the set of changes]. Various information in addition to source code changes or
revisions may also be documented or tracked by, or using, source control application 54. In an
embodiment, the data associated with, generated by, and/or collected by source control
application may be stored, e.g., on storage device 16 associated with server computer 12, which
executes source control application, and/or another suitable storage device.") [Examiner's Note:
Executing the tracking or documenting over time indicates that the process can be executed repeatedly wherein the information obtained is used to enable the methods described]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hey into the teachings of S in view of Lin and further in view of Shin. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, wherein the identified changes are specifically differences as detected in comparison to the previous version of software, as in Shin, and repeatedly executing the continuous integration over time for an updated application, as in Hey. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of remedying defects in a software product while including any binaries, resources, or previous changes as required in the deployment if they are impacted in any way (Hey [0015]).
Claims 9 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over S in view of Lin as applied to claim 1 above, in view of US 20190361686 A1 hereinafter "Gnazdowsky" and further in view of US 20230418585 A1 hereinafter "Wang".
With regards to claim 9, the rejection of claim 1 is incorporated.
The combination of S and Lin does not teach: detecting a build trigger to generate the build artifact
However, in an analogous art Gnazdowsky teaches detecting a build trigger to generate
the build artifact (Gnazdowsky [0043], "Further, one or more steps of the method disclosed
herein may be initiated, maintained, controlled and/or terminated based on a control input
received from one or more devices operated by one or more users such as, for example, but not
limited to, an end user, an admin, a service provider, a service consumer, an agent, a broker and a
representative thereof. Further, the user as defined herein may refer to a human, an animal or an
artificially intelligent being in any state of existence, unless stated otherwise, elsewhere in the
present disclosure. Further, in some embodiments, the one or more users may be required to
successfully perform authentication in order for the control input to be effective.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Gnazdowsky into the teachings of S in view of Lin. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, further facilitating a build in response to a trigger and dependency analysis, as in Gnazdowsky. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of performing a change impact analysis that defines change propagation, change impact, and change requirements (Gnazdowsky [0063]).
The combination of S, Lin, and Gnazdowsky does not teach: wherein generating the build payload comprises generating the build payload based on the build trigger.
However, in an analogous art Wang teaches wherein generating the build payload
comprises generating the build payload based on the build trigger. (Wang [0058-61], "In a
step of S301, a terminal device sends an identifier and current version information of a software
to a version upgrade server [based on the build trigger]; In a step of S302, the version upgrade
server determines an installation package corresponding to the latest version of the software
according to the identifier, and determines an installation package corresponding to the current
version of the software according to the current version information; In a step of S303, version
upgrade server obtains first feature information and second feature information according to the
installation package corresponding to the latest version of the software and the installation
package corresponding to the current version of the software. The first feature information
corresponds to the first installation subpackage, the second feature information corresponds to
the second installation subpackage. The first installation subpackage is one installation
subpackage in the installation package of the latest version of the software. The second
installation subpackage is one installation subpackage corresponding to the first installation
subpackage in the installation package of the current version of the software. In a step of S304,
the version upgrade server generates the update package of the software [generating the build
payload comprises generating the build payload] according to the first installation subpackage
when the first feature information is different from the second feature information;")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wang into the teachings of S in view of Lin and further in view of Gnazdowsky. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, further facilitating a build in response to a trigger and dependency analysis, as in Gnazdowsky, and generating a deployable package according to the triggering condition, as in Wang. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of generating an update package for installation incrementally only when there is a difference in the features of the package for maximized efficiency (Wang [0021]).
With regards to claim 11, the rejection of claim 9 is incorporated.
The combination of S, Lin, and Gnazdowsky does not teach: detecting the build trigger based on change-based trigger criteria, the change-based trigger criteria being indicative of changes to the code base.
However, in an analogous art Wang teaches detecting the build trigger based on change-based trigger criteria, the change-based trigger criteria being indicative of changes to the code base. (Wang [0056], "Whether the first feature information is the same as the second feature information is determined. If the first feature information is different from the second feature information, it indicates that the second installation subpackage needs to be updated [based on change-based trigger criteria, the change-based trigger criteria being indicative of changes to the code base]. If the first feature information is the same as the second feature information, it indicates that the second installation subpackage does not need to be updated. The update package of the software is generated according to the first installation subpackage if the
first feature information is different from the second feature information [detecting the build
trigger].") [Examiner's Note: based on an identified change the system will initiate a trigger for
the update package]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wang into the teachings of S in view of Lin and further in view of Gnazdowsky. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, further facilitating a build in response to a trigger and dependency analysis, as in Gnazdowsky, and generating a deployable package according to the triggering condition, as in Wang. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of generating an update package for installation incrementally only when there is a difference in the features of the package for maximized efficiency (Wang [0021]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over S in view of Lin in view of Gnazdowsky in view of Wang as applied to claim 9 above, and further in view of US 20220398078 A1 hereinafter "Segler".
With regards to claim 10, the rejection of claim 9 is incorporated.
The combination of S, Lin, Gnazdowsky, and Wang does not teach: wherein detecting a build trigger comprises: detecting the build trigger based on time-based trigger criteria.
However, in an analogous art Segler teaches wherein detecting a build trigger comprises: detecting the build trigger based on time-based trigger criteria (Segler [0090], "A design time manifest trigger 524 may prompt the creation of a modified software service build that includes changes to operations code and applications code. The modified software service build may be generated, for example, as described herein with respect to FIGS. 1 and 2. When the modified software service build is to bc deployed, the determine production environments routine 534 is executed to determine which environments are to receive the modified software service build. The multiplexer 536 also executes to determine operations features 538, 540, 542, 544, 546 are to be executed at the respective environments. For a modified software service build responsive to a design time manifest trigger 524, the calculate manifest feature 540 executes to re-calculate the manifests 548, 550 in accordance with the new design time manifest. Also, the execute provisioning/scaling feature 542 may be executed to calculate (e.g., re-calculate) provisioning and scaling at the environment in accordance with the new design time manifest. If changes to provisioning and scaling are called for at an environment, the execute customer lifecycle feature 546 and/or execute software deployment feature 544 may be executed.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Segler into the teachings of S in view of Lin in view of Gnazdowsky and further in view of Wang. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, further facilitating a build in response to a trigger and dependency analysis, as in Gnazdowsky, and generating a deployable package according to the triggering condition, as in Wang, wherein the build trigger is based on the timing of the software version, as in Segler. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of generating and deploying changes to portions of a build deployment in accordance with what is needed in a particular environment (Segler [0037]).
Claims 13-14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over S in view of Lin as applied to claim 12 above, and further in view of Bouley.
With regards to claim 13, the rejection of claim 12 is incorporated.
The combination of S and Lin does not teach: recursively identifying, as recursively identified items, additional related items based on the payload items and the additional payload items, and wherein generating the build payload includes identifying as additional payload items, the recursively identified items.
However, in an analogous art Bouley teaches recursively identifying, as recursively identified items, additional related items based on the payload items and the additional payload items, and wherein generating the build payload includes identifying as additional payload items, the recursively identified items. (Bouley [0034-35], "the deployment service 103 may analyze compatibility between configurations included in a configurations package to generate the solution. In some embodiments, the deployment service 103 may modify the configurations included in a configurations package to ensure compatibility between configurations. In some embodiments, the deployment service 103 may modify the configurations included in a configurations package to generate the executable solutions in an execution environment [recursively identifying, as recursively identified items, additional related items based on the payload items and the additional payload items,] In some embodiments, the deployment service 103 may generate executable code from the configuration package 120. In some embodiments, the deployment service 103 may facilitate a user to publish the generated configuration package, for example, at a marketplace 130. As shown in FIG. 1A, the published configuration package may be deployed by partner customers of the computation platform 100A. FIG. 1B is a diagram illustrating a computational platform 100B for generating configuration packages. As shown in FIG. 1B, the computational platform 100B may facilitate functionalities that treat configuration packages 120 as recursive entities. In some embodiments, configuration packages 120 have the capacity to encompass other configuration packages 120, and they can, in turn, be encompassed within other configuration packages 120 [wherein generating the build payload includes identifying as additional payload items, the recursively identified items]. It is essential to note that configuration packages 120 are designed to adhere to logical constraints, preventing scenarios where a configuration package 120 contains itself, i.e., preventing self referential recursiveness") [Examiner's Note: by modifying the configuration the system is identifying the proper items for deployment]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Bouley into the teachings of S in view of Lin. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, and recursively identifying additional items for inclusion into the deployed configurable package, as in Bouley. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of generating a package for deployment that adheres to expected configuration and can extend adaptability by recursive inclusion (Bouley [0067]).
With regards to claim 14, the rejection of claim 13 is incorporated.
S further teaches generating the build artifact corresponding to the build payload. (S [0037], "FIG. 3 shows a diagram of a flash file structure 300 that is configured to support
modular flash memory updates. Flash file structure 300 may be a layout of a firmware update
payload package for updating one or more firmware images in the flash memory. In this
example, the firmware file update includes updates to BIOS 225, an embedded controller 320, a
management engine 325, etc. The aforementioned firmware updates may be arranged according
to a payload layout 305. Payload header 310 may include information associated with the
firmware update payload. For example, payload header 310 may include a globally unique
identifier of the payload, identifier and number of firmware images, size, and version of each
firmware image, etc. Each firmware image may include updates to a collection of firmware
routines, device drivers, and/or other software programs. A particular firmware is typically
assigned a revision or version number identifying the collection of routines or files included in
the firmware which is typically a newer version than the firmware image previously published
and/or used by a consumer.")
With regards to claim 20, the rejection of claim 19 is incorporated.
The combination of S and Lin does not teach: a recursive processor configured to recursively identify, as recursively identified items, additional related items based on the payload items, and wherein the recursive payload generator is configured to generate the build payload identifying, as additional payload items, the recursively identified items.
However, in an analogous art Bouley teaches a recursive processor configured to recursively identify, as recursively identified items, additional related items based on the payload items, and wherein the recursive payload generator is configured to generate the build payload identifying, as additional payload items, the recursively identified items. (Bouley [0034-35], "the deployment service 103 may analyze compatibility between configurations included in a configurations package to generate the solution. In some embodiments, the deployment service 103 may modify the configurations included in a configurations package to ensure compatibility between configurations. In some embodiments, the deployment service 103 may modify the configurations included in a configurations package to generate the executable solutions in an execution environment [recursively identifying, as recursively identified items, additional related items based on the payload items and the additional payload items,] In some embodiments, the deployment service 103 may generate executable code from the configuration package 120. In some embodiments, the deployment service 103 may facilitate a user to publish the generated configuration package, for example, at a marketplace 130. As shown in FIG. 1A, the published configuration package may be deployed by partner customers of the computation platform 100A. FIG. 1B is a diagram illustrating a computational platform 100B for generating configuration packages. As shown in FIG. 1B, the computational platform 100B may facilitate functionalities that treat configuration packages 120 as recursive entities. In some embodiments, configuration packages 120 have the capacity to encompass other configuration packages 120, and they can, in turn, be encompassed within other configuration packages 120 [wherein generating the build payload includes identifying as additional payload items, the recursively identified items]. It is essential to note that configuration packages 120 are designed to adhere to logical constraints, preventing scenarios where a configuration package 120 contains itself, i.e., preventing self referential recursiveness") [Examiner's Note: by modifying the configuration the system is identifying the proper items for deployment]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Bouley into the teachings of S in view of Lin. This combination of teachings would have resulted in a method to identify changes to a code base in order to generate a package that incorporates the changes for implementation of the update on target devices, as in S, and analyzing code structural dependencies to incrementally build accordingly, as in Lin, and recursively identifying additional items for inclusion into the deployed configurable package, as in Bouley. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of generating a package for deployment that adheres to expected configuration and can extend adaptability by recursive inclusion (Bouley [0067]).
Response to Arguments
Applicant’s arguments with respect to claims 1-20 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.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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 Mui can be reached at 571-272-3708. 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights