Obviousness

Obviousness Analysis of US Patent 7,640,332 under 35 U.S.C. § 103

Current Date: 2026-05-25

Under 35 U.S.C. § 103, a patent claim is considered obvious if "the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which the subject matter pertains." This analysis requires identifying the scope and content of the prior art, ascertaining the differences between the prior art and the claims at issue, and resolving the level of ordinary skill in the pertinent art. A crucial aspect is determining whether there would have been a motivation to combine or modify prior art teachings to arrive at the claimed invention, with a reasonable expectation of success.

The independent claims of US Patent 7,640,332 (Claims 1, 9, and 14) generally describe a method, computer-readable medium, and computer system, respectively, for hot deployment/redeployment in a grid computing environment. Key steps include: (1) adding a new application version to a repository, (2) a discovery module identifying which grid nodes are running the associated application, (3) notifying client application managers on these nodes about the new version and the required data transfer protocol, and (4) hot deploying/redeploying the new version using an appropriate hot deployment plug-in based on the specified protocol.

Prior Art Combinations and Motivation for Obviousness

A strong argument for obviousness can be made by combining the teachings of US Patent Application Publication 2005/0138618 A1 to Gebhart ("Grid compute node software application deployment") with the common general knowledge of hot deployment techniques, as acknowledged within US7640332 itself.

Primary Reference: US2005/0138618A1 (Gebhart)
Gebhart teaches a system for deploying software applications to grid compute nodes. Its abstract states, "A compute resource, such as a grid node, can register for software deployment, upon which a deployment service determines what software is authorized for deployment to the resource, what software is currently deployed on the resource, and what software is to be deployed to the resource to satisfy its authorizations. The deployment service then provides an authorized software image and configuration information to a software deployment client on the resource to effect deployment." [cite: US20050138618A1]

Let's break down how Gebhart addresses the elements of Independent Claim 1 of US7640332:

1. Adding a new version of an application release bundle in a repository server: Gebhart's disclosure of a "deployment service" that "provides an authorized software image" implies the existence of a repository where software images (akin to application release bundles) are stored and managed, allowing for new versions to be made available for deployment. [cite: US20050138618A1]
2. Determining by a discovery services module which of the one or more grid nodes are running an application associated with the added new version of the application release bundle upon adding the new version of the application release bundle in the repository server: Gebhart explicitly describes a "deployment service [that] determines... what software is currently deployed on the resource." [cite: US20050138618A1] This directly teaches the function of a discovery module identifying which grid nodes are running a particular application. The context of "grid compute node software application deployment" firmly places this within a grid computing environment. [cite: US20050138618A1]
3. Notifying a client application manager associated with one or more of the determined grid nodes about adding the new version of the application release bundle along with a type of data transfer protocol to use: Gebhart states that the deployment service "provides an authorized software image and configuration information to a software deployment client on the resource to effect deployment." [cite: US20050138618A1] A person having ordinary skill in the art (PHOSITA), aware of the heterogeneous nature of grid computing environments (as described in the background of US7640332), would recognize that "configuration information" provided to a deployment client would naturally include details essential for successful transfer, such as the specific data transfer protocol (e.g., FTP, HTTP, etc.) to be used. This is a common requirement for interoperability in distributed systems.
4. Hot deploying/redeploying the new version of the application release bundle on running one or more application servers in an associated grid node using an appropriate hot deployment plug-in based on the data transfer protocol by a respective one of the client application managers: US7640332's own background section acknowledges that "Hot deployment refers to a process of deploying/redeploying an application without having to shutdown/restart an application container" and that "Hot deployment is commonly used in containers that run in standalone mode or homogenous cluster environment." The primary problem addressed by US7640332, as stated in its background, is the "significant overhead" incurred by suspending and reinitializing grid systems during application deployment/redeployment due to dynamic application-to-server mappings and heterogeneous platforms. [cite: US7640332B2]

Motivation to Combine:
A PHOSITA seeking to improve upon Gebhart's general grid application deployment system, specifically to address the known problem of system downtime and overhead during application updates in heterogeneous grid environments, would have been motivated to integrate the well-known "hot deployment" technique. The goal would be to allow updates without restarting application containers or entire grid nodes, thereby reducing the "significant overhead" identified in US7640332.

Furthermore, given Gebhart's teaching of providing "configuration information" to the client, and the necessity in a heterogeneous grid environment to handle "different data transfer mechanisms" (as also noted in US7640332's background), it would be obvious for a PHOSITA to implement modular "plug-ins" that correspond to the specified data transfer protocol. The use of plug-ins to handle different protocols (such as ftp, http, gridftp, tcp, and udp, as explicitly listed in US7640332's detailed description) is a standard and predictable software engineering approach for creating extensible and flexible systems in a diverse computing landscape.

Other Supporting Prior Art:

• US2006/0195688A1 (IBM): This reference further reinforces the concept of "managing applications in a shared computer infrastructure" including "deploying the application service based on the application images." [cite: US20060195688A1] This supports the general notion of application management and deployment in a distributed environment, making the motivations to improve such deployment even more apparent.
• US2006/0005181A1 (IBM): This patent describes "dynamically building application environments in a computational grid by specifying application environment descriptions." [cite: US20060005181A1] This highlights the dynamic nature of grid environments and the need for flexible deployment solutions, which would naturally lead a PHOSITA to consider hot deployment.

Conclusion:
In conclusion, the combination of Gebhart (US2005/0138618A1) as a primary reference for grid-based application deployment and discovery, along with the widely known practice of hot deployment in application containers (as acknowledged within US7640332), would render Claim 1, and by extension dependent Claims 9 and 14, obvious to a PHOSITA. The motivation would be to predictably improve the efficiency and reduce the downtime and overhead associated with application updates in heterogeneous grid computing environments, a problem clearly articulated by the patent in question. The use of protocol-specific plug-ins for data transfer is a straightforward and conventional engineering choice for handling diverse communication requirements in such environments.