Data processing: software development – installation – and managem – Software upgrading or updating – Network
Reexamination Certificate
2000-07-06
2003-12-16
Chavis, John (Department: 2124)
Data processing: software development, installation, and managem
Software upgrading or updating
Network
C717S178000
Reexamination Certificate
active
06665867
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer software, and deals more particularly with a method, system, and computer program product that enables software objects and applications to dynamically self-propagate, as needed, through a computer network.
2. Description of the Related Art
Business and consumer use of distributed computing, also commonly referred to as network computing, has gained tremendous popularity in recent years. In this computing model, the data and/or programs to be used to perform a particular computing task typically reside on (i.e. are “distributed” among) more than one computer, where these multiple computers are connected by a network of some type. The Internet, and the part of the Internet known as the World Wide Web (hereinafter, “Web”), are well-known examples of this type of environment wherein the multiple computers are connected using a public network. Other types of network environments in which distributed computing may be used include intranets, which are typically private networks accessible to a restricted set of users (such as employees of a corporation), and extranets (e.g., a corporate network which is accessible to other users than just the employees of the company which owns and/or manages the network, such as the company's business partners).
The client/server model is the most commonly-used computing model in today's distributed computing environments. In this model, a computing device operating in a client role requests some service from another computing device operating in a server role. The software operating at one particular client device may make use of applications and data that are stored on one or more server computers which are located literally anywhere in the world. Similarly, an application program operating at a server may provide services to clients which are located throughout the world. A common example of client/server computing is use of a Web browser, which functions in the client role, to send requests for Web pages or Web documents to a Web server. Another popular model for network computing is known as the “peer-to-peer” model, where the requester of information and the provider of that information (i.e. the responder) operate as peers.
Whereas the HyperText Transport Protocol (HTTP) is the communications protocol typically used for communication between a client and a server in a client/server model, a protocol such as Advanced Program-to-Program Communication (APPC) developed by the IBM Corporation is typically used for communication in a peer-to-peer model.
Distributed computing provides a number of advantages which are well known and need not be described herein. However, there are shortcomings in the way that the computer systems exchange data in these prior art distributed computing techniques. In particular, the prior art requires that processing code is designed and implemented in pairs: one part for executing the client (or requester) functionality, and the other part for executing the server (or responder) functionality.
An example of the requirement for paired applications can be seen in the case where a Web page is to include an image file. Suppose the image is originally created, by the first of the two application “parts” (i.e. a creation part), as a file in the JPEG format. When a Web page which includes the image as an embedded JPEG image file is generated at a server and transmitted to a client for rendering, the client device must have the other “part” of the JPEG software (i.e. a rendering part) locally available in order to process the image for rendering at the client device. If the client does not have the proper software for processing (i.e. rendering) the received image file, then either the software must be obtained or the image cannot be rendered. Most users of distributed computing will be familiar with the frustration of a scenario of this type, where a file is received for which the local processing “part” is unavailable. In many cases, the user will not be able to determine where to obtain the missing part—or even what the missing part is.
Another common situation where the requirement for paired software becomes apparent is when a client device receives a “PDF”, or Portable Document Format, file. A product such as Adobe Acrobat is typically used to create files of this type; a product such as Adobe Acrobat Reader is then used to view the file. By convention, application software that transmits a PDF file typically provides a message to the user containing information on how to obtain a copy of the Reader software if it is not already locally available on the user's computing device. However, the user must then take explicit action to obtain the Reader software, and becomes responsible for installing, configuring, and maintaining the software on his or her device.
While the examples provided above occur most frequently in a Web environment, this is merely for purposes of illustration: paired applications of one type or another exist whenever one computing device provides data or processing services for other device(s). For example, a book supply company may allow its customers to place orders electronically through its extranet, perhaps using a proprietary communications protocol. In this scenario, the customers' computing devices must have the software part installed which properly formats and transmits order requests, and the company's server(s) must have the software part installed which receives those requests and uses the information contained therein to complete the book ordering process. Only devices on which the customer's part of the application is installed are able to participate as customers of the book supply company.
Many more examples of paired applications will be obvious to one of skill in the art.
In the general case, the two parts of a paired application will execute on different physical computing devices. Each of the two parts thus needs to be explicitly distributed to each target device on which it is to operate, and must be installed on that device as well. If these processes have not been performed at a particular target device, then the application's functionality cannot be used at that device. If the software is subsequently revised, then the distribution and installation process must be repeated. Furthermore, once the software has been installed on a device, maintaining the software (for example, ensuring that the most recent version is available, and ensuring that obsolete or infrequently-used software does not waste storage space on the local device) typically becomes the responsibility of the device owner, who may or may not be capable of performing the necessary maintenance tasks. As will be obvious, when one or both of the parts of a paired application is to reside on a large number of devices, this prior art methodology results in a huge administrative burden that is expensive, time-consuming, and error-prone.
Applets provide one prior art technique for dynamically delivering application code to a target machine. However, this technique does not enable downloading data objects and code segments as part of an integrated application, and has several limitations which make it unsuitable as a general solution for distributing code in an application-independent manner. First, the well-known “Java sandbox” restriction, which is designed to prevent security problems when applets are downloaded, narrowly restricts the location of the code that can be executed. In particular, the class loader which downloads applets loads them into a namespace hierarchy that identifies the server and codebase which was the source of the download. When an applet executes, it is automatically restricted to interacting with server code on the source server, and within the corresponding codebase. The sandbox restriction also requires that a static data area is allocated for use by the code in the applet's namespace. For example, objects to be used by the classes (such as values for varia
Ims Steven D.
Li Yongcheng
Tan Yih-Shin
Chavis John
Doubet Marcia L.
Ray-Yarlette Jeanine S.
LandOfFree
Self-propagating software objects and applications does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Self-propagating software objects and applications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Self-propagating software objects and applications will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3101366