Network communication system - Patent Review 5377191

What is claimed is:

1. A digital computer system comprising (i) an operating system, (ii) a plurality of routines operable under said operation system, and (iii) a plurality of queues for job data identifying routines to be run, said routines including routines in first, second and third modules, said first module including user routines, said second module including service routines providing services and said third module including interface routines,

said user routines including routines requesting services from said service routines,

said interface routines including a schedule routine callable by each service routine to place job data on a selected one of said queues and a run routine callable by a user routine to cause a notification routine identified by job data on a selected one of said queues to be run, at least some said service routines providing return results for said first module of routines,

wherein, said queues are in sets allocated to a plurality of different owners and wherein each owner can only call said run routine in respect of a queue which that owner owns; and

wherein, following a request to a service routine, processing within said first module can continue without pending for a return result from a service routine.

2. A digital computer system comprising (i) an operating system, (ii) a plurality of routines operable under said operation system, and (iii) a plurality of queues for job data identifying routines to be run, said routines including routines in first, second and third modules, said first module including user routines, said second module including service routines providing services and said third module including interface routines,

said user routines including routines requesting services from said service routines,

said interface routines including a schedule routine callable by each service routine to place job data on a selected one of said queues and a run routine callable by a user routine to cause a notification routine identified by job data on a selected one of said queues to be run, at least some said service routines providing return results for said first module of routines,

wherein each of said queues has a data structure including;

(a) the priority level of the queue,

(b) the identifier for the queue,

(c) pointers to control blocks for the first and last notification routines on the queue, and

(d) pointers to the next and previous queues,

and wherein each control block has a data structure including:

(e) pointers to the next and preceding control blocks,

(f) a pointer to said notification routine, and

(g) arguments to be passes to said notification routine; and

wherein, following a request to a service routine, processing within said first module can continue without pending for a return result from a service routine.

3. A digital computer system according to claim 2, wherein said queues are in sets allocated to a plurality of different owners and wherein each owner can only call said run routine in respect of a queue which that owner owns, and wherein said data structure further includes a plurality of anchor structures, one per owner, and each including:

(h) pointers to the next and preceding owner anchor structures,

(i) a pointer to a stack base,

(j) a plurality of status bits,

(k) a pointer to an identifier for at least one queue owned by that owner.

4. A network communication system including a plurality of gateways for serving respective access units, said gateways being connected to communicate with each other through a message handling system, wherein at least one gateway comprises:

a network interface providing access to the access unit served by that gateway,

a message transfer interface for sending messages to and receiving messages from said message handling system, and

a software interface including a library of routines which provide communication between said message transfer interface and said network interface and process data passing through that gateway to effect at least format conversion,

and wherein said routines in said software interface include routines in first, second and third modules, said first module including user routines, said second module including service routines providing services and said third module including interface routines,

said user routines including routines requesting services from said service routines,

said interface routines including a schedule routine callable by each service routine to place job data on a job data queue and a run routine callable by a user routine to cause a notification routine identified by job data on said queue to be run, at least some said service routines providing return results for said first module of routines,

wherein, following a request to a service routine, processing within said first module can continue without pending for a return result from a service routine.

5. A network communication system according to claim 4, wherein said run routine is callable with a flag indicating whether said run routine is to pend or not pend in the event there is no job data on said queue.

6. A network communication system according to claim 5, wherein said third module further includes a wake-up routine callable by a user routine to signal to said run routine when pended that it should return.

7. A network communication system according to claim 4, wherein at least some of said service routines each takes an argument pointing to one of said notification routines, enabling each user routine to pass a pointer to a selected one of said notification routines to be scheduled on to said queue.

8. A network communication system according to claim 4, wherein there is a plurality of job data queues and said schedule routine takes an argument identifying which queue job data identifying a notification routine is to be placed on.

9. A network communication system according to claim 8, wherein said queues have differing priorities and wherein said run routine runs notification routines in order of priority of their queues.

10. A network communication system according to claim 9, wherein said run routine runs notification routines within a queue in the order in which they were placed on said queue by said schedule routine.

11. A network communication system according to claim 8, wherein said schedule routine takes as arguments said indication of which queue a notification routine is to be placed on, a pointer to said notification routine which is to be placed on said queue and a plurality of arguments for passing to said service routine.

12. A network communication system including a plurality of gateways for serving respective access units, said gateways being connected to communicate with each through a message handling system, wherein at least one said gateway of said plurality of gateways comprises:

a network interface providing access to a selected access units served by that gateway,

a message transfer interface for sending messages to and receiving messages from said message handling system,

a software interface which matches said message transfer interface,

computer means for executing processing routines for handling at least one of messages to be transmitted and received messages,

means storing a plurality of said routines which provide communication between said message transfer interface and said software interface, and means storing a plurality of specific ones of said routines individual to that gateway and providing communication between said network interface and said software interface,

wherein said specific routines convert between the format and protocols of the network interface and the format and protocols of said software interface and wherein communications between said gateways on said message handling system are effected in protocol data units including an envelope part and a message part, said envelope part including data identifying the message originator and non-gateway specific data identifying the message recipient,

wherein said routines include service routines implementing services required during message handling,

and wherein said computer means is operative to execute a main processing task including a plurality of said routines, during execution of a calling routine of said main processing task to call at least one of said service routines, continue with further processing in said main processing task without pending said at least one called calling routine, terminate said service routine and store job data identifying a notification routine, execute a run routine within said main task to cause a notification routine identified by stored job data to be executed.

13. The network communication system of claims 12 wherein said envelope part contains no data which is specific to the gateway serving the message recipient.

14. A network communication system including a plurality of gateways for serving respective access units, said gateways being connected to communicate with each through a message handling system, wherein each gateway of said plurality of gateways comprises:

a network interface providing access to said access units served by that gateway,

a message transfer interface for sending messages to and receiving messages from said message handling system,

a software interface which matches said message transfer interface,

computer means for executing processing routines for handling at least one of messages to be transmitted and received messages,

means storing a plurality of generic ones of said routines which provide communication between said message transfer interface and said software interface, and means storing a plurality of specific ones of that routines individual to said gateway and providing communication between said network interface and said software interface,

wherein said specific routines convert between the format and protocols of the network interface and the format and protocols of said software interface and wherein communications between said gateways on said message handling system are effected in protocol data units including an envelope part and a message part, said envelope part including data identifying the message originator and non-gateway data identifying the message recipient.

15. A network communication system according to claim 14, wherein said message handling system is in accordance with the CCITT X400 Standard.

16. A network communication system according to claim 14, wherein said message handling system is in accordance with the CCITT X400 Standard, 1988 version.

17. A network communication system according to claim 16, wherein one of said gateways includes a network interface to CCITT X400 Standard, 1984 version, user agents.

18. A network communication system according to claim 14, including a document converter accessible by each said gateway and wherein said envelope part of any protocol data unit whose message part consists of at least part of a document includes information identifying the document format, and wherein said plurality of specific routines of each gateway includes routines responsive to received information identifying said document format of a received message to submit said message part automatically to said document converter when said received information identifying said document format identifies a format incompatible with said access units served by the receiving gateway, whereby gateways are free to transmit in any document format without regard to said document formats acceptable to recipients.

19. A network communication system according to claim 14, including at least one directory accessible by each gateway and wherein said routines include (1) routines which submit originating gateway data, said originating gateway data identifying the message originator and the message recipient, to said at least one directory for inclusion in a protocol data unit and (2) routines which submit message originator data and message recipient data from a received protocol data unit to said at least one directory to determine at least said message recipient in the format required by said network interface of that receiving gateway.

20. A network communication system according to claim 19, including a main directory unit holding a directory which is directly accessible by all said gateways on said message handling system.

21. A network communication system according to claim 20, wherein said main directory is a directory in compliance with the CCITT X500 Standard.

22. A network communication system according to claim 19, wherein at least one gateway includes a directory unit holding a directory which is indirectly accessible by said other gateways via said message handling system and said one gateway.

23. The network communication system of claim 14 wherein said envelope part contains no data which is specific to the gateway serving the message recipient.

24. In a network communication system comprising a plurality of gateways for serving respective access units, said gateways being connected to communicate with each through a message handling system, a method of handling messages comprising the steps of: (a) providing each gateway with a network interface providing access to said access units served by that gateway, (b) providing each gateway with a message transfer interface for sending messages to and receiving messages from said message handling system, (c) processing a message entering said network interface by a library of specific routines matched to said access units to provide an intermediate message in a system-standard format, (d) processing said intermediate message by a library of core routines which are substantially the same in all gateways to form at least one protocol data unit including an envelope part and a message part, said envelope part including data identifying the message originator and data identifying the message recipient but no data specific to the gateway serving said message recipient, wherein said library of specific routines converts between the format and protocols of said network interface and the format and protocols of said intermediate message and said library of core routines converts between said format and protocols of said intermediate message and the format and protocols of said message transfer interface, (e) transmitting said at least one protocol data unit on said message handling system via said message transfer interface.

25. A method according to claim 24, further including the steps of:

(f) processing a protocol data unit entering said message transfer interface by said library of core routines to form an intermediate message,

(g) processing said intermediate message by said library of specific routines to form a local message,

(h) transmitting said local message to an access unit via said network interface.

26. A method according to claim 24, wherein said message handling system is in accordance with the CCITT X400 Standard, 1988 version.

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to a network communication system for use in handling communications between access units which may comprise office automation systems, telex, teletex, facsimile, etc.

Abbreviations and acronyms used herein are listed at the end of the description. References to Data General are to Data General Corporation, the assignees of the present application.

2. Description of the Prior Art

There exist today many proprietary communications systems and various international standards relating to message handling and data transmission. Nevertheless there is no system in existence which will allow all kinds of access units to communicate freely with one another.

It is true that there do exist gateway systems, known commercially as Soft-Switch and Mailbus which are intended to allow interchange of messages between dissimilar systems. However these known systems are essentially suitable for use by private corporate and other large users because they utilize a proprietary message transfer protocol handled via a central processing system which converts from and to the message protocols employed by the various gateways. Moreover they are set up as complete systems in which each gateway has to know what other gateways there are on the system and what are the characteristics of the various gateways.

The known systems are neither intended for nor suitable for public services.

Another problem with which the invention is concerned arises in conjunction with computer operating systems (e.g. MS-DOS and UNIX) which are single threaded, i.e. they can handle only a single processing thread at a time. This leads to the result that routines frequently have to wait if the processing path comes to a halt while waiting for an external event. The routine is said to pend. Although other operating systems can handle multiple threads (e.g. AOS/VS) the system according to the invention is desirably not restricted to a particular operating system and should be capable of operating with single threaded operating systems. Some systems, e.g. UNIX can simulate multitasking by holding a plurality of copies of a program in memory and scheduling the allocation of the CPU to the different processes. However this is wasteful of memory resources. MS-DOS has no built-in facilities for achieving even this level of multi-tasking.

In a network communication system waiting for events occurs all the time, e.g. as transfers are effected across interfaces, and single threaded systems lead to inefficient usage of computer resources, for the reasons explained above.

SUMMARY OF THE INVENTION

The object of the present invention is to provide an improved system which will allow access units to utilize gateways or nodes in an unrestrained way, without any knowledge of the nature of the system or of the other gateways or nodes in the system.

The terms "node" and "gateway" are used interchangeably herein even although some nodes may not by strictest definition be gateways.

More specifically the improved system is intended to be utilizable by PTTs (postal, telegraph and telephone authorities) to provide gateways which may be accessed by the respective access units for transparent communication with access units connected to the same system or another system installed by a different PTT.

The improved system is equally suitable for use by other large users such as public and private corporations for example.

Another object of the invention is to avoid the need for routines to pend awaiting external results, even in a single threaded operating system. Such a routine will be called an unpended routine.

The network communication system according to the invention comprises a plurality of gateways or nodes for serving respective access units. For example, one node may serve a facsimile network, another node a telex network, other gateways a plurality of proprietary office automation systems such as CEO (Data General Corporation), DISOSS and PROFS (both IBM), etc.

The gateways or nodes are connected to communicate with each other via a standard message handling system, preferably the CCITT X400 Standard, hereby incorporated by reference. X400 exists in a 1984 version (denoted 1984 X400 herein) which has been implemented by many users. X400 also exists in a 1988 version (denoted 1988 X400 herein) and it is this system which is preferably employed as the "backbone" of the inventive network communication system. It is particularly advantageous that the invention can thus employ an accepted, international standard and not introduce yet another proprietary message handling system. However, since 1988 X400 is not yet widely implemented, it is particularly advantageous to provide as one of the gateways an X400 gateway, which can interface the "backbone" to the somewhat lower-specified 1984 X400.

Each gateway or node of the system according to the invention comprises a network interface providing access to the access unit or units served by that gateway. This is the external, user-specific interface of the gateway. Each gateway moreover comprises an external message transfer interface (MTI) for sending messages to and receiving messages from the standard message handling system, or backbone.

Internally each gateway comprises a software interface which is identical in all gateways and moreover matches the message transfer interface. A library of core routines provide communication between the message transfer interface and the software interface. This library contains the bulk of the gateway software and, since it is the same for all gateways, the invention avoids the heavy expense of developing a lot of software specific to each gateway.

Each gateway further comprises a library of specific routines individual to that gateway and which provide communication between the network interface and the software interface. These routines convert between the format and protocols of the network interface (which are specific to each gateway) on the one hand and the standardised format and protocols of the software interface on the other hand. These node-specific routines represent a much smaller part of the software of each gateway.

Examples of the functions performed by the core routines are as follows:

Assemble and transmit a packet of data to the backbone

Receive and disassemble a packet from the backbone

Look up destination address in a directory

Submit a document to a document format converter

All housekeeping function, such as logging and audit trail, accounting, error handling.

Examples of the functions performed by the specific routines are as follows:

Convert from/to the format specific to the network served by the gateway.

Convert between addresses within the network served by the gateway and within the host backbone.

The communications between the gateways or nodes on the standard message handling system are effected in protocol data units (PDU's). Each PDU comprises--see X--400--an envelope part and a message part. The envelope part includes data identifying the message originator and the message recipient but does not contain any data specific to the gateway serving the message recipient. In accordance with X400 1988, the envelope part, denoted P1, comprises primarily the originator, the destination, message priority and an indication of whether a delivery report is required. The message part, denoted P2, comprises a header, which repeats much of the P1 data and includes a subject title, a document type identifier and the main body of the message.

This is a highly significant feature of the invention because it enables any access unit to send a message to any other access unit without concerning itself in any way with the nature of the receiving gateway. Indeed the originator does not have to know that any gateways are involved. The system according to the invention is completely transparent to its users and can be installed by PTTs to enhance greatly their message handling capabilities in a way which requires no action on the part of end users. What is more the system does not have to be reconfigured when a gateway is added or removed. Of course, users have to know the addresses with which they wish to communicate but the fact that they are on various gateways does not have to be known. This is because the envelope part of each PDU does not contain any data specific to the gateway serving the message recipient. All messages simply go out onto the universal messaging backbone and a gateway which recognises a recipient address accepts the message.

A subsidiary problem resides in the existence of different document formats. There are various word-processing formats in common use, various file formats and formats specific to telex and teletex. Further features of the invention relieve an originating access unit of any need to worry about the format details of the message recipient (although common sense must naturally be employed--it is no use expecting a highly formatted word-processing file to be handled satisfactorily by a telex recipient). Document converters for format conversion are known in themselves and may be incorporated in the network communication system according to the invention.

The envelope part of any protocol data unit whose message part consist of a document (or part of a document) includes format information identifying the document format. The library of specific routines of each gateway includes routines which are responsive to received format information to submit the message part automatically to the document converter when the format information identifies an incompatible format. Gateways are thus free to transmit in any document format, without regard to the document formats acceptable to recipients, secure in the knowledge that, if conversion is necessary, it will be taken care of automatically.

Within the message handling system, such as 1988 X400, there will be a standard address structure comprising many parts for identifying message originators and recipients. Most network interfaces will employ different address formats of much more restricted range. It is accordingly preferred to provide at least one directory accessible to each gateway via the message handling system. The library routines include routines which submit data identifying the message originator and message recipient at an originating gateway to the directory or directories. This is used to determine identifying data in a standard form (in accordance with the message handling system) for inclusion in the envelope part of the PDU. Further routines submit the identifying data in the envelope part of a received PDU to the directory or directories in order to determine at least the message recipient in the form which is required by the network interface of the receiving gateway.

Preferably the system comprises a main directory unit holding a directory which is directly accessible by all the gateways on the message handling system. This directory may be in compliance with the CCITT X500 Standard. However one or more subsidiary directories may be held in directory units within individual gateways. Such a directory is indirectly accessible to other gateways via the message handling system and the holding gateway.

The invention further comprises, as part of the core routines, an interface which can operate with different operating systems (such as AOS/VS on an MV computer, MS-DOS on a PC and UNIX on an MV computer or other hardware). The interface is referred to as a General Unpended Interface, GUI. Under GUI, when a routine wishes to make a request of a service provider, specifically a GUI-conformant service provider (GCSP) the user calls the relevant routine but does not wish to wait for its completion. Rather, the user is informed when the routine is complete by way of a notification routine. In the meantime the user can carry on with other processing.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the overall system,

FIG. 2 is a block diagram of the hardware of one gateway of the system,

FIG. 3 is a functional block diagram of one gateway of the system,

FIGS. 4 and 5 illustrate the transfer of a message between two different networks,

FIGS. 6 to 12 show the steps in handling a message in more detail,

FIG. 13 illustrates performance of two concurrent tasks under GUI (general unpended interface),

FIG. 14 shows a key to FIGS. 15, 16 and 17,

FIGS. 15 to 17 show the flow of routines under GUI,

FIG. 18 shows the structure of a GUI,

FIG. 19 shows a job queue structure for a GUI,

FIGS. 20 to 25 show various GUI data structures, and

FIGS. 26A and 26B show an example of usage of GUI within the communications server network.

DESCRIPTION OF THE PREFERRED EMBODIMENT

This description is in four main sections:

I General system description

II Network communication

III General unpended interface

IV Abbreviations and acronyms

It is emphasised that the whole of the description is given by way example and the invention is not limited by any of the features disclosed, except insofar as defined by the appended claims. For example, GUI is described primarily in conjunction with a communications server system but it is not limited to this particular application. The GUI routines do not necessarily have the structure described. The organisation of the routines of the communications server system offers infinite possibilities for variation, and so on. Moreover the detailed coding of the routines and indeed the language in which they are coded are a matter of choice for the programmer implementing the invention within the context of particular hardware and for a particular application.

I GENERAL SYSTEM DESCRIPTION

FIG. 1 shows a plurality of nodes or gateways 12 communicating with each other via a universal messaging backbone 15 using the 1988 X400 protocol and, at least in part, the X25 packet switched message transfer protocol (although each gateway may use other media for part of its communication path, e.g. land lines). FIG. 1 shows eight gateways by way of example; there is in principle no restriction on the number of gateways. Examples of the gateways are:

CEO gateway 12A for the Data General CEO office automation network 13A

SNADS gateway 12B for IBM DISOSS office automation network 13B

SNADS gateway 12C for IBM PROFS office automation network 13C

X400 gateway 12D for 1984 X400 communication with X400 network 13D

Fax/telex gateways 12E for communication with fax and telex networks 13E, F

Each gateway is connected to its network through a standard interface or access unit 14A-14F. For clarity, each gateway is shown dedicated to a single network and indeed such a configuration may well be adopted in practice, at least so far as some gateways are concerned. On the other hand, a single gateway may serve a plurality of different access units. FIG. 2 described below is a combined fax/telex (telefax) gateway and, as another example, a gateway may be both a CEO gateway and a fax/telex gateway. This requires the gateway to have both the necessary interfaces and also the necessary specific routines for each type of access unit.

The overall system in FIG. 1 is denoted Communications Server (CS) System 10. Each gateway 12 has an interface 15A denoted MTI for message transfer interface and these interfaces communicate via the 1988 X400 protocol as indicated by a `bus` 15B--which may be constituted physically by any form of communications links. The interfaces 15A and `bus` 15B constitute the messaging backbone 15. The `bus` 15B also provides communication with directory services 48 and a master document converter 46. These services, coupled with the messaging backbone 15 itself may be regarded as the host 10A of the communications server system 10.

The physical location of the master document converter 46 and the directory services 48 is immaterial. Structurally, each may comprise a database and a processing facility and each may thus be physically located in one of the gateways 12 or in a dedicated gateway. The master document converter 46 implements conversion routines, such as are well known per se in PC programs, as well as in more sophisticated applications software. The directory services 48 database may be, as already stated, in compliance with the CCITT X500 Standard, hereby incorporated by reference and provides standard database facilities for querying and searching directory entries as well as adding, amending and deleting entries.

FIG. 2 shows the overall hardware configuration of a typical gateway, which interfaces to a plurality of networks and devices. A combined telex/fax (telematic) gateway 13E,F is chosen as the illustrated example. It is assumed that a plurality of computers are required to handle the volume of processing and the embodiment shown comprises three Data General MV series mini-computers MV1, MV2, MV3, each with an associated disk drive D1, D2, D3 storing the respective computer programs. The computers are connected by a high speed LAN 16, such as a standard (thick) Ethernet LAN or an MRC bus carrying 400 Mb/s. The computers are further connected via a disk controller 18 to a bank of disk drives D4 to D8 (for example) constituting a disk farm 22 for molding the user data.

The computers are connected via a terminal switch 20 to a plurality of interfaces here shown as a telex interface 14F, a fax interface 14E and a printer interface 14P. The terminal switch 20 enables the various access units to share the computer resources and moreover enables two good computers to be used when one is down and generally makes it possible to use the resources in a flexible manner. In principle the invention does not require a plurality of computers and the way in which a plurality of computers is used forms no part of the invention. Briefly they will be handled in accordance with the known principles of multi-processor systems with one computer acting as master and assigning the activities of the others and controlling the terminal switch 20 and an X25 switch 32 so that the correct computer communicates with the correct interface for each input/output operation performed, also with provision for a different computer to take over as master under fault conditions. In a simpler system, there will be one computer and the terminal switch 20 will not be required.

Each computer moreover has a connection to the X25 switch 32 connected to a PDN (public data network) interface 34 and possibly also to a leased line 36, one use for which would be a direct connection to another gateway. The interface 34 implements the message transfer interface 15A of FIG. 1, forming part of the universal messaging backbone 15.

FIG. 3 is drawn as another block diagram but illustrates the configuration of a gateway in functional terms rather than hardware terms. If the gateway is again assumed by way of example to be a telematic gateway serving telex and fax, the actual telex and fax communications will be handled by standard items with which the present invention is not concerned, e.g. a Hasler telex unit and a PC with a fax card, such as a GammaFax CP/T card. These standard items communicate with a network interface 14 which acts as one port of the gateway and may comprise plural interfaces, as in FIG. 2. Similarly, the network interface 14 might be matched to a CEO network, a PROFS network, and so on. The message transfer interface 15A forms a second port communicating with the messaging backbone bus 15B.

The interfaces 14 and 15A are linked by a software interface 44 which is identical in all gateways. This interface 44 comprises a library of core routines which provide communication between the message transfer interlace 15A and the software interface 44. Although this core library could be and is always functionally equivalent to a single library it may, for convenience, be handled as a plurality of separately maintained libraries. In the present embodiment these comprise libraries denoted TOOLS, GUI, ART. GUI represents a General Unpended Interface and is fully described below. ART represents ASN.1 (ISO standard) Run Times library routines, i.e. routines for encoding data in a format in accordance with the ISO ASN.1 standard, hereby incorporated by reference. These routines are used by TOOLS to build PDUs, specifically 1988 X400 PDUs.

The non-specific software interface 44 is matched to the network interface 14 by a library of specific routines 45. The specific routines comprise the routines necessary at higher level to control the flow of messages, in accordance with the nature of the gateway which they serve. TOOLS on the other hand provides "tools" or services common to all gateways. More specifically TOOLS routines impose the X400 1988 format on the PDUs constructed by ART,send the messages, receive message confirmations, receive messages, send confirmations, handle the disk saves, submission to the directory service and to the document converter and may perform other functions required in common by the gateways

The gateway communicates via the messaging backbone 15 with the document converter 46 and with the main directory service 48. It may optionally include its own sub-directory library 49.

II NETWORK COMMUNICATION

When a user on one network sends a message "A" via the corresponding gateway to a user on a different network via the gateway corresponding thereto, the network communication system 10 converts the message from the specific format of the source network, here assumed to be CEO, to the different specific format of the destination network, here assumed to be PROFS. FIG. 4 shows the CEO network 13A sending message "A" in CEO format to the system 10. Then (FIG. 5) the system 10 converts the message to PROFS (SNADS) format and sends it to the PROFS network 52.

This process typically involves address translation, handled by the directory service 48, protocol conversion, handled by the specific routines 45, and document format conversion handled by the document converter 46. A second example will now be described in more detail. In this example the scenario is that of a message arriving from an external 1984 X400 network (say one provided by a PTT) and leaving via a fax card into the telephone network.

FIG. 6: The X400 network 13D opens a connection to the 1984 X400 gateway 12D. It transfers the message from the PTT network to the X400 gateway 12D. The message is then saved on to disk, namely in the disk farm 22, as indicated at 58, (so that even if the system crashes, the message will not be lost).

The message is checked for validity and the addresses of the recipients are checked to ensure that the recipients are "within" the netw