Method and apparatus for content processing and routing

Abstract

A method and apparatus for incorporating content processing and content routing intelligence into networks. In one embodiment, the content processing and routing (CPR) system is aware of the content and requirements of data and service requests, as well as the capabilities of all services accessible via the system. Efficient network routing is accomplished by considering the capabilities of the available transmission channels, and the transmission needs of all current transmission service requests. Service requests are routed to the most suitable service or combination of services to fulfill the request. A mechanism is also provided for transparently converting data to accommodate data format differences between clients and services. In one embodiment, the CPR system comprises a system kernel consisting of the core software modules that are required to load, initialize and start CPR services, and allow the services to communicate securely. The CPR services conform to several general service types. These types include application services which act as the interface between a specific external application or device and the CPR system; kernel services which provide services on behalf of the kernel; content services which act on information in transit through the CPR system; routing services which contain the routing logic specific to a particular application; and link services which provide for the joining of two CPR instances over a network or other transmission channel. Data exchange is supported for bounded data in the form of media objects and unbounded data in the form of media streams.

Claims

What is claimed is:

1. Computer system apparatus comprising:

a network comprising at least one node, each node having a plurality of services that transmit data and service requests amongst each other as media objects, said plurality of services comprising:

at least one kernel service comprising a kernel router service, wherein said kernel router service routes media objects between each service within said node;

at least one application service, each application service forming an interface between an external application and said node for the exchange of said data and service requests; and

at least one content service, each content service providing processing of said data internal to said node.

2. The apparatus of claim 1, wherein said node further comprises at least one routing service, each routing service specifying an application-specific service route for transmitting and processing said data in said network.

3. The apparatus of claim 1, wherein said at least one kernel service further comprises a kernel stream service for setting up stream buffers between services that support unbounded data.

4. The apparatus of claim 1, further comprising at least one link service, each link service capable of forming a communication link with a corresponding link service in another node.

5. The apparatus of claim 1, wherein said at least one kernel service further comprises a service locator service, said service locator service maintaining a database comprising:

information about the location, identity and capabilities of services in said network; and

a list of service calls supported by each service.

6. The apparatus of claim 1, wherein said at least one kernel service further comprises a service locator service, said service locator service maintaining a directory comprising:

information about the location, identity and capabilities of services in said network; and

a list of service calls supported by each service.

7. The apparatus of claim 1, wherein said at least one kernel service further comprises a service monitor that tracks the status of services running on said node.

8. The apparatus of claim 7, wherein said service monitor monitors services running on a remote node by performing updates via service requests to and from a service monitor running on said remote node.

9. The apparatus of claim 1, wherein said at least one kernel service comprises a capability-based service request service which resolves a service route for service requests based on attributes associated with said service requests and capabilities associated with said plurality of services.

10. The apparatus of claim 1, further comprising an application service forming an interface between a device and said node.

11. The apparatus of claim 1, wherein said at least one content service performs analysis of said data in transit through said network.

12. The apparatus of claim 1, wherein said at least one content service examines said data to determine attributes associated with the content of said data.

13. The apparatus of claim 1, wherein said at least one content service converts said data from a first format to a second format.

14. The apparatus of claim 1, wherein said at least one content service modifies said data in transit through said network.

15. The apparatus of claim 1, wherein said at least one content service combines a plurality of data input formats into a single output format.

16. The apparatus of claim 1, wherein said at least one content service replicates at least one data input format to provide a plurality of data output formats.

17. The apparatus of claim 1, wherein said at least one content service terminates data.

18. The apparatus of claim 1, wherein said at least one content service converts a plurality of data input formats into a plurality of data output formats different from said data input formats.

19. The apparatus of claim 1, wherein said at least one content service separates a data input format into multiple output formats derived from said data input format.

20. The apparatus of claim 1, further comprising a kernel having a plurality of management modules accessible to said plurality of services via function calls.

21. The apparatus of claim 20, wherein said plurality of management modules comprise a boot manager which loads and starts other management modules.

22. The apparatus of claim 20, wherein said plurality of management modules comprise a monitor manager which monitors execution threads created in the node.

23. The apparatus of claim 20, wherein said plurality of management modules comprise a logging manager which handles message logging.

24. The apparatus of claim 20, wherein said plurality of management modules comprise a storage manager which handles storage of configuration information.

25. The apparatus of claim 20, wherein said plurality of management modules comprise a queue and stream manager which manages object queues and stream buffers for the input and output of media objects and media streams, respectively, from each of said plurality of services.

26. The apparatus of claim 20, wherein said plurality of management modules comprise a remote service call manager which handles encapsulation of service requests into media objects for a sending service, and which handles unpackaging of said service requests from said media objects for a receiving service.

27. The apparatus of claim 20, wherein said plurality of management modules comprise a configuration manager which loads and starts said plurality of services.

28. The apparatus of claim 20, wherein said plurality of management modules comprise a link manager, said link manager comprising a compression module manager, an encryption module manager and an authentication manager.

29. The apparatus of claim 20, wherein said plurality of management modules comprise an object handler, said object handler used by said plurality of services to read, write and delete said data from said media objects.

30. A method for incorporating content processing and content routing intelligence into networks, comprising:

forming a network comprising a plurality of nodes;

within each node,

forming an interface between an external application and said node by providing an application service for the exchange of data and service requests;

within a content service, processing said data in transit through said network; and

routing said data and service requests between each service in said node via a kernel router service.

31. The method of claim 30, further comprising specifying in a routing service an application-specific service route for transmitting and processing said data in said network.

32. The method of claim 30, further comprising setting up, via a kernel stream service, stream buffers between services that support unbounded data.

33. The method of claim 30, wherein said kernel router service routes said data and said service requests in the form of media objects.

34. The method of claim 30, further comprising:

maintaining information about the location, identity and capabilities of services in said network; and

maintaining a list of service calls supported by each service.

35. The method of claim 34, further comprising resolving a service route for service requests based on attributes associated with said service requests and said capabilities associated with said plurality of services.

36. The method of claim 30, further comprising, within each node, monitoring the status of services running on said node.

37. The method of claim 36, further comprising, within each node, monitoring the status of services running on a remote node by performing updates via service requests to and from a monitoring service on said remote node.

38. The method of claim 30, further comprising forming an interface between a device and said node by providing another application service for the exchange of said data and said service requests.

39. The method of claim 30, wherein said step of processing said data in transit through said network comprises performing analysis on said data.

40. The method of claim 30, wherein said step of processing said data in transit through said network comprises examining said data to determine attributes associated with the content of said data.

41. The method of claim 30, wherein said step of processing said data in transit through said network comprises converting said data from a first format to a second format.

42. The method of claim 30, wherein said step of processing said data in transit through said network comprises separating said data into separate data elements.

43. The method of claim 30, wherein said step of processing said data in transit through said network comprises combining separate data elements into a single data element.

44. The method of claim 30, wherein said step of processing said data in transit through said network comprises replicating at least one data input format to provide a plurality of data output formats.

45. The method of claim 30, wherein said step of processing said data in transit through said network comprises terminating data.

46. The method of claim 30, wherein said step of processing said data in transit through said network comprises converting a plurality of data input formats into a plurality of data output formats different from said data input formats.

47. The method of claim 30, further comprising, within each node, providing a plurality of management modules accessible to services in said node via function calls.

48. The method of claim 47, further comprising loading and starting said plurality of management modules via a boot manager.

49. The method of claim 47, further comprising, within each node, monitoring execution threads created in said node via a monitor manager.

50. The method of claim 47, further comprising, within each node, logging messages via a logging manager.

51. The method of claim 47, further comprising, within each node, handling storage of configuration information via a storage manager.

52. The method of claim 47, further comprising, within each node, managing object queues and stream buffers for the input and output of media objects and media streams from each service via a queue and stream manager.

53. The method of claim 47, further comprising:

within each node, in a remote service call manager,

encapsulating service requests within media objects for a sending service; and

unpackaging said service requests from said media objects for a receiving service.

54. The method of claim 47, further comprising, within each node, loading and starting said services via a configuration manager.

55. The method of claim 47, further comprising, within each node, each service using an object handler to read data from, write data to and delete data from a media object.

56. The method of claim 47, further comprising, within each node, providing a compression module manager to load a compression module and to manage compression and decompression of data transmitted between nodes.

57. The method of claim 47, further comprising, within each node, providing an encryption module manager to load an encryption module and to manage encryption and decryption of data transmitted between nodes.

58. The method of claim 47, further comprising, within each node, providing an authentication manager to manage authentication of data transmitted between nodes.

59. The method of claim 30, further comprising, in said node, forming a communication link with another node via a link service.

60. A computer program product comprising:

a computer usable medium having computer readable program code embodied therein for incorporating content processing and content routing intelligence into a network having a plurality of nodes, within each node, said computer program product comprising:

computer readable program code configured to cause a computer to form an interface between an external application and said node by providing an application service for the exchange of data and service requests;

computer readable program code configured to cause a computer to process, within a content service, said data in transit through said network; and

computer readable program code configured to cause a computer to route said data and said service requests between each service in said node via a kernel router service.

61. The computer program product of claim 60, further comprising computer readable program code configured to cause a computer to specify in a routing service an application-specific service route for transmitting and processing said data in said network.

62. The computer program product of claim 60, further comprising computer readable program code configured to cause a computer to set up, via a kernel stream service, stream buffers between services that support unbounded data.

63. The computer program product of claim 60, wherein said kernel outer service routes said data and said service requests in the form of media objects.

64. The computer program product of claim 60, further comprising:

computer readable program code configured to cause a computer to maintain information about the location, identity and capabilities of services in said network; and

computer readable program code configured to cause a computer to maintain a list of service calls supported by each service.

65. The computer program product of claim 64, further comprising computer readable program code configured to cause a computer to resolve a service route for service requests based on attributes associated with said service requests and said capabilities associated with said plurality of services.

66. The computer program product of claim 60, further comprising computer readable program code configured to cause a computer to monitor the status of services running on said node.

67. The computer program product of claim 66, further comprising computer readable program code configured to cause a computer to monitor the status of services running on a remote node by performing updates via service requests to and from a monitoring service on said remote node.

68. The computer program product of claim 60, further comprising computer readable program code configured to cause a computer to form an interface between a device and said node by providing another application service for the exchange of said data and said service requests.

69. The computer program product of claim 60, wherein said computer readable program code configured to cause a computer to process said data in transit through said network comprises computer readable program code configured to cause a computer to perform analysis on said data.

70. The computer program product of claim 60, wherein said computer readable program code configured to cause a computer to process said data in transit through said network comprises computer readable program code configured to cause a computer to examine said data to determine attributes associated with the content of said data.

71. The computer program product of claim 60, wherein said computer readable program code configured to cause a computer to process said data in transit through said network comprises computer readable program code configured to cause a computer to convert said data from a first format to a second format.

72. The computer program product of claim 60, wherein said computer readable program code configured to cause a computer to process aid data in transit through said network comprises computer readable program code configured to cause a computer to separate said data into separate data elements.

73. The computer program product of claim 60, wherein said computer readable program code configured to cause a computer to process said data in transit through said network comprises computer readable program code configured to cause a computer to combine separate data elements into a single data element.

74. The computer program product of claim 60, wherein said computer readable program code configured to cause a computer to process said data in transit through said network comprises computer readable program code configured to cause a computer to replicate at least one data input format to provide a plurality of data output formats.

75. The computer program product of claim 60, wherein said computer readable program code configured to cause a computer to process said data in transit through said network comprises computer readable program code configured to cause a computer to terminate data.

76. The computer program product of claim 60, wherein said computer readable program code configured to cause a computer to process said data in transit through said network comprises computer readable program code configured to cause a computer to convert a plurality of data input formats into a plurality of data output formats different from said data input formats.

77. The computer program product of claim 60, further comprising computer readable program code configured to cause a computer to provide a plurality of management modules accessible to services in said node via function calls.

78. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to load and start said plurality of management modules via a boot manager.

79. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to monitor execution threads created in said node via a monitor manager.

80. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to log messages via a logging manager.

81. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to handle storage of configuration information via a storage manager.

82. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to manage object queues and stream buffers for the input and output of media objects and media streams from each service via a queue and stream manager.

83. The computer program product of claim 77, further comprising:

computer readable program code configured to cause a computer to, in a remote service call manager,

encapsulate service requests within media objects for a sending service; and

unpackage said service requests from said media objects for a receiving service.

84. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to load and start said services via a configuration manager.

85. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to read data from, write data to and delete data from a media object via an object handler.

86. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to provide a compression module manager to load a compression module and to manage compression and decompression of data transmitted between nodes.

87. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to provide an encryption module manager to load an encryption module and to manage encryption and decryption of data transmitted between nodes.

88. The computer program product of claim 77, further comprising computer readable program code configured to cause a computer to provide an authentication manager to manage authentication of data transmitted between nodes.

89. The computer program product of claim 60, further comprising computer readable program code configured to cause a computer to form a communication link with another node via a link service.

Description

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, destination address, port, priority, tag, size of object and type of packet of data. Dedicated hardware solutions include video routing hardware, splitters, and switches. Those hardware solutions are inflexible, expensive, non-scalable, and suited solely to the task for which they are designed.

In addition to dedicated hardware solutions, general purpose hardware is combined with dedicated software, such as with gateway software or application bridges. For instance, a database gateway may provide conversion from SQL (structured query language) format to proprietary formats, and a four-way H.320 bridge can allow four H.320 video conferencing devices to communicate, with each terminal viewing the other three. Those dedicated software solutions are of limited utility, beyond their specific design purpose.

In the prior art, networks are typically used very inefficiently when multiple digitized information types are being transmitted across a single network simultaneously. For example, current network applications and devices usually request network bandwidth on demand, regardless of the competing requirements of other applications and devices that need to share the available bandwidth. Even in technologies such as ATM (asynchronous transfer mode) switches, which allow applications to make more specific requests of the network (e.g., to provide limited but constant bit rate bandwidth), no consideration is given to the relative requirements of other applications that also need to use the network. Also, when multiple networks are available between a server application and a client application, the network actually used normally is selected based exclusively on configuration settings. That is inefficient because the most appropriate network for transmission may only be determinable at the time of transmission of information.

BACKGROUND REFERENCES

The following U.S. patents pertain to routing and media distribution:

U.S. Pat. No. 5,509,123, issued to Dobbins, is directed to an object-oriented packet routing system which utilizes common protocol-independent base objects to instantiate protocol specific objects, and which distributes the critical function and system behavior into autonomous objects. The system supports multiple network and routing protocols.

U.S. Pat. Nos. 5,251,205 and 5,430,727, issued to Callon, are directed to routing algorithms that support multiple protocols. The method includes a determination of nearest neighbor routers and their respective packet format support capabilities for use in determining network transmission paths. Multi-protocol routers are used to forward packets of differing formats, such as IP (internet protocol) and OSI (open systems interconnection) formats, to the nearest router that is in the desired transmission path and that also supports the packet format of each respective packet.

In Callon '205 and '727, when the nearest routers do not support a given packet format, the packet data is encapsulated into a supported format and forwarded. The new encapsulated packet is given a dummy address which another router in the transmission path can interpret as indicating an encapsulated packet. The encapsulated packet is extracted and routed to the designated end system or another router.

U.S. Pat. Nos. 5,423,002 and 5,583,997, issued to Hart, disclose a system for transparently extending network resources, such as the multi-protocol routing functionality of a router, to a remote LAN (local area network). From the perspective of the end systems on interconnected LANs, a "routing adapter" and a "boundary router" provide the same functionality as two interconnected routers. A small site LAN may install a routing adapter which operates independently of the higher level protocol suites. The boundary router at the local LAN provides the higher level protocol suite services to the remote LAN by way of a direct communication link and the routing adapter.

U.S. Pat. No. 5,434,863, issued to Onishi, discloses an internetworking apparatus for performing routing and packet transmission. The apparatus comprises one or more routing accelerators for assisting a main processor to perform routing. The routing accelerator subjects reception packet data to routing and transmits the data to other routing accelerators if necessary. The routing accelerator discriminates the type of the data frame, and, where the data frame is not of a routable protocol, the data is transmitted to other routing accelerators to perform bridge operations. The main processor acts as a routing manager for the internetworking apparatus, and distributes the routing table to the routing accelerators. More routing accelerators may be added to the apparatus as the network size increases.

U.S. Pat. No. 5,519,704, issued to Farinacci provides a reliable transport protocol that works with unicast and multicast transmission, and a routing protocol based on the transport protocol. A technique is provided by which destinations may be labeled with authentication information or with an administrative tag that specifies a method of routing in response to policy considerations such as security, financial, reliability, application-based policy, or other policy reasons.

U.S. Pat. No. 5,381,527, issued to Inniss, discloses a method and system for distributing messages utilizing a data processing system. A user specifies and prioritizes alternate distribution media and associated distribution channels. In the event that the distribution of a message fails in the preferred channel, the system automatically attempts to distribute the message via the user-specified alternate distribution channels based on the priorities specified by the user.

U.S. Pat. No. 5,473,599, issued to Li, is directed to network systems having redundant routers for receiving packets from a host on a LAN. Data packets are routed from a host on a LAN through a virtual address belonging to a group of routers. The group of routers comprise an active router and a standby router. The active router handles all data packets processed through the virtual address. If the active router becomes inoperative, the standby router takes over as the active router. The other routers in the group hold an election to determine a new standby router.

U.S. Pat. No. 5,517,620, issued to Hashimoto, discloses a system for dynamically updating routing information for routing packets between LANs connected to a plurality of routers via a public network. A local router comprises a protocol processor for periodically processing routing information into a local routing information protocol (RIP) datum indicative of the LANs connected to the local router. A comparator compares the RIP datum with stored information in a RIP memory, and the stored information is updated if the RIP datum is incoincident with the current stored information. The current stored RIP information is sent to other routers via a public network interface, and routing tables in each router are updated in response to the incoming RIP information.

U.S. Pat. No. 5,544,320, issued to Konrad, discloses a remote information service access system based on a client-server-service model. The service functionality is separated into a human interface service functionality, a starter service functionality, and a desired utility service functionality. The functionality is then distributed between a local host and a remote host in a manner transparent to the user.

U.S. Pat. No. 5,553,289, issued to Johnson, provides a method for automatically assigning attributes, such as "Private--Audio Content," to multimedia distributions. Specific attributes are associated with specific types of media. The distribution is searched to determine the types of media being distributed, and those attributes associated with the media types contained in the distribution are assigned to the distribution.

U.S. Pat. No. 5,583,862, issued to Callon, discloses a method and apparatus for routing for virtual networks. Routing tables are maintained in routers or gateways which identify whether or not a destination is directly reachable by the router listed in the routing information entry, or whether the destination is part of a virtual network served by the listed destination routers. Routers in communication with a virtual network are first queried for the identity of a particular destination router address before packets are delivered to eliminate the need of packet forwarding.

U.S. Pat. No. 5,608,726, issued to Virgile, discloses a system and method for routing multicast packets in a subnetwork so as to conserve bandwidth in at least some of the network segments or collision domains of the subnetwork. Multicast packets are only retransmitted in the network segments that are on a path to a host that is a member of the multicast group of hosts to which the multicast packet is directed.

SUMMARY OF THE INVENTION

The invention provides a method and apparatus for incorporating content processing and content routing intelligence into networks. In one embodiment, the content processing and routing (CPR) system is aware of the content and requirements of data and service requests, as well as the capabilities of all services accessible via the system. Efficient network routing is accomplished by considering the capabilities of the available transmission channels, and the transmission needs of all current transmission service requests. Also, service requests are able to be cast without specifying a particular service to fulfill the request. A service request is routed to the most suitable service or combination of services to fulfill the request. This permits services to be added to the system without reconfiguration or reprogramming existing applications. The CPR system also provides a mechanism for transparently converting data to accommodate data format differences between clients and services.

In one embodiment, the CPR system comprises a system kernel consisting of core software modules that are required to load, initialize and start CPR services, and that allow the services to communicate securely. The CPR services conform to several general service types. These types include (1) application services that act as the interface between a specific application and the CPR system; (2) kernel services that provide services on behalf of the kernel, including service location and routing resolution; (3) content services that act on information in transit through the CPR system, including providing data conversions; (4) routing services that contain the routing logic specific to a particular application, such as broadcasting to a subscriber list; and (5) link services that provide for the joining of two CPR instances over a network or other transmission channel. Each service implementation of these general types performs a particular task or set of tasks and supports a standard set of software interfaces, such that the kernel and other services are able to call functions within the service.

Data exchange is supported for bounded data in the form of media objects and unbounded data in the form of media streams. An object handler kernel component is provided so that each service may uniformly read, write or delete data in a media object. Service requests are communicated between services in the form of remote service calls (RSCs) which are encapsulated within media objects. A remote service call manager kernel component packs and unpacks remote service calls from media objects and interfaces with services to issue the remote service call as direct function calls.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of component interaction in the system according to an embodiment of the invention.

FIG. 2 is a diagram illustrating the interaction between services and the kernel with respect to queuing and object passing according to an embodiment of the invention.

FIG. 3 is a diagram illustrating interaction between services and the kernel with respect to logging of messages according to an embodiment of the invention.

FIG. 4 is a diagram illustrating an embodiment of an information flow between services in the system of the present invention.

FIGS. 5A and 5B are block diagrams illustrating the flow of remote service call objects between services and the kernel router in an embodiment of the invention. FIG. 5A illustrates object flow when the service is acting as a server, and FIG. 5B illustrates object flow when the service is acting as a client.

FIG. 6 is a block diagram illustrating the communication of media objects between two instances of the content processing and routing system according to an embodiment of the invention.

FIG. 7 is a block diagram illustrating communication of media streams between two instances of the content processing and routing system according to an embodiment of the invention.

FIG. 8 is a block diagram illustrating an embodiment of a content processing and routing (CPR) network, including conversion between object or stream types.

FIG. 9 is a block diagram illustrating an embodiment of the content processing and routing system of the invention.

FIG. 10 is a block diagram of a general purpose computer suitable for implementing a content processing and routing system embodiment of the invention.

FIG. 11 is a flow diagram illustrating an embodiment of the startup process for the kernel components.

FIG. 12 is a flow diagram illustrating an embodiment of the startup process for services.

FIG. 13 is an example embodiment of a media object.

FIG. 14 is an example of a business internet application implementing an embodiment of the invention.

FIG. 15 is an example of a business video network application implementing an embodiment of the invention.

FIG. 16 is an example of a personalized television application implementing an embodiment of the invention.

FIG. 17 is an example of an information publishing and broadcasting application implementing an embodiment of the invention.

FIG. 18 is an example of a distributed Java application implementing an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is a method and apparatus for content processing and routing. In the following description, numerous specific details are set forth to provide a more thorough description of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well known features have not been described in detail so as not to obscure the present invention.

1. Hardware Embodiment of a General Purpose Computer System

An embodiment of the invention can be implemented as computer software in the form of computer readable program code executed on a general purpose computer such as illustrated in FIG. 10. A keyboard 1010 and mouse 1011 are coupled to a bi-directional system bus 1018. The keyboard and mouse are for introducing user input to the computer system and communicating that user input to central processing unit (CPU) 1013. Other suitable input devices may be used in addition to, or in place of, the mouse 1011 and keyboard 1010. I/O (input/output) unit 1019 coupled to bi-directional system bus 1018 represents such I/O elements as a printer, network communications card, modem, A/V (audio/video) I/O, etc.

The computer system of FIG. 10 also includes a video memory 1014, main memory 1015 and mass storage 1012, all coupled to bidirectional system bus 1018 along with keyboard 1010, mouse 1011 and CPU 1013. The mass storage 1012 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology. Bus 1018 may contain, for example, thirty-two address lines for addressing video memory 1014 or main memory 1015. The system bus 1018 also includes, for example, a 32-bit data bus for transferring data between and among the components, such as CPU 1013, main memory 1015, video memory 1014 and mass storage 1012. Alternatively, multiplex data/address lines may be used instead of separate data and address lines.

In one embodiment of the invention, the CPU 1013 is a microprocessor manufactured by Intel, such as a processor from the 80.times.86 or Pentium processor families. Other possible microprocessors include the 680.times.0 or PowerPC 60.times. processor families manufactured by Motorola, the SPARC microprocessor from Sun Microsystems, and the DEC Alpha. However, any other suitable processor or microcomputer may be utilized. Further, the apparatus may comprise a plurality of microprocessors in a multi-processing arrangement.

Main memory 1015 is comprised of dynamic random access memory (DRAM). Video memory 1014 is a dual-ported video random access memory. One port of the video memory 1014 is coupled to video amplifier 1016. The video amplifier 1016 is used to drive the cathode ray tube (CRT) raster monitor 1017. Video amplifier 1016 is well known in the art and may be implemented by any suitable apparatus. This circuitry converts pixel data stored in video memory 1014 to a raster signal suitable for use by monitor 1017. Monitor 1017 is a type of monitor suitable for displaying graphic images.

The apparatus of FIG. 10 may be used as a stand-alone system, or the apparatus may be coupled to other similar apparatus across any type of network (e.g., LAN, WAN (wide area network), PSTN (public switched telephone network), Internet, Cable TV, etc.), or any combination thereof.

The computer systems described above are for purposes of example only. An embodiment of the invention may be implemented in any type of computer system or programming or processing environment.

2. The Content Processing and Routing (CPR) System

The invention provides a software platform for incorporating content processing and content routing intelligence into any type of network, enabling re-use of existing applications and content in a network service, and enabling more efficient use of underlying data networks. The invention also provides for developing, deploying and managing of new services across a digital network, which, in the prior art, typically requires extensive customized system development and re-engineering of existing applications and content.

Scalable support is provided for processes. Where a large amount of information has to be processed very quickly to enable an application to deliver its business objectives (e.g., real-time video processing), the invention, automatically and transparently to the host application, generates multiple instances of the process on a single processor, multiple processors and/or at other nodes in a content routing and processing (CPR) network as appropriate.

Support is provided for bounded (object type) and unbounded (streaming type) data in a single model. Traditionally, in the prior art, separate tools are required for different types of applications. The CPR system of the invention includes a queue and stream manager which can interface with any service to support applications processing either objects or streams.

Attributes are associated with every service request which allow the CPR system to obtain knowledge about the content and requirements of each service request. Further, every service registers its associated capabilities with the CPR system. The CPR system uses its knowledge about the content and requirements of a service request as well as its knowledge of the available services to make intelligent routing decisions with respect to selecting suitable services for the fulfillment of service requests and selecting and scheduling network transmissions between CPR nodes, i.e., between computers containing an active instance of the CPR system.

The invention enables applications or devices competing for access to network or processing resources to be granted access in a more efficient, calculated manner. Depending on the nature of the information type and content, there are different requirements for the data crossing the network. By understanding all of the types and content of information, the invention controls usage of network resources in a more efficient manner. The routing decisions are not made at the usual network level (e.g., based on pre-defined destination network address, resolvable named network address, packet priority, circuit priority, etc.), but are based on the content and properties of the information itself. This may be independent of the type of underlying network that provides the digital communications capabilities.

Also, many digital devices and applications in the prior art are unable to communicate with each other due to differences in information formats and communications session protocols. The invention provides a platform through which these incompatible devices and applications can communicate. CPR system components handle the conversion of information formats and the support of appropriate communications session protocols.

Content Processing and Routing (CPR) System Architecture

One embodiment of the CPR system of the invention is an object-oriented design based around a kernel. Communication between all software components outside the kernel is asynchronous and location-independent, enabling applications and services developed on the CPR platform to scale from a single processor machine to high volume, multi-processor servers in a clustered or wide-area distributed environment. The kernel consists of the core software modules that are required to load, initialize and start CPR services and allow the services to communicate securely.

The fundamental application unit of the CPR system is known as a service. There are several different types of services, though all share certain common facets. A service performs a particular task or set of tasks and supports a standard set of software interfaces, such that the kernel and other services are able to call functions within the service. The general types of services in the CPR system include: kernel services, link services, application services, content services and routing services. An instance of the CPR system can host many services of each type and multiple instances of each service. Each service may support either bounded media objects or unbounded media streams. Service requests and inter-service communication are performed using a standard call format referred to as a remote service call (RSC). These remote service calls are encapsulated in bounded media objects to conform to a standard media-object-based interface.

FIG. 9 is a general block diagram illustrating the primary components of a CPR instance, and the general means by which a CPR instance communicates with an external application and a second CPR instance. CPR instance 901A comprises kernel 902A, application service 903A, content service 904A, routing service 905A, kernel service 906A, and link service 907A. CPR instance 901B comprises kernel 902B, application service 903B, content service, 904B, routing service 905B, kernel service 906B, and link service 907B.

Each type of service (i.e., kernel service, application service, etc.) performs a separate general function for the system. Each service in CPR instance 901A is coupled to kernel 902A to share the kernel resources. Similarly, kernel 902B in CPR instance 901B is coupled to each service within CPR instance 901B. Each service shown represents a general service type, and multiple specialized services of each service type may be present in the CPR instance. Further, when necessary, multiple instances of a service may run concurrently in the CPR system.

The CPR system communicates with external applications via application services specifically designed to transport data between the respective application and the CPR system in the manner required by the application. Thus, a different application service may be required for each possible external application.

In FIG. 9, application 900 is coupled to CPR instance 901A via application service 903A. A second external application may be similarly coupled to CPR instance 901A via another application service to allow the two external applications to exchange services, as well as utilize the other services provided by the CPR instance. Thus, a single instance of the CPR system may be used as a stand-alone platform for joining applications.

A computer system containing an active CPR instance is referred to as a CPR node. CPR nodes communicate across networks to other CPR nodes via link services. A CPR network comprises one or more CPR nodes joined or capable of joining in this manner. Different link services may be provided to support communication via many different communication protocols or across many different types of networks. Link services can interface to the network at any required level, for instance ATM (layer two of the OSI seven layer stack), TCP (transmission control protocol, layer four) or MQ (message-queuing, layer seven). In FIG. 9, link service 907A is coupled to link service 907B to join CPR instances 901A and 901B. Through the link provided by link services 907A and 907B, application 900 may access the services provided by CPR instance 901B, as well as any applications joined to CPR instance 901B via application service 903B.

Application Services

An application service operates as the interface between the CPR system and a third-party application or an industry-standard information interchange interface. The task of the application service is to obtain and/or deliver information externally to the CPR environment. To a third-party application, an application service may appear to be a conventional client, a server, a peer, or a gateway.

Examples of application services include a WWW (World Wide Web)/Java service, an FTP (file transfer protocol) service, a MAPI (messaging application programming interface) service, and a DMTF (Desktop Management Task Force) service. The WWW/Java service is able to receive requests using HTTP (hypertext transport protocol) over a TCP/IP (transmission control protocol/internet protocol) network from a web browser and to return HTML (hypertext markup language) content to a browser. A CPR system can emulate a WWW server or filter HTML requests for specific information while passing general requests to a third-party web server. Any Java application may access CPR capabilities through the WWW/Java service by using remote service calls.

An FTP service is used to send and receive files to and from an FTP server over a TCP/IP network connection. A MAPI service is used to connect as a user to any e-mail system supporting the messaging API, such as Microsoft Mail, Exchange, CompuServe and Internet Mail (SMTP--simple mail transfer protocol). A DMTF service enables DMTF-compliant system management products to remotely manage and monitor one or more CPR instances.

Kernel Services

Kernel services provide services on behalf of the kernel. Kernel services have special knowledge of the CPR kernel, and the kernel has special knowledge of these kernel services to enable the kernel and the kernel services to cooperate in providing fundamental system services, such as logging, monitoring, version management, etc., that form part of the core CPR system. Examples of kernel services include the kernel router service, the service locator service, the service monitor, the capability-based service request (CBSR) service and the network resource service.

The kernel router service is responsible for the precise routing of every media object and media stream, and also validates the security and integrity of every media object that it routes. The kernel router service will be discussed in further detail later in this specification.

The service locator service provides and maintains, in a database or directory, information about the location, identity and capabilities of all known services in a CPR network, and also maintains a list of remote service calls (RSCs) supported by each known service. The database for the service locator service may comprise a complete copy of all location, identity, capability and RSC information for the CPR network stored at each CPR node in the network. Also, the database may comprise a distributed database in which information about services local to each CPR node is stored at the respective CPR node, and is accessible to the service locator services of other CPR nodes on the network via remote service calls.

The service monitor tracks the status of all CPR services running on the local CPR node, and is also capable of monitoring services running on remote CPR nodes. The monitoring of remote CPR nodes is accomplished by performing scheduled or requested updates via remote service requests to and from the service monitors of the remote CPR nodes.

The capability-based service request service permits service requests to be routed based upon quality-of-service requirements of the request rather than a fixed route to a predetermined destination service. This is accomplished by assigning attributes to service requests. In resolving the route for the service request, selection is made from those services, or combinations of services, that fulfill the capability and quality-of-service requirements of the service request. If no single service can fulfill the service request, the CBSR service resolves a piecewise resolution of the service request by determining a route through multiple services that each perform one or more functions of the service request. The capabilities of each service are detailed in the database of the service locator service, and service status may be obtained from the service monitor.

For example, if a request is made to transmit data from one location to another, the request may include attributes detailing transmission requirements, such as encryption, bandwidth, and cost requirements. To resolve the transmission route, the CBSR service determines which link services are associated with transmission channels meeting the given requirements. Content services may also be used to change data formats to accommodate format requirements of specific routes.

Once a transmission channel has been selected, a remote service call may be made to the CBSR service on the CPR node at the other end of the transmission channel to further resolve the next section of the transmission route, if required. A given route may be registered so that subsequent transmissions with the same requirements may follow the same route without the need for further CBSR route resolution. Also, the registered route may be assigned a lifetime to prevent chosen routes from becoming obsolete due to changes in available bandwidth and other dynamic channel characteristics. The following are some examples of attributes that can be assigned to service requests:

    Net/Cost                  Net/Bandwidth/Minimum
    Net/Cost/PricedByUsage    Net/Bandwidth/Average
    Net/Cost/PricedByConnection Net/Security
    Net/Cost/FixedPrice       Net/Security/Encryption
    Net/Jitter                Net/Security/Encryption/Level
    Net/Jitter/Maximum        Net/Security/Authentication
    Net/Jitter/Average        Net/Security/Authentication/Level
    Net/Latency               Net/Security/Delivery
    Net/Latency/Maximum       Net/Security/Delivery/Guaranteed
    Net/Latency/Average       Net/Security/Private
    Net/Bandwidth             Net/Security/VirtualPrivate
    Net/Bandwidth/Maximum     Net/Security/Public
    Person/Name               Person/Position
    Person/Name/English       Person/Company
    Person/Name/Japanese      Person/TelephoneNumber
    Person/Name/LastName      Person/TelephoneNumber/Home
    Person/Name/FirstName     Person/TelephoneNumber/Work
    Person/Name/Title         Person/TelephoneNumber/Mobile

    Logging Manager API
    Start( );          Sets up the internal logging file and logging level, and
     begins
                       internal logging
    Stop( );           Stops internal logging
    CreateInputQueue( ); Creates an input queue for writing log strings
    CreateOutputQueue( ); Creates an output queue; the output queue may receive
     strings
                       from several input queues and write them to a file
    DeleteInputQueue( ); Deletes an input queue previously allocated
    DeleteOutputQueue( ); Deletes an output queue previously allocated
    BindQueue( );      Binds an input queue to an output queue
    WriteLog( );       Writes a message to a given input queue; messages below
     the
                       current logging level are discarded
    GetLoggingLevel( ); Retrieves the current logging level in force on an
     input queue
    BindDirect( );     Creates an input queue and binds it to a given output
     queue
    WriteEventLog( );  Writes a message to a particular event log

    Message Name                            Message
    IDS_MRTCP_STARTUP                       "MRTCPIP Transport service V1.05
     Copyright
                                            (c) 1996-97 RedBox Holdings NV. All
     rights
                                            reserved."
    IDS_STARTUP_FAILED                      "This service failed to start up
     correctly.
                                            This service is unable to route
     data."
    IDS_STARTUP_WINSOCK_INIT_SUCCESS        "Windows Sockets (2.0)
     initialized."
    IDS_STARTUP_WINSOCK_INIT_FAILURE        "Error initializing Windows
     Sockets. Error
                                            was %1!d!."
    IDS_STARTUP_INVALID_CONFIG_FILE         "Error accessing the kdb file. This
     service
                                            will have no external links -
     unable to route
                                            data."
    IDS_SHUTDOWN_WINSOCK_SUCCESS            "Windows Sockets successfully
     closed."
    IDS_SHUTDOWN_WINSOCK_FAILURE            "Error closing Windows Sockets.
     Error was
                                            %1!d!."
    IDS_CONFIG_LINK_LOCAL_IP                "Link %1: Local I.P. address is
     %2."
    IDS_CONFIG_LINK_REMOTE_IP               "Link %1: Remote I.P. for this link
     is %2."
    IDS_CONFIG_LINK_SERVER_PORT             "Link %1: The server is listening
     on port
                                            %2!d!."
    IDS_CONFIG_FILE_ERROR                   "Link %1: Error in line %2."
    IDS_SERVER_START_SUCCESS                "Link %1: Server started
     successfully."
    IDS_SERVER_START_FAILURE                "Link %1: Error starting the
     server. This link
                                            will not be able to accept incoming
     data."
    IDS_SERVER_SHUTDOWN_SUCCESS             "Link %1: Server stopped
     successfully."
    IDS_SERVER_SHUTDOWN_FAILURE             "Link %1: Error stopping the
     server."
    IDS_SERVER_SOCKET_CREATE_SUCCESS        "Link %1: Server listening socket
     created
                                            successfully."
    IDS_SERVER_SOCKET_CREATE_FAILURE        "Link %1: Error creating Server
     listening
                                            socket."
    IDS_SERVER_SOCKET_NAME_FAILURE          "Link %1: Server unable to name to
     socket for
                                            client associations. Error was
     %2!d!."
    IDS_SERVER_LISTEN_SUCCESS               "Link %1: Server listening for
     network
                                            ACCEPT and CLOSE messages."

    Monitor Manager API
    Start( );      Starts the monitor manager in a given mode
    Shutdown( );   Stops the monitor manager
    CreateThread( ); Creates a thread with a given stack size, start address,
                   thread ID, thread type, etc.

    Storage Manager API
    Startup( );        Initializes the storage manager
    LoadConfig( );     Loads a file as a database and returns a handle
    CloseConfig( );    Closes a database and saves the data to a file
    Shutdown( );       Shuts down all configuration databases
    SetupSession( );   Starts a session with a database
    EndSession( );     Cancels a session with a database
    GetFirstAddress( ); Retrieves first unique address in database
    GetNextAddress( ); Returns next unique address for any given session
    GetFirstType( );   Retrieves the first type in a configuration for an
     address/type
                       tuple
    GetNextType( );    Retrieves next type in a configuration for the given
     session
    GetFirstService( ); Retrieves the first unique service given an address and
     type
    GetNextService( ); Retrieves the next unique service for a given session
    GetFirstName( );   Retrieves the first name in a configuration for an
                       address/type/service three-tuple
    GetNextName( );    Retrieves the next name for a session
    GetInformation( ); Retrieves info from the specified data point
    SaveInformation( ); Adds the given data to the database at the given data
     point
    DeleteInformation( ); Deletes the specified data point

    Queue & Stream Manager API
    Start( );               Starts the queue and stream manager
    Shutdown( );            Shuts down the queue and stream manager in this
     instance
    CreateObjectBank( );    Creates a new object bank
    DeleteObjectBank( );    Deletes a specified object bank
    CreateObjectQueue( );   Creates an object queue
    ModifyObjectQueue( );   Modifies an existing object queue
    DeleteObjectQueue( );   Deletes a specified object queue
    CreateMediaObject( );   Creates a media object (allocated from an
     appropriate bank)
    LockObjectToPtr( );     Obtains the pointer to the object memory from the
     object
                            handle
    UnlockObject( );        Unlocks the object previously locked w/
     LockObjectToPtr()
    DeleteMediaObject( );   Deletes a media object allocated by
     CreateMediaObject()
    ReallocateMediaObject( ); Reallocates the size of a media object
    BindToInputQueue( );    Binds a given service with input end of a queue
    GetQueueClassType( );   Retrieves the class type of objects associated w/ a
     given queue
    PlaceObjectOnQueue( );  Places a media object on a given queue
    BindToOutputQueue( );   Binds a given service with the output end of a
     queue
    RegisterQueueSemaphore( ); Registers a semaphore object with the output end
     of a queue
    GetObjectFromQueue( );  Retrieves an object from a queue
    UnbindQueue( );         Unbinds a service from a queue
    CreateStreamBuffer( );  Creates a stream buffer with a specified maximum
     size and
                            number of channels
    DestroyStreamBuffer( ); Destroys a given stream buffer
    BindToInputStream( );   Binds a given service to the input of a given
     stream buffer
    BindToOutputStream( );  Binds a given service to the output of a given
     stream buffer
    RegisterStreamEvent( ); Registers a given event with a stream
    AddDataToStream( );     Adds data to a stream buffer
    GetDataFromStream( );   Retrieves data from a stream buffer

    Remote Service Call Manager API
    Start( );                    Starts the RSC manager
    Shutdown( );                 Stops the RSC manager
    Callside_Start( );           Initializes the calling side info for a
     service
    Callside_ProcessObject( );   Used to process a received RSC object at the
     calling
                                 side; returns TRUE if processed
    InitializeCall( );           Sets up a new function call
    AddParameter( );             Adds a parameter to a function
    MakeCall( );                 Makes a function call
    GetStatus( );                Tests the state of a given function call
    WaitMore( );                 Waits for a longer time for completion of a
     function
                                 call
    GetStatusDescription( );     Retrieves any description of an error state
    GetReturnValue( );           Gets a return parameter from a returned
     function
    CloseCall( );                Destroys an outbound call
    ReceiveSide_Start( );        Starts a session for responding to API calls
    ReceiveSide_ProcessMediaObject( ); Used to process an incoming media object
     at the
                                 receive side; returns TRUE if processed
    GetParameter( );             Retrieves a parameter from a function call
    GetSafeParameter( );         Same as above, but exceptions are trapped and
     the
                                 size is set to zero and the data to null
     automatically
    AddReply( );                 Adds a reply to a function call
    ReturnReply( );              Replies to a function call
    CloseReply( );               Closes a reply to a function call

    Terminal/Authentication Module Manager (Link Manager) API
    Start( );               Starts the terminal/authentication module manager
    Stop( );                Stops the terminal/authentication module manager
    Initialize( );          Sets up all terminal services
    AddTerminalService( );  Installs a terminal service DLL (module)
    StartTerminalSession( ); Starts a terminal session of a given terminal
     service
    GetDataFromTerminal( ); Retrieves data to be sent across transmission
     channel to the
                            remote terminal
    GiveDataToTerminal( );  Passes data retrieved from the transmission channel
     to the
                            terminal
    ConvertToChannelData( ); Lets the terminal convert regular data into a form
     to place
                            on the channel
    ConvertFromChannelData( ); Lets the terminal convert channel data back to
     the data
                            buffer originated at the source terminal
    StopTerminalSession( ); Ends a terminal session

    typedef enum
    {
         KTERM_SLAVE,     / / The terminal should wait for
    communication
         KTERM_MASTER     / / The terminal should initiate the protocol
    } KTERM_TYPE;
    typedef enum
    {
         KTERM_NOTIFY_WAITING,       / / The terminal is waiting for
    the other end
         KTERM_NOTIFY_HASDATA,       / / The terminal has data it
    wishes to send over the channel
         KTERM_NOTIFY_AUTHENTICATED,      / / The terminal has
    authenticated the remote terminal
         KTERM_NOTIFY_SECURE,             / / The terminal has
    agreed on an encryption standard for the channel
    (all data should flow through the terminal)
         KTERM_NOTIFY_COMPRESS,           / / The terminal has
    agreed on a compression standard for the channel
    (all data should flow through the terminal)
         KTERM_NOTIFY_NOTAUTHENTICATED,        / / The terminal
    could not authenticate the remote terminal
         KTERM_NOTIFY_DISCONNECT               / / The terminal
    has disconnected from the channel
    } KTERM_NOTIFICATION;

    void DLLEXPORT KTermMan_StartTerminalSession(
         const_TCHAR *terminal_name,  / / The name of the terminal
    service
         const_TCHAR *terminal_address, / / Address of terminal
         KTERM_TYPE  terminal_type, / / Whether the terminal is
    to be the master or slave
         KTERM_HANDLE *terminal_handle  / / Will be filled with
    the handle to this terminal session
         PFN_TERMMAN_CALLBACK callback,     / / The callback to be
    used for notification of important state changes
    LPDWORD   callback_data);

    Encryption Module Manager (Link Manager) API
    Start( );          Starts the encryption module
    Stop( );           Stops the encryption module
    Initialize( );     Sets up all crypto services found in the configuration
     file
    AddCryptoService( ); Installs a crypto service DLL
    EncryptObject( );  Encrypts a media object
    DecryptObject( );  Decrypts an encrypted media object
    DeleteObject( );   Deletes an object created by EncryptObject() or
                       DecryptObject()
    AddPublicKey( );   Adds a public key to the database supported by the
                       encryption type
    RevokeKey( );      Revokes a key

    Compression Module Manager (Link Manager) API
    Start( );          Starts the compression module manager
    Stop( );           Stops the compression module manager
    Initialize( );     Sets up all compression services found in the
     configuration file
    AddCompService( ); Installs a compression service DLL
    CompressObject( ); Compresses a media object
    DecompressObject( ); Decompresses a compressed media object
    DeleteObject( );   Deletes an object created by CompressObject() or
                       DecompressObject()

    Configuration Manager API
    Start( ),                    Starts the configuration manager
    Stop( );                     Stops the configuration manager
    GetVariable( );              Gets a variable defined
    GetFirstService( );          Returns details of first services currently
     active on
                                 this CPR instance
    GetNextService( );           Returns details of next service active on this
     CPR
                                 instance
    PrepareScriptFromServiceObject( ); Prepares a configuration script from a
     running service
                                 and returns the script as a string
    ScriptSetup( );              Configures a new service from a string of
     configuration
                                 information
    ServiceSetup( );             Starts up a service when CPR system is already
                                 running
    ServiceShutdown( );          Shuts down an existing service while CPR
     system
                                 continues to run

    Object Handler API
    StartSession( );          Starts an object handler session; creates a new
     media
                              object
    EndSession( );            Ends an object handler session; deletes the media
     object
    GetObjectData( );         Copies the raw data of the media object to a
     buffer
    CompactObject( );         Compacts the data of the media object; removes
     media
                              marked as deleted
    GetTotalSize( );          Returns the total size of the media object
    Add( );                   Adds a medium to the media object
    Get( );                   Gets a medium from the media object
    Delete( );                Marks a medium in the media object as deleted
    GetFirstName( );          Retrieves the first name of the specified type,
     if present
    SingleShot_GetFirstName( ); Starts a session, retrieves first name of the
     specified type,
                              and closes the session
    GetNextName( );           Retrieves the next name of the current type
    AddName( );               Adds a name of the specified type
    GetFirstAddress( );       Retrieves the first address of the specified type
    SingleShot_GetFirstAddress( ); Starts a session, retrieves the first
     address of the
                              specified type, and closes the session
    GetNextAddress( );        Retrieves the next address of the current type
    AddAddress( );            Adds an address of the specified type
    CompressObject( );        Compresses the media object
    DecompressObject( );      Decompresses the media object
    SignObject( );            Creates a message digest for the media object and
     encrypts
                              that digest using the private key for the source
     service
    CheckSignedObject( );     Tests to see if the media object is signed using
     SignObject