Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This is the initial office action based on the application filed on October 1, 2023, which claims 1-20 are presented for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims, of which claim 1 and 11 are in independent form.
Priority
4. This application has PRO 63/379,977 10/18/2022.
The Office's Note:
5. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
Information Disclosure Statement
6. Information disclosure statement filed on 03/19/2024 and 05/01/2025, have been reviewed and considered by Examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
7. Claims 1-10 invoked 112(f). The claims 1-10 in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim Rejections - 35 USC § 103
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.
8. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Price (US 20160004528 and further in view of Newell (US 20170003950, herein after Newell).
Claim 1 is rejected, Price teaches a system, comprising (Price, abstract and summary):
a first endpoint of the manage network that implements a first operating system (OS) and a first application configured to operate on the first OS (Price, para [0039], these heterogeneous server computers may execute a large number of different operating systems (e.g., Windows, Unix, Linux, Macintosh OSX, etc.)—each requiring different patches—and further may execute many different types and/or versions of applications (e.g., web server applications, database server applications, etc.) that similarly require different patches. Para [0082], each update application module is the same, but in some embodiments each is customized to the particular computing device (e.g., based upon the operating system and/or resources of the computing device, or based upon the particular applications executing on that computing device). Para [0100-0101], This decentralized manner in which the patching may occur across multiple computing systems potentially heterogenous computing environments increases efficiency.);
a second endpoint of the manage network that implements a second OS, a second application configured to operate on the second OS, and an agent (Price, para [0039], these heterogeneous server computers may execute a large number of different operating systems (e.g., Windows, Unix, Linux, Macintosh OSX, etc.)—each requiring different patches—and further may execute many different types and/or versions of applications (e.g., web server applications, database server applications, etc.) that similarly require different patches. Para 0082], each update application module is the same, but in some embodiments each is customized to the particular computing device (e.g., based upon the operating system and/or resources of the computing device, or based upon the particular applications executing on that computing device). Para [0100-0101], This decentralized manner in which the patching may occur across multiple computing systems potentially heterogenous computing environments increases efficiency.); and
an update device communicatively coupled to the repository device, the first endpoint, the second endpoint, and a second vendor device, wherein the update device is configured to (Price, para [0048], Administrative server 102 can be a top level orchestrator or other cloud management utility that provides the update application modules to the various computing devices during each patching procedure. In some embodiments, administrative server 102 may execute on a separate computing device external to computing devices 104A-104N, execute on a client device (e.g., of a network administrator), or execute on a computing device within a pod.):
receive from the second vendor device a first update configured modify the first application on the first endpoint and first metadata associated with the first update (Price, para [0037], patch. Para [0076-0077], With knowledge of the set of executing and relevant applications 314 on that device, the update application module 324, in some embodiments, connects to the shared network location 304 and may query the mapping of labels 305 (e.g., download and examine, or issue an API call to the device at the shared network location 104) to determine one or more labels that are applicable. Thus, the update application module 324 is able to retrieve a set of patches 306 that the particular computing device requires (with respect to the executing applications). Para [0063-0064], In certain embodiments, the update application module may determine the required labels or patches for its applications by communicating with a patch server 206. The update application modules of computing devices 204A-204N can send configuration information to patch server 206. In return, patch server 206 may send back to the respective computing devices patch identification information identifying the required labels or patches for each computing device and/or one or more server locations in which the required labels or patches may be accessible.);
generate a first update package based on the first metadata, wherein the first update package includes a command and data sufficient to implement the first update on the first endpoint (Price, para [0064-0065], According to the patch identification information received from patch server 206, a computing device can request a subset of patches from one or more servers 208A-208N. In some embodiments, patch identification information may indicate a location where certain required label(s) or patch(es) are stored or are accessible. Different subsets of the required patches may be accessible at different server locations 208A-208N. Thus, the update application module at a single computing device may request different subsets of patches from different servers 208A-208N. In some embodiments, the update application module gathers the required patches for that computing device according to the needed label(s) for that computing device.);
distribute the first update and the first update package to the first endpoint such that the first endpoint implements the first update according to the first update package to modify the first application(Price, para [0066], The update application module may then install the subsets of patches on the computing device. Upon receiving each subset of patches from a server, the update application module prepares the subset of patches and the computing environment for update. The update application module shuts down the necessary server applications and performs the patching. Subsequently, the update application module performs a post-patching process. If any additional subsets of patches are received from another server, the update application module may prepare that subset of patches for update. Fig. 5 and para [0086-0087], In the depicted embodiment, flow 500 begins with block 502, where the computing device to be upgraded receives, from an adminstrative server, an update application for updating the computing device. In some embodiments, a top level orchestrator (e.g., an adminstrative server) provides the update application module to each computing device as part of a patching procedure. The administrative server can send out an update application module to each of the multiple computing devices simultaneously or sequentially to enable the multiple computing devices to perform a patching procedure on their individual devices. The update application module allows each computing device to identify the necessary patches for the computing device, retrieve the patches, and cause the patches to be applied to the applications being executed on the computing device. Para [0088-0092].);
access from the agent a product update list, wherein the product update list identifies the second application on the second endpoint that is in an unpatched state and repository information with which the second endpoint communicates to access a second update associated with the second application(Price, fig. 5, component 506 and para [0089]. Based on the configuration information, an update application module being executed on the computing device can determine the set of patches that are necessary to update the applications (and/or versions or releases of the applications) that are executing upon the computing device. Para [0090], In some embodiments, the update application module may determine the set of patches by sending the configuration information to a patch server. Upon receiving the configuration information of a computing device, the patch server may then determine the necessary patches for an update and send back patch identification information to the computing device. The patch identification information may include identifiers for the set of patches and/or network locations at which each of the set of patches may be retrievable. Para [0063-0065], According to the patch identification information received from patch server 206, a computing device can request a subset of patches from one or more servers 208A-208N. In some embodiments, patch identification information may indicate a location where certain required label(s) or patch(es) are stored or are accessible. Different subsets of the required patches may be accessible at different server locations 208A-208N. Thus, the update application module at a single computing device may request different subsets of patches from different servers 208A-208N. In some embodiments, the update application module gathers the required patches for that computing device according to the needed label(s) for that computing device.);
based on the repository information, access, from the repository device, the second update and second metadata associated with the second update(Price, para [0039], these heterogeneous server computers may execute a large number of different operating systems (e.g., Windows, Unix, Linux, Macintosh OSX, etc.)—each requiring different patches—and further may execute many different types and/or versions of applications (e.g., web server applications, database server applications, etc.) that similarly require different patches. Para [0082], each update application module is the same, but in some embodiments each is customized to the particular computing device (e.g., based upon the operating system and/or resources of the computing device, or based upon the particular applications executing on that computing device). Para [0047]. Price, para [0064-0065], According to the patch identification information received from patch server 206, a computing device can request a subset of patches from one or more servers 208A-208N. In some embodiments, patch identification information may indicate a location where certain required label(s) or patch(es) are stored or are accessible. Different subsets of the required patches may be accessible at different server locations 208A-208N. Thus, the update application module at a single computing device may request different subsets of patches from different servers 208A-208N. In some embodiments, the update application module gathers the required patches for that computing device according to the needed label(s) for that computing device.);
generate a second update package based on the second metadata, wherein the second update package includes a command and data sufficient to implement the second update on the second endpoint (Price, para [0064-0065], According to the patch identification information received from patch server 206, a computing device can request a subset of patches from one or more servers 208A-208N. In some embodiments, patch identification information may indicate a location where certain required label(s) or patch(es) are stored or are accessible. Different subsets of the required patches may be accessible at different server locations 208A-208N. Thus, the update application module at a single computing device may request different subsets of patches from different servers 208A-208N. In some embodiments, the update application module gathers the required patches for that computing device according to the needed label(s) for that computing device. Price, para [0039], these heterogeneous server computers may execute a large number of different operating systems (e.g., Windows, Unix, Linux, Macintosh OSX, etc.)—each requiring different patches—and further may execute many different types and/or versions of applications (e.g., web server applications, database server applications, etc.) that similarly require different patches. Para [0082], each update application module is the same, but in some embodiments each is customized to the particular computing device (e.g., based upon the operating system and/or resources of the computing device, or based upon the particular applications executing on that computing device). Para [0047].); and
distribute the second update and the second update package, the distribution being configured such that the second endpoint locally implements the second update according to the second update package to modify the second application(Price, para [0066], The update application module may then install the subsets of patches on the computing device. Upon receiving each subset of patches from a server, the update application module prepares the subset of patches and the computing environment for update. The update application module shuts down the necessary server applications and performs the patching. Subsequently, the update application module performs a post-patching process. If any additional subsets of patches are received from another server, the update application module may prepare that subset of patches for update. Fig. 4, step 408 and para [0084]. Fig. 5 and para [0086-0087], In the depicted embodiment, flow 500 begins with block 502, where the computing device to be upgraded receives, from an adminstrative server, an update application for updating the computing device. In some embodiments, a top level orchestrator (e.g., an adminstrative server) provides the update application module to each computing device as part of a patching procedure. The administrative server can send out an update application module to each of the multiple computing devices simultaneously or sequentially to enable the multiple computing devices to perform a patching procedure on their individual devices. The update application module allows each computing device to identify the necessary patches for the computing device, retrieve the patches, and cause the patches to be applied to the applications being executed on the computing device. Para [0088-0092].).
Price does not explicitly teach
a repository device that is communicatively coupled to a first vendor device that operates outside a managed network
However, Newell teaches
a repository device that is communicatively coupled to a first vendor device that operates outside a managed network (Newell, US 20170003950, component 116 – repository, component 106 – Hardware/Software Suppliers and para [0028], The example software manager 114 receives software from the example hardware/software supplier(s) 106 and stores the data in the example repository 116. );
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filling date of the claimed invention would have been motivated to incorporate Newell into Price to determine multiple updates to be installed on physical computing resources in the virtual server rack system based on a manifest file. The dependency requirements are determined for installing the software updates identified in the manifest file. An order for installation of the software updates is determined to meet dependency requirements by executing an instruction with a processor. The installation of the software updates identified in the manifest file is scheduled by executing an instruction with the processor as suggested by Newell(See abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Price and Newell teach the system of claim 1, wherein: the first OS includes a non-Linux-based OS; and the second OS includes a Linux-based OS(Price, para [0039], these heterogeneous server computers may execute a large number of different operating systems (e.g., Windows, Unix, Linux, Macintosh OSX, etc.)—each requiring different patches—and further may execute many different types and/or versions of applications (e.g., web server applications, database server applications, etc.) that similarly require different patches. Para [0082], each update application module is the same, but in some embodiments each is customized to the particular computing device (e.g., based upon the operating system and/or resources of the computing device, or based upon the particular applications executing on that computing device). Para [0100-0101], This decentralized manner in which the patching may occur across multiple computing systems potentially heterogenous computing environments increases efficiency).
Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Price and Newell teach the system of claim 1, wherein: the update device is configured to obtain outside metadata from an outside source; and the second update package is generated based at least partially on the outside metadata (Newell, fig. 1A and 1B, component 106 – Hardware/Software Suppliers and para [0032], The example repository 116 stores software received from the example hardware/software supplier(s) 106 and manifest files generated by the example software manager 114 for the example software. The repository 116 of the illustrated example is communicatively coupled with the example software manager 114 to allow the example software manager 114 to store and retrieve software. The example repository 116 is a database. Alternatively, the example repository may be any other type of storage such as, for example, a network attached storage, a hard drive, a shared network drive, a file, a folder, etc.).
Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Price and Newell teach the system of claim 3, wherein:
the outside source includes a common vulnerabilities and exposures (CVE) host site or a vulnerabilities management and prioritization site; and the outside metadata includes one or more or a combination of a security or risk rating of the second update, an application affected by the second update, a patch type, a patch source, and a vulnerability severity (Newell, para [0065-0066], The request handler 308 of the illustrated example determines if a bundle acceleration instruction was received (block 522). A bundle acceleration instruction indicates that a software bundle should be deployed to virtual server racks more rapidly than the next scheduled software release. For example, distribution of a bundle may be accelerated when the existing software bundle includes a vulnerability that is patched by the most-current software bundle. The bundle acceleration instruction may be received from a user, may be identified in an attribute of the software received by the example software receiver 302, etc.).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Price and Newell teach the system of claim 1, wherein:
the update device is further configured to implement a policy related to the second endpoint; the policy is configured to trigger an automated product update based on one or more values in the second metadata; and the generation of the second update package and the distribution of the second update and the second update package is based on the policy (Price, fig. 4, steps 406 and 410 and para [0084], the second update is carried out automatically based on a policy).
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Price and Newell teach the system of claim 1, wherein the update device is further configured to:
implement a policy related to the second endpoint (Wellness, para [0065], A bundle acceleration instruction indicates that a software bundle should be deployed to virtual server racks more rapidly than the next scheduled software release. For example, distribution of a bundle may be accelerated when the existing software bundle includes a vulnerability that is patched by the most-current software bundle. The bundle acceleration instruction may be received from a user, may be identified in an attribute of the software received by the example software receiver 302, etc.);
determine that the second metadata includes insufficient information to assess severity of the second update (Wellness, para [0066], When the example request handler 308 determines that a bundle acceleration instruction was not received (block 522));
determine whether the policy includes a default deployment configuration, the default deployment configuration triggers distribution of the second update in absence of the second metadata being indicative of information sufficient to assess severity of the second update (Wellness, para [0066], when the example request handler 308 receives a request from a virtual server rack (e.g., a software update request), the example request handler 308 will detect the flag and notify the requesting virtual server rack that an accelerated bundle is available (e.g., to suggest that the virtual server rack should deploy the bundle even if it is not time for a scheduled release). ); and
responsive to the policy including the default deployment configuration, trigger the generation and distribution of the second update (Wellness, para [0066], when the example request handler 308 receives a request from a virtual server rack (e.g., a software update request), the example request handler 308 will detect the flag and notify the requesting virtual server rack that an accelerated bundle is available (e.g., to suggest that the virtual server rack should deploy the bundle even if it is not time for a scheduled release). ).
Claim 7 is rejected for the reasons set forth hereinabove for claim 1, Price and Newell teach the system of claim l, wherein the update device is further configured to parse the second metadata to determine whether the second update includes a characteristic that triggers one or more automated update operations of the second application (Price, fig. 4, steps 406 and 410 and para [0084-0085] - the second update is carried out automatically based on a policy).
Claim 8 is rejected for the reasons set forth hereinabove for claim 1, Price and Newell teach the system of claim 1, wherein :the product update list is generated based on an inquiry communicated by the agent to the repository device and product information accessed by the agent at the second endpoint; and the repository device includes an entity-specific repository device developed by an administrator of the managed network (Price, fig. 4 and step 408 and para [0084-0085] – the second update is generated based on an inquiry of the device to be updated. The inquiry results are compared to target patch level.) .
Claim 9 is rejected for the reasons set forth hereinabove for claim 1, Price and Newell teach the system of claim 1, wherein the update device is configured to: determine that a third endpoint includes the second OS and the second application; and in response to the determination that the third endpoint includes the second OS and the second application, further distribute the second update and the second update package to the third endpoint (Price, the above discussion for upgrading the software on the second endpoint applies accordingly to the third endpoints of this claim).
Claim 10 is rejected for the reasons set forth hereinabove for claim 1, Price and Newell teach the system of claim 1, wherein: the repository device includes a first repository device; the repository information is first repository information; the product update list further identifies a third application on the second endpoint that is in an unpatched state and second repository information with which the second endpoint communicates to access a third update associated with the third application; the system further comprises a second repository device for the third application on the second endpoint; and the update device is further configured to: based on the second repository information, access, from the second repository device, the third update and third metadata associated with the third update; generate a third update package based on the third metadata, wherein the third update package includes a command and data sufficient to implement the third update on the second endpoint; and distribute the third update and the third update package, the distribution being configured such that the second endpoint locally implements the third update according to the third update package to modify the third application(Price, the above discussion for upgrading the software on the second endpoint applies accordingly to the third endpoints of this claim).
As per claim 11, this is the method claim to system claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 12, this is the method claim to system claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 13, this is the method claim to system claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 14, this is the method claim to system claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the method claim to system claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the method claim to system claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the method claim to system claim 7. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the method claim to system claim 8. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the method claim to system claim 9. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the method claim to system claim 10. Therefore, it is rejected for the same reasons as above.
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached on 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199