US00537719lA
`.
`5,377,191
`[11] Patent Number:
`[191
`United States Patent
`Farrell et al.
`[45] Date of Patent:
`Dec. 27, 1994
`
`
`OTHER PUBLICATIONS
`’-
`“Operating Systems: Design and Implementation”; An-
`drew S. Tannenbaum; pp. 104-105.
`Proceedings Real-Time Systems Symposium, Dec. 3-5,
`1985; pp. 67-75.
`“Real Time Dist. Control with Async. Message Recep-
`tion” Operating Systems Review; pp. 32—44; An Input-
`/Output Subsystem for the Hawk Operating System
`Kernel; Aug. 10, 1987.
`
`Primary Examz'ner—Douglas W. Olms
`Assistant Examiner——Dang Ton
`
`In a network communication system passing messages
`a
`gateways are interfaced specifically to their respective
`network access units and are interfaced generically to
`the message handling system using routines common to
`all gateways. Messages are sent in protocol data units
`including recipient addresses which. do notidentify
`recipient gateways as such; the gateways are used trans-
`parently. The data format is CCITT I988 X400 stan-
`dard with automatic conversion to and from this format
`at sending and receiving gateways plus automatic docu-
`merit conversion. Message handling involves waiting
`for many services and events. The invention allows
`routines to avoid pending while
`for
`events and services. Service routines, including event
`-
`-
`-
`-
`-
`watching and timer routines, schedule notifications on
`to queues and the main processing task runs notifica-
`15°35 °ff the ‘l“e“°S by calling 3 ‘"11 ‘°“fi“e-
`
`[54] NETWORK COMMUNICATION SYSTEM
`5
`:
`. F
`_
`- -
`_
`.
`[7 ]
`‘(I-Sahgszlne 1:-(I;1]ll’oIf-,hClhaI‘;1gri§ge
`United Kingdom
`
`Inventors
`
`’
`
`_
`
`_
`_
`[731 Asslgneei Data Genflal C0l'P0l‘3t10n: We5tb°1'°a
`M353
`
`[21] App]. No.: 604,696
`
`51
`Int Cl 5
`0
`0
`nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnu
`1
`
`E55 Field of Search
`""
`62 85
`370/85.1, 85.13, 85.14, 85.15, 95.3, 94.3;
`379/202, 93, 94, 96, 112, 114, 168, 219, 220,
`225, 271, 272, 34, 62; 455/9, 115; 340/8255,
`825.02, 825.51; 380/18; 371/3; 395/650;
`364/483, 492
`
`[56]
`
`References Cited
`U_S_ PATENT DOCUMENTS
`
`
`
`3,676,846 7/
`.......................... 200
`3°“ 5;; 3'
`----------------'
`,
`,
`.
`.........
`310
`4,562,550 12/1985 Beam, et al
`364/483
`4,620,283 10/1986 Butt et a1.
`......
`364/493
`1:: 395/650
`4,658,351
`4/1987 Teng
`4,685,125
`8/1987 Zave .... ... ...... ..
`.... ... 379/96
`
`4,734,931
`
`........................ .. 379/93
`3/1988 Bourg et al.
`MASTER
`DOOJENT
`CONVERTER
`
`COMINCATIONS SERVER SYSTEM 10
`
`26‘Claims, 17 Drawing Sheets
`
`PETWORK
`NTERFACES
`BA
`
`CEO
`3
`
`0
`HA
`
`Page 1 of 39
`
`AT&T EXHIBIT 1017
`
`Page 1 of 39
`
`AT&T EXHIBIT 1017
`
`

`
`U.S. Patent
`
`Dec. 27_, 1994
`
`Sheet 1 of 17
`
`11919773.,5
`
`MASTER
`DOCUNENT
`CONVERTER
`
`f_9MJ'1’N_'E&fl9.N§_5§B_"_EB§I§[5MJ2
`
`wMMM
`
`DISOSS
`NETWORK
`
`FIG.
`
`I
`
`Page 2 of 39
`
`Page 2 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 2 of 17
`
`5,377,191
`
`«
`
`,_____ ___1
`
`11,}:
`
`PRINTER
`I/F
`
`.
`
`_
`
`14F
`
`ME
`
`max
`I/F
`
`
`
`I
`TERMINAL SWITCH
`2°
`
`’
`
`FAX
`1/F
`
`I
`
`36
`
`-
`
`LEASED
`
`LINE
`
`E MTIISA }
`;
`:
`L l _3_’*_
`
`I
`
`I J
`
`PDN
`
`'
`
`x25 SWITCH
`
`Ffl 32
`m MV2
`MV3
`
`MV1
`
`Page 3 of 39
`
`Page 3 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 3 of 17
`
`5,377,191
`
` SPECIFIC
`
`
`
` I
`TOOLS GUI ART
`LIBRARY
`
`SOFTWARE INTERFACE
`
`DIRECTORY
`
`ROUTINES
`
`
`
`
`
`MESSAGE
`NETWORK
`TRANSFER
`
`INTERFACE
`INTERFACE
`
`
`45
`
`
`
`ISB
`
`MESSAGING BACKBONE BUS
`
`
`
`MASTER
`DOCUMENT
`CONVERTER
`
`
`
`A H03
`
`
`
`
`DIRECTORY
`
`SERVICE
`
`
`
`
`13A
`
`10
`
`MEs§AgE
`°°”M”?z"§$§T3I“I
`ceé
`SERVE
`FORMAT
`
`
`
`
`I3A
`
`’
`
`10
`
`‘
`
`I
`
`13C
`
`
`
`MESSAGE
`COMMUNICATION
`"A"
`SERVER SYSTEM
`PROFS
`
`
`
` FORMAT
`
`
`
`
`F/0.5
`
`Page 4 of 39
`
`Page 4 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 4 of 17
`
`5,377,191
`
`X400 GATEWAY —12D"
`
`T30
`
`140
`
`44
`
`15A
`
`33?
`
`.
`
`A
`TOOLS
`CHECK VAL.
`
`1984
`x4oo
`
`NETWORK
`
`AND ADDRESSES
`
`TO TOOLS
`
`FROM QUEUE
`
`
`
` SPECIFIC ROUTINES
`1984x400 :—>-198T8><A00
`
`
`
`ADD TRACE INFO .
`
`F/0.7
`
`A
`
`I
`
`-
`
`A
`
`Page 5 of 39
`
`Page 5 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 5 of 17
`
`5,377,191
`
`-I2D-
`
`az.
`
`15A
`
`188
`
`15A
`
`—I2E-
`1.4:
`
`TOOLS
`
`F/0. 9
`
`-12E-
`
`ROUT I NES
`
`SPEC I F I C
`
`TOOLS
`
`cowv. om.
`
`AIS
`
`
`
`
`
`
`SPECIFIC ROUTINES
`GENERATE COPIES
`FORM DIAL NOS.
`COPIES ON QUEUE
`
`
`
`/-'/0.//
`
`Page 6 of 39
`
`
`
`Page 6 of 39
`
`

`
`U.S. Patent
`
`Dec. 27,’ 1994
`
`Sheet 6 of 17
`
`5,377,191
`
`FROM QUEUE
`
`-12E-
`
`
`
`
` WITH
`FAX CARD
`
`GCSP ROUTINESI
`
`USER
`ROUTINE5
`
`GUI
`RQUTINES
`
`CZ] CHE]
`
`CALL
`
`RETURN
`
`AXES
`
`TIME
`
`F/0. 74
`
`Page 7 of 39
`
`Page 7 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 7 of 17
`
`5,377,191
`
`USER
`PROCESSING
`
`
`
`UNPENDED
`REQUEST
`
`
`
`
`
`
`
`130
`
`13‘
`
`REQUEST INITIATED
`
`CHARACTER
`‘RECEIVED
`
`CHARACTER
`RECEIVED
`
`
`
`FURTHER
`USER
`PROCESSING
`
`
`
`
`
`CHARACTER
`‘RECEIVED
`
`
`CHARACTER
`RECEIVED
`
`
`
`
`
`
`
`TTTT"
`NOTIFICATION
`GUI-
`———— "“
`ROUTINE
`SCHEDULE
`
`138
`REQUEST TERMINATES
`
`
`
`I
`'33
`
`H0. /3
`
`T
`P‘
`
`Page 8 of 39
`
`INPUT
`LINE
`COMPLETE
`
`Page 8 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 8 of 17
`
`5,377,191
`
`USER
`MAIN TASK
`
`150
`
`CALL
`
`,
`
`—
`
`EVENT
`HANDLER
`PATH
`
`USER
`PROCESSING
`
`151
`
`CALL
`
`GCSP REQUEST
`
`152
`
`153
`
`156
`
` “
`
` GJF¥RfiR)
`
`INCOMING EVENT“*'
`
`155
`
`‘
`
`157
`
`l§:5EmCE
`
`INTERTASK
`‘MESSAGE
`
`GUI SCHEDULE
`
`158
`
`GCSP
`NOTIFICATION
`
`'59
`
`PENDED
`GUI_RUN()
`
`I
`
`‘55
`
`F/0.75
`
`Page 9 of 39
`
`Page 9 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 9 of 17
`
`5,377,191
`
`USER
`MAIN TASK
`
`‘
`
`'
`
`OTHER
`PATH
`
`USER
`PROCESSING
`
`mcomwe EvE:NT—>
`
`PENDED
`
`G”I—R”N
`
`160
`
`16'
`
`ggggassxwe
`
`’
`
`INTERTASK MESSAGE
`
`GUI_wAKE_UP
`
`162
`
`USER
`PROCESSING
`
`’63
`
`PENDED
`GUI RUN
`
`164
`
`F/0. 76-
`
`Page 10 of 39
`
`Page 10 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 10 of 17
`
`5,377,191
`
`USER
`MAIN TASK
`
`-
`
`EVENT
`HANDLER
`PATH
`
`USER
`PROCESSING
`
`GCSFLREQUEST
`
`no
`
`'7'
`
`INCOMING EVENT ——>
`
`usER
`[DL5
`LOOP
`
`I72
`
`SERVICE
`EVENT
`
`’
`
`'73
`
`INTERTASK
`
`MEssAeE
`
`:74
`
`E —
`
`'I
`
`I
`
`I75
`
`USER
`NOT|F|CATl0N
`
`'75
`
`USER
`IDLE LOOP
`
`Page 11 of 39
`
`Page 11 of 39
`
`

`
`U.S. Patent
`
`Dec.27,1994_
`
`Sheet 11 of 17
`
`5,377,191
`
`
`
`
`---'
`
`Ai
`
`2
`
`3
`
`
`
`Page 12 of 39
`
`
`
`
`
`I
`
`I
`
`185
`
`° GUI_SCHEDULE
`
`180
`
`184
`
`Page 12 of 39
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 12 of 17
`
`5,377,191
`
`GUI_RO0T
`
`--—.-
`
`
`
`
`
`OWNER 2
`Q ANCHOR
`
`OWNER N
`
`o ANCHOR "—"'-
`
`FIG. 79
`
`Page 13 of 39
`
`Page 13 of 39
`
`

`
`HmD
`
`19J,773.,
`
`
`
`
`
`zo=oz<zmzzom:o_>mz¢>mz¢
`
`.X82Wm:mm:.::mS25%vaiE225.._omfimvafimE230
`
`
`v_mE-~m:z_ngazemowBE.._mfizgo2815:...wE322
`
`
`
`
`5.
`
`
`
`_M88mo_,5:mfizzon__5o..5§NWQC
`
`m%:o_,_<52,5:32:32m%Fc
`
`
`
`
`
`
`%_§,_<en:.2E25~_o.._~§a2<k:5QCm_Ezzomo...%
`t___mo9a3P.mSMU
`
`DI
`
`Page 14 of 39
`
`

`
`m
`
`.o/.,m
`
`5
`
`1.919
`
`
`
`
`
`4}momowoxmzm.mmz3opxmzmom.o
`
`_omowzomozhomo
`
`7_omowzomozmmm_m
` 1.I.momommz_ooommommmzmommozmmmoMomowm_mmmoo_ooo_oomomoom>mm
`
`
`
`
`>H_mo_mm»H_mo_mm
`
`
`
`omow>mmmm.mmzmo_>mmm
`
`w .2A
`
`3,mm|.\
`
`eII_om>mmmm.M ommoommommowmomm;oz_:§
`
`o_,:_,_zomw.wmNFo.mS.5Ue
`
`gaD:
`
`NW.9:.\
`
`Page 15 of 39
`
`
`

`
`C
`
`M
`
`0wW...
`
`19la7739
`
`mN92n._$2
`
`mm$~_8<oziz_,_oE5::oz
`
`
`
`moz>mmm>mzm
`
`m22
`
`%eV92QC
`
`
`
`:32m_So9a.3p_.mm8252
`S.mU
`
`P
`
`
`
`
`
`7_2.5«EomowAl.En_..o:mo_,u_5o
`
`5.
`_Ezzono%=o_,_<5230AImznfizsoQC
`
`
`
`Page 16 of 39
`
`
`

`
`U.S. Patent
`
`Dec. 27, 1994
`
`Sheet 16 of 17
`
`5,377,191
`
`MAIN PROCESS
`
`‘
`
`.
`gu1_run
`
`262
`
`264
`
`tpc
`gui-schedu1e()
`
`266
`
`Ce0_mSg_
`
`"
`/9026/4
`
`‘
`
`268
`
`.
`
`B”}88Ls
`PD“
`
`DIRECTORY
`
`SERVER PROCESS
`
`276
`
`IPC f78,»’
`
`pen
`
`280
`
`ocsp
`r€QUeSt
`TO0LS_send()
`
`‘”}85E§T
`DFOCESSTHQ
`
`Directory
`
`LOOKUDS
`
`270
`
`272
`
`
`
`/‘
`
`/
`
`I-53l"'C37'3COCOOOOOO777?77CC:'C,'0‘C1'0
`
`Page17of39
`
`-———————————/
`
`/
`
`Directory
`Compietion
`
`‘\
`
`3
`/
`
`/
`
`Directory
`Completion
`
`Directory
`Comoietion
`
`To FIG 26B
`
`Page 17 of 39
`
`

`
`U.S. Patent"
`
`Dec. 27, 1994
`
`Sheet 17 of 17
`
`5,377,191
`
`From FIG.26A
`
`23h
`
`286
`
`GCSE request
`mti_send()
`
`Network
`Connection
`
`Connected ‘
`I
`
`7
`
`238
`
`290
`
`'
`
`29?
`
`Data confirmed
`
`mtieconnected()
`
`-TOOLS
`data GCCESS
`
`routine
`
`SEND _
`data
`
`TOOLS
`data access
`routine _
`
`SEND
`data
`
`Data confirmed
`——————--.-——----T-—->
`
`TOOLS
`data access
`routine
`
`SEND
`data
`
`Data~confirmed
`
`IPC to network
`
`Interface-
`Message done
`
`mti_send-done()
`
`Page18of39
`
`Page 18 of 39
`
`

`
`1
`
`NETWORK COMMUNICATION SYSTEM
`
`5,377,191
`
`10
`
`15
`
`20
`
`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
`25
`essentially suitable for use by private corporate and
`other large users because they utilize a proprietary mes- _
`sage transfer protocol handled via a central processing
`system which converts from and to the message proto-
`cols 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 sys-
`tem and what are the characteristics of the various
`gateways.
`The known systems are neither intended for not suit-
`able for public services.
`Another problem with which the invention is con-
`cerned 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 ac-
`cording 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 hold-
`ing 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 re-
`sources. 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.
`
`30
`
`35
`
`45
`
`50
`
`55
`
`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 inter-
`changeably herein even although some nodes may not
`by strictest definition be gateways.
`
`65
`
`Page 19 of 39
`
`2
`More specifically the improved system is intended to
`be utilizable by PTTS (postal, telegraph and telephone
`authorities) to provide gateways which may be ac-
`cessed 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 corpora-
`tions 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 of-
`fice automation systems such as CEO (Data General
`Corporation), DISOSS and PROFS (both IBM), etc.
`The gateways or nodes are connected to communi-
`cate 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 imple-
`mented by many users. X400 also exists in a 1988 ver-
`sion (denoted 1988 X400 herein) and it is this system
`which is preferably employed as the “backbone” of the
`inventive network communication system. It is particu-
`larly advantageous that the invention can thus employ
`an accepted, international standard and not introduce
`yet another proprietary message handling system. How-
`ever, 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 ac-
`cess to the access unit or units served by that gateway.
`This is the external, user-specific interface of the gate-
`way. 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 inter-
`face which is identical in all gateways and moreover
`matches the message transfer interface. A library of
`core routines provide communication between the mes-
`sage 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 spe-
`cific 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 inter-
`face 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 back-
`bone
`
`Page 19 of 39
`
`

`
`5,377,191
`
`3
`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_t_he 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 back-
`bone.
`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 con-
`tain any data specific to the gateway serving the mes-
`sage recipient. In accordance with X400 1988, the enve-
`lope part, denoted P1, comprises primarily the origina-
`tor, 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 Pl data and includes a subject title, a docu-
`ment 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 serv-
`ing the message recipient. All messages simply go out
`onto the universal messaging backbone and a gateway
`which recognises a recipient address accepts the mes-
`sage.
`A subsidiary problem resides in the existence of dif-
`ferent document formats. There are various word-proc-
`essing formats in common use, various file formats and
`formats specific to telex and teletex. Further features of 50
`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 con-
`version are known in themselves and may be incorpo-
`rated in the network communication system according
`to the invention.
`
`4
`format, without regard to the document formats accept-
`able to recipients, secure in the knowledge that, if con-
`version is necessary, it will be taken care of automati-
`cally.
`Within the message handling system, such as 1988
`X400, there will be a standard address structure com-
`prising 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 iden-
`tifying 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 identify-
`ing 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 gate-
`ways. Such a directory is indirectly accessible to other
`gateways via the message handling system and the hold-
`ing 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 com-
`puter, MS-DOS on a PC and UNIX on an MV com-
`puter 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—conforfnant
`service
`provider
`(GCSP) the user calls the relevant routine but does not
`wish to wait for its completion. Rather, the user is in-
`formed when the routine is complete by way of a notifi-
`cation 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.
`
`10
`
`15
`
`20
`
`25
`
`'
`
`30
`
`35
`
`45
`
`55
`
`The envelope part of any protocol data unit whose
`message part consist of a document (or part of a docu-
`ment) includes format information identifying the docu-
`ment format. The library of specific routines of each
`gateway includes routines which are responsive to re-
`ceived 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
`
`65
`
`Page 20 of 39
`
`Page 20 of 39
`
`

`
`5
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENT
`
`5,377,191
`
`This description is in four main sections:
`I General system description
`II Network conignunication
`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 de-
`fined by the appended claims. For example, GUI is
`described primarily in conjunction with a communica-
`tions 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 de-
`tailed 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 ap-
`plication.
`
`I GENERAL SYSTEM DESCRIPTION
`
`10
`
`15
`
`20
`
`25
`
`FIG. 1 shows a plurality of nodes or gateways 12 '
`communicating with each other via a universal messag-
`ing 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 auto-H
`mation network 13B
`SNADS gateway 12C for IBM PROFS office auto-
`mation 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 plural-
`ity 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 Communica-
`tions Server (CS) System 10. Each gateway 12 has an
`interface 15A denoted MTI for message transfer inter-
`face and these interfaces communicate via the 1988
`X400 protocol as indicated by a ‘bus’ 15B—which may
`be constituted physically by any form of‘communica-
`tions 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.
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`Page 21 of 39
`
`6
`The physical location of the master document con-
`verter 46 and the directory services 48 is immaterial.
`Structurally, each may comprise a database and a pro-
`cessing 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 conver-
`sion routines, such as are well-known per se in PC pro-
`grams, 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 pro-
`vides 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 net-
`works 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 mim-
`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 comput-
`ers 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 re-
`sources 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 accor-
`dance with the known principles of multi-processor
`systems with one computer acting as master and assign-
`ing the activities of the others and controlling the termi-
`nal 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 pro-
`vision 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 net-
`work) 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 mes-
`sage transfer interface 15A of FIG. 1, forming part of
`the universal messaging backbone 15.
`FIG. 3 is drawn as another block diagram but illus-
`trates 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 communi-
`cations 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 Gam-
`maFax CP/1‘ 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
`
`Page 21 of 39
`
`

`
`5,377,191
`
`7
`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 Gen-
`eral Unpended Interface and is fully described below.
`ART represents ASN.1 (ISO standard) Run Times li-
`brary routines, i.e. routines for encoding data in a for-
`mat
`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.
`
`10
`
`15
`
`20
`
`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 neces-
`sary 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 confir-
`mations, handle the disk saves, submission to the direc-
`tory service and to the document converter and may
`perform other functionsrequired in common by the
`gateways
`The gateway communicates via the messaging back-
`bone 15 with the document converter 46 and with the
`
`25
`
`30
`
`35
`
`8
`The message is checked for validity and the addresses
`of the recipients are checked to ensure that the recipi-
`ents are “within” the network communication system.
`These procedures are well known per se in communica-
`tions networks. The message is then placed on a queue
`of messages to be processed further, indicated at 60. The
`message is acknowledged to the remote (PTT) system
`13D.
`
`FIG. 7: The message was received in 1984 X400
`format and needs to be converted into 1988 X400 which
`is the internal format used_by the system. Trace Infor-
`mation is added in accordance with conventional com-
`munications techniques. This information is used to
`track a message through all the systems which it tra-
`verses. It is used to detect looping messages (they pass
`through the same system twice). The message is then
`passed to TOOLS in the software interface 44.
`FIG. 8: The recipients are looked up in the directory
`service 48 to see which gateways the message should be
`sent to. The originator is checked to see if he is allowed
`to use the network communication system. This use of
`the directory service is conventional per se.
`The new copy of the message is stored away (62) and
`placed on the queues (64) for the other gateways.
`FIG. 9: The message is now transferred to the peer
`TOOLS in the other gateway 10 (in this case Fax). This
`is done using what is referred to as a remote operation,
`meaning that a command (SUBMlT_MESSAGE) and
`some data (in this case the message itself) is transferred.
`A sequence number is also sent over in order to prevent
`duplication of messages.
`The message is thus now in TOOLS 44’ of the FAX
`gateway 12E. In FIGS. 9 to 12 the elements of this
`gateway are distinguished by added primes.
`FIG. 10: The message is stored again (72). The desig-
`nation of the originator is converted (CONV. ORIG.)
`into human readable form for use as a CSID (the string
`that appears at the top of the fax page). More call bar-
`ring checking is done to bar calls which are, according
`to the directory, not permitted to the addressed recipi-
`ent from the call originator iii question.
`_The message is handed to the specific software rou-
`tines 45’ of the fax gateway 12E. All action now takes
`place in the fax gateway 12E.
`FIG. 11: The copies of the message are generated and
`stored (76) one per recipient and the dialled numbers are
`formed. The format of fax addresses that are passed
`around are 9 <country code> <national number>.
`This is converted into a sequence of digits to dial.
`Each copy is now placed on a queue (78) to be sent
`when an outgoing line (fax card) becomes free.
`It will be noted that the message is repeatedly saved
`to disk. This is not a serious overhead because the ma-
`jority of the message is left on disc and the different
`“saves” are effected by constructing pointers to the
`stored message proper. There is some management to
`ensure that, when a copy is ‘deleted’, the stored message
`itself is not deleted until the last user releases it.
`FIG. 12: For each copy of the message, the specific
`routines 45’ wait until a fax card 82 becomes available,
`(signalled as an event), and then transfers the message
`via the fax network interlace unit 80 to the fax access
`
`45
`
`50
`
`55
`
`main directory service 48_. It may optionally include its
`own sub-directory