DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/25/2025, for application 17/546,860 has been entered.
This Office Action is in response to the Amendment filed on 02/18/2025. In the instant amendment: Claims 1 and 14 have been amended and claims 1 and 14 are independent claims. Claim 24 has been cancelled and claims 25-33 newly added. Claims 1-23, 25-33 have been examined and are pending.
Examiner’s Notes:
To promote compact prosecution, the Examiner contacted applicant’s representative, Benjamin Volk Jr. (Reg. No.: 48017), to propose and Examiner’s amendment. However, the Examiner was unable to reach an agreement with the applicant.
Response to Arguments
Claim interpretation under 35 U.S.C. 112(f) is maintained.
Applicants' arguments in the instant Amendment, filed on 11/25/2025, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant Argues: Zacks and Mitra fail to disclose “wherein the first and second services comprise different applications for running on an operating system” of amended claims 1 and 14, and “wherein the automated management by the controller includes deletion of the modification to the first service, removal of the modification to the first service, and/or undoing of the modification to the first service based on the cleanup rule if the second service is deleted and/or disabled ” of amended claim 14. See Remarks at 8-9.
The examiner respectfully disagrees because these arguments are not persuasive.
In regards to, “wherein the first and second services comprise different applications for running on an operating system,” Zacks teaches “one or more applications 170A-C may be running on the operating system 150. As used herein, an application 170A-C may be referenced as an application program, a program… In an example, the one or more applications 170A-C may run directly on the computer system 100 without an operating system 150 beneath it. The computer system 100 may run any type of dependent, independent, compatible, and/or incompatible applications 170A-C on the underlying hardware and OS 150.” See Zacks FIG. 1, ¶¶ [0016]-[0017] (emphasis added). Indeed, applications of different types or having difference characteristics may run on the computer and its operating system. Accordingly, Zacks teaches the above limitations of claims 1 and 14.
In regards to, “wherein the automated management by the controller includes deletion of the modification to the first service, removal of the modification to the first service, and/or undoing of the modification to the first service based on the cleanup rule if the second service is deleted and/or disabled,” Zacks discloses “[i]n this manner, an OS 150 level change, such as a security patch, may be installed on multiple applications 170A-B without having to save the same first data (e.g., the security patch) for each application 170A-B for which the OS 150 level change is made. For example, rather than separately storing the security patch for two separate applications 170A-B, the security patch may be advantageously stored once using the snapshot manager 160 of the present disclosure. In an example, the snapshot manager 160 (and/or OS 150) is configured to uninstall one or more applications 170A-C and delete the one or more snapshot tables 210A-C corresponding to the one or more applications 170A-C. For example, responsive to a request (e.g., by a user and/or the OS 150) to uninstall (or delete) the first application 170A, the snapshot manager 160 (and/or OS 150) may cause the first application 170A to be uninstalled and delete the first snapshot table 210A1.” See Zacks ¶¶ [0039] –[0040] (emphasis added). As explained in the footnote, a security patch is an update to a previous version of software to address a vulnerability. Because successive software updates/application of security patches can remove, change, or undo prior (and possibly outdated and flawed) security patches for a plurality of software applications, Zacks thus teaches “wherein the automated management by the controller includes deletion of the modification to the first service, removal of the modification to the first service, and/or undoing of the modification to the first service based on the cleanup rule if the second service is deleted and/or disabled” of amended claim 14.
In conclusion, applicant’s arguments are unpersuasive and the rejection of claims 1 and 14 are maintained.
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.
The claims 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
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
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.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “controller is configured to manage” of claim 1, “controller to validate” of claim 3, “controller [] configured to validate” of claim 4, “controller [] configured to provision” of claim 6, “controller [] configured to delete/manage” of claim 8, “controller [] configured to disconnect” of claim 9, “controller [] configured to re-connect” of claim 10, “controller [] configured to disconnect” of claim 11, “controller [] configured to re-connect” of claim 12, “controller [] configured to resolve” of claim 13, “controller is configured to maintain” of claim 14, “controller is configured to identify” of claim 15, “controller [] configured to determine/apply” of claim 17, “controller is configured to identify” of claim 21, “controller [] configured to log/generate” of claim 22, “controller is configured to provision/interact” of claim 24.
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 discloses as set forth in section 102 of this title, 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, 2, 5, 13, 14-23, 25-28, 30-33 are rejected under 35 U.S.C. 103 as being unpatentable over Zacks et al. (“Zacks,” US 20170364451, published Dec. 21, 2017) in view of Mitra (“Mitra,” US 20200356354, filed May 7, 2019).
Regarding claim 1, Zacks teaches An information technology (IT) computer system comprising: a controller configured to automatically manage the system based on a plurality of system rules, a system state for the system, [and a plurality of templates] (Zacks [0030]. The snapshot manager 160 may then determine whether the first application 170A has permission to access the first memory block (block 340). In an example, the snapshot manager 160 may maintain metadata regarding whether and/or how much access is permitted for each snapshot table 210A-C and application storage 220A-C to which each snapshot table 210A-C corresponds.);
a resource for connection to the controller (Zacks [0013], [0015]. In one illustrative example, a processor may follow Von Neumann architectural model and may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. Processors 120A-C may be interconnected using a variety of techniques, ranging from a point-to-point processor interconnect, to a system area network, such as an Ethernet-based network.),
wherein the resource comprises a first service and a second service (Zacks FIG. 3, [0017], [0023]. In an example, the one or more applications 170A-C may run directly on the computer system 100 without an operating system 150 beneath it. The computer system 100 may run any type of dependent, independent, compatible, and/or incompatible applications 170A-C on the underlying hardware and OS 150. In an example, applications 170A-C executing on a computer system 100 may be dependent on the underlying hardware and/or OS 150. For example, an application 170A executing on a computer system 100 may be dependent on the underlying hardware and/or OS 150 while other applications 170B-C executing on a computer system 100 may be independent of the underlying hardware and/or OS 150. FIG. 3 illustrates a flowchart of an example method 300 for secure live virtual machine guest based snapshot recovery in accordance with an example of the present disclosure.);
wherein the first and second services comprise different applications for running on an operating system (Zacks FIG. 1, [0016]-[0017]. One or more applications 170A-C may be running on the operating system 150. As used herein, an application 170A-C may be referenced as an application program, a program… In an example, the one or more applications 170A-C may run directly on the computer system 100 without an operating system 150 beneath it. The computer system 100 may run any type of dependent, independent, compatible, and/or incompatible applications 170A-C on the underlying hardware and OS 150.).
an application programming interface (API) that interfaces the first and second services with each other and with the controller (Zacks [0033], [0035]. [T]he snapshot manager 160 will permit the first application 170A's requested access to the first memory block. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the second application (e.g., application 170B-C) via an application program interface (API) of the snapshot manager 160. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.).
Zacks does not explicitly teach:
a plurality of templates;
wherein the first and second services have dependency with respect to each other, wherein the first service comprises a dependency service with respect to the second service, wherein the second service comprises a dependent service with respect to the first service;
wherein the templates include a template for the second service that comprises a list of dependencies required for setting up the second service, wherein the listed dependencies include the first service; and wherein the automated management by the controller includes, based on the template for the second service, configuring the second service and managing an interoperability of the first service with respect to the second service.
However, in an analogous art, Mitra teaches a system, comprising:
a plurality of templates; wherein the first and second services have dependency with respect to each other, wherein the first service comprises a dependency service with respect to the second service, wherein the second service comprises a dependent service with respect to the first service; wherein the templates include a template for the second service that comprises a list of dependencies required for setting up the second service, wherein the listed dependencies include the first service (Mitra FIGs 9, 11, [0043], [0047]. Along with this assessment, a software priority assignment module 244 can review the software items that have been determined to require updates and calculate or otherwise assign levels of priority to each. In some implementations, the system 200 can include provisions for automatically assigning such priority labels based on discrete categories (e.g., high priority, intermediate or average priority, or low priority) or may be configured to generate a distinct sequence of priority to each software instance, relative to the priority for other software instances in the group of applications that are to be updated (e.g., 1st, 2nd, 3rd and so forth). In different implementations, this information can be used by the prioritization module 246 as it submits an update query to an online software repository regarding the different software components (for example, for submission to the software update manager 270). In further examples, the update manager component 220 can also help determine a preferred sequence of downloading and/or applying the updates based on corresponding client configurable rules or preferences 216. Furthermore, the input component 222 can be configured to receive available updates (e.g., update packages 284)…. In some implementations, the system 200 can include provisions for determining or otherwise generating a schedule for the automated updates process based at least in part on this information [ ] in order to ensure a timely installation and availability of the various (updated) software programs. In some implementations, the schedule can be planned such that the higher priority updates are downloaded at a time prior to the OS upgrade event, thereby accommodating the estimated total deployment time for all updates.);
wherein the automated management by the controller includes, based on the template for the second service, configuring the second service and managing an interoperability of the first service with respect to the second service (Mitra FIG. 4, [0052]-[0053]. In different implementations, the system can include provisions for determining whether any software stored on the client device 300 is incompatible with the upcoming upgrade and generating instructions or workflow for ensuring updates (if any) for such software are obtained. In this example, at a first stage 412, the system determines that the version currently installed on the client device for first software 410 will be incompatible after the upgrade. In some implementations, such a determination can trigger a query to an online store or central software repository 450 from which information and update packages for software may be obtained.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings Mitra and Zacks to include: wherein the second service comprises a dependent service with respect to the first service; wherein the controller is configured to manage an interoperability of the first service with respect to the second service. One would have been motivated to provide users with a means to check the compatibility of the operating system with respect to the software application programs and to adjust or update the operating system with respect to the compatibility. (See Mitra FIG. 4, [0052] – [0053].)
Regarding claim 2, Zacks and Mitra teach the system of claim 1. Zacks further teaches wherein the second service is configured to issue a call on the first service through the API for the first service to perform an operation (Zacks [0033], [0035]. [T]he snapshot manager 160 will permit the first application 170A's requested access to the first memory block. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the second application (e.g., application 170B-C) via an application program interface (API) of the snapshot manager 160. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.).
Regarding claim 5, Zacks and Mitra teach the system of claim 1. Zacks further teaches wherein the first service is configured to perform an operation for the second service contingent on a permission from the controller (Zacks [0018], [0035]. In an example, the operating system 150 includes a file system 155. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.).
Regarding claim 13, Zacks and Mitra teach the system of claim 1. Mitra further teaches wherein the controller is further configured to resolve dependencies between the first and second services (Mitra FIG. 4, [0052]-[0053]. In different implementations, the system can include provisions for determining whether any software stored on the client device 300 is incompatible with the upcoming upgrade and generating instructions or workflow for ensuring updates (if any) for such software are obtained. In this example, at a first stage 412, the system determines that the version currently installed on the client device for first software 410 will be incompatible after the upgrade. In some implementations, such a determination can trigger a query to an online store or central software repository 450 from which information and update packages for software may be obtained.).
The motivation is the same as that of claim 1 above.
Regarding claim 14, Zacks teaches An information technology (IT) computer system comprising:
a controller configured to automatically manage the system based on a plurality of system rules, a system state for the system, [and a plurality of templates] (Zacks [0030]. The snapshot manager 160 may then determine whether the first application 170A has permission to access the first memory block (block 340). In an example, the snapshot manager 160 may maintain metadata regarding whether and/or how much access is permitted for each snapshot table 210A-C and application storage 220A-C to which each snapshot table 210A-C corresponds.);
a resource for connection to the controller (Zacks [0013], [0015]. In one illustrative example, a processor may follow Von Neumann architectural model and may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. Processors 120A-C may be interconnected using a variety of techniques, ranging from a point-to-point processor interconnect, to a system area network, such as an Ethernet-based network.),
wherein the resource comprises a first service and a second service (Zacks FIG. 3, [0017], [0023]. In an example, the one or more applications 170A-C may run directly on the computer system 100 without an operating system 150 beneath it. The computer system 100 may run any type of dependent, independent, compatible, and/or incompatible applications 170A-C on the underlying hardware and OS 150. In an example, applications 170A-C executing on a computer system 100 may be dependent on the underlying hardware and/or OS 150. For example, an application 170A executing on a computer system 100 may be dependent on the underlying hardware and/or OS 150 while other applications 170B-C executing on a computer system 100 may be independent of the underlying hardware and/or OS 150. FIG. 3 illustrates a flowchart of an example method 300 for secure live virtual machine guest based snapshot recovery in accordance with an example of the present disclosure.);
wherein the first and second services comprise different applications for running on an operating system (Zacks FIG. 1, [0016]-[0017]. One or more applications 170A-C may be running on the operating system 150. As used herein, an application 170A-C may be referenced as an application program, a program… In an example, the one or more applications 170A-C may run directly on the computer system 100 without an operating system 150 beneath it. The computer system 100 may run any type of dependent, independent, compatible, and/or incompatible applications 170A-C on the underlying hardware and OS 150.);
wherein the system rules include a cleanup rule that identifies a modification made to the first service as a dependency of the second service, and wherein the automated management by the controller includes deletion of the modification to the first service, removal of the modification to the first service, and/or undoing of the modification to the first service based on the cleanup rule if the second service is deleted and/or disabled (Zacks [0039] –[0040]. In this manner, an OS 150 level change, such as a security patch, may be installed on multiple applications 170A-B without having to save the same first data (e.g., the security patch) for each application 170A-B for which the OS 150 level change is made. For example, rather than separately storing the security patch for two separate applications 170A-B, the security patch may be advantageously stored once using the snapshot manager 160 of the present disclosure. In an example, the snapshot manager 160 (and/or OS 150) is configured to uninstall one or more applications 170A-C and delete the one or more snapshot tables 210A-C corresponding to the one or more applications 170A-C. For example, responsive to a request (e.g., by a user and/or the OS 150) to uninstall (or delete) the first application 170A, the snapshot manager 160 (and/or OS 150) may cause the first application 170A to be uninstalled and delete the first snapshot table 210A2.).
Zacks does not explicitly teach:
a plurality of templates;
wherein the first and second services have dependency with respect to each other,
wherein the first service comprises a dependency service with respect to the second service and
wherein the second service comprises a dependent service with respect to the first service.
However, in an analogous art, Mitra teaches a computer system, comprising:
a plurality of templates; wherein the first and second services have dependency with respect to each other, wherein the first service comprises a dependency service with respect to the second service and wherein the second service comprises a dependent service with respect to the first service (Mitra FIGs 9, 11, [0043], [0047]. Along with this assessment, a software priority assignment module 244 can review the software items that have been determined to require updates and calculate or otherwise assign levels of priority to each. In some implementations, the system 200 can include provisions for automatically assigning such priority labels based on discrete categories (e.g., high priority, intermediate or average priority, or low priority) or may be configured to generate a distinct sequence of priority to each software instance, relative to the priority for other software instances in the group of applications that are to be updated (e.g., 1st, 2nd, 3rd and so forth). In different implementations, this information can be used by the prioritization module 246 as it submits an update query to an online software repository regarding the different software components (for example, for submission to the software update manager 270). In further examples, the update manager component 220 can also help determine a preferred sequence of downloading and/or applying the updates based on corresponding client configurable rules or preferences 216. Furthermore, the input component 222 can be configured to receive available updates (e.g., update packages 284)…. In some implementations, the system 200 can include provisions for determining or otherwise generating a schedule for the automated updates process based at least in part on this information [ ] in order to ensure a timely installation and availability of the various (updated) software programs. In some implementations, the schedule can be planned such that the higher priority updates are downloaded at a time prior to the OS upgrade event, thereby accommodating the estimated total deployment time for all updates.)
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings Mitra and Zacks to include: wherein the second service comprises a dependent service with respect to the first service. One would have been motivated to provide users with a means to check the compatibility of the operating system with respect to the software application programs and to adjust or update the operating system with respect to the update priority and compatibility. (See Mitra FIG. 4, [0043], [0047].)
Regarding claim 15, Zacks and Mitra teach the system of claim 14. Zacks further teaches wherein the second service is configured to call on the first service for the first service to perform an operation, and (Zacks [0035]. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.); and
wherein the modification to the first service relates to performance of the operation; wherein the controller is configured to identify the modification to the first service as part of the cleanup rule (Zacks [0039] – [0040]. In this manner, an OS 150 level change, such as a security patch, may be installed on multiple applications 170A-B without having to save the same first data (e.g., the security patch) for each application 170A-B for which the OS 150 level change is made. In an example, the snapshot manager 160 (and/or OS 150) is configured to uninstall one or more applications 170A-C and delete the one or more snapshot tables 210A-C corresponding to the one or more applications 170A-C. For example, responsive to a request (e.g., by a user and/or the OS 150) to uninstall (or delete) the first application 170A, the snapshot manager 160 (and/or OS 150) may cause the first application 170A to be uninstalled and delete the first snapshot table 210A3.).
Regarding claim 16, Zacks and Mitra teach the system of claim 15. Zacks further teaches wherein the cleanup rule associates the modification to the first service with the second service (Zacks [0039] – [0040]. In this manner, an OS 150 level change, such as a security patch, may be installed on multiple applications 170A-B without having to save the same first data (e.g., the security patch) for each application 170A-B for which the OS 150 level change is made. In an example, the snapshot manager 160 (and/or OS 150) is configured to uninstall one or more applications 170A-C and delete the one or more snapshot tables 210A-C corresponding to the one or more applications 170A-C. For example, responsive to a request (e.g., by a user and/or the OS 150) to uninstall (or delete) the first application 170A, the snapshot manager 160 (and/or OS 150) may cause the first application 170A to be uninstalled and delete the first snapshot table 210.).
Regarding claim 17, Zacks and Mitra teach the system of claim 15. Zacks further teaches wherein the controller is further configured to (1) determine that the second service is or is to be deleted and/or disabled (. In an example, the snapshot manager 160 (and/or OS 150) is configured to uninstall one or more applications 170A-C and delete the one or more snapshot tables 210A-C corresponding to the one or more applications 170A-C. For example, responsive to a request (e.g., by a user and/or the OS 150) to uninstall (or delete) the first application 170A, the snapshot manager 160 (and/or OS 150) may cause the first application 170A to be uninstalled and delete the first snapshot table 210A.), and
(2) in response to the determination that the second service is or is to be deleted and/or disabled, apply the cleanup rule to delete, remove, and/or undo the identified modification to the first service (Mitra FIG. 4, [0052]-[0053]. In different implementations, the system can include provisions for determining whether any software stored on the client device 300 is incompatible with the upcoming upgrade and generating instructions or workflow for ensuring updates (if any) for such software are obtained [note that different software updates may undue, delete, or remove previous modifications/patches, as appropriate). In this example, at a first stage 412, the system determines that the version currently installed on the client device for first software 410 will be incompatible after the upgrade. In some implementations, such a determination can trigger a query to an online store or central software repository 450 from which information and update packages for software may be obtained.).
The motivation is the same as that of claim 14 above.
Regarding claim 18, Zacks and Mitra teach the system of claim 14. Zacks further teaches wherein the resource comprises a plurality of additional services that have dependencies with respect to each other (Zacks [0017]. In an example, the one or more applications 170A-C may run directly on the computer system 100 without an operating system 150 beneath it. The computer system 100 may run any type of dependent, independent, compatible, and/or incompatible applications 170A-C on the underlying hardware and OS 150.), and
wherein the cleanup rule comprises a plurality of cleanup rules that identify modifications made to the services by services (Zacks [0039]. In this manner, an OS 150 level change, such as a security patch, may be installed on multiple applications 170A-B without having to save the same first data (e.g., the security patch) for each application 170A-B for which the OS 150 level change is made. [Note that the Perkins reference as discussed previously may keep track of patches applied to applications as part of the process to track and update patches, as needed]).
Regarding claim 19, Zacks and Mitra teach the system of claim 18. Zacks further teaches wherein each service that is a dependent service is associated with cleanup rules that identify modifications to its dependency services (Zacks [0039]. In this manner, an OS 150 level change, such as a security patch, may be installed on multiple applications 170A-B without having to save the same first data (e.g., the security patch) for each application 170A-B for which the OS 150 level change is made. [Note that the Perkins reference as discussed previously teaches keeping track of patches applied to applications as part of the process of tracking and updating patches.]).
Regarding claim 20, Zacks and Mitra teach the system of claim 18. Zacks further teaches an application programming interface (API) that interfaces the services with each other and with the controller (Zacks [0033], [0035]. [T]he snapshot manager 160 will permit the first application 170A's requested access to the first memory block. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the second application (e.g., application 170B-C) via an application program interface (API) of the snapshot manager 160. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.).
Regarding claim 21, Zacks and Mitra teach the system of claim 20. Mitra further teaches wherein the dependent services are configured to call on their dependency services through the API (Mitra [0090]. The example software architecture 1302 may be conceptualized as layers, each providing various functionality. For example, the software architecture 1302 may include layers and components such as an operating system (OS) 1314, libraries 1316, frameworks 1318, applications 1320, and a presentation layer 1344. Operationally, the applications 1320 and/or other components within the layers may invoke API calls 1324 to other layers and receive corresponding results 1326.); and
wherein the controller is configured to identify the modifications to the dependency services as part of the cleanup rules (Mitra FIG. 4, [0052]-[0053]. In different implementations, the system can include provisions for determining whether any software stored on the client device 300 is incompatible with the upcoming upgrade and generating instructions or workflow for ensuring updates (if any) for such software are obtained [note that different software updates may undue, delete, or remove previous modifications/patches, as appropriate). In this example, at a first stage 412, the system determines that the version currently installed on the client device for first software 410 will be incompatible after the upgrade. In some implementations, such a determination can trigger a query to an online store or central software repository 450 from which information and update packages for software may be obtained.).
The motivation is the same as that of claim 20 above.
Regarding claim 22, Zacks and Mitra teach the system of claim 21. Zacks further teaches wherein the API is configured to log commands from the services, and wherein the controller is further configured to generate the cleanup rules from the logged API commands (Zacks [0033], [0035], [0039]. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the second application (e.g., application 170B-C) via an application program interface (API) of the snapshot manager 160. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160. In an example, responsive to receiving a request to modify more than one application 170A-B with first data, the snapshot manager 160 may save the first data in a second memory block…In this manner, an OS 150 level change, such as a security patch, may be installed on multiple applications 170A-B without having to save the same first data (e.g., the security patch) for each application 170A-B for which the OS 150 level change is made.).
Regarding claim 23, Zacks and Mitra teach the system of claim 14. Zacks further teaches a plurality of resources for connection to the controller, wherein the resources comprise a plurality of services that have dependencies with respect to each other, and wherein the cleanup rule comprises a plurality of cleanup rules that identify modifications made to the services by services (Zacks FIG. 3, [0017], [0023], [0039]. In an example, the one or more applications 170A-C may run directly on the computer system 100 without an operating system 150 beneath it. The computer system 100 may run any type of dependent, independent, compatible, and/or incompatible applications 170A-C on the underlying hardware and OS 150. In an example, applications 170A-C executing on a computer system 100 may be dependent on the underlying hardware and/or OS 150. For example, an application 170A executing on a computer system 100 may be dependent on the underlying hardware and/or OS 150 while other applications 170B-C executing on a computer system 100 may be independent of the underlying hardware and/or OS 150. FIG. 3 illustrates a flowchart of an example method 300 for secure live virtual machine guest based snapshot recovery in accordance with an example of the present disclosure. In this manner, an OS 150 level change, such as a security patch, may be installed on multiple applications 170A-B without having to save the same first data (e.g., the security patch) for each application 170A-B for which the OS 150 level change is made.).
Regarding claim 25, Zacks and Mitra disclose the system of claim 1. Zacks further discloses wherein the second service is configured to call the first service during an execution of the second service (Zacks [0033], [0035]. [T]he snapshot manager 160 will permit the first application 170A's requested access to the first memory block. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the second application (e.g., application 170B-C) via an application program interface (API) of the snapshot manager 160. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.).
Regarding claim 26, Zacks and Mitra disclose the system of claim 25. Zacks further discloses wherein the management of the interoperability of the first service with respect to the second service includes configuring the first service to be called by the second service (Zacks [0033], [0035]. [T]he snapshot manager 160 will permit the first application 170A's requested access to the first memory block. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the second application (e.g., application 170B-C) via an application program interface (API) of the snapshot manager 160. In an example, the application 170A may request that the second application B storage 220B be shared with application 170A. For example, a web browser application 170A may wish to access the memory of an document reading application B 170B. In another example, a document reading application 170A may wish to access a printer driver application B 170B. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.).
Regarding claim 27, Zacks in view of Mitra disclose the system of claim 1. Zacks further discloses wherein the second service comprises a web application, and wherein the first service comprises an http server application (Zacks [0033]. For example, a web browser application 170A4 may wish to access the memory of an document reading application B 170B. In another example, a document reading application 170A may wish to access a printer driver application B 170B.).
Regarding claim 28, Zacks in view of Mitra disclose the system of claim 1. Mitra further discloses wherein the second service comprises an electronic mail application or web mail application (Mitra [0060]. While a pop-up message is presented for purposes of this example, it should be understood that in other implementations, any other form of communication associated with the user's account may be used to provide such information, including but not limited to text messages, chat messages, email messages.).
The motivation is the same as that of claim 1 above.
Regarding claim 30, Zacks in view of Mitra disclose the system of claim 1. Zacks further discloses wherein the template for the second service further comprises connection rules that contain a call to the API for the first service (Zacks [0033], [0035]. [T]he snapshot manager 160 will permit the first application 170A's requested access to the first memory block. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the second application (e.g., application 170B-C) via an application program interface (API) of the snapshot manager 160. In an example, the application 170A may request that the second application B storage 220B be shared with application 170A. For example, a web browser application 170A may wish to access the memory of an document reading application B 170B. In another example, a document reading application 170A may wish to access a printer driver application B 170B. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.).
Regarding claim 31, Zacks in view of Mitra disclose the system of claim 1. Zacks further discloses wherein the controller comprises one or more processors and one or more memories, wherein the one or more memories are configured to store instructions for execution by the one or more processors to carry out the automated management (Zacks [0045]. The computer system 500 may include a memory 520 and a processor 510 in communication with the memory 520. The memory 520 may include a file system storage 530. The computer system 500 may further include an operating system 550 configured to execute on the processor 510. The snapshot manager 560 may then receive a first request, by the application 580, to access a first memory block of the memory 520. The snapshot manager 560 may determine whether the application 580 has permission to access the first memory block.).
Regarding claim 32, Zacks in view of Mitra disclose the system of claim 1. Zacks further discloses wherein the second service is configured to call the first service during an execution of the second service (Zacks [0033], [0035]. [T]he snapshot manager 160 will permit the first application 170A's requested access to the first memory block. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the second application (e.g., application 170B-C) via an application program interface (API) of the snapshot manager 160. In an example, the application 170A may request that the second application B storage 220B be shared with application 170A. For example, a web browser application 170A may wish to access the memory of an document reading application B 170B. In another example, a document reading application 170A may wish to access a printer driver application B 170B. In an example, the snapshot manager 160 will permit the first application 170A's requested access to the first memory block allocated to the file system 155 via an application program interface (API) of the snapshot manager 160.).
Regarding claim 33, Zacks in view of Mitra disclose the system of claim 1. Zacks further discloses wherein the controller comprises one or more processors and one or more memories, wherein the one or more memories are configured to store instructions for execution by the one or more processors to carry out the automated management (Zacks [0045]. The computer system 500 may include a memory 520 and a processor 510 in communication with the memory 520. The memory 520 may include a file system storage 530. The computer system 500 may further include an operating system 550 configured to execute on the processor 510. The snapshot manager 560 may then receive a first request, by the application 580, to access a first memory block of the memory 520. The snapshot manager 560 may determine whether the application 580 has permission to access the first memory block.).
Claims 3, 4, 6, 7 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Zacks et al. (“Zacks,” US 20170364451, published Dec. 21, 2017) in view of Mitra (“Mitra,” US 20200356354, filed May 7, 2019) and Falk (“Falk,” US 20210326441, filed April 12, 2019).
Regarding claim 3, Zacks and Mitra teach the system of claim 1. Zacks and Mitra do not explicitly teach: wherein the first service is configured to ask the controller to validate the second service in order to perform an operation for the second service.
However, in an analogous art, Falk teaches wherein the first service is configured to ask the controller to validate the second service in order to perform an operation for the second service (Falk [0021], [0059] –[0060]. Moreover, in some advantageous modifications, a chain of security proves may be established by providing integrity and validation data for each part of chain regarding security of this first data processing apparatus [and its applications], such as the generic security of the first data processing apparatus with respect to its hardware, firmware and/or operational state, the security of a hypervisor running on the hardware, the security of a virtual machine running on the first data processing apparatus and being managed by the hypervisor, the security of an operating system running in the virtual machine, specifically the current platform configuration and/or part of it regarding this operating system, and an application running within this operating system. [See [0050] for validation of integrity data through digital signature.]).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Falk, Mitra and Zacks to include: wherein the first service is configured to ask the controller to validate the second service in order to perform an operation for the second service. One would have been motivated to provide users with a means to verify the integrity of apparatus and its software applications. (See Falk [0021].)
Regarding claim 4, Zacks, Mitra and Falk teach the system of claim 3. Falk further teaches wherein the controller is further configured to validate the second service based on at least one of mutual tls authentication, public key authorization, and/or network- based validation (Falk [0024], [0059] –[0060]. According to some embodiments, signing by a digital signature, verifying based on a digital signature, and/or a digital signature may be implemented by asymmetric encryption, in particular by a private key and a public key. According to some embodiments, the first data processing apparatus is configured to verify the validation data based on the second digital signature. Furthermore, the first data processing apparatus is configured to selectively provide the integrity data and/or the validation data and/or the application data and/or request the application data depending on the verifying of the validation data. In some embodiments, in which the validation data is digitally signed, the second data processing apparatus is configured to verify the validation data based on the second digital signature.).
The motivation is the same as that of claim 3 above.
Regarding claim 6, Zacks and Mitra teach the system of claim 1. Falk further teaches wherein the controller is further configured to provision encryption keys to the first and second services for use in validation of the first and second services (Falk [0024], [0059] –[0060]. According to some embodiments, signing by a digital signature, verifying based on a digital signature, and/or a digital signature may be implemented by asymmetric encryption, in particular by a private key and a public key. According to some embodiments, the first data processing apparatus is configured to verify the validation data based on the second digital signature. Furthermore, the first data processing apparatus is configured to selectively provide the integrity data and/or the validation data and/or the application data and/or request the application data depending on the verifying of the validation data. In some embodiments, in which the validation data is digitally signed, the second data processing apparatus is configured to verify the validation data based on the second digital signature.).
The motivation is the same as that of claim 3 above.
Regarding claim 7, Zacks, Mitra and Falk teach the system of claim 1. Falk further teaches wherein the encryption keys comprise different key pairs for each of the first and second services, each key pair comprising a public key and a private key (Falk [0021], [0024]. Moreover, in some advantageous modifications, a chain of security proves may be established by providing integrity and validation data for each part of chain regarding security of this first data processing apparatus [and its applications], such as the generic security of the first data processing apparatus with respect to its hardware, firmware and/or operational state. According to some embodiments, signing by a digital signature, verifying based on a digital signature, and/or a digital signature may be implemented by asymmetric encryption, in particular by a private key and a public key. Additionally or alternatively, in some embodiments, digitally signing may be implemented by one time keys.).
The motivation is the same as that of claim 6 above.
Regarding claim 29, Zacks and Mitra disclose the system of claim 1. Falk further discloses wherein the first service comprises an authentication application (Falk [0064], [0090]. In some embodiments, in which the integrity data is signed by a third digital signature, the first data processing apparatus is configured to verify the integrity data based on the third digital signature. Furthermore, the first data processing apparatus is configured to selectively provide the integrity data and/or the validation data and/or the application data and/or requests the application data depending on the verifying of the integrity data. According to an exemplary embodiment, the first data processing apparatus 100 furthermore may be configured to run at least one software component, (e.g., an application).).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Falk, Mitra and Zacks to include: wherein the first service comprises an authentication application. One would have been motivated to provide users with a means to verify the integrity of apparatus and its software applications. (See Falk [0021].)
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Zacks et al. (“Zacks,” US 20170364451, published Dec. 21, 2017) in view of Mitra (“Mitra,” US 20200356354, filed May 7, 2019), Falk (“Falk,” US 20210326441, filed April 12, 2019) and Pilozzi (“Pilozzi,” US 20200382294, filed May 29, 2019).
Regarding claim 8, Zacks, Mitra and Falk teach the system of claim 7. Falk further teaches
wherein the controller is configured to manage validation of the first and second services based on the public keys (Falk [0024], [0059] –[0060]. According to some embodiments, signing by a digital signature, verifying based on a digital signature, and/or a digital signature may be implemented by asymmetric encryption, in particular by a private key and a public key. According to some embodiments, the first data processing apparatus is configured to verify the validation data based on the second digital signature. Furthermore, the first data processing apparatus is configured to selectively provide the integrity data and/or the validation data and/or the application data and/or request the application data depending on the verifying of the validation data. In some embodiments, in which the validation data is digitally signed, the second data processing apparatus is configured to verify the validation data based on the second digital signature.).
Zacks, Mitra and Falk do not explicitly teach: wherein the controller is further configured to delete its copies of the private keys after provision of the private keys to the first and second services.
However, in an analogous art, Pilozzi teaches wherein the controller is further configured to delete its copies of the private keys after provision of the private keys to the first and second services (Pilozzi [0124]. After the host key information HKSE has been installed in the HD-HKSE slot 66 of the host device 1060, the host device private key nHD and the secure element public key PSE are optionally deleted in step 1019 to further protect the anonymity of the host key information HKSE. For example the binding process stored in the system operational code 1064 may be atomic and delete all key material as soon as it is used.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings Pilozzi, Zacks, Mitra and Falk to include: wherein the controller is further configured to delete its copies of the private keys after provision of the private keys to the first and second services. One would have been motivated to provide users with a means to improve security of private keys though delete relevant key materials after designated use. (See Pilozzi [0124].)
Claims 9-12 are rejected under 35 U.S.C. 103 as being unpatentable over Zacks et al. (“Zacks,” US 20170364451, published Dec. 21, 2017) in view of Mitra (“Mitra,” US 20200356354, filed May 7, 2019) and Shiibashi (“Shiibashi,” US 20190304610, filed Mar 29, 2018).
Regarding claim 9, Zacks and Mitra teach the system of claim 1. Zacks and Mitra do not explicitly teach: wherein the controller is further configured to disconnect the resource from any external networks when the first and/or second service is being configured by the controller.
However, in an analogous art, Shiibashi teaches a system, comprising: wherein the controller is further configured to disconnect the resource from any external networks when the first and/or second service is being configured by the controller (Shiibashi FIG. 1B, [0046] – [0047]. FIG. 1B shows an example in accordance with one or more embodiments where a connection between one of the in-network healthcare facilities and the cloud (101) is disconnected. In this state, the application may automatically configure the local computers (111) and local servers (107) at the disconnected healthcare facility to access the local data stored in the local repository (109). In one or more embodiments, the disconnected healthcare facility continues to store into the local repository (109) medical images and data taken or updated during the time of disconnection. This enables the disconnected healthcare facility to establish a continuous workflow without experiencing any downtime caused by the disconnection from the cloud (101). As the cloud (101) is being updated with the medical images and data from the reconnected healthcare facility, the application stored in the local computers (111) of the other in-network facilities may automatically update their respective local repositories (109) with the new remote data.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings Shiibashi, Zacks, and Mitra: wherein the controller is further configured to disconnect the resource from any external networks when the first and/or second service is being configured by the controller. One would have been motivated to provide users with a means for processing and updating data and file during and after periods of cloud connection downtime. (See Shiibashi [0047].)
Regarding claim 10, Zacks, Mitra and Shiibashi teach the system of claim 9. Shiibashi further teaches wherein the controller is further configured to re-connect the resource to any disconnected external networks after the first and/or second service has been configured by the controller (Shiibashi FIG. 1B, [0046] – [0047]. FIG. 1B shows an example in accordance with one or more embodiments where a connection between one of the in-network healthcare facilities and the cloud (101) is disconnected. In this state, the application may automatically configure the local computers (111) and local servers (107) at the disconnected healthcare facility to access the local data stored in the local repository (109). In one or more embodiments, the disconnected healthcare facility continues to store into the local repository (109) medical images and data taken or updated during the time of disconnection. This enables the disconnected healthcare facility to establish a continuous workflow without experiencing any downtime caused by the disconnection from the cloud (101). As the cloud (101) is being updated with the medical images and data from the reconnected healthcare facility, the application stored in the local computers (111) of the other in-network facilities may automatically update their respective local repositories (109) with the new remote data.).
The motivation is the same as that of claim 9 above.
Regarding claim 11, Zacks, Mitra and Shiibashi teach the system of claim 9. Zacks further teaches at least one of an in band connection, an out of band connection, and/or a storage area network connection between the resource and the controller (Zacks [0013], [0015]. In one illustrative example, a processor may follow Von Neumann architectural model and may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. Processors 120A-C may be interconnected using a variety of techniques, ranging from a point-to-point processor interconnect, to a system area network, such as an Ethernet-based network.).
Shiibashi further teaches wherein the controller is further configured to disconnect the resource from the in band connection, out of band connection, and/or storage area network connection when the first and/or second service is being configured by the controller (Shiibashi FIG. 1B, [0046] – [0047]. FIG. 1B shows an example in accordance with one or more embodiments where a connection between one of the in-network healthcare facilities and the cloud (101) is disconnected. In this state, the application may automatically configure the local computers (111) and local servers (107) at the disconnected healthcare facility to access the local data stored in the local repository (109). In one or more embodiments, the disconnected healthcare facility continues to store into the local repository (109) medical images and data taken or updated during the time of disconnection. This enables the disconnected healthcare facility to establish a continuous workflow without experiencing any downtime caused by the disconnection from the cloud (101). As the cloud (101) is being updated with the medical images and data from the reconnected healthcare facility, the application stored in the local computers (111) of the other in-network facilities may automatically update their respective local repositories (109) with the new remote data.).
The motivation is the same as that of claim 9 above.
Regarding claim 12, Zacks, Mitra and Shiibashi teach the system of claim 11. Shiibashi further teaches wherein the controller is further configured to re-connect the resource to the disconnected in band connection, out of band connection, and/or storage area network connection after the first and/or second service has been configured by the controller (Shiibashi [0047], [0052]. Then, when the connection between the disconnected healthcare facility is reestablished with the cloud (101), the local computers (111) and local servers (107) of the reconnected healthcare facility may be configured by the application to transmit to the cloud (101) all of the medical images and data stored in the local repository taken or updated during the time of disconnection. Once the pre-set time period has expired, the user would be prompted with another display message (201) to reconnect to the cloud (101).).
The motivation is the same as that of claim 11 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Luu Pham can be reached on 571 270 5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR.
Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
1 A security patch is a software update that addresses a system deficiency/security vulnerability. It is standard routine to update and/or remove security patches, as needed, to address changing requirements of a computer system. See Perkins et al., Automatically Patching Errors in Deployed Software, SOSP’09, Oct 2009, p 89 (“ClearView uses this capability to apply and remove patches that enable ClearView to check and enforce invariants… Each Node Manager interacts with its corresponding Managed Program Execution Environment instance to appropriately apply and remove patches to and from running and newly-launched applications.”) (emphasis added).
2 A security patch is a software update that addresses a system deficiency/security vulnerability. It is standard routine to update and/or remove security patches, as needed, to address changing requirements of a computer system. See Perkins et al., Automatically Patching Errors in Deployed Software, SOSP’09, Oct 2009, p 89 (“ClearView uses this capability to apply and remove patches that enable ClearView to check and enforce invariants… Each Node Manager interacts with its corresponding Managed Program Execution Environment instance to appropriately apply and remove patches to and from running and newly-launched applications.”) (emphasis added).
3 A security patch is a software update that addresses a system deficiency/security vulnerability. It is standard routine to update and/or remove security patches, as needed, to address changing requirements of a computer system. See Perkins et al., Automatically Patching Errors in Deployed Software, SOSP’09, Oct 2009, p 89 (“ClearView uses this capability to apply and remove patches that enable ClearView to check and enforce invariants… Each Node Manager interacts with its corresponding Managed Program Execution Environment instance to appropriately apply and remove patches to and from running and newly-launched applications.”) (emphasis added).
4 An application associated with the web may include http server protocols. See Li, X. and Xue, Y., 2014. A survey on server-side approaches to securing web applications. ACM Computing Surveys (CSUR), 46(4), PP 54:2 (“TheWebplatformisacomplexecosystemcomposedofalargenumberofcomponents and technologies, including the HTTP protocol, web server and server-side application development technologies (e.g., CGI, PHP, and ASP), and web browser and clientside technologies (e.g., JavaScript and Flash).”).