CA2174773A1 - Application programming interface system and technique - Google Patents

Abstract

A novel method of and system for heterogeneous connectivity and universal and generic interfacing for distributed applications and processes residing in a wide variety of computing platforms communicating over varied transport facilities, through an integrated set of lower-level programs and routines that handle specific services (message/data recovery, security, directory services etc.) available from applications and processes within varied complex computing and communications environments, and without having to deal with the idiosyncarsies of differing networks protocols devices multiple "standards", routing, recovery and other transport difficulties and differences. This is effected by novel single-function software modules or verbs, called application programming interface (API), that together provide a consistent and universal interface through which application programs/processes can access the messaging communications services in a manner that isolates the applications and processes from the confusing and fast-changing communications environment, as well as from differences in various computer operating systems, platforms and hardware.

Description

2 1 7 ~ 7 7 3 PCT/IB94/00322 APPLICATION PROGRAMMING INTERFACE SYSTEM AND TECHNIQUE

The present invention relates to electronic mess~ging systems and techniques for providing mess~ing services between applications and processes, being more particularly concerned with providing a universal or generic approach for interfacing distributed applications and processes residing in a wide variety of 5 computing platforms, and enabling communicating over one or mol e transpolt facilities as desired -- providing for use within a multi-media, multi-platform and multi-network con~ lin~ and communications environment.

Back~Tound of the Invention Though tlle term "electronic messsaging" has come often to be inte~ et~d as synonymous Witll "electronic mail", in the context of the present invention and this application, the term "mess~gil~g" is used in a much broader sense enco~npassing also any type of content; namely, the encapsulation of any data 5 objects -- text, graphics, data, digitized voice or image or tlle like -- together with delive~ tili7~tion and identification information that SUBSTITUTE SHEET (RULE 26) WO9SIllS60 2 ~ ~773 -2- PCT~B94/00322 is needed to produce at each Einal destination, those activities specified by the encapsulated content.

Heretofore, individual and specially tailored soft-ware has been required for interworking and integrating distributed applications and processess and linking stand alone applications. The diEferent computer platforms hnve required diferently designed data/message transfer treat-ment and linking programs and processes running in a variety of environments and with a variety of communica-tions types or media, all specifically tailored to the particular equipment networks and protocols -- and each being restricted to and useful for its environment only.

Underlying the present Lnvention is the surprising discovery that despite such wide and often disparate variety of equipments, networks, protocols, platforms and communications techniques and environments, each requiring its intividualized treatment, there can be a universality or generic approach to the programmatic interfacing or SUBSTITUTE SHEET (RULE 26) WO9Sl11560 2 1 74 ~ 7 3 PCT~B94/00322 underlying message/data transport and recovery services that can indeed provide consistent, seamless and trans-parent connectivity betweeen applications and for pro-cesses residing in widely different computer platforms linked by a variety oE different networks and protocols.
This Ls referred to herein as heterogeneous connectivity for dlstributed applications and processes, witll the elec-tronics messaging systems concept of the invention being referred to as "EMS".
The highly novel approach of the present invention to attain this seemingly impossible task resides, in part, in an Integrated set of software lower-level programs and routines that handle specific services - message/data re-covery, security, directory services, etc., available from 15 applications and processes within varied complex computing and communications environment3, and without having to deal with the idLosynchrasies of differing networks, protocols, devices, multiple 'standards", routing, recovery and other transport difficulties and differ-20 ences. This is effected in EMS, by isolating applicationsand processes from the increasingly confusing and fast-changing communications environment. as well as from differences in varying computer operating systems, and platforms and hardware.

SUBSTITUTE SHEET (RULE 26) WO95/llS60 ~¦ ~ 4 7 13 PCT~B94/00322 The inherent problems underlying implementing communications programs between computer systems, make Lt very difficult to handle all of the idiosynchrasies of different hardware, operating environments, protocols, an-l 5 networks. Maintaining appropriate so~tware as operating systems are upgraded and new communications features come to market is nearly impossible - especially when communl-cations are embedded in application programs.
To obviate these di~ficulties, EMS has undertaken to 10provide:

a) message/data queuing and communications ser-vices separated from application proFrams and processes;
b) specifics of hardware and operating environment handled completely and transparently by the communications services facility; and c) stable, consistent interface between applications and the communications environment that does not change every time a networ~ or computing platform Ls added, changed or removed.

SuBsTlTuTE SHEET ~R~It~R\

2 1 747~3 WO95/llS60 - PCTAB94/00322 The invention achieves a ~olution to this increasing-ly common, complex and costly problem through insulating both the developer and the user From the vagueries of the communications facilites and networks and from the speci-fics of the operating environment and hardware. EMS alsoprovides access to the widest variety of communication facilities. In addition, EMS tracks the status of a message, and, depending on the facilites on the receiving side, can guatantee delivery to the destination applica-10 tion.
Through the novel approach of the EMS techaique, amiddleware toolkit i8 provided consisting of a programma-tic interface and underlying message/data transport and recovery services that together provide the before-15 described consistent, seamless and transparent connecti-vity between applications and/or processes that reside in different computer platforms linked by different networks and protocols. The term "middleware" is used to connote a layer of soft~are located between the networks, protocols 20 and transport facilities available on a computing plat-form, and the applications or processes that require transport of messages and data to and from applications and processes on different computing platforms. The SUBSTITUTE SHEET (RULE 26) W095/11560 2 ~ ~ 4 7 7 ~ PCTAB94100322 inte~rated set of lower-level programs and routines that handle specific services-mefisage/data recovery, security, directory services - within a complex computing and communications environment and that constitutes the "tool kit", enable Guaranteed data/message transfer - managing the transmission and recelpt of messages and data so as to ensure absolutely that these are received by the intended destination;

Most communications media supported - types of communication; media supported range from asynchro-nous dial-up modem communications to wireles3 RF ser-vices, such as ARDIS and RAM. Where there is a choice of media to use, RMS assists in deciding wllicl one to employ.

Most popular computing platforms supported- EMS
software runs on most of the popular computing platforms to enable developers to link programs and processes tunning in a variety of environments.

SUBSTITUTE SHEET (RULE 261 WO95/llS60 2 ~ 7 ~ 7 ~ 3 PCTAB94/00322 Present day data communication systems mandate one type of protocol to get all the data across. The present lnvention, on the other hand, provides a scheme at the communication layer that allows for the management o mul-tiple communication facilities simultaneously. Upon 1O8-ing one communication facility type, another communication facility type can be picked up to continue the sending of information. A management facility that manages what is called communication agents, attached to each type of com-lO municationg facility, recognizes when and what is avail-able to be able to transmit data. It takes a packet of information, regardless of whetller it all belongs to one message or is in dLferent messages, stages it for delivery, and llands it off to tl-e proper co~municstion 15 port that is available at that point in time, moving the data through in a continuous pipe or stream. By segment-ing the message into logical units of data related to one another by headers, if a communications facility, (for example TCPIP) is lost after one segment is sent, any 20 other routes or communicatlon facilities avaiiable to the environment are identified, and the next piece oE data SUBYITUTE SHEET ~UL~ 26~

WO95/11560 2 1 7 4 7 7 3 PCT~B94/00322 will accordingly be sent along such, following preset guide-lines. An upper layer protocol recognizes that data is related, but that it has been fragmented, sometimes oddly. It must be interperted, extracted and fitted together. Just as wllen analyzing proteins in genetlcs, when fracturing, it is desired to know what is missing from the chain so as to rebuild the chain to create the gene. In similar fashion,in acccordance with the inven-tion, a piece of missing data that fits in somewhere lO within the data chain can be requested by the receiving end from the transmiting end, no matter what the protocol that is being used, enabling interdisbursement of the movement of information or packets that belong to a single unified piece of inf~rmation -- and across ~ultiple paths 15 and communication types, from end to end, and without the application having to know anything about the communica-tlons facLlities. Additionally, the present invention can run on multiple operating systems with exactly tlle same interface being presented to the application or the 20 process or the user of the system. All of the specific devices, communicstions facillties and memory management are llidden from the usersj providing a novel minimal consistent communication environment sitting on top of the operating system and facility.

SUBSTITUTE SHEET (RULE 26) ~ WO95/11560 2 ~ 74 773 PCT~B94/00322 Ob~ects of Inventlon .

~ n object of the present invention, accordingly, is to provide a new and improved method o~ and system or apparatus and controlling software for electronic messag-ing that provides heterogeneous connectivity and a measure of universal or generic interfacing for distrlbuted appli-cstions and processes re~iding ln a w~de variety of different computing platforms, communicating over one or l0 more different tran~port facilities.
A further object 18 to provide such univer~al connec-tivity through the technique of isolating applications and processes from the communication~ environment with an lntegrated set of lower-level programs and routines that 15 handle specific servlces-message/data recovery, security, directory services, etc. - within complex computing and communications environments wLthout dealing with the idLo-syncro~Les of differlng networks, protocols, devices, mul-tiple 'standards", routing, recovery and other transport 20 prOblems-Other and further ob~ect~ will be explained herein-after and are more particularly delineated in the appended claims.

SUBSTITUTE SHEET (RULE 26) WO9S/11560 ~ 7 ~ ~ ~ 3 - i PCT~B94/00322 --1 o--Summary In summary, however, from one of its broader aspects, the invention embraces a method of electronically me~sag-ing between computers by heterogeneously and universaLlyinterfacing distributed applications and processes resid-ing in a wide variety of differing computer platforms and communications transport facilities of various types, that comprises, providing a set of single-function software lO modules controlled by a preselected set of verbs that together provide a consistent application programming interface between the application/process and the communi-cations facility and through which application programs/
processes can access the electronic messaging; under the 15 control of the set of module verbs, first queuing and routing messages and data flowing from and to the sending and receiving computer applications/processe~ and monitor-Lng the delivery status thereof, and then c~municst~ng the routed messages snd data through a communication agent 20 for each communication transport facility; and providing common messaging functions for all communication agents independently of and without user concern for the speci-fics of the various communications facilities and their characteristics.
Preferred and best mode designs and details of system construction and operation and modified form6 thereof are 1ater presented.

SUBSTITUTE SHEET (RllLE 26) WO95/11560 PCT~B94/00322 2 1 714 ~ 7 3 Drawing 8 The invention will now be described with reference to the accompanying drawings, Fig. 1 of whlchis a block dia-gram schematically illustratlng tlle EMS messaging servicesand functions ln accordance with a preferred embodiment oE
the invention;
Fig. 7 is a similar diagram illustrating the messag-ing system of the invention within a communications environment;
Fig. 3 is a messaging process diagram tracing from (1) start-up and initialization of the E~S systems, through (2) sending messages, (3) checking status, and (4) receiving messages;
Fig. 4 is a diagram similar to Fig. 2, but sllowing the message header (EMH~, router control block (RCB) and interface control block (ICB) locations;
Flg. 5 is a bl~ck diagram showing the sending -receiver computer messaging tllrougll a network or other transport facility;
Fig. 6 is a combined apparatus and flow diagram lllustrating tlle outgoing messaging process and steps;

SUBSTITUTE SHEET (RUEE 26) WO95/11560 2 1 7 ~ 7 7 3 PCTAB94/00322 Fig. 7 is a similar diagram of the incoming message processing;
Figs. 8 through 17 are operational flow charts of steps carried out by the software in effectuating the API
control verbs COMMIT, DELETE, FREEBUF, GETBUF, INITIALI%E, PURGE, RECEIVE, SEND, STATUS and TER~IINATE, respectively;
and Fig. 18 is a chart summarizing the current hetero-geneous connectivity features of the present construction Of the invention for a variety of existing commercial platforms and communication protocol/ network systems.

Description of Preferred Embodiment(s) of Invention It is now in order to describe how the novel resuLts of the present invention are attained in integrating into each application that will use EHS messaging services three main steps. First, designing a messaging user interEace to each particular application/process that satisfies the requirements of its users, and *hich deter-mines how the particular programs will utilize EMS messag-ing capabilities. SecondLy, integrating EMS into each application/process using EMS automatic programming lnter-SUBSTITUTE SHEET (RULE 26) WO95/11560 ~ 1 74 7 73 PCTnB94/00322 face (API) verbs. In general this requires only the loading o a data buffer with message and message processing instructions and calling the appropriate verb with linking procedure on the particular platform providing access to the EMS automatic programming interface API verbs. Thirdly configuring and testing EMS using appropriate testing guidelines. In general the manner in which EMS is used will be the same across all platforms and environments differing only where lO platform requirements make such differences unavoidable.
The technique or method underlying the invention provides all of the tools needed for intelligent delivery of data between applications and processes by a simpie consistent programmatic interface rather than 15 dozens of network protocol and device complexities. If communicating applications or processes change from mainframe to a Unix box no change is required for applications and processes. EMS simply uses the change ln address to redirect data and messages through the new set 20 of interfaces.

SUBSTITUTE SHE~T rRlJEE 26~

WO95/llS60 PCTAB94/00322 2~ 7~7-7~ 4 A full range of queuing, communications and related services are accessible through ~MS, but these can be selected and used onLy as needed. In each computing environment, the EMS API calls remain the same, so that no 5 changes to the calls are required when migrating from one platform to another. The invention, moreover, supports mort o~ the ma~or wireless 8ervi.ce8, medis and protocols as well as those on wireline networks, allowing developer~
to use EMS as a tool for integrating applications and pro-cesses that communicate across multiple networks.
More specifically, EMS provides a single, consistentprogrammatic interface to access the queuing, communica-tion and related services for multiple external and internal communication networks, protocols and transport 5facillties. Neither the user nor the application develop-er needs to be concerned with the specifics of various communications and networ~ protocols and the characteris-tics of hardware devices. EMS, indeed, supports both wireline (dial-up, dedicated line, and LAN) and wireless 20(radio frequency -- RF and cellular) connection devices.
These interfaces may be internal to the user organization or to public or private networks. Communication among SUBSTITUTE SHEET (RULE 26) WO95111560 2 1 ~ 3 PCTAB94/00322 processes on the same computer are always supported. The communications interfaces, moreover, may be installed in any combination for which they are available in that environmen~, supported by the hardware and operating system, and providing a unique commmon message switching application across this breadth of operating environ-ments. EMS automatically selects the proper communica-tions medium to use, although the user may override the default section. In either case, EMS takes care of all lO the message and network-level protocols on behalf of the user and/or application, providing transparent communica-tions selection and operation.
As before stated, tl1e invention handles both outgoing and incoming queuing of data or messages on behalf of tlte 15 application or process. This means that the user does not have to wait for a communications mechanism or facility to become available to send data or messages. Slmilarly, data/messages can be received in background while this or other applications and processes are running. As appro-20 priate, both memory and disk queuing are supported toprovide for automatic restart.
EMS, furthermore, is configured at installation time SUBSTITUTE SHEET (RULE 261 WO95/11560 2 ~ 3 PCT~B94/00322 with various defaults. It may be reconfigured at any time without shutting down either the application or process or E~IS itself.
Referring to Fig. 1, EMS is shown installed in a simple system with two different environments I & II
communicating across three separate network/protocol facilities 1, 1' and 1". The basic internal structure of EMS, interfacing multiple spplications or procesBes ~ 80 labelled, and various communications facilities A,B and C, 10 is shown comprising multi-media messaging, multi-network protocol, security services, full recovery, multi-plat-forms, directory services, guaranteed delivery, encryp-tion/decryption and compression functlons, later more fully described.
As previously mentioned, the EMS for each environment consists of a set of toolkit modules tailored specifically for that environment. As more particularly shown in Fig.
Z, the basic EMS mo~ules are the following:
Application Programming Interface labelled (AP~) - a 20 set of single-function software modules, or verbs, that together provide a consistent interface through which application programs/processes can access the EMS communi-cations services.

SUBSTITUTE SHEET (RULE 26) ~ WO95/11560 2 1 7 ~ 7 7 3 PCT~B94/00322 Queue ~2anager/Router ('Queues /"Router"~ - ~tages messages and data flowing to and from the applicationtprocess and monitors the delivery status of each.
5 Communication Agents ("Comm. Agent" or "CA") - one for each different network, protocol or communication transport facility. (sllown as "Communication Network" "A"
"B" & "C").
Communication ~lanager ("Comm. Manager" or "CM") -lO provides common messagLng functions Eor all the communica-tions agent present.
Configuration Manager ("Config. Mgr." or "CFM") -supports dynamic reconflguration of EMS; automates the decisions for which communication medium and port to use 15 and monitors availability of communications facilities.
Configuration Utility ("Config.") - as~ists in soft-ware set-up and installation.
User Status Utility ("USU") - allows the u~er to view queues 8Q~ oti1er status. U~er CollEiguration Utilit~
("UCU") - allows user to manage available communications resources.
Any number of nodes may be linked by communications net-works and facilities using the EMS of the invention.
Considering, now, each of these modules in more - 25 detail, the application programming interface API, as before stated, consists of a set of verbs provided as callable routines ~or user programs. There are preferably SUBSTITUTE SHEET (RULE 26~

WO95/llS60 2 1 ~ ~ 7 ~3 PCTAB94/00322 three basic verbs in the API corresponding to the three main functions required to handle message transfer and receipt:

SEND
RECEIVE
COMMIT

The function of the COMMIT verb ls to finalize the message 10 receive process once all segments of the message have been confirmed as received by the destination EMS.
In addition, four message utility verbs are provided to help manage messages and message queues:

PURGE
DELETE
STATE
S TATU S .

20 A final set of four environment utility verbs handle e~sential functions related to resource allocation and deallocation:

INIT
TERM
G E T B U F
FREEBUF

Together, these few verbs are able to provide a powerful, 30 flexible and consistent programmatic interface across multiple environments.

SllBSTITUTE SHEET (RULF 263 WO95/11560 2 1 7 ~ 7 7 3 PCT~B94/00322 The Router of Figs. 2 and 4 is a background process which runs in support of API calls for data and message transmission, delivery and status, and as a server for the User Status Utility. The Router manages both disk-based and memory-based queues (for outgoing and incoming data/
messages) and sets event flags, depending on the environ-ment, to notify applications of message status changes.
It also manages timed events for messages in progress, again depending upon the environment.
On startup, it rebuilds its queues from the disk, based save files. On shutdown, it stores messages whicll have not been completed and which have been designated as saveable to the disk save files.
For incoming messages, if the application for the 15 designated user is not active, the EMS Router may request the EMS Configuration Manager CMF to start the applica-tion process so that the incoming message can be deliver-ed.
Each Commnnication Agent (CA), Fig. 2, is specific to 20 the communications hardware and network to which it will attach and to the particular EMS operating environment.
Ench CA is structured in similar manner to handle the SUBSTITUTE SI~EET (RULE 26) WO9S/11560 2 1 7 4 7 7 3 PCT~B94/00322 line, RF device or other transport facility. On the EMS
side, it passes messages to and Erom the Communications Manager (CM). Each CA, moreover, may operate as a driver or as an independent process, depending on the operating 5 environment.
As for the Communications Manager (CM), this comp-onent provides a set of common routines or independent processes used by all of the communicatLon agent~. The CM
strips or adds any required control data for the environ-l0ment to the received message (may contain network controldata and message contents). The CM, furthermore, may be an independent process or a library (i.e. a Dynamic Link Library -- DLL) depending on the env~ronment in which EMS
is installed.
The User Configuration Utility (UCU) of Fig. 2 pro-vides an environment-specific process for the person main-taining EMS to install and maintain the various parameters EMS employs to manage the communication resources svail-able. UCU is run as a majnr part of the installation 20 procedure to provlde the initial defaults to the system.
It may then be run on demand to up-date the defaults and to introduce new facilities and routing.

SlJBSTITUTE SHEET (RULE 263 ~ WO95/11560 _ 1 2 1 ~ ~ 7 7 3 PCT~B94/00322 Lastly, Configuration ~lanager (CFM) is a background process (or common library routines, depending on the platform) which runs in support oE the Router, the User Status Utility (USU), and the User Configuration Utility (UCU). The CFM accesses configuration file(s)to determine service and communication agent to use for the delivery of a message, and other default parameters. It is also a server process for the environment-specific user utili-ties. The CFM, indeed, is the 'start up' process for EMS, lO starting up all of the other background processes in the correct order, as well as the appropriate communication agents according to conflguration defaults, It is next in order to examine the message flow through the EMS of the invention. Fig. 3 traces the messa-15 ging process start-up and in~tialization, to the sending of the message, the checking of status, and the message receipt.
EMS handles alL communications between applications or processes using this message-based datagram approach.
20 An EMS message, as before explained, may be a short text string, a large data file, or a megabyte or more of a multi-media message (text, data, graphics, images, voice SUBSTITUTE SHEET (RULE 26) WO9S/11560 2 ~ 7 ~ 7 ~ 3 PCT~B~ 03~2 -2~-and even video). Long messages are segmented by EMS at the destinatlon. Segment length for an EMS message depends upon the network being used for transfer and i9 optimized accordingly.
Each individual application creates its own message comprising any specific data-strin~, file, image, etc. as part of its normal processing, as shown at 2 in Fig,. 3.
Editing and formating of message contents are done by the application or process strictly under its own control.
10 When the appllcation or process is ready to transfer the data/message to an application or process on another computer (or on the same computer), it calls the EMS SEND
service at 4. ~hese calls are normally embedded in the application/process by developers and are not seen by 15 application users except as the developer may wish to inform the user of this background activity.
The EMS then formats the message for transfer. When the application or process calls the SEND verb, a message header, called the Interface Control Bloc~ (ICB), noted at 20 4 in Fig. 3 and at 4' in Fig. 4. is built to identify:
the ultimate destination of the message the tag for selecting this particular message the type of special processing required for the message . the urgency of the message . the special handling chsracteristics of thc me3sage.

SUBSTITUTE SHEET (RULE 26) WO95/11560 2 1 7 4 7 ~ 3 PCT~B94/00322 EMS then determines, as later explained, the ~roper medium and transport facility to use to reach the speci~
fied destination, taking into con5ideration defaults set up in the configuratLon file for both the sender and the destination, the communication agents present, and the status of the various communication devices attached to the user computer. EMS then places the data/message queue and returns control to the appLication.
When the designated transport facility becomes avail-lO able, the messsge is transferred and delivery confirmed.The data/message is transmitted by the Communication Agent C~, Figs. 2 and 4, associated with that facility and status of the EMS message is updated. If the message re~uires guarsnteed delivery, then EMS will not consLder 15 it completed until a positive commit message is received from destination. The message is then delivered to the destlnation application.
When a message Ls received by the destination through any of the com~unication agents, it is queued for receLpt by the destination application according to instructions in the later-described EMS message header, 'EMH" in Fig.

4. The destination application "asks' for each message SUBSTITUTE SHEET (RULE 263 WO95/11560 ~ ~ 7 ~ 7 ~3 PCT~B94/00322 either automatically or as the result of a user command.
Once the message has been succe9sfully delivered to the destination application, EMS automatically generates a "commit" message back to the sending application (if re-quired by the sender). Message delivery i9 theteupon con-firmed to the sending application. When the sending copy of EMS receives the "commit for a message, it automatic-ally releases the queuing resources taken up by the origi-nal message, and updates the status for the sending appli-l0 cation, automatically freeing the message buffer. ,Return-ing to the message ptocessing chart of Fig. 3, and consid-ering the same in con~unction with the message header diagram of Fig. 4 (incorporating the system of earlier-described Fig. 2), the API routines or verbs, callable 15 from the EMS literary structure that is native to the local computing and communications environment,-enable the performance of the following functions.
EMS is initialized at 5, Fig. 3, by calling the beEore-listedlNlT verb whicl- sets up sending and receiYing 20 queues for the calling application/process and for each local communications transport facility (if these queues are not already in exlstence). Paramet2rs u~ed for initialLzation are retrieved from a configuration file but may be changed as part of the call. INIT must be called SUBSTITUTE SH~ET (RULF 26~

~ WO95/llS60 2 t 7 4 7 ~ 3 PCT~B94/00322 by the application prior to issuing any of the other API
verbs.
Before building an outgoing message or requesting seatus, an application or process must obtain a memory allocatlon for the message control data and for the message itself by executing the GETBUF verb at 3, Fig. 3.
Message control defaults are filled in by GETBUF but may be altered by the caller. GETBUF returns pointers to both the message control data and the message data area.
10 Incoming EMS messages also require allocation of memoty before they can be passed to the destination application or process. The EMS receive verb RECV (at 9, Fig. 3) automatically calls GETBUF in this case.
To send a message, the application progra~ or process 15 executes the SEND verb at 4 after making any desired changes to the message control data and inserting the length of the data or message being transmitted. EMS
checks the message control data as a header to the data/
~essage itself and places the combined structure, or EMS
20 message, on the EMS queue to await availability of the re-quired appropriate Communications Agent, CA, Figs. 2 and 4.
After the application has completed processing message or status response, it should release memory SUBSTITUTE SHEET (RULE 26) WO95lllS60 2 ~ 3 PCTAB94/00322 aLlocated for the message control data and the message data areas associated with the EMS message. Memory for the messa~e control data is freed by executing the FREEBUF
verb at ll. After execution of FREEBUF, however, EMS is no longer aware of the message or able to ~ccess it. If the application needs to access the message later, the message must be saved by the appllcation at lO.
To receive an incoming message, the application or process executes the RECV verb at 9, Fig. 3. When RECV
lO runs, the EMS Router, Figs. 2 and 4, provides pointers to the message control data and to the data/message contents Eor RECV to return to the csller. One message at a time is given to the calling application or process. Following delivery of the data/message, its status in th~ EMS in the 15 queue is updated. It should be noted that the message, together with its control data, remains on the queue until EMS receives a FREEBUF call (or COMMIT at l0) from the destination applicatlon or process. When an application or process w~ich ca~ recefve messages starts up, it should 20 immediately issue a RECV call to obtain any walting incoming data/messages.
For most communications services and networks sup-ported by EMS, acknowled~ment of received data/messages is taken care of by the Communication Manager and Router, SUBSTITUTE SHEE~ (BULE 26) -WO95/11560 2 1 7 4 7 7 3 PCT~B94/00322 Figs. 2 and 4, automatically on behalf of the destination applicatlon. For networks which support application and/
or user acknowledgments, however, the application program must call COMMIT (at 10, Fig. 3) to Yend the back through - 5 the network originator.
Applications and processes can obtain the status of an EMS message by executing the STATUS verb at 6-8, Fig.
3. Message status is maintained by EMS in tlle message control data area of each EMS message stored on the queues.
Applications or processes can find out the state of an EMS queue by executing the STATE verb. A STATE query for a queue returns the number of active items in that queue, and the state of the queue. Individual EMS mes-lS sages, moreover, may be deleted Erom the EMS queue by invoking the earller listed DELETE verb. All i,tems in a queue destined for the same address may be deleted with a slngle DELETE call. Items designated are deleted regard-lesY of status. If outstanding acknowledgements are received subsequently, the application or process will be notified. The DELETE verb is not used in normal process-ing. It should be invoked with care only to cancel messages which have not been sent because of extended unavailability of destination systems or communications links-SUBSTITUTE SHEET (R~ 26~

WO95/llS60 2 1 ~ ~ 7 7 ~ PCT~B94/00322 ~

All items in an application or process queue (either incoming or outgoing) may be discarded by calling the PURGE verb. The purge action takes place regardless of the status of lndividual message,~. The PURGE verb is not 5 used in normal processing. It should be invoked with care and only in error cotrection situations. (See DELETE.) Before an application or process using EMS ends, it normally calls the before-mentioned EMS API termination verb1 TER~I. TERM "cleans up" all outstanding messages 10 (incoming and outgoing) for the calling application or process, ensuring that the messages to be saved are properly stored on disk. This includes both application/
process created data/messages and EMS administrative or commit messages. If the EMS queues for the application/
15 process are empty, they are deleted. (They will be created again when the application or process starts up or a message is received for the application/process, Fig.
3.) In accordance with the~ invention, E~S encapsulat~s 20 each message submitted by an application (ViQ the EMS API) for transport across whatever network/protocols EMS is configured to support. Encap~ulation involves completing an EMS Message Header (~IH), Fig. 4, for the message data prior to transport and removing the transport specifics 25 from EMH just before delivering the message data to the SUBSTITUTE SHEET (RIJLE 26) ~ WO9S/11560 2 1 7 ~ 7 7 3 PCT~B94/00322 destination application. This header contains all inform-ation necessary for EMS to transfer the message from the originating application and EMS copy to receiving EMS copy and destination application across whatever network/
protocol comblnation that may be required, as schematic-ally shown in Fig. 5.
The EMH is used internally by EMS, as well as by certain networks, to instruct the various processes involved in transfer as to how the message is to be handled, and its format asnd content may change several times as it moves through the sending EMS, communications networks/protocols and the receiving EMS. Certain fields are dropped when no longer needed; others are compressed or coded to minimize overhead; fields generated within EMS
are added for temporary use by certain networks and protocols are removed immediately after they have served this purpose.
The full EMH is also structured according to the me6sa8e class-of-service; i.e. the message priority, length and requested acknowledgement level. ~These para-meters are used by EMS to determine the path that the message will take (including communicatlons ~ervice(s) SUBSTITUTE SHEET (RULE 26) ~ ~ 7 ~ ~ 7 3 PCT~B94/00322 selection), with the EMH containing only the minimum amount of information needed to support that class-of-~ervice. The EME~ for any speclfic message thus repre~ents a specific class-oE-service view of the full EMH - one 5 that may have both different content and different format depending on the handling characteristics, processing ~tage and communications medium.
In Fig. 4, EMH transformation5 at the various stages of EMS are shown. The programmer will be concerned only lOwith the fields that specify message handling and end - to - end logical addressing in the Interface Control Block (ICB) portion 4' of the EMH. All other fields in tlle EMH
are handled internally by EMS.
EMS messages can be of any length (subject to 5constraints of the local operating environment) but most networks and protocols have some limitations on message length. This means that EMS must provide some mechanism for subdividing messages that are too long for the specified communications path and for reassembling the 20pieces at the destination. In practice, message sub-division may be done in several steps. First, message SUBSTITUTE SHEET (RULE 26) J WO95/llS60 2 1 ~ 4 7 7 3 PCT~B94100322 segmentation. Messages no longer than some nominal limit - usually 32,767 bytes - are segmented upon receipt by EMS
prior to being enqueued for transmission. This nominal limit is contained in the EMS configuration files and i8 also modifiable. Secondly, segment packetization. Most networks and protocols have a maximum length for actual transport (and error correction) and for handling of the transported data internally. Since each protocol has different framing requlrements, the EMS software or local lO operating environment must take care of this final subdivision and formatting. A packet may require several frames to transport in full and receiving component of EMS
(or local operating environment) must handle reassembly of frames into packets. This subdivision and reassembly 15 process is transparent to applications and processes that use EMS. EMS, indeed, hides all of the message handling and communLcations complexity from users and their applications, removLng this costly and burdensome task from users.
The details of developlng outgoing messasges are presented in the flow chart of Fig. 6 which outlines the main steps in preparing a message for transmission and in sending that message.

SUBSTITUTE SHEET (RULE 26) WO95/11560 2t7~ 32- PCT~B94/00322 The application, througt~ its normal processlng, creates at 20 the block of data to be transferred. Thi3 data block or message ~D, as previously explained, may have a simple structure such as te~t, or it may have a complex internal structure containing binary data, images, text, graphics and other ob~ects that have meaning only to the receiving application. EMS has the ~ob of deliverin~
this message content to a specified destination wit'hout loss.
The application (or its user) must also decide at 2l how the message MD is to be handled (this deflnes the class-of-service for the message). Handling options supported by EMS may include acknow1edgement level, prior-ity with regard to otller traffic, service routing accord-15 ing to logical destlnation, identifier, recoverability, retry options, and timing and delayed delivery options.
The message dest~nation must be specified using IDs (7, Fig. 3) that have been established for the user envir-onments. Both message handllng and mes~age destination 20 specifications are loaded into a special E~IS data buffer -the Interface Control Ulock (ICB) 4', Figs. 4 and 6, -before the EMS API function call is made.

SUBSTITUTE SHEET (~.ULE 26) ~ WO95/11560 2 ~ 7 4 7 7 3 PCT~B94/00322 After definlng both the message data content for EMS
(in terms of length and pointer to message data start) and the message handling instructions (via the ICB), the appl-ication makes calls to the EMS API to make the transfer.
5 In general, thls requires a GETBUF call (3,6 in Fig. 3) to set up the message resources, and a SEND call (4, Fig. 3) to initiate the transmission (depending on the platform).
The receiving EMS process is the EMS Router, Fig. 6, or Queue Manager "QUEUES", depending again on the platform 10 involved.
Upon receipt of a message MD, EMS "encapsulates" it by prefixing the message handling data as a message header at 22 to the message data to form the complete EMS message ready for transport. As described before, content, struc-15ture and format of data in this header changes as the EMSmessage moves through the process. Because, as previously explained, EMS is designed to handle messages of any length, longer messages (such as images) must be broken into segments oE the maximum size supported ~ointly by the 20networks involved, as at 24. In practice, this may be, for example, a 10,000 byte or 32,767 byte size limit so that megabyte-size messages must be broken into many seg-SUBSTITUTE SHEET (;~ULE 26) WO9S/llS60 2 ~ 3 PCT~B94/00322 ments. Each segment carries an EMS header and is treated as an independent datagram between the source and destina-tion EMS copies, bein~ stored for transport at 25. The EMS-generated message segments wlll often require further subdivision, as before detailed, to accomodate network and protocol requirements. The appropriate communication agent is selected at 28, and for actual transport across many networks, messages are broken into the before - des-cribed packets of specific length and structure at 26.
Error detection fields may be added during the packetiza-tion process.
The message packets created by EMS normally undergo a f~lrther subdivision into frames at 27, Eor actual trans-port. The communication device (modem, port, driver, etc.) and the underlying network layer handle transport at 30 of data frames from a source node to a destination node, often by way of a number of intermediate nodes.
Error detection and frame retransmission where errors are detected occur at this level. Slnce EMS sh~ps only the header data needed by the receiving EMS to handle the message properly, all other header information is stripped prior to transport. Message header data required by cer-tain networks and services are added to the EMS message SUBSTITUTE SHEET (RULE 26) ~ WO95/11560 2 1 7 4 7 7 3 PCT~B94/00322 header in positions, structures and Eormats required by these such specialized header data is also removed when no longer required.
It is now appropriate to consider, in detail, the treatment of the incomlng messages sent by the technique of Fig. 6. The principal steps involved in receipt o~ a message to the destination application are shown in Fig.

7 .
The message data, and frame format, are received at 31 at each EMS - supported node and are reassembled into packets at 32. The transport layer data and structures are removed and the message header is unpacked to its full EMS format. The message packets are reassembled at 33 (segmentation created by the sending EMS is removed) and protocol data stripped and local header data added at 34.
The segments are delivered to the Local EMS QUEUE or Router at 35, where the complete messages are reassembled at 36 and acknowled~ment messages generated, if needed, at 37. On this queue, messages await either delivery at 38 to a local recipient or transmission over thè next trans-port hop. When the destination application or user re-quests a message from its assigned EMS Queue, using the RECEIVE verb, the message storage area is delivered to the SUBSTITUTE SHEET (RULE 26) WO95/11560 2 ~ 7 4 7 7~ PCT~B94/00322 ~

application. Other data contalned in the message ICB i8 also available to the application, if needed. The appli-cation can read the message data and display it or store it for the intended user (or application). If the ICB
~pecifies that application or user acknowledgement is required, the receiving application must initiate sn appropriate acknowledgement at 40. Formal return receipts are transmitted to the message sender as separate mes~ages.AcknowLedgement of teceipt lnternal to EMS is handled by the COMMIT mechanism and does not invoive either sending or receiving application. EMS generates the properly formatted messages on behalf of the applica-tion.
Messages requiring any processing follo~ing delivery to the destination must be processed by the destination application or by an associated module. This responsibil-ity includes saving of messages as at 41 (and of the ICB
if neccessary). EMS releases all resources involved in message transfer as 80011 as the receiving applicatiol1 notifies EMS (using the before-described FREEBUF verb or COMMIT verb) that it no longer needs separate access to the message.

SUBSTITUTE SHEET (RU-E 26) ~ WO9S/11560 2 1 7 4 7 7 3 PCTAB94/00322 Some important implementation details of routing functions for outgoing message handling and other func-- tions will now be addressed. Look up destination routing options may be used, providing possible medLa and network addresses for the destination (usLng an address book func-tion) based upon the ICB contents. Such an EMS address-book may contain a short name by which the user knows the correspondent, the correspondent's expanded name, the correspondent's location or address (description field), lO the correspondent's city, networks and their associated addresses for the correspondent, routing preferences for this correspondent, owning user or public indicator, compression option, encryption key to correspondent, encryption key from correspondent, and the like.
Message size and the other class-of-service charac-teristics are evaluated to determine which communication network provldes the best route to use for the next hop.
This information may be contained in the genera~ routing configuration flle having, as contents, maximum message 20 lengths -- i.e. 100, 200, 1000, 2000, 10000, 999999 --and, by priority, text type (character, binary), and maxi-mum message length.
It is also important to provide for the extraction of new network message information. If the outgoing message SUBSTITUTE SHEET (RULE 26) WO95/11560 2 ~ 74 7 73 PCT~B94/00322 is to transverse a processing network (for example, the Motorola MoNet) and the network ID for the destlnation is not in the addressbook, then it is added to the address-book. Like all of the other configuration files, the addressbook itself ls an editable file and may be completed with other information at a later date. The ID
i8 captured on the fly, however, to simplify later main-tainence by the user or administrator.
To complete the EMS message header, proper network, communication medium, next hop and final address (as appropriate) are filled into the ICB and reformatted as needed into the EMS Message Header (EMH), Fig. 4. Only the next hop and final address (as known) are inserted.
Each hop along the way determines the medium and address-ing for the next hop. This approach means that pathlng may vary as necessary and achieves the desireable result that such is totally transparent both to the preceding and succeeding hops and to the initiator and receiver of the message.
Based on the communication medium selected, moreover, the proper communication agent type ls selected from the ~ervlce information file. For each EMS Communication Agent type, a standard template is provided lncludlng SUBSTITUTE SHEET (RULE 26) 21 7~773 t WO95/11560 PCT~B94/00322 service name, process driver name, CA class (Express, Bulk, All), type (i.e. ARDIS), device ID (ESN or telephone number), port or network address, start automatically at run time (Y/N), shut down when no applications open (Y/N) (i.e. last TERM), maximum message size (including ICB's but not protocol headers), block/packet size, name of file containing startup command for communications agent, and name of special parameter file (for device/network specific parameters), This is where all of the protocol and device specific information goes and it also uses the keyword formats.
The message is segmented to the maximum message size from the relevant service file entry,as earlier discussed, and the messages are placed on the queue defined by the service. This is "receive" queue for the appropriate EMS
Communication Agents. Depending on the platform, the EMS
Router notifies the Communication Manager that there is traffic to be sent out on this queue.
Another function for processing outgoing messages is deferred sending, as where the queue management software will delay passing the message to the communications mana-ger until the specified time is reached. If the next hop routing for a message cannot be compLetely determined, SUBSTITUTE SHEET (~iUEE 26) WO9Sl11560 ~ 7 7 ~ PCTnB94/00322 t furthermore, the reason for the problem is placed in the ICB return code field. The message is they placed elther on the appllcation "receive" queue or the "receive queue"
for the application speciEied as the error process in the EMS header. The application selection is determined from the information in the local message header defaults configurat~on file, and the queue is selected from the application configuration file.
Further details on the handling functions of the in-coming messages are similarly helpful. For identification of the destination queue, the receiving EMS uses the application and destination ID ln the ICB attached as part o~ the E~IS Header, Figs. 3 and 4, to determine the proper queue for the message. The queue name i9 selected from the application configuration file, if it is present, including such items as application or ptocess name, Queue name, maximum number of copies (as applicable), start flag -- if not running when incoming messages received (Y/N), pass incoming commits to applicatlon (Y/N), pass incoming network acknowledgments to application (Y/N), permanent queue flag (Y/N), queue by user and application (Y/N) --vs. by applicatlon only, outgoing queue size (initializa-tion), incoming queue size (initialization), startup file SUBSTITUTE SHEET (RULE 26) ~ WO9S/11560 21 74 7 ~3 PCT~Bg4/00322 name (for complete startup command to start process), and text type of message generated (character, binary), etc.
If no application is specified in the incoming mes-sage, then the default application for the destination user is selected from the user configuration file. If there ls no default application, the message is enqueued only for the user. The received ICB and header Ls expand-ed and checked to see if a commit and/or other acknowledg-ment is requlred. If the routing functions are to gener-lO ate these messages automatically before the applicationreceives the message, then the appropriate header informa-tion is extracted for use in these datagrams. Depending on the platform, moreover, the routing process will detect true duplicates. These duplicates are identified by the 15 same message ID (which includes segment number). In theYe rare cases, the second message is considered the duplicate and is discarded since the message database is keyed on message ID.
The message status is set to recelYed but not yet 20 retrieved from the queue , and the message i~ enqueued on the receive queue for the application. Routing func-tions determine if a commit or device-level acknowledgment is required for the incoming message from the ICB con-tents. The commit requirement is determined by the set-SUBSTITllTE SHEET (RUEE 26) WO95/llS60 2 ~ 7 4 ~ ~ 3 PCT~B94/00322 t tlng of the receipt requested fle~d In the lnternnl por-tion of the ICB whLle device acknowledgement requlrement is determined from the confirmation mode field in the net-work portion of the ICB. The commit and/or acknowledgment i5 not generated until the message is enqueued for the destination application or next hop. This meets the "safe storage" requirement of many missioncritical applications.
As in the case of the outgoing message handling, as above explained, if a message Ls received via a processlng 10 network and the sender's network ID i5 not in the local addressbook, then it ~8 automatically added. Lil;e all of the other configuration files, the addressbook is an edit-able file and may be completed with other information at a later date. The ID is again captured on the flv, however, 15 to simplify later maintainence by the user or administra-tor.
Successful receipt of a mes~age (segment) by a final destination or delivery service is signalled by an acknow-ledgement me~sage being returned to the sender. There are 20 at least four levels at which the ability to generate receipt acknowledgements are valuable; namely, u~er (i.e., SUBSTITUTE SHEET (RULE 26J

~ WO95/11560 2 ~ 7 4 7 7 ~CT~B94,00322 a person), application, device (EMS) and/or communication protocol. EMS handles device and protocol acknowledge-ments and, through its API, support application-level and user-level acknowledgements if the application developer elects to provide these. All EMS messages have "network-level" fields to define these important class-of-service options.
Considering the above-mentioned device acknowledge-ment, an EMS Router that receives a message (segment) will lO generate a "device acknowledgement" if requlred and will forward it as a seperate datagram back to the message originator via the same path. A device acknowledgement is requlred if the confirmation mode ln the network-related fleld~ in the EMS message Header is set to "device acknow-15 ledgement." For example, when the Router at the destlna-tion subscriber unit receives an incoming message via a proceRsing service (e.g., MoNet) which has the confirma-tion mode in the natwork ICB set to "device acknowledge-ment", the Router wlll generate the required devlce ac-20 knowledgement message and forward it as a separate data-gram back to the message orlginator via the same process-ing service path. An example of the content of such a devlce acknowledgement ls presented ln the followlng Table 1 :

SUBSTITUTE SHEET (RULE 26) WO 95/11~60 2 ~ 7 ~ ~ 7 3 PCr/IB94/00322 ~ablc 1. EI~S Message Header:
DEVIC~ AC~O~O~LEDGE~ilENT - Local IC~ Pol110 f~eld Conlenl Eye Catchcr 'CAC8' Release 0300 Message l'ointer Default Message Length 22 Nelv~lk IC8 Pointr~r Default Netvork ICB Ler~th Default D. ", " ~ Felds Source fields frorn incoming message Message ID NewIDfc~r ~ea~ Mt ~y~ . It Number of Segments Mode Express Hop Fonnat B' Local Priolity flecovr,~ry 'Y' Commit Indicator 'Y' Commit Type '2' 2 o Cornmit So~nce DQs~nation address from incoming message O-iginal Message 11) Message 1~ rrorn illCOmirl9 meSSa~Q
Number of Re~bs Derault RQ~Y Colmt l)efault In~erval ~)efault 2 5 n~.hd~ _- 11) 'O-UOrl~S-SUBSTITUTE SHEET (RULE 26) t WO95111S60 2 1 7 4 7 7 3 PCT~B94/00322 A destination application may be given the ability to generate an application acknowledgement to confirm the message receipt by having the application issue a CO~1~1IT
call to the destination EMS Router. The EMS Router will generate the required application acknowledgement message and forward it as a separate datagram back to the message originator via the same network path. When the destina-tion application issues a COMMIT verb for a messsge marked for 'application acknowledgement" in the conflrmation field, the Router will generate the required application acknowledgement me~sage and forward it as a separate data-gram back to the message originator via the same process-ing service path. A typical application acknowledgement content i~ ~hown in the following Table 2:

SUBSTITUTE SHEET (RU~E 26) WO 95/11560 2 1 7 4 ~ 7 } PCT/IB94/00322 t Tabie 2. EMS Message Header:
APPLlCATlON ACKNOWL~DGEMÆ~Jr - Local IC~ Por110r r-7cld Conlenl s EYQ CatCher C~C8 Reiease 03ûO
Message Poin~er Derault Message Lerlglh 22 Nelwork ICB Pointct Delault Netwolk IC13 LengJl Dehult Dc ~ Fieids Souroefields ~romincomingmcssage IrieSSage ID Ncw ID for Vle a~.. !~ig~
Number Or Segments Mocie Exprt ss HorJ ronnat B-Local P~iorily o Recovcry Y
Commil hdic~tot Y
2 o Commit Tyf)e 2 CommitSource Uestinalion 0ddress fiom incoming message O~iginal Message IV Message 1[) fi ~m incoming mossage NulnberoFFit!t~ies l)crault Relfy Counl Derauit Inlrrval Deraîllt Sn)~l 'O' ~OIES

SUBSTITUTE SHEET (RULE 26) t WO95/11560 2 ~ 74773 PCT~B94/00322 ~ destination application may also be given the ability to generate an acknowledgement confirmlng message receipt by the receiving user. This requires the appllca-tion to is8ue a COMMIT to the destination EMS Router. The EMS Router will generate the required acknowledgement message and again forward it as a separate datagram back to the message originator via the same network path.
When the destination spplication issues a CO~I~IIT verb for 8 message marked for 'user acknowledgement" in the con-l0 firmation mode field, the Router will generate the re-quired user acknowledgement message and forward it as a ~eparate datagram back to the message origlnntor via the same proce~sing service path.
A typical user.acknowledgement content is shown in 15 the following l'able 3:

SUBSTITUTE SHEET ~RULE 26~

WO95/11560 2~ 747~3 PCT/IB94/00322 Table 3. EMS Messagc Header:
VSEn ACI~NO~YLEDG~lJr- Local ICR Po~tlon r:Teld Cor11en~

Eye Catcher CACB
~elease ~3W
Message Poin~er Dc~ault Messarle l~ngth 3~
~letu~k ICr3 Pointer Default lletwolk ICB tQn~lh De~ult 1). ,.~ti~ Fields Source Felds r~om hlcnming message MessaS1e ID New ID ror thc aJu,o.. l~ ul ~umber o~ Segmetlts Mode r~xr~ress Hop Format 8 ocal Priority -n Recovery Y~
CommitNndicatnr ~f 2 0 Commit. r~pe 2 Cornmit Source Destinaton address firom incomirlq message Original Messagc ID Mcssagn ID Iroln incomirlg mcssagc Nulllher oFt~r hies Derault ~etry Count Derault 2 5 Interval Derault I tl,tl dl l'.~
~aTEs SUBSTITUTE SHEET (RULE 26) ~ WO95/llS60 2 ~ 7 4 7 7 3 PCT~B94/00322 When the EMS Router receives a network acknowledgment message, it uses several fields in the network portion of the EM~I to match the acknowledgment to the original out-going message:

Message ID
Message Tag Application Destination/Source ID

Only one level of acknowledgement Ls received for a message. A messsge with multiple destinations (list) how-ever will get the same acknowledgement type from each destinattion which successfully receives the message. If 15 at least one acknowledgement is received, then it i8 Up to the processing network to deliver the rest. Since the expansion of group addresses may take place at the pro-cessing network, the source has no way of knowing how many acknowledgements will be received. In this case, the con-20 figuration for this application should be set to returnacknowledgments to the application for final reconcilia-tion.If, therefore, a network - generated acknowledgment is received for a message which is not on the EMS Router's queues, then the acknowledgment is placed on "receive"
25 queue for the originating user (from the source network SUBSTITUTE Sl~EET (RULE 26~

W O 9SI11560 2 ~ 7 ~ ~ ~3 PCT~IB94/00322 ID field in the network-related EMH fields) and application.
In the event that a message cannot be delivered as specified in the EMH, a negative acknowledgment in the confirmation mode field is generated if 80 requested by the processing network. Gateways in a network complex, furthermore, even if they are EMS-supported, simply pass through acknowledgment me~sages in the same manner as for any other message (except in the rare case that the Gate-lO way node ltself is the destination~.
While earlier referred to, it is now in order toexplain the details of the EMS Message Commits. The commit, it will be recalled, i8 an internal message sent from a receiving EMS to the sendlng EMS to notify the 15 sender that the message at the sending side may be released. This is the mechanism by which EMS is able to guarantee delivery and to recover messages in the event of any transmission 10.88.
The EMS router issues a commit message to the EMS
20 Communication Manager upon receipt of a message requiring a receipt acknowledgment. The commit is issued after the SUBSTITUTE SHEET (RULE 26) ~ WO95/11560 2 1 7 4 7 7 3 PCT~B94/00322 EMS Router ha~ placed the message safely on the queue for the next destination. Thi~ commit, Fig. 3, is passed as an independent datagram (i.e. EMS message) through the EMS
Communlcation Agent back to the previous sending computer EMS Router, serving a8 acknowledgments between the hops.
Typical content of the EMS Message Header in a,commit datagram is shown in Table 4. (All other fields are set to default values.) Commlts are not retriable messages, such that if they fail, then the normal message recovery 10 will talce over.

SUBSTITUTE SHEET (RULE 26) WO9S/11560 ~ t ~4 7 7;~ PCT/IB94/00322 l~ble ~ EMS l.les5agc Header COMMI~

Elltl Feld Con~ent Eye Ca~cher CAC8 l~elease 03W
Message Pr~inler n Messaqe Ler glh n Nelw~rk Area P dn~r Nelwork Aroa LenDtl- ~
De: l .. iliJn Fields Source ficlds l~orn incomillq messarJe Messa~e ID Nr~w IU ~r Ihe commit Number of Segments Mode Exrress l lol~ Fommat 8 Local Prioritr Recovery -y Commit hdicalor ~I
2 0 Commit Type -1 CommitSource l~es~in~60rl addrcss fiom incomillg messarlr-Odginal Message ID Message IU ~m incomin g message Nulllber ol tlelries 0 Rr-~y Counl 0 2 5 Inl~rval ~
n~h .... ~ . . . ~ . I~
COMME-'~ltS

SUBSTITUTE SHEET (RULE 26) S WO95/llS60 2 1 74 773 PCTnB94/00322 Considering now the handling of an Lncoming EMS
Commlt, when the EMS Router receives a commit from the next hop destination, it updates tlte status of tlle next message in the QEB for the message segment, and determines if the orlginal message i8 now complete. If the message has an EMH destination node, which implies a network, thcn the EMS Router has to wait for acknowledgments as directed in the network-related E~IH fields before marking the message as completed. If the message is complete, the EHS
10 Router removes the related message from its queues or enqueue~ the original message and/or commit as directed by the exit routine area in the EMH. If,however, the message is not complete, the EMS Ro~ter leave~ the ~essage enqueued as it was, but with the new status, on the E~S
15 Communication Agent queue (which is part of the Router queue). Finally, if a commit is received for a message which cannot be fouhd by the EMS Router, it discards the commit. (The original message may have expired, or may have been deleted by an application).Upon tlle lapse of the 20 time periods specific in the EMH (or ICB) interval ~ield before a commit message is received from the next hop, then a retry sequence is initiated.

SUBSTITUTE SHEET (RULE 26) WO95/11560 2 ~ ~ 4 ~ ~ ~ PCTAB94/00322 It is next appropriate to consider the actual integration of the invention EMS into applications and processes -- such involving little more than inserting calls to the EMS API verbs at appropriate points in the programs. Before each call, of course, the fields required by the verb must be loaded by the applicatLon.
In some situations, tllere will be nothing more required in terms of interface desLgn. EMS functionality will provide everything needed to handle the application requirements. More commonly, however, tlle application or proce~s will need to have a number of interface routines added to handle tasks such as saving messages for future reference, notifying users that messages are waiting, handling addressbook maintainence, creating application;
process acknowledgments, creating user acknowledgements, and the like. The principal aspects oE setting up calls to the EMS API involve only loading the Lnterface control block (ICB), Fig. 4, that accompanies each message content.
As will be recalled, message handling instructions from the sending application/user are placed by the appli-cation into the special E~IS data buffer called the Inter-face Control Block (ICB). ~pplications must provide SUBSTITIJTE SI~EET (RUI E 26) t WO9S/11560 2 1 7 ~ 7 7 3 PCT~B94/00322 certain pieces of the ICB data before calling the EMS API
to begin message transfer. EMS loads default data into the message ICB prior to allowing the application access to the ICB. The message ICB, indeed, exists only for the purpose of communicatlng between application and the EMS
API. Data in the message ICB becomes the ~MS Message Header once the message is accepted by EMS for transfer.

Application programmers are glven access to the external lO view of the ICB, divided into two majot portions: Data that governs end-to-end communication and most class-of-service processing; and data that determines local proces-slng f~r the communications hop in progress. Information is not duplicated from one portion to the other.

EMS, in accordance with the invention, manages both the end-to-end communications as well as each intermediate hop. The application never sees the details of the intermediate hop and it has no need ever to know this any 20 more than one would care how a telephone call was physically routed.

SU8STITUTE SHEET (RUI E 26) WO95111~60 2 ~ 7~ 56 PCTnB94/00322 t When the applicatLon executes the GET nUFFER verb ~ig. 3, EMS hands back an inltialized external view of the ICB along with the message area and destination list area. Both the network and local processing portions are set to the default values, along with the addresses and lengtl1s determined for the GET BUFFER call.
While the only network which currently utiLizes the network fields in the ICB directly is the ~1otorola MoNet, the information in this area is sufficient to permit lO connection to many other processing networks with the addition of a new communication agent. ~ayout oE the LCB
is independent of the actual communications media and networks used in the message transfer.
The ICB is accessed as a structure by the 15 application. I~ order to guarantee compatibill~y wLth future EMS releases, the application should always access the ICB fields by name within the structure.The ICB
~tructure is provided to the application programmer as a 'c' header file. IMRTREXT.I~. IE the calling program is 20 not written in 'c' than a similar structure needs to be defined in the development language.

SUBSTITUTE SHEET (RULE 26) WO95/11560 PCT~B~ C~??

This header file includes both the structure and the definitions of the layouts of various internal fields.
The application may use these internal fLeld definitions elsewhere for other purposes so that the programme~ shouLd ~lways address the subfields by name to preserve compata-bility with later releases. If the programmer saves the ICB or portions thereof to structured dlsk Eiles (depend ent on the platform), 8 file conversion may be necessary to acce~s thls data between EMS versions.
In the ICB layout, network fields are presented before the local processing fields. Field defaults are taken from the configuration files NETYICB and LOCALICB.
In Tables 1-4, the fields that are presented and addition-al regained flelds have the following descriptions.
~ye Catcher The eye catcher field is filled in the EMS API verb GET
BUFFER and is used to ensure that the processing computer recognizes the header area. It is two byte character field, and is ~et to "~*" in this version of EMS. The initial value comes from the NETICB configuration fLle.

SUBSTITUTE SHEET (RUI E 26~

WO95111S60 2 1 7 4 7 73 PCT~B~4~ ~22 Release The release field is filled in by the EMS API verb GET
BUFFER and is used to ensure tl1at the processing computer is utili~ing the correct view of the ICB for the EMS
version which initiated the message. The init~al value co~es from the NETICB configuration file.

Message Length The message length contains the length requested by the application in the call to EMS API verb GET BUFFER. It is an unslgned short integer. limitin~ message length to 32.767 in this example. There is no default message 15 length.

Message Type The message type currently defLnes the administrative 20 message type according to, for example, the before -mentioned Motorola MoNet Service standards. The default value is "MS" for a normal message and ~s taken from the NETICB configuration file. This is a two chsracter field. The application should normally produce only:

SUBSTITIJTE SHEET (RUEE 26~

WO95111560 2 1 7 4 7 73 PCT~B94/00322 ~lessnge (~IS), MN ~parameter maintainence), Status request (ST) and Look-up (LU) types. Depending on the setup of ehe configuration files, the application ~hould expect to receive only: Message (MS)~ Look-Up Re~pon~e (LU), Maintainence Response (MN), and Status Response (SR) types.
EMS configuration files. as before discnssed, may be set up to return acknowledgements to the application, in which case the ServiceR Acknowledgement (DL), the ~evice Acknowledgement (DV), the Applicatlon Acknowledgement (AP), the User Acknowled~ement (US), and the Negative Acknowledgement (NK) message types. This field is used ln determining the ultimate cla~s-of-service.

Text Type The text type indlcates whether the contents in the message area are to be considered as binary or text, for compre~sion purposes. Other values may be added further to describe the types of ob~ects which may be shipped vla EMS. Tbis Eield i8 set to binary always, at this tlme, and the default is always taken from the NETICB configu-SUBSnTUTE SHEET (RULE 26) WO95/11~60 2 1 7 ~ PCT~B94/00322 uration file. This ~ield is presented to the applica~ion to ensure that lt moves data properly internally. Text type is a one-character field and is used in determinillg the ultimate class-of-services.

Delivery Mode The delivery mode i~ used by the processing network to define retry policy for messages to be routed by the net-lO work. As illustratLons, "send once and qult", means tll~tthe message will be sent to the delivering ser~ice once.
~he processing network then discards the original mes-qage. The co~firmation is ignored. '-Send until expired--means that the message will be retried on a periodic basis 15 until the proper acknowledgement message is received in response or until the message reaches its expiration time. The acknowle~gement level i8 defined in the conEir-mation mode field. The default for this field l~ set from the NETICB configuration file. This field is ignorcd, 20 however, for messages in which the processing network generates a correspondinK response and is used in deter-mining class-of-service.

SUBSTITUTE SHEET (RULE 26) WO95/11~60 2 ~ ~ 7 ~ 3 PCTABg4/00322 Delivery Expiration Time The delivery expiration time is used by both the processing network and local EMS copy to determlne when a message should no longer be kept in an incomplete state.

It ls expressed in minutes as an unsigned integer and the default is taken from the NETICB configuration file.
Maximum value, for example, is 32767 minutes (approximate-ly 22 days).

10 Confirmation Mode The confirmation mode defines the level of acknowledgement which the application expects in response to the receLpt of the outgoing message by the ultimate destination. This 15 is a one-character field and the default is set from the NETICB configuration file. The administrator, further-more, may want to set this to other than supplied value depending on the criticallity of the applications which will be using EMS to send messages from this platform.
20 This field is ignored for messages in which the processing network generates a corresponding response. This field is also used in determining class of service.

SUBSTITUTE SHE~T (RULE 26~

WO95/11560 2 ~ 3 PCTnB94/00322 Encryption Mode The encryption mode defines the type of encryption and compression processing to be applied to the message area.
5 The default value for this one-character field is also taken from the NETICB configuration file. This field is further uaed in determlning class-of-service.

Dest~nation List Type The destination list type is a one-character field that identifies the types of identifiers provided in the destination list. The processing network uses this ind~cator further to deteroine class-of-service. The default value once more is taken from the NETICB
configuration file. The value of destination list type is compared agalnst the destination 11st actually provided (single entry or multiple) for consistency ~hen the sending application executes the EMS ~PI SE~D verb.

Routing Preference The routing preference is a one-character field which tile processLng network uses to determine how best to reach the SUBSTITUTE SHEET (RULE 26) WO95/11560 2 ~ 7 4 7 73 PCT~Bg4/00322 final de~tination, with the default value taken from the NETICB field. The administrator of EMS on this platform may want to alter this default, depending on the criticallity of the application on the platform. It should be noted that a message to a sLngle destinat$on ID
can be expanded by tlle processing network to multiple messages. This implies that multiple acknowledgements may be returned. This field is used in determining tlle ultimate class-of-service.

Message Priority The message priorlty determines the order that this message will be handled by EMS and the processing network relative to other messages. The value of thls one-character field varies form the number "0" to "9", with "0" being tlle highest priorlty. The application ~hould send messages with values "1" through '9" only, since commits and some network responses use "0" to ensure the speediest processing possible. The default for this field is contained in NETICB confi~uration file. This field is used in determining class-of-service by both EMS
and the process~ng network.

SUBSTITUTE SHEET (~1 'LE 2~) WO9~111560 2 ~ ~ 4 ~ ~3 PCT~B94100322 Recovery The recovery indicator is used by EMS on certain platforms to indicate whether the messsge is to be put to permanent media while it i8 active. Certain platforms alwsys put messages to dlsk while the message is active. Others keep active messages ln memory only, unless directed by thls field to put them to disk. If the recovery indicator is ~et to 'N", then the message may be lost by an EMS copy if the platform fails while the message is in an active state. Possible values may be "N' for no and "Y" for yes. The default value once more is taken from the NETI('B
configuration file.

Destination Node Ttle des~natlon node name identifies the name for the next hop. This field ne~d not be used by the sendlng application lf the destination list type is single and the destination ID is present in the addre~sbook. It is filled in by the routing logic ln response to the EMS ~PI
SE~D verb or lf the default from the NETICB file is sufficient. It is provided for information pu-po~es to the receiving application at the destination EMS
installation, and reflects the last hop information.

SUBSTITUTE SHEET (RULF 26~

WO95/llS60 2 1 7 ~ ~ 7~ PCT~B94/00322 .

Destination Service The destination service identifies the communications medium (communication agent type) over which the message is to be sent (outgoing) or was received (incomlng) for the current hop. This field need not he used by the send-ing application if the destination list type is single and the destination ID is present in the addressbook. It ls filled in by the routing logic i.n response to the E~IS API
SEND verb or if the default from the NETICB ~ile Is suffi-cient. It is provided for information purpo'ses to the receiving applic~tion at the destination EMS installation, and reflects the last hop information. Posslble values for this two charActer field depend upon the communication agent set installed on the platform.

Destination Address Destination address is the specific network address (i.e.

telephone number, radio modem ID, IP address, x.25 ~ddress, etc.) by which the message is to be dellvered to the next hop (outgoing) or by which the message was received (incomi.ng). It is filled in by routing logic in SU2STITUTE SHEET (RULE 26) WO95111560 ~7~773 PCT~B94/00322 response to the EMS API SEND verb of if the default from the NETICB file is sufficient. It is also provided for information purposes to the receiving application at the destinatlon ~MS installation, and reflects tl1e last 11o~
information. This is a 16-character field and presents the address in its expanded format.

Network Source User ID

lO If the E~S installation on a platform supports an inter-face to a processing network, then the network ID of the current user is placed ~n thls eight-character field. It is provided to the applLcation for reference only.

15 Submitting Network For outgoing messages, this is the communication medium which wlll be used to send the me~sage to tlle first i10p.
Possible values for this field depend upon b~th the 20 communications media which are installed on tl1is platform and those which can somehow connect with a processing net-work. This field is filled in by routing loglc in response to the E~S ~PI SEND verb or is the default from the NETICB file, if sufficient.

SUBSTITUTE SHEET (RULE 26) WO95/11560 2 1 7 4 7 7 3 PCToB94/0032Z

Submitting Device For outgoing messages tl1is is the communication network address (i.e. telephone number radio modem ID etc.) which will be used to send the message to the first hop.
For incoming messages this i8 the communlcation network address over which the message was sent to the first 11op.
Po~sible types and formats for this field depend upon both the communications media which are installed on th~s plat-form and those which can somehow connect with a process-ing network. Contents of this field may be compressed if the address is numeric and can be longer than eight numeric characters. This field is filled in by routing logic in response to the EMS API SEND verb or is the default from the NETICB file if sufflcient.

Me~sage Pointer The message pointer is provided in response to the EMS API
verb. It is a pointer to the message data area which is as long as the message lengtl1. The application must not change this value but needs to use it to fill in the message contents or to retrieve the message contents as SUBSTITUTE SHEET (RULE 26) WO9S/llS60 PCT~B94/00322 2~ 7~773 ~

is appropriate. The format of the pointer is platform-dependent.

~ddress Llst Pointer The address list pointer ls provided in response to the EMS A~I verb. It is a polnter to the destination address list area, which is as long as the length of an address, say (8) times the number of ID's. The application must not change this value but needs to use it to flll in the destination network addresses or to retrieve them, as appropriate. On incomin~ messages to an application, there is only a single address. The format of the pointer is also platform-dependent.

Local User ID

The local user ID field contains the name of the current local user (as contained in the USER configuration file).
It 1s provided for application reference only for sending and receiving, but m~y be used for further queue qualification on other types of E~IS API verb executions.
It also may be an 8-character fleld.

SUBSTITUTE SHEET (RULE 26~

WO9S/11560 2 1 7 4 7 7 3 PCTABg4/00322 Message Identifier The message idcntifier in an EMS-generated field {g used uniquely to identify ev~ry EMS me~sa~e. It ls asslgned by the E~IS API verb CET BUFFER for each message. The plat-form name is ta~en from the EI~S Registration configuration information.

Receipt Requested Mode The receipt request~d mode lndicates whether intermedint hops are to send EMS commits for this message. The dc-fault for outgoing messages is taken from the LOCALICB
configuration file, this ficld being also part oF the class-of-service determination.

EMS Mode The EHS mode indicates an overall tran8port priorltv based upon the ob~ect type; for example, express for normal messaging, and bulk for larger object transmissions. This field is included for future expansion purposes, with the default value belng taken from tlle LOCAL ICB configuration lnformation.

SUBSTITUTE SHEET ~RULE 2~3 WO95/llS60 ~ ~ 7 4 7 73: PCT~B94100322 Resubmit Indicator The resubmit indicator is used by E~IS to determine if retries on hop transmissions are to be executed. The default is taken from the LOCAL - IC~ configuration information. On incoming messages, this indicator is '()"
if this is the original transmission, and "1" if it iB a retried transmission.

Reque~t ~'ode The request code deEines an inquiry request to EMS for other than sending ~nd receiving messages.

Number of Desired Retries Thls field indicates the number of desired retries between hops. The default is taken from the LOCALICB configura-tion information. The sending application may change this value, which is a short integer.

SUBSTITUTE SHEET (RULE 26~

WO95/11560 PCT~B94/00322 Return Code .

The EMS status and purge type verbs return parameters and status codes. Depending on the verh, the values are placed in return code field.

Retry Period The retry period is the number of seconds which th~ E~IS
Router will wait to receive a commit from the next IIOP for an outgoing message before reinitiating the transmission via the communication manager. There ls a minimum time which is allowed based on the communication medium involved (service configuration information). The default is fLlled in from the LOCALICB configuration file for a GETBUFFER verb.

Message Completlon Process The name of the process to handle all the messages which are comple~ed is entered in this field. The default is taken from the LOCALICB configuration file. If the process name is not provided, completed messages are not SUBSTITUTE SHEET ~IJI E 2fi) WO95/11560 2 ~ ~ 4 ~ 7~ PCT~B94/00322 .

enqueued for any other application. The process is translated into a queue name from the APPLICATION config-uration informati~n. lf there is no entry In this file for the specified application, the message ls enquequed to the specified name.

Message Time Out Process Message time out process is the name of the process to be called to handle all messages that do not receive either a commit within the retry period or that reach a completed state before the expiration period. The default is taken from the LOCALICB configuration file. If the process name is not provided, completed messages are not enqucued for any otller npplication. The process is translated into a queue name from the application configuration informa-tion. lf there is no entry in the configuration file for the specified application, the message is enquequed to the ~pecified name.

SU~STITUTE SHEET (RULE 26) WO95/11560 2 1 7 4 7 7 3 PCT~B94/00322 Message Time Out Request ID Process Message time out request ID process is the name of the process to handle all messages that do not receive either a commit ~ithin the retry period or that reach a completed state before the expiration perio~. The default is taken from the LOCALICB configuration file. If the process name is not provided, completed messages are not enqueued for ~ny other application. The process is translated into a queue name from the application configuration informa-tion. If there is no entry in the configuration file for the specified application, again, the message is enqùeued to the specified name.

Time Sent or Received For incoming messages, the time received is filled in by EMS. For outgoing messages, the time sent is filled in by EMS. This is a reference field or the application.
Format of the time is the same on all platforms.

SUBSTITUTE SHEET (RULE 26) WO95111560 2 ~ ~ ~ 7 ~3 PCT~B94/00322 .

Scheduled Time ~, If an application desires to defer a message until a specified time, then the date and time for the initial attempt are entered in this area. If no values are enter-ed here, the message will be ~ent as soon as the selected communication medium becomes available and all higher priority messages for that medium wl1ich are ready (not delayed for retry) have been sent.

Details of Er1S API Verb Operatlon While the identification of EMS API verbs and their usage has been discussed, further details as to their format, function and uses for various applications and platform differences ls now in order.
Turning, first, to the COMMIT A~I verb, it, as before explained, Figs. 3, is used to inform a sending F~1S Router that a complete message has been successfully received and processed as required and that the message resources ti.e. delete the message and related queue data), both local and remote, may now be released. Me6sage status SUBSTITUTE SHEET (RULE 26) WO95/llS60 2 ~ 7 4 7 7 3 PCT~B94/00322 is also updated. U8er and application reque~t~ for retur receipt/guaranteed delivery are made by setting the confirmation mode field in the net-work ICB. When the message is received hy the EMS Router on the receiving computer, it uses the COMMIT verb to return a receipt acknowledgement to the sender (user or application).
Alternatively, a receivin~ user or application can call COMMIT to send an acknowledgement message to a sending user or application followlng message receipt and processing. By this means, EMS can provide end-to-end message delivery acknowledgements. ~O~IMIT is also used between EMS Routers to provide hop (internal3 delivery acknowledgements.
Thus, in the flow chart of Fig. 8, after checking the call parameter validity and u~ing the ICB message pointer to locate the QCB (queue continue block), such i8 ellqUetled and the EMS Ro~ter is notified to issue the proper ackn~w-ledgement. The message buffers are then freed and the ~CB
de-queued.
Considering now the DELETE verb, Fig. 9, such, it will be recalled, allows the removal of one or more selected mes~ages from a ~pecified queue (destlnation) SUBSTITUTE SHEET (RULE 2fi) WO9S/11560 2 1 ~ 4 ~ ~ ~ PCT~B94/00322 regardless of priority, pending or ~ctive stste or whether receipt has yet been acknowledged. A user or application may occasionally discover messages still ln a queue await-ing destination availability that are no longer valid, that have a destination no longer in existence (user, application or system), or that have a dest~nation known to be experiencing extended unavailability. The DELETE
verb allows such messages to be removed by the user or application.
Following call parameter validity check and QCB pool enqueuin~, the active QCB wlth the input ICB queue name is located, Fig. 9. ~f an active QCB is found, following enqueuing, each segment attached to the QCB is connected to a free list and the active QCB and the QCB pool are dequeued. If, on the other hand, an active QCB is not found, the QCB pool is thereupon dequeued, and the return code is to error.
To accommodate for platform differences, since DELETE
might cause unpredictable results if operating on a queue being accessed by another process in a multi-processing environment, it will reserve the queue to allow itself exclusive use of the queue while it is deleting records.
Any other process sending or receiving from the queue at SUBSTITUTE SHEET (RULE 26) WO95111560 2 1 7 4 7 7 3 PCT~B94/00322 the same time is suspended temporarily. This is a special internal transieslt state that exists only for the duration of the DELETE operation. The external state of the queue will remain as it existed prior to the commencement of the DELETE operation.
The FREEBUF verb, before discu~sed, is called by an application to free resources:
(a) allocated by GETBUF for STATUS calls, (b) allocated by GETBUF for STATE call~, (c) passed to ti-e user via the RECEIVE call for incoming message delivery where a COMHIT i8 not issued, and/or (d) allocated by GEIBUF for oucgoing messages not passed on to the Router (i.e., cancelled).

Whenever an application receive~ a message or checks message status or queue ~tate, EHS creates data storage areas and queue entries.

SUBSTITUTE SHEET (RULE 26) WO95111S60 PCT~B94/00322 2 ~

These resources must be released using the FREEBUF verb, Fig. 3, after they are no longer required - after a message has been received and processed by the application and after each ST~TUS and ST~TE call. Application programs use the FREEBUF verb to release the resources a~sociated Wittl the ~PI buffers allocated by GETBUF and message receipt. FREEBUF releases the local and n,etwork ICB and message data areas for messages, as well as the Queue Entry Block. FREEBUF also validates the input message buEfer to ensure that the resources are not associated with a me~sage in progress (on the outbound queues), returns the buffer to the free buffer pool, and relea~es any other resources associated with the message.
Referring to Fig. 10, following call parameter, input buffer and message .state validation, if the input buffer is temporary t it is returned to the operating system; but if a segment bufEer condition exists, the buffer is returned to free segment node and the return code ls set.

SUBSTITUTE SHEET (RULE 26) WO95/11560 ~ PCTAB94/00322 -7~-In Fig. 11, the flow of the GETBUF verb operation is outlined, this verb, as previously ~escribed, allocating internal E~IS memory and/or other re~ources needed to support the SEND, STATE, and STATUS servlces of E~S.
Application programs must use the GETBUF subroutine, Fig. 3, to allocate all EMS API buffer~ needed to SEND
messages, to retrieve queue STATE and to obtain STATUS for an individual messages. GETBUF returns an empty message buffer that carries ICBs loaded with default values. By lO ~ecurlng message resources with GETBUF prior to i~suing a SEND call, an application can be assured of having the nece~sary resources available for message delivery. This feature is especially important for very long messages that may at certain times exceed available resources.
GETBUF interrogates the message bùffer pool for svailable resources. If thè requested size i8 greater than che maximum ~ize, GETBUF returns an error. If the requestèd size is less than or equal to the ~aximùm size, GETBUF locates a free buffer in the message segment pool 20 and returns it to the calling program. If GETBUF cannot locate a temporary buffer or segment, it teturns error to the calling program. GETBUF accepts a message length of SUBSTITUTE SHEET (RULE 26) WO95/11560 PCT~B94/00322 ~1 7~3 0 for use prior to STATUS and STATE calls.
As summarized in Fig. 11, following call parameter validlty check and enqueueing the segment pool, the next free segment ls located and the return buffer pointer and return code set. IE, however, no free segment i8 found, a return error code is set.
The INITIALIZE verb, as before explained, connects the calling application process to the EMS infrastructure by creating and initializing one or more EMS Router queues lO (normally, a send quéue and a receive queue) for the calling process. The INITIALIZE, Fig. 3, establishes the connection between an application and the EMS infra-~tructure. It must be called before any other EMS API
calls are made - usually, at the tlme the application 15 itself is initialized. INITIALIZE creates and initializes one or more queues msnaged by the EMS Router and notLfies the EMS Communications ~lanager CM to initialize appro-priate EMS Communication Agents, Figs. 2 and 4, so that the message traffic to and from the application may begin.

SUBSTITUTE SHEET (RULE 26) INITIALIZE first looks for an existin~ queue for the application process - one which may have been established during sy~tem initialization and configuration. If the queue already exists, INITIALIZE locates the existing queue control block (QCB) and, after verifying that no other active application proce~s has issued an INITIALIZE
for that queue (depending on envlronment), connects the queue with the calling process (mechanism dependent on environment). If an existing queue is not found, on the other hand, INITI~LIZE creates one and then goes through the same connection process.
INITIALIZE further opens the approprlate files (mall-boxes) for the designated queues based on the EMS Configtl-ration Files and the operating environment. If the queue file for the designated queue already exists, then it is read from the medi~ and QEB ~ are built for the messages contained ln the file. If no queue file exists for the requested queue, one is established and a QCB is set up with null pointers in the QEB entries.
Depending on the environment, moreover, a wake-up i8 issued for the EMS Communication Manager CM, Figs. 2 and 4. If the C~l is already running, this call has no effect, otherwise, the CM iR started. INITIALIZE does not, however, wait for the CM to start before continuing.

SUBSTITUTE SHEET (RULE 26~

WO95/llS60 2 ~ ~ 4 7 ~ ~ PCTAB94/00322 It is not necessary, furthermore, for any npplication to issue INITIALIZE if all of the queues for a platform in any environment are defined in the configuration ~Lles as static queues. Existing queues may be memory-based, disk-file based using environment conventions, or residellt in adatabase, or a comb~nation of all of the~e. The exact implementation of the queues does not affect the basic functionality of the E~IS processes or the API verbs.
Whenever the enviroment supports it, messages will be wrltten to auxiliary media (disk) lf they are designated as recoverable. The queue name length is specified in imrtrext.h. It must not be chan~ed for DOS or WINDOWS
implementation as it is used to build a queue file name.

After call parameter check, Fig. 12, and enqueueing the QCs pool, the active QCB with the appropriate input process queue name is located and enqueued. If it is true that the active QCB o-~ner ls not callin~ thè proce3s (and there is not a null), the active QCB is dequeued and the return code is set to error; but if such i8 not true (false), the active QCB owner is set to calling process, an active QCB name and a maximum message count, and then the QCB is dequeued and return is effected. This latter sequence is also ordered if the active QCB is not found SUBSTITUTE SHEET (RULE 26~

WO95111560 2 1 7 ~ PCT~B94/00322 and a free QC8 is enqueued and connected to the active QCB
list. Should no free QCB be found, however, the return code i8 set for error.
Turning now to the previously described PURGE verb, such allows an application to remove all messages from any local queue regardless of priority and regardless of pend-ing or active state.
An application may find it necessary or desirable in rare lnstances to remove all of the messages from one of lts EMS Queues. This migl-t occur if the computer runs low on resources and needs to free up memory, if the user learns that a particular destination (queue) is no longer available, or if the user wishes to clear all messages from a particular sender (i.e, wlthout receiving them). A
PURGE call for the queue name will delete alL ~essages Eor that destination or sender.
As Rhown in Fig. 13, after validating the input para-meters, PURGE enqueues the QCB pool and locates the QCB
with the input ICB queue name. If the QCB is found, PU~GE
frees all message segments for all priorities chained to the QCB, and then rrees the QCB itself, setting the return code to SUCCESS. If the input QCB is not found, however, SUBSTITUTE SHEET (RUI E 26~

WO95/llS60 2 1 7 4 7 7 3 PCT~B94/00322 PllRGE returns an error code to the caller.
The RECEIVE verb is used to effect delivery of an incoming message to the destinstion application or user and to query the EMS Routor about traffic awaiting delivery to this destination. The flr~t message of the highest priority awaiting delivery is returned in the ICB
and the return code in the local ICB i~ ~et to the number of remaining messages that are to be retrleved, Figs. 4 and 6. Since every application is different, it is necessary for the individual application to be able to control when snd how it receives incoming messsges addressed either to itself or to the current user. Tlle RECEIVE verb, provided for this purpose, allows appllca-tions to call for messages only when the application (user) is ready to process the message.
RECEIYE validates the input parameter~, Fig. 14, and allocates the buffer space necessary for the ICB areas itnd the me~sage segment. Depending on the configuration para-meters, RECEIVE then moves the data from each segment into the receive buffer to build the complete message, or returns the message segments to thl9 application, one at a time, as independent datagrams. Thus, after locating the SUBSTITUTE SHEET (RULE 26) WO95111560 2 ~ 7~ pCT~B94/00322 .

highest priority message and optional segment size, either each message segment is moved to temporary message buffer and then sets the return buffer, or the return buffer is set from the message ~egment buffer enabling a change in message stste, if needed, to PENDlNG COMMIT. In the event there ls no message count (0), tl-e QCB is t11ereupon dequeued and the return order code set to error.
RECEIVE returns the pointer to the local ICB~ which, in turn, contains the pointer to the network ICB and message data areas. The application has addressability to ench area. The return code field of the local ICB con-tains the number of messages enqueued for the application (not counting ehis one).
The SEND verb permits an application to place a mesgage into the EMS Router ~ueue for eventual trans-mission to the specified destination. The application may then go on to do other work. It does not hsve to w~it for the me~sage transmlsslon to complete. MeYsages created by application are handed to EMS using the API's SEND verb.
SEND thereupon causes a message to be placed on the EMS
Router Queue for the specified destination where it will SUBSTITUTE SHEET (RULE 26) WO9SIIlS60 ~1 7 ~ 7 7 3 PCT~B94/00322 await processlng based on instructions in the locaL and network ICBs and the E~IS Configuration Files. SEND places an application message on the "send queue" assigned to that application and user, and performs only the basic formattin~ error checks such as field presence or absence, and pointer range. All other local and network ICB checks and audits are performed by the EMS Router uslng the con-figuration values.
Even in an environment such as ~IS-DOS, the message processlng after the SEND function is completed proceeds in background to the user spplications. It should be noted, moreover, that the EMS Communication ~lanager CM, Figs. 2-4, also uses the SEND verb to pass incoming messages to the EMS Router for further dlrection (to a local appllcation/user or to the next node ln the net-work).
In Flg. 15, accordingly, after call parameter and input ICB validstion, the work queue name i8 `8et to destlnstion node snd process name and the QCB pool is enqueued. I~ an active QCB using the work queue i8 loc~-SUBSTITUTE SffEET (RULE 26) WO95111560 2 ~ ~ ~ 173 PCT~B94/00322 .

ted, unconditional enqueueing of the active QC8 is effect-ed and the pool dequeued, with the return code set to SUCCESS. If such an actlve QCB is not found, a free QCn is enqueued and connected to the active ~)CB list before the pool i8 dequeued and SUCCESS indicated. Should there be no free QCB, however, the return code is ~et to error.
The before-described STATE verb allow6 an application process to inquire about or to alter the state of any local EMS Router que-1e. Application programs can use the 10 STATE verb to alter the state of an EMS queue or to inquite about the state of a queue. During certain times, an applicstion program (or the user) may, for example, wlstl to allow only tlle queueing of incoming messages, but to disable sending of me~sage until tt1e state is changed.
The local ICB carries queue status as part of its normal data. When an applicat~on program calls STATE to alter the queue state, it must first place the desired state in the local ICB (obtained using a GETBUF call).
STATE call returns with the altered state of the queue, if 20 successful. When an application program calls STATE to inqulre on the state of a queue, STATE updates the ICB
with the actual state of the queue vhich can then be read SUBSTITUTE SHEET (RULE 26) WO9SIllS60 2 ~ ~ 4 7 ~ ~ PCT~B94/00322 by the appl~cat~on. The EMS Router queue state processor (STATE function) allow two operations to be performed on single queue - either inquiry or update of queue state.
The local ICB for tl-e verb update includes the reason code and the state change.
The ST~TUS verb allows an application to inquire about or alter the status of any message in the named send queue and to obtain the number of messages in the queue.
In general, application programs will not need to use thc 10 STATUS verb. STATUS should be used by application pro-grams only in environments where message acknowledgements are not returned to application programs and there is no generally available way supported by the environment to notify the program when an event has occurred. For 15 example, in some enviroments it is necesssry for the send-ing application to 'poll the EMS Router to ~ee if an out-going ~e6sage hAs been co~plete~ (older MS-DOS). ~hcn needed, however, STATUS allows the queue state of any message entry in the queue to be read or modified.

SUBSTITUTE SHEET (RULE 26) 2 1 ~ 3 W095/11560 PCT~B~/00 STATUS flrst validstes the local ICB. If the call in-dicates a status inquiry, STATUS returns message status in the local ICB passed by the calling program. IE the call indicates a status change, STATUS verifies that the current status Ls accurately set in the request ICB by the calling program. If the current status is properly depicted by the caLIing program in the ICB, STATUS
attempts to make the status change indicated. If the status chsnge requested is logically incorrect, STATUS
reports an error to the calling program.
In Fig. 16, therefore, following location of an active QCB with the input queue name and a code field request check, a status inquiry may be effected by copying the QCB status data in the ICB input. For a status change, on thc other hand, the ICB is enqueued and either the ICB new state is moved to the current state and then the QCB is dequeued, or the QCB dequeueing i8 directly effected and the return code set to error.
Before application exit, TERMINATE is called to clean up, resolve latent messages, and termlnate the application EMS Router queue connection. The TERMINATE verb dis-connects an application process from the EMS queueing SUBSTITUTE SHEET (RULE 26) WO95/llS60 2 ~ 7 ~ 7 73 PCT~B94/00322 infr~structure. TERMIN~TE deactivates the E~1S Router queue (previously created by INITIALIZE) and causes LogOff messages to be sent to attached networks ~f the queue ~s "send" or "receive" (this is done at application termina-tion processing tlme only). TERMINATE releases the re-sources associated with the input and output queue connections for the calling process. This verb must be called before exiting the application in order to ~nsure queue integrity and orderly communications close-out.
TERMINATE, furthermore, logically disassociates the call-ing process from the EMS Router queue described by the input queue ha11dle. It first checks for messages on the calling process Router queue. If there are no messages, TERMINATE frees the queue control block. If there are messages, they are either saved as directed in the config-uration files, or discarded.
Referrin~ to Fi~. 17, accordin~ly, upon locating an active QCB with the appropriate input queue ~name and enqueueing the ICB, if the calling proces~ i8 the active QCB owner ("yes") and is not a null, after setting the queue owner to null, sctive messages are either ~aved be-SUBSTITUTE S~IEET (RULE ~6~

2~ 74773 fore dequeueing the QCB, or if there are no active messages, the QCB is connected to free QCB 11st before dequeueing. Otherwise, the return code is set to error.
The invention, thus, in addressing business needs of supporting enterprise integration and worker/task/work-place mobility, and integrating incompatable networks with multi-media, multi-network and multi-platform needs, provides a consistent and cost-effective solution ~hrougtl its provlding of vendor and platform independence, guaran-teed data/message delivery, and transparent interchange ofmulti-media data, with fully recoverable store-and-forward transfers and the broadest connectivity availability.
EMS equipment designed in sccordance with the inven-tion, as currently constructed, supports the operating environments, for the designated communications services and media shown in Fig. 18, wlth additions to this envir-on~ent list to lnclude ~N~ System V P~elea~e 4 and Macintosh System 6.04 and others. Palmtop un~ts running MS-DOS 3.3~ are also supported. Cellular modem support may be provided, also, for all environments that currently support dial-up asynchronous communications, and connect-ivity extensions to platforms including the Microsoft NT, SUBSTITUTE SHEET (RULE 26) WO9S/11560 2 1 7 4 7 7 3 PCT~B94/00322 DEC ULTRIX, HP-UX and Sun-OS are useable with the inven-tion, also; demonstrating the wide scope of the universal, generic or heterogeneous approach of the inventlon.
Further modifications will also occur to those skilled in this art, and such are considered to fall with-in the spirit and scope of the invention as defined in the appended claims.

SUBSTITUTE SHEET (RULE 26)

Claims (22)

1. A method of electronically messaging between compu-ters by heterogeneously and universally interfacing dis-tributed applications and processes residing in a wide variety of differing computer platforms and communications transport facilities of various types, that comprises;
providing a set of single-function software modules con-trolled by a preselected set of verbs that together pro-vide a consistent application programming interface between the applications/process and the communications facility and through which application programs/processes can access the electronic messaging; under the control of the set of module verbs, first queueing and routing mes-sages and data flowing from and to the sending and recov-ering computer applications/processes and monitoring the delivery status thereof, and then communicating the routed messages and data through a communication agent for each communication transport facility; and providing common messaging functions for all communication agents indepen-dently of and without user concern for the specifics of the various communications facilities and their character-istics.

2. A method as claimed in claim 1 and in which the module verbs are used to provide for message transfer and receipt, message managing and queuing, and environment resource allocating and deallocating.

3. A method as claimed in claim 2 in which the managing of the data/message comprises managing queues for routing outgoing and incoming data/message transmission and delivery, and notifying applications of message status changes.

4. A method as claimed in claim 3 wherein, on startup, queues for the data/messages are rebuilt from saved files;
and, on shutdown, data/messages which have not been completed and are saveable are entered into such saved files.

5. A method as claimed in claim 3 and in which, if the application for a designated user is not active, the application process is started to deliver the incoming data/message.

6. A method as claimed in claim 1 and in which each said communication agent manages the passing of data/messages to and from its communications transport facility.

7. A method as claimed in claim 1 and in which data/
messages, particularly of substantial length, are segment-ed for sending and are reassembled upon receipt, with seg-ment length optimised in accordance with the particular communications transport facility.

8. A method as claimed in claim 7 and in which a message header is applied between the application/process and the module-verb interface to encapsulate prefix header control data with the message to identify the ultimate destination of the data/message and to provide a tag or name for selecting the particular data/message.

9. A method as claimed in claim 8 and in which there is included in the message header all data needed to route, acknowledge or confirm, and recover the electronic data/
messages as they move from sender to destination.

10. A method as claimed in claim 9 and in which the message header data controls how the data/message is to be handled and further enables adding and dropping informa-tion as and when needed or no longer required, including by the communications facility.

11. A method as claimed in claim 7 and in which the message segments are subdivided into message pockets corresponding substantially to the maximum handlable by the particular communications facility.

12. A method as claimed in claim 11 and in which the message packets are combined in preselected frames prior to sending over the communications facility.

13. An electronic messaging system for communicating between computers and the like with heterogeneous and universal interfacing between distributed applications and processes residing in a wide variety of differing computer platforms and communications transport facilities of various types, having, in combination, means for providing between an application/process and a communications facility a set of single-function software modules controlled by a preselected set of verbs that together provide an application programming interface through which application programs/processes can access the electronicmessageing by an interface control block; message routing means controlled by the application programming interface control block for staging messages and data flowing from and to the sending and receiving computer applications/processes by a router control block for determining message handling and communications facilities, and monitoring the message delivery status; communication agent means, one corresponding and connected to each communication transport facility, controlled by common communication management means connected to the routing means and responsive to its said router control block to control the message flow from each communication agent means to its corresponding communication transport facil-ity independently of and without user concern for the specifics of the various communications facilities and their characteristics.

14. An electronic messaging system as claimed in claim 13 and in which the application programming interface verbs comprise a set for message transfer and receipt, a set for message managing and queueing, and a set for environment resource allocating and deallocating.

15. An electronic messaging system as claimed in claim 14 and in which which means is provided controlled by the communications management means for providing the message with a header containing data needed to route, acknowledge or confirm, and recover the electronic data/messages as they move from sender to destination.

16. An electronic messaging system as claimed in claim 15 and in which the header providing means further provides information to control how the data/message is to be handled and enables adding and dropping information as and when needed or no longer required, including by the commu-nications facility.

17. An electronic messaging system as claimed in claim 13 and in which means is provided for segmenting the data/messages for sending and for reassembling upon receipt, with segment length substantially optimized in accordance with the particular transport communications facility.

18. An electronic messaging system as claimed in claim 17 and in which means is provided for subdividing the message segments into message packets.

19. An electronic messaging system as claimed in claim 18 and in which means is provided for combining the message packets in preselected frames prior to sending over the communications facility.

20. An electronic messaging system as claimed in claim 13 and in which means is provided for enabling the verbs of said application programming interface modules selectivity to effect one or more of the following functions: COMMIT, to inform the routing means that a complete message has been successfully received and processed as required, and that the message and its related queue data may be re-leased; DELETE, to remove one or more selected messages from a specified queue regardless of priority, pending or active state, or whether receipt has yet been acknow-ledged; FREEBUF, to release data/storage and queue entries when no longer required: GET BUF, to allocate resources such as internal memory needed to support message sending and status services; INITIALIZE, to connect the calling application or process for electronic messaging PURGE, to remove all of the messages from any local queue regardless of priority and pending an active state; RECEIVE, to de-liver an incoming message to destination application and to queue the message traffic awaiting delivery and prior-ity to such destination; SEND, to place a message into routing queue for eventual sending to the specified des-tination; STATE, to inquire about or alter the state of any local routing message queues; STATUS, to inquire about or alter the status of any message in the named message sending queue and to obtain the number of messages in such queue; and TERMINATE, to resolve latent messages before application exit and then terminate the application connection to the routing message queue.

21. An electronic messaging system as claimed in claim 13 and in which means is provided for enabling the verbs of said application programming interface modules selectivity resources to effect one or more of the following func-tions: (1) to inform the routing means that a complete message has been successfully received and processed as required, and that the message and its related queue data released; (2) to remove one or more selected messages from a specified queue regardless of priority, pending or active state, or whether receipt has yet been acknow-ledged; (3) to release data/storage and queue entries when no longer required: (4) to allocate resources such as internal memory needed to support message sending and status services; (5) to connect the calling application or process for electronic messaging; (6) to remove all of the messages from any local queue regardless of priority and pending an active state; (7) to deliver an incoming message to destination application and to queue the message traffic awaiting delivery and priority to such destination; (8) to place a message into routing queue for eventual sending to the specified destination; (9) to inquire about or alter the state of any local routing message queues; (10) to inquire about or alter the status of any message in the named message sending queue and to obtain the number of messages in such queue; and (11) to resolve latent messages before application exit and then terminate the application connection to the routing message queue.

22. A method of heterogeneous connectivity and universal and generic interfacing for distributed applications and processes residing in a wide variety of computing plat-forms communicating over varied communications transport facilities, that comprises, interposing between the computer platforms and the varied communications facili-ties, a common application programming interface of single-function software modules controlled by preselected verbs, that upon separate actuation, provide a common control of message/data recovering, security and directory services irrespective of the varied protocols and idio-syncrasies of the varied communications facilities, iso-lating the applications/processes from such protocols and idiosyncrasies and effecting message/data handling by the programming of the common interface modules.