DETAILED ACTION
This Action is a response to the filing received 3 April 2024. Claims 1-20 are presented for examination.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3 April 2024 is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. § 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 4-6 and 18-20 are rejected under 35 U.S.C. § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention. Claims 4-6 recites the limitation "the inter-relationships" in their respective line 1. There is insufficient antecedent basis for this limitation in the claim. Examiner recommends amending these claims to refer to and depend from claim 3, which sets forth “building inter-relationships.” Similar issues are found in claims 18-20, which should be amended to refer to and depend from claim 17.
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”).
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.).
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 further teaches: 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)).
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 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 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 in further view of Ahmed et al., U.S. 9,424,025 B1 (“Ahmed”).
Regarding claim 4, the rejection of claim 1 is incorporated, but Mesde in view of Farrell do 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 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.
Conclusion
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/Examiner, Art Unit 2191