DETAILED ACTION
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 .
This Office Action is in response to amendment filed on 03/26/2026.
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 03/26/2026 has been entered.
Response to Amendment
By this amendment, claims 1 and 7 are amended. Therefore, claims 1-12 are pending. Any objections and rejections not repeated below is withdrawn due to Applicant's amendment.
Response to Arguments
Applicant's arguments filed 03/26/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
Each of the independent claims has been amended to incorporate three features disclosed in the specification but not previously claimed, and not taught or suggested by the combined teachings of Devlin, Xu, and Beedu. The amended independent claims recite first and second clusters running under a single instance of the virtualization platform. This limitation is supported by the specification's FIG. 1, which depicts Cluster 1 and Cluster 2 both running under vCenter Server A (110-1). In addition, each amended independent claim recites, responsive to detecting an access to one of the extension points while the second cluster is the in-context cluster, determining a proxied URL of the auxiliary server based on a server ID for the second cluster and a plugin server list provided by a platform plugin SDK. Written descriptive support for this feature is found m the specification's description of FIG. 3, operations 356-357. Still further, the amended independent claims recite loading static resources from the auxiliary server using the proxied URL, which ties the static resource loading step to the newly recited proxied URL determination.
With regard to point (a), Examiner disagrees with Applicant that Devlin and Xu do not teach Applicant’s amendments. Xu discloses wherein the first and second clusters run under a single instance of the virtualization platform ([0029] “In the example in FIG. 1, two example cluster types are shown. Management cluster 130 may be deployed to manage workload clusters 140 and packaged services. Workload clusters 140 may be deployed by management cluster 130 to run containerized workloads…”). In other words, clusters are managed and run by a management cluster in the cloud environment. In addition, Devlin discloses determining a proxied URL of the auxiliary server based on a server ID for the second cluster and a plugin server list provided by a platform plugin software development kit (SDK) ([0041] “…A plugin is declared to the universal proxy 128 by way of a plugin definition. The plugin definition can declare a set of data services, each of which consist of a URL pattern and a supporting implementation…”, [0050] “…For example, secure protocols (e.g., HTTPS) may be used to serve the static resources (e.g. html, css, javascript, etc) of the desktop application 120 from the proxy 128, to load web applications 148, 152 from auxiliary hosts 112, 116…”, [0106] “Specifically, the architecture and implementation of the various server-side and client-side plugins together may determine how much application logic is performed on the server computer 606 and how much is performed on the client computer 604. The application logic may initially be stored on the server computer 606 and retrieved by a program 616 for rendering such as a web browser.”, [0107] “Each plugin may be associated with a plugin definition. The plugin definition can include the definitions of server-side data services, each of which consist of a URL pattern and a supporting implementation.”, [0114] “The system 600 may be in communication with a plugin marketplace feature that enables users to select plugins to install from a set of available plugins in one or more marketplaces. The use of multiple marketplaces allows, for example, an administrator or authorized user to set up internal marketplaces that contain only preapproved sets of plugins which may include internally developed plugins.”, [0117] “Step 704 involves autonomously deploying, by the server-side plugin, a client-side plugin to a client computer for installation…”, Note: Auxiliary application/server-side plugin contains plugin code (to be installed on the client), and the marketplaces containing available plugins to install is interpreted as the SDK. A user chooses a plugin to install from the marketplace (SDK) which must be located and retrieved from a server-side plugin (server ID of the second cluster), wherein the URL of the service (auxiliary host or server containing the server-side plugin) is determined from the plugin definition). Therefore, the claims are still rejected for the reasons in this Office Action’s 103 rejections below. Argument has not been found to be persuasive.
Claims 6 and 12 were rejected under 35 U.S.C. § 103 as allegedly unpatentable over Devlin in view of Xu, and further in view of Beedu et al., U.S. Patent Application Publication No. 2022/0350492 (hereinafter, "Beedu").
The ground of rejection is moot in view of the patentability of the amended independent claims as explained in the preceding remarks addressing the primary ground of rejection.
With regard to point (b), Examiner disagrees with Applicant that the ground of rejections for claims 6 and 12 is moot in view of the patentability of the amended independent claims for the reasons in point (a). Argument has not been found to be persuasive.
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-5 and 7-11 are rejected under 35 U.S.C. 103 as being unpatentable over Devlin et al. Pub. No. US 2018/0084087 Al (hereafter Devlin), in view of XU et al. Pub. No. US 2024/0028411 Al (hereafter XU).
Regarding claim 1, Devlin teaches … loading a CMP manifest, indicative of user interface extension points defined by the CMP, from the primary server ([0108] “In some embodiments, a pluginDefinition tells the client and server computers 604 and 606, respectively, how to load the plugin(s). Additionally, the pluginDefinition declares the access points that allow other plugins to call this plugin, both on the server (i.e., for server-to-server calls and client-to-server calls) and the client (i.e., for client-to-client calls).”, [0082] “The plugin definition loaded in the proxy 128 can contain a list of launch declarations. Each launch declaration can contain one or more of the following items:”, [0083] “(1) The identifier of the launch. This identifier is typically unique within a given plugin definition.”, [0085] “(3) The generic name of the action (e.g., "deleteElement").”, [0045] “At least one of the primary hosts 104, 108 in the cluster 124 (here, primary host A 104) executes a universal proxy 128…”, [0041] “The virtual desktop 120 may be modular in nature, allowing the addition of additional modules called plugins to access various applications executing on a host computer 104-116 and to provide associated user interface elements in the virtual desktop 120…”, Note: A pluginDefinition or the group of all pluginDefinitions containing access points with associated user interface elements is interpreted by the Examiner to be the CMP manifest containing user interface extension points. pluginDefinition is declared in the proxy 128 which is executed in the primary host (primary server)) … determining a proxied URL of the auxiliary server based on a server ID for the second cluster and a plugin server list provided by a platform plugin software development kit (SDK) ([0041] “…A plugin is declared to the universal proxy 128 by way of a plugin definition. The plugin definition can declare a set of data services, each of which consist of a URL pattern and a supporting implementation…”, [0050] “…For example, secure protocols (e.g., HTTPS) may be used to serve the static resources (e.g. html, css, javascript, etc) of the desktop application 120 from the proxy 128, to load web applications 148, 152 from auxiliary hosts 112, 116…”, [0106] “Specifically, the architecture and implementation of the various server-side and client-side plugins together may determine how much application logic is performed on the server computer 606 and how much is performed on the client computer 604. The application logic may initially be stored on the server computer 606 and retrieved by a program 616 for rendering such as a web browser.”, [0107] “Each plugin may be associated with a plugin definition. The plugin definition can include the definitions of server-side data services, each of which consist of a URL pattern and a supporting implementation.”, [0114] “The system 600 may be in communication with a plugin marketplace feature that enables users to select plugins to install from a set of available plugins in one or more marketplaces. The use of multiple marketplaces allows, for example, an administrator or authorized user to set up internal marketplaces that contain only preapproved sets of plugins which may include internally developed plugins.”, [0117] “Step 704 involves autonomously deploying, by the server-side plugin, a client-side plugin to a client computer for installation…”, Note: Auxiliary application/server-side plugin contains plugin code (to be installed on the client), and the marketplaces containing available plugins to install is interpreted as the SDK. A user chooses a plugin to install from the marketplace (SDK) which must be located and retrieved from a server-side plugin (server ID of the second cluster), wherein the URL of the service (auxiliary host or server containing the server-side plugin) is determined from the plugin definition): loading static resources for the one user interface extension point from the auxiliary server in accordance with the proxied URL ([0041] “…A plugin is declared to the universal proxy 128 by way of a plugin definition. The plugin definition can declare a set of data services, each of which consist of a URL pattern and a supporting implementation…”, [0050] “…For example, secure protocols (e.g., HTTPS) may be used to serve the static resources (e.g. html, css, javascript, etc) of the desktop application 120 from the proxy 128, to load web applications 148, 152 from auxiliary hosts 112, 116…”, [0049] “The auxiliary application 148, 152 may or may not need to contain any code that is specific to its participation as a target for a client-side plugin 194, 198 running in the virtual desktop 120…”, [0094] “Features of various embodiments also allow for various sub-applications (i.e., plugins) to be installed on a server side computer…”, [0106] “Specifically, the architecture and implementation of the various server-side and client-side plugins together may determine how much application logic is performed on the server computer 606 and how much is performed on the client computer 604. The application logic may initially be stored on the server computer 606 and retrieved by a program 616 for rendering such as a web browser.”, [0107] “Each plugin may be associated with a plugin definition. The plugin definition can include the definitions of server-side data services, each of which consist of a URL pattern and a supporting implementation.”, [0117] “Step 704 involves autonomously deploying, by the server-side plugin, a client-side plugin to a client computer for installation…”, Note: Auxiliary application contains plugin code); and calling REST API's from the auxiliary server ([0050] “…For example, secure protocols (e.g., HTTPS) may be used to serve the static resources (e.g. html, css, javascript, etc) of the desktop application 120 from the proxy 128, to load web applications 148, 152 from auxiliary hosts 112, 116…”, [0095] “Additionally the client UI of a plugin can interact with the client UI of other plugins on the client side at an API level. These client Uis can also access the functionality of the plugin's own server-side functionality or data services (e.g., Representational State Transfer services), as well as access the server-side functionality or data services of other plugins.”, Note: HTTPS methods are called, and REST API comprises HTTPS methods)…
Devlin fails to teach a method, comprising: registering a first plugin server
as a primary server of a cluster management plugin (CMP) for a virtualization platform user interface (VPUI), wherein the first plugin server is associated with a first cluster within a virtualization platform; registering a second plugin server as an auxiliary server for the CMP, wherein the second plugin server is associated with a second cluster running in the virtualization platform, wherein
the first and second clusters run under a single instance of the virtualization platform … responsive to detecting an access to one of the user interface extension points while the second cluster is an in-context cluster of the VPUI … responsive to detecting an access to one of the user interface extension points while the first cluster is the in-context cluster of the VPUI: loading static resources for the one user interface extension point from the primary server; and calling REST API's from the primary server.
In analogous art XU teaches a method, comprising: registering a first plugin server as a primary server of a cluster management plugin (CMP) for a virtualization platform user interface (VPUI), wherein the first plugin server is associated with a first cluster within a virtualization platform ([0069] “In the example in FIG. 6, a first UI (see 610) may include UI elements specifying multiple add-ons that are selectable by user 152 for installation in a particular cluster, including service add-ons such as vSphere-csi (see 620) in FIG. 5…”, Note: vSphere-csi is the first plugin server which is installed in a particular cluster (first cluster)); registering a second plugin server as an auxiliary server for the CMP, wherein the second plugin server is associated with a second cluster running in the virtualization platform ([0072] “…In the example in FIG. 8, a first UI (see 810) may be generated to specify multiple add-ons that are selectable by user 152 for installation in a particular cluster, including service add-ons such as NFS (see 820) in FIG. 7…”, Note: NFS is the second plugin server which is installed in a particular cluster (second cluster)), wherein the first and second clusters run under a single instance of the virtualization platform ([0029] “In the example in FIG. 1, two example cluster types are shown. Management cluster 130 may be deployed to manage workload clusters 140 and packaged services. Workload clusters 140 may be deployed by management cluster 130 to run containerized workloads…”, Note: Clusters are managed and run by a management cluster in the cloud environment) … responsive to detecting an access to one of the user interface extension points while the second cluster is an in-context cluster of the VPUI ([0021] “…In response to receiving a second request for a second management action associated with the second add-on via a second user interface, a second instruction may be generated and sent to cause the second management action to be performed in the first cluster or the second cluster based on multiple second configuration values associated with the respective multiple second configuration fields…”, Note: The extension point is the second management action which is performed in the second cluster) … responsive to detecting an access to one of the user interface extension points while the first cluster is the in-context cluster of the VPUI ([0021] “In response to receiving a first request for a first management action associated with the first add-on via a first user interface, a first instruction may be generated and sent to cause the first management action to be performed in the first cluster based on multiple first configuration values associated with the respective multiple first configuration fields…”, Note: The extension point is the first management action which is performed in the first cluster): loading static resources for the one user interface extension point from the primary server ([0102] “…For example, HTTP GET requests may be used, such as "GET cluster/<uuid>/addon<uuid>" and "GET cluster/<uuid>/addon<uuid>/status." At 1160, MP entity 110 may generate and send a query to CP entity 120 to obtain status information associated with the service add-on. This way, at 1170, the status information may be reported to user 152 via UI(s) supported by UI module 112.”, Note: UI(s) (of the status information) supported by UI module 112 are the static resources for the extension point (HTTP requests)); and calling REST API's from the primary server ([0102] “…For example, HTTP GET requests may be used, such as "GET cluster/<uuid>/addon<uuid>" and "GET cluster/<uuid>/addon<uuid>/status." At 1160, MP entity 110 may generate and send a query to CP entity 120 to obtain status information associated with the service add-on. This way, at 1170, the status information may be reported to user 152 via UI(s) supported by UI module 112.”, [0028] “Depending on the desired implementation, MP entity 110 may provide user interfaces (Uis) and Representational State Transfer (REST) application programming interfaces (APis) to user 152 (e.g., network administrator) to automate virtual infrastructure deployment, provision Kubemetes cluster(s), manage cluster-dependent virtual infrastructure and third-party systems, customize cluster node(s), instantiate service(s), etc…”, Note: HTTP methods are called, and REST API comprises HTTP methods).
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Devlin to incorporate the teachings of XU to extend cluster functionality by utilizing cluster addons (plugins) (XU [0002] “…In practice, it may be desirable to extend functionality of such clusters through cluster addons.”).
Regarding claim 2, Devlin and XU teach the method of claim 1, and XU further teaches responsive to detecting an access to one of the user interface extension points: loading a plugin code from the primary server ([0069] “In the example in FIG. 6, a first UI (see 610) may include UI elements specifying multiple add-ons that are selectable by user 152 for installation in a particular cluster, including service add-ons such as vSphere-csi (see 620) in FIG. 5. A second UI (see 630) may include UI elements specifying multiple configuration fields associated with selected cluster add-on=vSphere-csi, including zone, region, default storage class name, whether vSphere-csi is the default, reclaim policy and datastore URL…”, Note: Multiple configuration fields (static resources) loaded in the second UI is the plugin code from the add-on vSphere-csi (primary server)); and sending a server ID lookup request to a plugin core in the primary server ([0102] “…HTTP GET requests may be used, such as "GET cluster/<uuid>/addon<uuid>" and "GET cluster/<uuid>/addon<uuid>/status." At 1160, MP entity 110 may generate and send a query to CP entity 120 to obtain status information associated with the service add-on…”, Note: uuid is the server ID).
Regarding claim 3, Devlin and XU teach the method of claim 2, and XU further teaches determining, based on one or more cluster custom attributes of the in-context cluster, a server ID for the in-context cluster ([0102] “…HTTP GET requests may be used, such as "GET cluster/<uuid>/addon<uuid>"…”, Note: uuid is the server ID for the in-context cluster); and determining, based on the server ID, a URL for the in-context cluster ([0069] “In the example in FIG. 6, a first UI (see 610) may include UI elements specifying multiple add-ons that are selectable by user 152 for installation in a particular cluster, including service add-ons such as vSphere-csi (see 620) in FIG. 5. A second UI (see 630) may include UI elements specifying multiple configuration fields associated with selected cluster add-on=vSphere-csi, including … datastore URL.”, Note: A datastore URL of the add-on (plugin) for the specific cluster is determined).
Regarding claim 4, Devlin and XU teach the method of claim 3, and XU further teaches wherein the cluster custom attributes include a server IP address and a manager version ([0072] “…a first UI (see 810) may be generated to specify multiple add-ons that are selectable by user 152 for installation in a particular cluster, including service add-ons such as NFS (see 820) in FIG. 7. A second UI (see 830) may be generated to specify multiple configuration fields associated with selected cluster add-on=NFS, including … NFS server's IP address or hostname and mount path…”, [0055] “…At 410, cluster add-on definition information 160 may include configuration fields to define version information (e.g., API version, Kubernetes version, cluster deployment platform version), applicable cluster types (e.g., management and workload)…”, Note: Cluster add-on (plugin) definition information for each cluster includes a server IP address and a deployment platform version which is the manager version).
Regarding claim 5, Devlin and XU teach the method of claim 1, and XU further teaches wherein the VPUI comprises a vSphere Client user interface ([0069] “…A second UI (see 630) may include UI elements specifying multiple configuration fields associated with selected cluster add-on=vSphere-csi, including zone, region, default storage class name, whether vSphere-csi is the default, reclaim policy and datastore…”).
Regarding claim 7, XU further teaches an information handling system, comprising: a central processing unit (CPU); and a memory including processor executable instructions that, when executed by the CPU, cause the information handling system to perform operations including ([0136] “…The computer system may include a non-transitory computer-readable medium having stored thereon instructions or program code that, when executed by the processor, cause the processor to perform processes described herein with reference to FIG. 1 to FIG. 17.”). The other limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 8, it is machine claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 9, it is machine claim whose limitations are substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 10, it is machine claim whose limitations are substantially the same as those of claim 4. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 11, it is machine claim whose limitations are substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
Claims 6 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Devlin et al. Pub. No. US 2018/0084087 Al (hereafter Devlin), in view of XU et al. Pub. No. US 2024/0028411 Al (hereafter XU) as applied to claims 1-5 and 7-11 above, and further in view of Beedu et al. Pub. No. US 2022/0350492 Al (hereafter Beedu).
Regarding claim 6, Devlin and XU teach the method of claim 1.
Devlin and XU fail to teach wherein at least one of the first and second clusters comprise an HCI running in an HCI appliance.
In analogous art Beedu teaches wherein at least one of the first and second clusters comprise an HCI running in an HCI appliance ([0044] “…a container-based application might rely on a database service that distributes its data across the storage devices of the nodes that constitute the HCI cluster…”, Note: The HCI cluster’s node is the HCI, and the container-based application (stored in the HCI cluster) is the HCI appliance).
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Devlin and XU to incorporate the teachings of Beedu to improve efficiency using compute and storage resources of the distributed system (Beedu [0118] “A hyperconverged system coordinates the efficient use of compute and storage resources by and between the components of the distributed system…”).
Regarding claim 12, it is machine claim whose limitations are substantially the same as those of claim 6. Accordingly, 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. In particular, US 20240231849 A1 is cited because it discloses workflows (actions) of plug-ins of clusters in a GUI.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN CHE-CHUN TONG whose telephone number is (703)756-1737. The examiner can normally be reached Monday-Thursday: 7:30 AM to 6:00 PM ET.
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 Y Blair can be reached at (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.
/J.C.T./Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196