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 .
No claims are currently amended. Claims 5, 12, and 18 are currently cancelled. No new claims have been added. Claims 1-4, 6-11, 13-17, and 19-20 are currently pending for examination.
Response to Arguments
Applicant’s arguments, pgs. 9-10, filed 10/30/2025, with respect to the rejection of the independent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Stefanov (US 20180341471 A1).
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.
Claims 1, 3-4, 7-8, 10-11, 14, 16-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Greenwood (US 20080295086 A1) in view of Hwang (US 20210019135 A1) in further view of Saraswat (US 20210304102 A1) in further view of Galchenko (US 20210409275 A1) in further view of Rishi (US 5953530 A) in further view of Stefanov (US 20180341471 A1).
Examiner Note: Support for the claimed OS layer and triggering can be found at e.g., [0013-0014] of the applicant’s specification; “The OS layer can be a patch, for example, that includes a set of changes to the base OS to enable the functionality corresponding to the OS layer.” [0014]: “In embodiments, the functionality OS layers and/or user OS layers can be added and/or removed in response to triggering events. A triggering event can be a user request, a usage condition threshold (e.g., conditions related to an increase or decrease in resource usage), an expiration of a specified time period, and/or a detection of another device within a mesh network. It should be appreciated that other triggering events are envisioned. The OS manager can detect a triggering event corresponding to a particular functionality.” And triggering is supported by e.g., [0018] “Once a triggering event has been detected, the OS layer corresponding to the functionality can be added to the base OS (e.g., by installing a patch retrieved from a centralized OS layer database”
As per claim 1, Greenwood discloses:
A method comprising: identifying a plurality of functionalities (Examiner Note: not further defined, reads on e.g., inherent computer functions and/or driver functions ; “As an example, at least a portion of the patch layering subsystem 240 may be implemented as one or more drivers (e.g., filter drivers) at the operating system”, 0051 ), available to a first device, wherein the first device comprises a base operating system (“Base OS 210 may include base configuration settings (e.g., registry settings) and files that are globally available to applications 220 for reading and writing operations. The configuration settings and files of the base OS 210 may be included in base file system and configuration libraries 230, also referred to as a base file system and configuration 230, for use in executing the functions of the base OS 210 including operating file systems, configuration settings such as registries, and other operating system functions. The base file system and configuration libraries 230, including the base files and configuration settings of the base OS 210, may be stored to a particular location in the memory of the computing device 120”, 0046)
wherein each functionality is associated with an operating system layer corresponding to the functionality (“In certain embodiments, layer type information may be used to distinguish different types of patches. For example, operating system patches can be distinguished from application patches by assigning them different layer types. Accordingly, OS patches can be recognized and processed in a custom manner, including making OS patch layers 250 available early in a boot cycle. As another example, patch prioritization (e.g., version checking) operations customized for OS patches may be employed to handle the potentially complex priority relationships within a group of virtually installed and enabled OS patch layers 250”, 0059 ; Examiner Note: a patch equates to an OS layer)
Greenwood teaches the identification of OS layer, or patch, functionalities; as well as a base operating system, but does not explicitly disclose the detection of a triggering event associated with a functionality.
However, Hwang discloses:
detecting the first triggering event associated with a first functionality of the plurality of functionalities (“Patch requests 410 may be received from any patch source capable of providing patch or update information to system 301. For example, a patch request 410 that includes a request to install a particular operating system update may be received from the software vendor from which the operating system was purchased or from the software manufacturer that designed the operating system”, 0071; “a patch request 410 may indicate that it is possible to install a word-processor patch”, 0088; Examiner Note: the receipt of a patch request equates to the detection of a triggering event. Word-processing is an example of a function associated with a request);
responsive to detecting the first triggering event, adding, to the base operating system, the operating system a first layer corresponding to the first functionality (“When system 301 receives one or more requests to install patches or updates on target entities 430a-430c, system 301, using rules, axioms, concepts and other knowledge stored in knowledgebase 400, intelligently derives an optimal patch-orchestration plan that directs patching mechanisms 420a-420f to install each patch in an optimal manner.", 0069 )
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Greenwood with that of Hwang in order to automate the virtual installation of patches through the use of event triggers- such as a user request- allowing the system to be employed as a service which does not require administrative action to function.
Greenwood in view of Hwang teaches the above limitations of claim 1, but does not teach a triggering event comprising an increase in resource usage associated with a first functionality.
However, Saraswat discloses:
the first triggering event comprising an increase in resource usage associated with the first functionality (“A determination is made as to whether an increase in extrapolated resource usage is greater than a threshold at step 760. The threshold may be set by an administrator, be tied to actual resources, or set based on other criteria. If the increase in the extrapolated resource usage is greater than a threshold, such as for example greater than a rate of increase, greater than the current resources available, or some other threshold of resource usage, an alert is triggered at step 770. The alert may indicate to an administrator that additional resources need to be acquired or activated in order to meet the extrapolated resource usage, or that the expected rate of increase or additional infrastructure may require additional components”, 0051 ; “a snapshot for a period of time is identified per resource and key performance indicator at step 710.”, 0049 ; Examiner Note: the functionality of the specific resource whose KPI (key performance indicators) indicated an increase in usage equates to the first functionality)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Greenwood in view of Hwang with the increased resource usage alert, or trigger, of Saraswat in order to provide a means for detecting that the usage of a resource responsible for a specific functionality has increased, allowing the system to take action to accommodate this change-such as adding a patch or OS layer, leading to improved system performance.
Greenwood in view of Hwang in view of Saraswat discloses the above limitations of claim 1, but does not disclose detecting a second triggering event comprising a decrease in resource usage associated with the first functionality.
However, Galchenko discloses:
subsequent to executing the program associated with the first functionality, detecting a second triggering event associated with the first functionality, the second triggering event comprising a decrease in resource usage associated with the first functionality (“In its mitigation evaluation process, policy engine 250 uses the output data of the analysis created by traffic manager 240 to compare currently utilized resources and if resource utilization, in one example, has decreased compared to a previous iteration of evaluation. In this non-limiting example, one mitigation strategy would be to release resources back to a common resource pool if decreased usage is observed, to allow more resources to be made available to lower priority communication sessions or application tasks, due to previous network conditions, network events, node status, node events, and the like.”, 0115 ; “From its traffic evaluation, traffic manager 240 creates an analysis of the network and the operatively coupled nodes. Other elements of SD-WAN device 210 may use this analysis for further evaluation, such as policy engine 250”, 0110 ; Examiner Note: the evaluation that resource usage has decreased equates to a triggering event, as it is a trigger for releasing resources back to a common resource pool. The network management functionality of the SD-WAN device equates to a first functionality)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Greenwood in view of Hwang in further view of Saraswat with the decreased resource usage trigger of Galchenko, in order to provide a means for detecting that the usage of a resource responsible for a specific functionality has decreased subsequent to executing the program associated with the first functionality, allowing the system to take action to accommodate this change- leading to improved system performance.
Greenwood in view of Hwang in view of Saraswat in further view of Galchenko discloses the above limitations of claim 1, but does not disclose the allocation of resources for an operating system layer, or execution of a program associated with the first functionality, nor the removal of an operating system later and the local storage of the operating system layer which was removed.
However, Rishi discloses:
executing, with the first operating system layer of the base operating system, a program associated with the first functionality; (“Fig.2 is a general flow chart of dynamic patching for the run-time error checking”, col.3, lines 29-30 ; see fig.2 ; “The Sun dbx debugger program 307 can dynamically load libraries at run-time that were not specified at link time. Since such loading of libraries is done dynamically in the debugger program 307, the RTC module 309 can trap all calls to load a new library in the program and may apply patches just before such libraries are executed. // In summary, with the Sun dbx debugger there is no necessity for pre-patching a program before execution. Instead, the patches may be applied when the checking is initiated, thereby delaying the choice of the user until the actual run-time. Furthermore, by not modifying the target program object code at all and thus eliminating the need to relink the object files to produce the executable program, the approach of the present method avoids the use of extra links. Finally, the patches are applied to an in-memory process initiated from the existing target program such that a fully instrumented process is achieved.”, col.6, lines 30-46 ; “A module within the debugger program 307 referred to as a "run-time checking" (RTC) module 309 handles the user interface, printing of error messages and also handles the patching of the in-memory process 308 corresponding to the program 302.”, col.6, lines 6-10 ; Examiner Note: the program executed is the Sun dbx program, which the patch (equating to a first operating system layer) is used to execute; and the in-memory processes of the debugger equate to the functionality)
allocating a quantity of computing resources for the first operating system layer, wherein the quantity of computing resources is based on the first functionality ("At the very end of the scan, the debugger program comes up with a total size of the section of patch area that the debugger program is going to need in order to accommodate the patch sites found. The identification of a patch site only needs to be done once for a load object and any subsequent execution pass only requires locating a space for the corresponding section of the patch area space and installing the patch. The total size needed for the patch area section is recorded and a list of the patch area section sizes is produced. This list of patch area section sizes is the input to the next step, step 140, in which memory space is actually allocated to the patch area.", col.7, lines 41-53 ; Examiner Note: the memory space equates to a quantity of computing resources, and is based upon the needs of the debugger program, which equates to the functionality)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko with the system of Rishi in order to provide a means for changing the patches, or operating system layers, which are currently installed in an operating system- thereby allowing for layers which are associated with a decreased usage to be removed, increasing the efficiency of the operating system.
Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi fully discloses the above limitations of claim 1, but does not disclose the removal of an operating system layer.
However, Stefanov discloses:
responsive to detecting the second triggering event, removing, from the base operating system, the first operating system layer corresponding to the first functionality (“For example, one or more operating system layers may be identified and removed from a software appliance.”, 0004 ; “As referenced above, when it is desired to ship the container image 118 for provisioning to customers using the host server 106, it is sometimes desirable to remove one or more layers of the container image 118. More specifically, in the examples that follow, it is desired to remove any OS-related layers, and the OS layer 122 is described in particular detail.”, 0023 ; Examiner Note: the need to ship the container image equates to a triggering event)
storing the first operating system layer removed from the base operating system locally on the first device. (“The imported second layer and remaining plurality of layers may be saved within a second container image that is stored at the host server and made available to the customer to provide the software appliance (212)”, 0044 ; “For example, one or more operating system layers may be identified and removed from a software appliance. Then, when the software appliance is distributed and provisioned in a cloud or other network context, a same or different version of the operating system layer(s) may be utilized in re-packaging the software appliance for one or more customers.”, 0004 ; Examiner Note: in order to be utilized after removal, the OS layer is necessarily stored within the second container image stored at the host server- equating to a local device)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi with the system of Stefanov in order to provide a means for removing operating system layers quickly and efficiently, without disrupting the distribution or provisioning of the software appliance, and without disrupting desired operations of the software appliance as a whole (Stefanov, [0004]).
As per claim 3, Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi in further view of Stefanov fully discloses the limitations of claim 1.
Furthermore, Hwang discloses:
responsive to detecting a third triggering event associated with a second functionality of the plurality of functionalities, adding, to the base operating system, a second operating system layer corresponding to the second functionality (“In step 500, improved patch-orchestration system 301 receives one or more requests 410 to install one or more patches on one or more target entities 430a-430c. ; 0104] In step 560, system 301 implements the optimal orchestration plan selected in step 550. This implementation may be performed by any means known in the art, such as by directing an orchestration layer of a cloud-management platform or a proprietary or platform-dependent orchestration mechanism 420a-420f to install the patches requested by the patch requests 410.”, 0076 ; “a patch request 410 may indicate that it is possible to install a word-processor patch”, 0088 ; Examiner Note: the receipt of requests to install patches equates to triggering events. The functionality of the requested patches equates to the functionality corresponding to the triggering event.)
Furthermore, Greenwood discloses:
determining a first priority level associated with the first functionality; determining a second priority level associated with the second functionality; and responsive to determining that the second priority level exceeds the first priority level, prioritizing the second operating system layer over the first operating system layer. (“The patch layer 250 may include other information, including, but not limited to, prioritization information that can be used to identify prioritization of the patch layer 250 in relation to other patch layers 250, and layer type information indicative of the type of content included in the patch layer 250. For example, layer type information may identify patch layer 250 as being associated with patch content, thereby allowing the patch layer 250 to be treated differently from (e.g., prioritized over) other types of layers, as disclosed in the aforementioned U.S. patent application Ser. No. 11/528,858 filed Sep. 28, 200”, 0058 ; Examiner Note: identifying relative priorities necessitates determining a priority associated with a first and second patch layer (equating to an OS layer with specific functionality).)
As per claim 4, Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi in further view of Stefanov fully discloses the limitations of claim 3.
Furthermore, Greenwood discloses:
determining the first priority level comprises at least one of: identifying, in an OS layer registry, the first priority level of the first operating system layer corresponding to the first functionality; or determining the first priority level associated with the first functionality based on an amount of resources consumed by the first functionality. (“By way of an example, the mapping data 260 may include priority information representative of priority relationships between multiple patch layers 250 or between specific content instances in a patch layer 250. In certain embodiments, the priority information may include or be based on version information associated with patches. Instances of mapping data 260 may be sorted or otherwise organized based on their respective priority information.", 0063 ; Examiner Note: the mapping data equates to an OS layer registry)
As per claim 7, Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi in further view of Stefanov fully discloses the limitations of claim 1.
Furthermore, Hwang discloses:
the first triggering event further comprises at least one of a user request, a usage condition threshold, an expiration of a specified time period, or detection of a presence of a second device (“When system 301 receives one or more requests to install patches or updates on target entities 430a-430c, system 301, using rules, axioms, concepts and other knowledge stored in knowledgebase 400, intelligently derives an optimal patch-orchestration plan that directs patching mechanisms 420a-420f to install each patch in an optimal manner.", 0069)
As per claim 8, it is a system claim with substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons.
As per claim 10, it is a system claim with substantially the same limitations as claim 3, and as such, it is rejected for substantially the same reasons.
As per claim 11, it is a system claim with substantially the same limitations as claim 4, and as such, it is rejected for substantially the same reasons.
As per claim 14, it is a C.R.S.M. (Stefanov discloses: “FIG. 1 is intended as a simplified example of computing environments that may be used to implement the described techniques. Various types of one or more computer processors, executing code stored on one or more types of non-transitory computer-readable storage media, may be used to implement the system 100 of FIG. 1.”, 0037) claim with substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons.
As per claim 16, it is a C.R.S.M. claim with substantially the same limitations as claim 3, and as such, it is rejected for substantially the same reasons.
As per claim 17, it is a C.R.S.M. claim with substantially the same limitations as claim 4, and as such, it is rejected for substantially the same reasons.
As per claim 20, it is a C.R.S.M. claim with substantially the same limitations as claim 7, and as such, it is rejected for substantially the same reasons.
Claims 6, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Greenwood (US 20080295086 A1) in view of Hwang (US 20210019135 A1) in further view of Saraswat (US 20210304102 A1) in further view of Galchenko (US 20210409275 A1) in further view of Rishi (US 5953530 A) in further view of Stefanov (US 20180341471 A1) in view of Gould (US 20210368334 A1).
As per claim 6, Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi in further view of Stefanov fully discloses the limitations of claim 1, but does not disclose the second triggering event comprising a decrease in usage below a predetermined percentage.
However, Gould discloses:
Detecting the second triggering event comprises determining that an amount of resources consumed by the functionality has decreased by at least a predetermined percentage (“The controller 4037 may also determine the change as a decrease in usage (e.g., in frequency and/or duration). The controller 4037 may determine that the current usage has changed if the usage changes (e.g., increased or decreases) by a threshold amount, for example, twenty-five percent.”, 0262 )
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi in further view of Stefanov with that of Gould, in order to provide the system administrators control over how much of a decrease in resource usage associated with a functionality should be considered a trigger for removal of an OS layer, thereby allowing for the prevention of unnecessary short term OS layer additions and removals in response to small/insignificant usage decreases.
As per claim 13, it is a system claim with substantially the same limitations as claim 6, and as such, it is rejected for substantially the same reasons.
As per claim 19, it is a C.R.S.M. claim with substantially the same limitations as claim 6, and as such, it is rejected for substantially the same reasons.
Claims 2, 9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Greenwood (US 20080295086 A1) in view of Hwang (US 20210019135 A1) in further view of Saraswat (US 20210304102 A1) in further view of Galchenko (US 20210409275 A1) in further view of Rishi (US 5953530 A) in further view of Stefanov (US 20180341471 A1) in view of Fellers (US 11330081 B1).
As per claim 2, Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi in further view of Stefanov fully discloses the limitations of claim 1.
Furthermore, Hwang discloses:
receiving a user identifier (“Similarly, a patch request 410 may include a request to perform a physical update on a hardware-based network component, received from the manufacturer of the network component, from the software manufacturer that markets a network-management system that monitors the hardware component, or from a system-maintenance company responsible for administering a maintenance contract on network infrastructure that includes the hardware component. In this case the patch request 410 may also include instructions on how to perform or install the patch, an identification of a location at which to find related documentation of software, or information related to obtaining any hardware or tools necessary to install or validate the patch.”, 0072 ; Examiner Note: The receipt of an identification of a digital location at which to find the relevant software (equating to an OS layer) from a user equates to the receipt of a user ID which is used to find an OS layer associated with user.)
Hwang discloses the receipt of a form of user ID, but does not disclose the identifying of configuration files associated with the user from a registry.
However, Fellers discloses:
identifying, in an end-user operating system layer registry, an end-user operating system layer associated with the user identifier, wherein the end-user operating system layer comprises one or more configuration files associated with the user identifier (“Data abstraction model 350 may describe the structure and configuration information of a client device and/or an operating system that is associated with a user identifier. The abstracted configuration information may include one or more configuration files in any format, including but not limited to text files, extensible markup language (XML) files, hypertext markup language (HTML) files, or proprietary files such as Microsoft Word® or Microsoft Excel® spreadsheets, and the like.", col.11, lines 1-9 ; Examiner Note: a data abstraction model equates to an end-user operating system layer registry)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Greenwood in view of Hwang in further view of Saraswat in further view of Galchenko in further view of Rishi in further view of Stefanov with that of Fellers, in order to provide the system with a digital structure relating users to associated OS layers, such that the system may implement the OS layers associated with a user by receiving the user’s ID, rather than requiring the user to transmit or specify in their request the typical configuration files which they would like to have installed.
As per claim 9, it is a system claim with substantially the same limitations as claim 2, and as such, it is rejected for substantially the same reasons.
As per claim 15, it is a C.R.S.M. claim with substantially the same limitations as claim 2, and as such, it is rejected for substantially the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
CaraDonna (US 20180173554 A1) – discloses a storage layer based orchestration method for managing a disparate virtualization environment wherein each VM is associated with at least one virtual disc including boot data.
Morgenstern (US 8365164) – discloses a method of mapping a software installation including interaction with a plurality of interaction points during installation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS MICHAEL VINCENT whose telephone number is (703)756-1408. The examiner can normally be reached Mon-Fri 8:30AM-5:30PM.
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, April Blair can be reached on (571) 270-1014. 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.
/R.M.V./
Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196