Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-02-03
2001-04-10
Dinh, Dung C. (Department: 2757)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S202000, C709S238000, C709S231000
Reexamination Certificate
active
06216173
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of computer-related systems, and more particularly to a software platform for incorporating content-processing and content-routing intelligence into networks.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.
2. Background Art
Computers and computer networks are used to exchange information in many fields such as media, entertainment, commerce, and telecommunications, for example. Media and entertainment information may include the digitized content of movies, video, audio CD's, radio, newspapers, books, magazines, and computer games. Commerce information includes electronic banking and bill payment, as well as electronic purchases. Voice telephone transmissions and video conferencing are examples of telecommunication information. The exchange of information between computers typically occurs between a “server application” that provides information or services, and a “client application” or device that makes requests of the server application and receives the provided information and services. Multiple server applications are sometimes available on a “service system”. A problem with current systems is the difficulty and complexity of delivering the information in the format required by the different client applications or devices, and the difficulty and complexity of determining the best route the information should take to move from a server application to a client application or device. This problem can be understood by reviewing current systems.
Software service systems have been developed to provide mechanisms for client applications and devices to access the services of a server application. However, these service systems have difficulty in servicing the requirements of a very large number of client applications and do not provide re-usability of information processing and content routing technology for applications other than those for which they are specifically designed. Also, there are many different types and formats of information to be transmitted over the same network. Current systems do not provide arbitration or scheduling prioritization based on user or application requirements between information types being transmitted over a network. Further, routing is not based on the actual content of information being transferred. Rather it is based only on certain well-defined, limited attributes such as originator address, destination address, priority, size of object and type of packet of data. Such attributes do not lead to the most efficient transmission of information in mixed usage networks.
Another disadvantage is that client applications must have knowledge of how to communicate with specific server applications to facilitate the location and access of the respective services. This makes the addition of new service applications or devices difficult because client applications must be reconfigured or reprogrammed to recognize the new server applications and to direct service requests to those new applications. There is no mechanism in the service system to allow new services to be added without such reconfiguring or reprogramming.
Another problem is that information to be transmitted may be in one of many different data encoding formats and may be transmitted as bounded data, in the form of objects, files, etc., or as unbounded data in the form of data streams. In prior art service systems, applications using one data encoding format or bounded/unbounded transmission format cannot access the services of another application using a different data encoding format or bounded/unbounded transmission format without the use of a gateway or converter built specifically for that purpose. There is no extensible and re-usable mechanism for resolving communication between the client and server applications, and, further, the underlying service system may support only one transmission format.
CORBA and OLE/COM
Networked object technologies, such as CORBA (Common Object Request Broker Architecture) and OLE/COM (Object Linking and Embedding/Component Object Model), allow applications access to networked objects and their shared services. CORBA is designed to allow different object systems from multiple vendors to interact with each other on a network.
The CORBA system implements an Object Request Broker (ORB) providing for the location and execution of objects through a standard interface protocol, enabling objects and programs to interact with each other across the network. In the CORBA environment, an ORB daemon process (ORBD) receives object calls from the client processes registered to it. The ORB daemon then locates the object on the network, and acts as the interface between the client process and the networked object.
The OLE/COM system supports marshalling of function calls to remote objects using the lightweight remote procedure call format (LRPC). Proxy/stub pair remoting code, defined using IDL (interface definition language), is maintained to service standard marshalling calls. The OLE/COM system includes an object server registry for locating an appropriate object server for a given object class ID. Information regarding what methods an object interface supports, and the types of parameters required by each method, may be obtained from a type library.
In both CORBA and COM, client applications designate a particular server object, or object class, as the target of a function call. To accommodate calls to a new service, the client application must be reconfigured or reprogrammed to send function calls to the new service. There is little flexibility as to which object responds to a function call, as the target service is predetermined by the client application. To determine what other services are available in the system, the client application itself must interrogate objects. This sort of interrogation assumes inherent knowledge of those objects. Further, if similar services are provided in the system, there is no mechanism for selecting between the services. Only that service which is designated in the function call may be accessed, even if another service better suited to the task at hand is available.
The CORBA and COM systems allow for single-source/single-destination communication and are oriented around communication between distributed processing logic rather than supporting the movement and distributed processing of content. That is, a client application may access only one service at a time. More complex service communications with multiple service destinations, such as directing a service request to visit multiple services in sequence, is not supported. To accomplish a similar function, a client must access a first service, receive a response from the first service, forward the first response to the second service, receive a second response from the second service, forward the second response to a third service, etc. It is inefficient for the client to issue multiple service requests in this manner and it usually also creates unnecessary additional network traffic.
ROUTING SYSTEMS
The service systems of the prior art typically rely on low-level systems to route information between parties (computers, applications, etc.). These low-level systems are typically hardware systems with little or no knowledge about the type of information being transmitted or of the relative requirements of one type of transmitted information over another. Thus, there is no mechanism to control routing at the application level where such knowledge exists.
Typical routing systems of the prior art, such as routers manufactured by Cisco Systems, Inc. of San Jose, Calif., operate only at a low level. These systems perform routing based on the network packet type, originating address, desti
Jones Adrian
Moore Alan
Dinh Dung C.
Redbox Technologies Limited
The Hecker Law Group
LandOfFree
Method and apparatus for content processing and routing 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 and apparatus for content processing and routing, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for content processing and routing will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2459138