Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-08-12
2002-02-05
Maung, Zarni (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S246000
Reexamination Certificate
active
06345315
ABSTRACT:
STATEMENT REGARDING FEDERALLY-SPONSORED RESEARCH OR DEVELOPMENT
Not applicable
BACKGROUND OF THE INVENTION
This present invention relates to an improvement in a communication system between computers and associated peripherals and appliances, and more particularly to platform- and protocol-independent communication.
In today's industry many users are faced with severe incompatibility problems, when they need to establish an information processing system. It is because the users are able to choose from a large set of available system components from many vendors for performing similar functions. For example, a computer user may need to have access to printer, scanner, telephone, FAX, camera, microphone, audio system, machine tools, alarm system, monitoring system, or other similar device, system, or appliance, besides the computer, depending upon the intended purpose.
All such entities that reside outside the conventional boundary of a computer system, but are attached in some way and can communicate with it, are generally called computer peripherals. Lately, many types of such peripherals are commonly attached to one or more computers, all interconnected by means of a network. A pair of such entities, either connected directly or by means of a network, which have a special relationship wherein one requests a service to be performed while the other performs the requested service, are commonly referred to as Client-Server pair. A server may be another computer or a computer peripheral, as long as it is capable of performing a known service, for example printing or database-access, etc. A client is typically a user application (such as a wordprocessor), either running locally or remotely, that needs the service.
In such a situation, the request for service arises out of an application and travels through several layers of client system software, through the client hardware, through the connecting medium, through the server hardware, possibly through several layers of server system software, finally to the server application software. Likewise, the server response flows back to the client in identical manner but in the opposite direction.
Typically, many clients request service from a given server. A general case of such interaction occurs on a network, where many clients may be distributed over several computers. These clients may be user applications created by many separate vendors, which may be executing on computers created by many other and different vendors. Yet all these clients and servers must communicate reliably and efficiently. Therefore, a standard is needed for facilitating such communication between different entities. A network protocol is such a standard. A layered model, such as the OSI (Open Systems Interconnection), is a stack of network protocol software that a client-server pair typically uses today to communicate with each other.
Even though the above-described approach conceptually solves the compatibility problem between clients and servers on a network, incompatibility may result due to many factors in reality. To begin with, there are several protocols at the Data-Link layer itself each with its own unique properties and behavior (such as Ethernet/IEEE-802.3, Token-Ring/IEEE-803.4, AppleTalk, FDDI (Fiber Digital Data Interconnect), ATM (Asynchronous Transfer Mode), etc.). There are also several protocols at the Network and Transport layers as well, e.g. TCP/IP (Transmission Control Protocol/Internet Protocol), IPX/SPX (Novell standard), NETBEUI (Microsoft standard), and AppleTalk, to mention a few. Likewise, there are several protocols for communicating with directly attached servers too; e.g., RS-232, IEEE-1284, IEEE-1394, Apple Desktop Bus, etc.
It should be noted that although all these protocols facilitate communication successfully and reliably, all of these, with one exception, namely RPC (Remote Procedure Call), are designed to transport data. RPC is a layer designed to operate on top of TCP/IP for remote execution of programs and to interpret data in a specific manner regarding the execution of a program or application. The recipient is obligated to execute a pre-existing code contained thereat. RPC is directed at solving a particular problem with a particular motivation, namely distributed processing. It has been very successfully deployed in the implementation of NFS (Network File System) in UNIX systems. Lately, newer distributed program system architectures such as CORBA (Common Object Request Broker Architecture), DCOM/ActiveX (Distributed Common Object Model), SOM (Simple Object Model), NEST (Novel Embedded System Technology), and JAVA (developed by Sun Microsystem), and the like, have come into existence. However, all these are incompatible with each other, which results in extremely difficult inter-operation creating severe difficulties for the user.
This invention seeks to solve the problem of software incompatibility in the special case of client-server communication, especially with regard to that needed between an application running on a host computer and its computer peripherals intended to function as directly attached or network-connected servers. The existing solutions, as described above, are either too complex or too expensive for this purpose, since those are designed to solve a more general set of problems.
The client-server communication under consideration here is characterized by a simple exchange of data that can occur in a platform-independent manner. None of the above-described systems can accomplish this form of exchange as can the present invention. Nor can the inventions described in U.S. Pat No. 5,491,693 issued to Britton on Feb. 13, 1996 (addressing the problem of incompatibility between various communication protocols in a heterogeneous network environment and attempts to solve the problem through translation of communication data from one protocol to another using a smart Gateway); U.S. Pat. No. 5,613,090 issued to Willems on Mar. 18, 1997 (addressing the problem of a special case of disparate windowing environments, namely that existing between X-Window Systems available on various UNIX platforms, by introducing a layer of software in the communication path to translate request and responses in both directions); U.S. Pat. No. 5,627,829 issued to Gleeson on May 6, 1997 (addressing the problem of reducing network traffic by eliminating unnecessary protocol data which may arise out of transition between LANs and WANs); and U.S. Pat. No. 5,636,371 issued to Yu on Jun. 3, 1997 (addressing the problem of concurrent execution of multiple instances of well known port applications and solves it through port mapping on a single protocol stack).
In order to create a protocol-independent communication and hardware-independent software at both ends, the following principles must be upheld:
a. The exchange of information between the client and server must be in a format not tied to any communication protocol and be such that data contained in this exchange can be interpreted unambiguously in a vendor-neutral, hardware-neutral, and protocol-neutral manner.
b. The client should be required to know only the published capabilities (or parameters) of the server, along with possibly the number of parameters, their data-types (which must be most primitive and language-neutral), and their sizes. The knowledge of how a server may render those capabilities must be completely hidden from the client. Likewise, any client activity triggered by events reported by the server must be completely hidden from the server.
c. There is no need for either agent (client or server whether acting as initiator/requestor or responder/target) to indicate urgency or priority of requested action to the other. The agent performing the service has full knowledge of urgency or priority of requested action and it must keep that knowledge private.
If the above principles have to be adhered to, it is necessary to add an interface layer as a communication session manager (referred to herein as session manager or segue component) between the existing commu
Chang Jung-won
Maung Zarni
Morkunas Frank G.
LandOfFree
Method for platform and protocol independent communication... 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 for platform and protocol independent communication..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for platform and protocol independent communication... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2965683