DETAILED ACTION
This Action is a response to the reply filed 10 June 2026. Claims 1, 3-6, 8, 15 and 18-20 are amended; no claims are canceled or newly added. Claims 1-20 remain pending for examination. In view of the amendments, the rejections under 35 U.S.C. § 112(b) are withdrawn.
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-3, 5-10, 12-17 and 19-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Mesde et al., U.S. 12,411,757 B1 (“Mesde”) in view of Farrell et al., U.S. 2019/0391798 A1 (“Farrell”) and Thodati et al., U.S. 2014/0344799 A1 (“Thodati”).
Regarding claim 1, Mesde teaches: A computer-implemented method (Mesde, e.g., 16:36-38, “methods described herein may be implemented in software, hardware …”) comprising:
identifying, by a processor set, hardware components of a hardware infrastructure of a computer node; identifying, by the processor set, attributes associated with each of the hardware components (Mesde, e.g., 8:18-40, “Testing environment 332 may offer instances, containers, and/or functions according to various configurations for testing including the performance of the test script … environment 332 may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size, and so on, for example to replicate conditions of an electronic control unit (ECU) of a vehicle and a specified software stack (e.g., a particular version of an operating system …” See also, e.g., 8:51-9:8, “test configurations 246 may determine properties of the electronic control units simulated in the testing environment 332 of the vehicle model that the software package 200 is intended to be deployed to … may determine the operating system of the electronic control unit being simulated in the testing environment …” Examiner’s note: the identification comprises the determination that certain components having particular attributes (such as an ECU having a number of CPUs) necessary to evaluate and certify a software release bundle (artifact set));
constructing, by the processor set, relationships between the hardware components and software release bundles based on the attributes (Mesde, e.g., 8:51-9:8, “test configurations 246 may determine properties of the electronic control units simulated in the testing environment 332 of the vehicle model that the software package 200 is intended to be deployed to … may determine the operating system of the electronic control unit being simulated in the testing environment …” Examiner’s note: the relationship is the connection and the logic necessary to configure simulated ECUs (hardware) for the deployment of particular software artifacts (software release bundle) (see further, e.g., 12:3-34));
determining, by the processor set, compatibility of the software release bundles with the hardware components using the relationships (Mesde, e.g., 9:19-42, “Once the testing system 140 has performed the test of the software package/software package binaries 142, the testing system 140 may receive a testing result … one or more statistics measuring performance of the vehicle software package 200 and/or determinations whether the software package 200 meets the requirements of the software testing … a particular iteration of the tests may generate a different software artifact set for the vehicle model associated with a particular software test iteration.” Examiner’s note: based on executing the tests on the particular configuration (i.e., the relationship between the bundle under test and the hardware of a target vehicle having particular components), the compatibility of the bundle is determined (i.e., a performance determination) that is used to determine whether to certify the bundle for the vehicle (see further, e.g., 12:35-13:8));
selecting, by the processor set, among the software release bundles, and based on a predefined criterion, a software release bundle for deployment on the computer node (Mesde, e.g., 13:19-30, “vehicle software release management system selects a certified software package of the plurality of certified software packages in a required format to be deployed by a distribution adapter …”).
Mesde does not more particularly teach monitoring deployment of the release bundle on the computer node and updating the relationships between the bundle and the hardware components based on results of the deployment. However, Farrell does teach: monitoring, by the processor set, deployment of the software release bundle on the computer node; and updating, by the processor set, the relationships between the software release bundle and the hardware components based on results of the deployment (Farrell, e.g., ¶¶38-41, “collecting first telemetry data from a first plurality of computing devices … includes usage of a first plurality of features of the first software application by the first computing devices … deployment tool 220 creates a first plurality of mappings … represents a profile or digital fingerprint of a computing device … the first software application, and usage of at least one feature … include a profile of a computing device (in terms of hardware, software …) For each mapping created … deployment tool 220 determines a level of deployment success …” See also, e.g., ¶47, wherein a determination of deployment success in a subsequent computer or group of computers results in testing or automated deployment, depending on comparison of the success score to a threshold) for the purpose of providing feedback to developers and to resource managers for identifying optimal and suboptimal software deployments based on deployment locations and feature and resource consumption, among other factors (Farrell, e.g., ¶¶4-9).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for evaluating the compatibility and performance of a plurality of software artifact bundles to diverse vehicle and vehicle system devices as taught by Mesde to provide for monitoring deployment of the release bundle on the computer node and updating the relationships between the bundle and the hardware components based on results of the deployment because the disclosure of Farrell shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for evaluating the deployment success of software bundle versions to similar and dissimilar computing systems to provide for monitoring deployment of the release bundle on the computer node and updating the relationships between the bundle and the hardware components based on results of the deployment for the purpose of providing feedback to developers and to resource managers for identifying optimal and suboptimal software deployments based on deployment locations and feature and resource consumption, among other factors (Farrell, Id.).
Mesde in view of Farrell does not more particularly teach that the relationships further define dynamic relationships between the hardware components having changing attributes, and the determining of the compatibility adapting to changing hardware and software landscapes based on the dynamic relationships. However, Thodati does teach: [constructing relationships between components and bundles based on attributes], the relationships further defining dynamic relationships between the hardware components having changing attributes (Thodati, e.g., ¶21, “method 300 begins at block 302 where system components and their associated firmware in a networked [system] are discovered … an administrator may trigger the discovery of the networked system 200, one or more of its system components, and the current firmware of those system components … In another example, a system component in the networked system 200 such as the port extender HIS … may be connected … and, in response, may publish its IP address … system management application 202a may then use that IP address to discover that system component and its current firmware, along with other system components … connected to that system component.” See also, e.g., ¶22, “method 300 then proceeds to block 304 where relationships between system components in the network system are determined to create a relationship graph that includes the system components and their associated firmware … may determine the physical connectivity relationships … relationships may be established based on a similarity in the nature of system components … type of system components … proximity of system components … functionality of system components … based on characteristics that cause those system components to require similar management operations (e.g., configuration operations) …” See also, e.g., ¶25, “… a relationship graph is created …” and ¶26, “blocks 302 and 304 of the method 300 may be repeated periodically by the system management application 202a …” Examiner’s note: the Specification provides that examples of attributes may include model, capacity, speed, version, type, and other known attributes and information (see Spec. at ¶41). The relationship table comprises at least component type/model and firmware version for each individual component of the system);
[determining compatibility of the bundles with the components using the relationships], determining of the compatibility adapting to changing hardware and software landscapes based on the dynamic relationships (Thodati, e.g., ¶27, “method 300 may then proceed to block 306 where a firmware compatibility table is created that details the system components in the networked system, along with compatible firmware for those system components …” See also, e.g., ¶30, “HIS manufacturers may publish a variety of compatibility details for many thousands of component combinations and provide those compatibility details for retrieval … those compatibility details may be used to create the firmware compatibility table … system management application 202a may use the relationship graph 400 to determine a component combination of the networked system such that compatibility details may be retrieved for that component combination in order to determine the compatible components and firmware needed to optimally run the networked system …”) for the purpose of periodically updating information regarding the components and corresponding attributes of a system as well as available firmware version and compatibility information in order to determine an optimal configuration for the system as a whole and, where necessary, provide firmware updates (Thodati, e.g., ¶¶5, 20-32).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for evaluating the compatibility and performance of a plurality of software artifact bundles to diverse vehicle and vehicle system devices as taught by Mesde in view of Farrell to provide that the relationships further define dynamic relationships between the hardware components having changing attributes, and the determining of the compatibility adapting to changing hardware and software landscapes based on the dynamic relationships because the disclosure of Thodati shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for system component and attribute relationship identification, management and optimization to provide that the relationships further define dynamic relationships between the hardware components having changing attributes, and the determining of the compatibility adapting to changing hardware and software landscapes based on the dynamic relationships for the purpose of periodically updating information regarding the components and corresponding attributes of a system as well as available firmware version and compatibility information in order to determine an optimal configuration for the system as a whole and, where necessary, provide firmware updates (Thodati, Id.).
Claims 8 and 15 are rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 8, Mesde further teaches: A computer program product comprising: a set of one or more computer-readable storage media; program instructions, collectively stored in the set of one or more storage media, for causing a processor set to perform (Mesde, e.g., 14:12-15:4, “exemplary computer system 1000 … includes one or more processors 1010 coupled to a system memory … System memory 1020 may be performed to store … program instructions … accessible by processor 1010 … program instructions and/or data may be received, sent or stored upon different types of computer-accessible media … separate from system memory 1020 …”) the following computer operations: [[[the method of claim 1]]]; and with respect to claim 15, Mesde further teaches: A computer system comprising: a processor set; a set of one or more computer-readable storage media; program instructions, collectively stored in the set of one or more computer-readable storage media, for causing the processor set to perform (Mesde, e.g., 14:12-15:4, “exemplary computer system 1000 … includes one or more processors 1010 coupled to a system memory … System memory 1020 may be performed to store … program instructions … accessible by processor 1010 … program instructions and/or data may be received, sent or stored upon different types of computer-accessible media … separate from system memory 1020 …”) the following computer operations: [[[the method of claim 1]]].
Regarding claim 2, the rejection of claim 1 is incorporated, and Mesde further teaches: verifying the software release bundle before initiating the deployment of the software release bundle for compatibility by conducting validation and testing procedures to confirm suitability of the software release bundle for deployment on the computer node (Mesde, e.g., 9:19-42, “Once the testing system 140 has performed the test of the software package/software package binaries 142, the testing system 140 may receive a testing result … one or more statistics measuring performance of the vehicle software package 200 and/or determinations whether the software package 200 meets the requirements of the software testing … a particular iteration of the tests may generate a different software artifact set for the vehicle model associated with a particular software test iteration.” Examiner’s note: based on executing the tests on the particular configuration (i.e., the relationship between the bundle under test and the hardware of a target vehicle having particular components), the compatibility of the bundle is determined (i.e., a performance determination) that is used to determine whether to certify the bundle for the vehicle (see further, e.g., 12:35-13:8)).
Regarding claim 3, the rejection of claim 1 is incorporated, and Mesde and Thodati further teach: wherein the constructing of the relationships between the hardware components and the software release bundles based on the attributes includes building inter-relationships of the attributes, wherein the relationships are constructed based on the inter-relationships of the attributes (Mesde, e.g., 8:51-9:8, “test configurations 246 may determine properties of the electronic control units simulated in the testing environment 332 of the vehicle model that the software package 200 is intended to be deployed to … may determine the operating system of the electronic control unit being simulated in the testing environment …” Examiner’s note: the relationship is the connection and the logic necessary to configure simulated ECUs (hardware) for the deployment of particular software artifacts (software release bundle) (see further, e.g., 12:3-34)),
the constructing further including maintaining the dynamic relationships by performing periodic updates (Thodati, e.g., ¶25, “… a relationship graph is created …” and ¶26, “blocks 302 and 304 of the method 300 may be repeated periodically by the system management application 202a …”).
Claims 9-10 and 16-17 are rejected for the additional reasons given in the rejections of claims 2-3 above.
Regarding claim 5, the rejection of claim [[1]]3 is incorporated, and Mesde further teaches: wherein the inter-relationships include direct dependencies among attributes (Mesde, e.g., 7:54-57, “software dependencies 244 may be direct dependencies that the software package 200 calls directly in its code, or they may be transitive dependencies that a dependency of the software package 200 is dependent upon …”).
Regarding claim 6, the rejection of claim [[1]]3 is incorporated, and Mesde further teaches: wherein the inter-relationships include indirect dependencies among attributes (Mesde, e.g., 7:54-57, “software dependencies 244 may be direct dependencies that the software package 200 calls directly in its code, or they may be transitive dependencies that a dependency of the software package 200 is dependent upon …”).
Claims 12-13 and 19-20 are rejected for the additional reasons given in the rejections of claims 5-6 above.
Regarding claim 7, the rejection of claim 1 is incorporated, and Mesde further teaches: checking for operating system compatibility with the software release bundles and updating the relationships based on the checking (Mesde, e.g., 3:1-7, “require the software package to be tested … carried out in the correct operating system of the vehicle model having the correct test resources and dependencies that are associated to that unique version of the software package.” See also, e.g., 8:18-34, “testing environment 332 may, for example, comprise one or more servers with a specified computational capacity … and a specified software stack (e.g., a particular version of an operating system, as may be used in … an ECU …” Examiner’s note: the determination of the operating system, followed by testing on that operating system, in order to determine whether the release bundle should be certified for that vehicle / model / operating system, results in updating the relationships (such as the certification record)).
Claim 14 is rejected for the additional reasons given in the rejection of claim 7 above.
Claims 4, 11 and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over Mesde in view of Farrell and Thodati, and in further view of Ahmed et al., U.S. 9,424,025 B1 (“Ahmed”).
Regarding claim 4, the rejection of claim [[1]]3 is incorporated, but Mesde in view of Farrell and Thodati does not more particularly teach that the inter-relationships include mandatory and optional characteristics among the attributes. However, Ahmed does teach: wherein the inter-relationships include mandatory and optional characteristics among the attributes (Ahmed, e.g., claim 1, “determining backward compatibility of a software component … identifying … [APIs] that are exposed by a first version of a software component … attributes of the exposed programming interfaces are converted into corresponding operations such that a flag is added … indicating whether the attribute is an optional or a mandatory attribute …”) for the purpose of generating a tree structure including and describing the relationship between software attributes and parameters thereof, wherein attribute relationships can have different types, and the tree structure being used to evaluate compatibility (Ahmed, e.g., 6:14-59).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for evaluating the compatibility and performance of a plurality of software artifact bundles to diverse vehicle and vehicle system devices as taught by Mesde in view of Farrell and Thodati to provide that the inter-relationships include mandatory and optional characteristics among the attributes because the disclosure of Ahmed shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for verifying the backward compatibility of software components to provide that the inter-relationships include mandatory and optional characteristics among the attributes for the purpose of generating a tree structure including and describing the relationship between software attributes and parameters thereof, wherein attribute relationships can have different types, and the tree structure being used to evaluate compatibility (Ahmed, Id.).
Claims 11 and 18 are rejected for the additional reasons given in the rejection of claim 4 above.
Response to Arguments
In the Remarks, Applicant Argues: The amendments to the claims render the rejections under 35 U.S.C. § 112(b) moot. Further, the subject matter included in the amendments to claims 1, 8 and 15 distinguishes over the teachings of Mesde, Farrell and Ahmed. Accordingly, the claims are in condition for allowance.
Examiner’s Response: In view of the amendments, the rejections under 35 U.S.C. § 112(b) have been withdrawn. In addition, Examiner newly cites to Thodati, and maintains the rejections under 35 U.S.C. § 103 under the new grounds set forth in full above.
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.
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191
Prosecution Insights