Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1994-06-17
2002-07-09
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S228000, C709S241000
Reexamination Certificate
active
06418484
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to methods of executing computer processes and, more particularly, to methods of remotely executing computer processes.
BACKGROUND OF THE INVENTION
Remote execution involves the execution of a computer process at a processor site other than the one initiating the process. In general terms processes may be regarded as including various actions such as the execution of a computer program, invocation of a system service or an interaction with a user. The computer initiating the remote execution is typically called the parent. The remote computer actually executing the process is normally referred to as the child. An example of remote execution is the situation where a user employs a home computer to run a program on another computer, such as a work station, back at the office.
Remote execution is advantageous in a variety of circumstances such as, for example, when hardware requirements dictate use of a more sophisticated remote processor. Remote execution can also be beneficial in instances where data or software transmission time and costs exceed those associated with simply operating the child computer remotely. If, for example, a user at home wished to work on a large database resident at a work station back at the office, the cost of transmitting the entire database to the home computer could be avoided by instead remotely executing the database software at the office work station. In some instances software licensing restrictions may also dictate that a process be executed at a specific computer site having a duly authorized copy of the software. The office work station may, for example, have a licensed version of an expensive commercial software package installed. Installing the same software on the user's home computer, however, might be a violation of the software license agreement unless another copy of the software is purchased for the home computer.
It is normally desirable for remote execution of a process to be network transparent. That is, the user at the parent computer should be able to run a program on the child computer in the same way as if the program were running on the parent computer, and should be able to obtain the same results. In some instances an opposite effect may be desired, so that remote execution of a process at a child computer is explicitly apparent to the user. This latter situation is termed non-transparent remote execution. In still other circumstances some aspects of the process preferably appear the same to the user (as if the process were running at the parent computer instead of at the child computer) while other aspects of the process should explicitly reflect their remote execution. This type of remote execution is usually termed semi-transparent. A semi-transparent type of remote execution may be desired, for example, when a user at their home computer wishes to execute a command at a computer site or location other than the home or office, but still make use of resources that are resident at the home or office computer and absent from the remote site of process execution.
During either local or remote execution most processes typically access various objects such as files, devices and system services. These objects are normally accessed through some form of representation, typically referred to as their name. An object name is commonly thought of as being bound to the object accessed through that name. In the case of transparent remote execution, objects are accessed through same representations, or names, irrespective of whether the process is being executed remotely at the child computer or locally at the parent computer. In the case of semi-transparent remote execution, at least some objects (involving those aspects of the process that are to appear the same to the user) are preferably accessed through the same names during either local execution at the parent computer or remote execution at the child computer.
In most distributed systems there is commonly a set of objects resident at each computer in the system. Each computer may, for example, employ the same operating system or word processing software package. Such objects are normally termed generic. During remote execution of a process on a child computer it is generally desirable for the remote process to access the generic objects resident at the child computer directly from the child computer. At the same time other objects, resident only at the parent computer, should still be accessed from the parent. Some objects such as data files may reside only at the parent computer. Accessing generic objects at the site of execution is usually regarded as more efficient, since the object need not be transferred from the parent computer to the child computer. Accessing other non-generic objects from the parent computer provides the desired name transparency for remote execution that is to be of the transparent or semi-transparent form. Unfortunately, however, most conventional naming schemes do not easily facilitate transparent or semi-transparent forms of remote execution that permit accessing objects from more than one computer site.
A majority of conventional computers typically employ a per-system naming scheme. Each computer has its own hierarchical naming tree containing component names through which objects are accessed. A particular document in a DOS based personal computer, for example, might be accessed through the name “c:\doc.1”. The same name, however, may represent separate objects on separate computers. By way of example office-coworkers may have different versions of the same document on their respective computers. While each version of the document is a separate object, both of these objects may have the same “c:\doc.1” name. Accordingly per-system naming schemes normally can only access objects resident at either the child computer or the parent computer, but not both. Thus per-system naming schemes generally are not sufficiently flexible to facilitate the most useful forms of transparent and semi-transparent remote execution.
An alternative to per-system naming schemes are the per-process naming schemes. In per-process naming schemes each computer process has its own set of name-to-object associations, or name bindings. These bindings are again typically organized in a hierarchical naming tree. Each computer on which a process is executed may also have a set of name bindings organized in a naming tree. The naming tree of a computer is normally attached to the naming tree of those processes that are executed on that computer. While each process normally has its own independent set of name bindings, many bindings may be shared between processes. One example of a per-process naming scheme is the EPort distributed environment, developed in part by the inventor herein. In the EPort environment computers are grouped into divisions. There is normally a high degree of sharing between computers within a division, but limited sharing across divisions. Each computer in the EPort environment possesses its own set of name bindings for objects resident at that computer, typically organized in a hierarchial naming tree. Each division has also its own hierarchial naming tree for objects that are shared among the computers within that division. Each process in EPort has its own root node to which it attaches the naming trees of various subsystems, such as the naming trees of individual computers and divisions. Typically, an EPort process attaches the naming tree of the computer and division within which the process resides. An EPort process can also attach the naming trees of other subsystems during remote execution.
Transparent and semi-transparent remote execution may normally be performed using per-process representation schemes such as EPort. During remote execution the set of name bindings of the parent process at the parent computer is passed to the child process at the child computer. Some changes, however, are made in the copy of the parent name bindings transferred to the child. The name bindings of som
Arter & Hadden LLP
Courtenay III St. John
LandOfFree
Method of remotely executing computer processes does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of remotely executing computer processes, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of remotely executing computer processes will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2876187