United States Patent
`
`[19]
`
`[11] Patent Number:
`
`5,406,643
`
`llllll||||||l|l||||||||||||lllllllllllllllllllllllllllllllllllllllIllllllll
`U8005406643A
`
`
`
` Burke et al. [45] Date of Patent: Apr. 11, 1995
`
`
`
`[54] METHOD AND APPARATUS FOR
`SELECTING BETWEEN A PLURALITY OF
`COMMUNICATION PATHS
`
`[56]
`
`[75]
`
`Inventors: Christopher J. Burke, Maple Valley;
`Janice M. Chnfiee, Auburn; Erez Nir,
`Bellevue; Thomas E. Kee,
`Lynnwood, all of Wash.
`
`[73]
`
`Assignee: Motorola, Inc., Schaurnburg, Ill.
`
`[21]
`
`Appl. No.: 991,892
`
`[22]
`
`Filed:
`
`Feb. 11, 1993
`
`[51]
`[52]
`
`[58]
`
`Int. Cl.“ ......................... 11040 11/04; H041 3/26
`US. Cl. ................................... 395/211); 370/94.1;
`364/DIG. 1; 364/284; 364/284.3; 364/284.4;
`364/24294; 364/229; 364/2293; 364/2294;
`364/2295
`395/200, 700, 650, 300;
`370/94, 94.1, 94.3, 60.1
`
`Field of Search
`
`References Cited
`T
`S
`. PA ENT DOCUMENTS
`U.
`4/1933 Aubin et a1.
`.......................... 370/60
`4,736,363
`..
`IMO/825.02
`4,825,206 4/1989 Brice, Jr. et a].
`5,088,032 2/ 1992 Bosack ........................ 395/200
`5,115,495
`5/1992 Tsuchiya et al.
`.. 395/200
`5,142,622 8/ l 992 Owens ..................... 395/200
`
`5,168,572 12/1992 Perkins ................................ 395/800
`
`
`
`Primary Examiner—Kevin A. Kriess
`Attorney, Agent, or Finn—Val Jean F. Hillman
`
`ABSTRACT
`[57]
`In a data communication system (100), a method is
`provided to distinguish between and select from multi-
`ple communication paths (4,6,and 8)to a designated end
`point (10). The communications path selection is done
`locally, on a portable subscriber unit (2). The communi-
`cations path is transparent to requesting software appli-
`cation (30). The method manages a plurality of commu-
`nications devices (42,44) using existing communications
`infrastructure.
`
`19 Claims, 9 Drawing Sheets
`
`10
`
`ENDPOINT
`
`4 couuumcmou PATH
`
`
`
`
`
`3 COMMUNICATION PATH
`
`
`SUBSCRIBER
`UNIT
`
`
`Microsoft Corporation
`
`Exhibit 1022-00001
`
`Exhibit 1022-00001
`
`Microsoft Corporation
`
`

`

`US. Patent
`
`Apr. 11, 1995
`
`Sheet 1 of 9
`
`5,406,643
`
`FIG.1
`
`1_o
`
`ENDPOINT
`
`
`
`
`
`
`4COMMUNICATION PATH
`
`:
`SUBSCRIBER
`UNIT
`
`3 COMMUNICATION PATH
`
`FIG.2
`
`
`
`
`EXTERNAL
`SOFTWARE
`INTERFACE
`__
`,
`l ——————————————————————————— 1—33
`|RUNTINE
`INTERNAL ,
`I ENGINE
`SOFTWARE I
`I
`INTERFACE I
`------"----"-—-- ""““""“'"“""TT‘
`4o
`35
`35 L!
`
`_—_—__——_—__— ———————————.———a
`
`
`
`Microsoft Corporation
`
`Exhibit 1022-00002
`
`Exhibit 1022-00002
`
`Microsoft Corporation
`
`

`

`US. Patent
`
`Apr. 11, 1995
`
`Sheet 2 of 9
`
`5,406,643
`
`PROTOTYPE
`ATTRIBUTE
`
`PATH
`CONFIGURATION
`
`STATUS
`
`PROTOTYPE
`HANDLE
`
`HANDLE
`
`DATA
`LINK
`HANDLE
`
`ATTRIBUTE
`LIST
`
`DATA LINK
`RESOURCE LIST
`
`PROTOTYPE
`HANDLE
`
`SESSION
`HANDLE
`
`DEVICE
`MANAGER
`
`DATA
`LINK
`HANDLE
`
`SESSION
`RESOURCE
`HANDLE
`
`FIG.6
`
`Microsoft Corporation
`
`Exhibit 1022-00003
`
`Exhibit 1022-00003
`
`Microsoft Corporation
`
`

`

`US. Patent
`
`Apr. 11, 1995
`
`Sheet 3 of 9
`
`5,406,643
`
` STORING LIST OF COMM PATHS
` 32
`
`IN MEMORY
`
`84
`
`ACCEPTING CONNECTION
`COMMAND
`
`
`
`
`
`86
`
`SELECTING FROM LIST AN
`AVAILABLE COMM PATH
`
`
`
`
`88
`
`,
`
`90
`
`ESTABLISHING A
`CONNECTION
`
`FIG.7
`
`Microsoft Corporation
`
`Exhibit 1022-00004
`
`Exhibit 1022-00004
`
`Microsoft Corporation
`
`

`

`US. Patent
`
`Apr. 11,1995
`
`Sheet 4 of 9
`
`5,406,643
`
`10%O
`
`CREATE A NEW SESSION
`
`’
`
`ISSUE COMMUNICATION
`COMMAND
`
`ROUTE COMMAND
`TD DEVICE MANAGER
`
`
`
`
` 160
`
`110
`
`12
`
`13.
`
`141
`
`15.
`
`CONTROL COMMUNICATION
`RESOURCES
`
`RETURN cowumcmon
`RESULTS
`
`
`FINISHED
`COMMUNICATING?
`
`
`
`YES
`
`17'
`
`DELETE A SESSION
`_
`
`,8 m
`
`FIG.8
`
`Microsoft Corporation
`
`Exhibit 1022-00005
`
`Exhibit 1022-00005
`
`Microsoft Corporation
`
`

`

`US. Patent
`
`Apr. 11, 1995
`
`Sheet 5 of 9
`
`5,406,643
`
`200
`
`205
`
`21o
`
`215
`
`220
`
`225
`
`CREATE A NEW SESSION
`
`REQUEST NEM SESSION
`
`EXAMINE PROTOTYPE LIST
`
`RESOURCES
`
`'
`
`A ALLOCATE COMMUNICATION
`
`25°
`
`SELECT BEST PROTOTYPE
`
`INITALIZE COMMUNICATION
`RESOURCES
`
`BIND TO PROTOTYPE
`
`MARK PROTOTYPE
`*5 ““55
`
`A00 OATA LINK
`
`RETURN REFERENCE TO
`OATA LINK
`
`A00 SESSION
`
`F I G 9
`°
`
`RETURN REFERENCE
`TO SESSION
`
`SAVE REFERENCE
`TO SESSION
`
`255
`
`235
`
`240
`
`245
`
`250
`
`255
`
`26°
`
`Microsoft Corporation
`
`Exhibit 1022-00006
`
`Exhibit 1022-00006
`
`Microsoft Corporation
`
`

`

`US. Patent
`
`Apr. 11, 1995
`
`Sheet 6 of 9
`
`5,406,643
`
`300
`
`305
`
`3m
`
`5
`
`DELETE A SESSION
`
`REQUEST DELETION
`0F SESSION
`
`OBTAIN DATA
`LINK REFERENCE
`
`.
`
`REQUEST DELETION OF
`DATA LINK
`
`320
`
`DE-INITALIZE & DE-
`ALLOCATE COMMUNICATION
`RESOURCES
`‘
`
`325
`
`o‘Tfifi’E'INEPErE'N E
`R
`c
`
`PR
`
`F I G . 1 0
`
`33o
`
`335
`
`_
`
`340
`
`345
`
`350
`
`355
`
`350
`
`ARK “IN:USE" PROTOTYP:
`As AVAILABLE
`
`DELETE DATA LINK
`
`PUBLISHING DATA LINK
`DELETION RESULTS
`
`RELEASE COMMUNICATION
`RESOURCES
`
`DELETE SESSION FROM
`SESSION LIST
`
`PUBLISH SESSION
`DELETION RESULTS
`
`REMOVE REFERENCE
`To SESSION
`
`365
`
`Microsoft Corporation
`
`Exhibit 1022-00007
`
`Exhibit 1022-00007
`
`Microsoft Corporation
`
`

`

`US. Patent
`
`Apr. 11, 1995
`
`Sheet 7 of 9
`
`5,406,643
`
`
`
`4<zmmhxm4<zxmth
`
`
`
`mm<ghmommm<gpkom
`
`an_¢n\\on_mu<kxmszuo<mxusz
`
`
`______._one._xu>zmm
`buxo<m__\n-FllllllllllllllL\J_lIIIIIIIIIIIIIIIIIIIII
`
`
`‘mpmw=owx"”Whmmscmx”ma>hoho=¢
`
`
`
`
`
`
`_____nupdeonmwmm_u_hmHaszA<h<=hmHaum>hohozm
`
`‘0*m.“onmmmm_¢J__szg<H<o=*
`
`
`____n*._on*..a._u_“warpOPO¢n"_~n*"_-¢mw=-ZH
`
`
`
`
`
`mumZO?mmmmmmz1mm“um>pohoxm
`
`__________
`
`..
`
`n_*
`
`Microsoft Corporation
`
`Exhibit 1022-00008
`
`Exhibit 1022-00008
`
`Microsoft Corporation
`
`
`

`

`US. Patent
`
`Apr. 11, 1995
`
`Sheet 8 of 9
`
`5,406,643
`
`an.
`
`mo<uzmth
`
`4<zmupxm
`
`ux<zhuow
`
`g<zmMPzH
`
`u¢<ghuom
`
`2:.
`
`o~+
`
`
`
`
`
`,on¢_u_3+_"onmmum
`
`nn+wmmzmmmg
`__¢J_
`onmmmm_.u“
`
`szd<h<o
`
`nuw
`
`szd<H<o
`
`hmHa22H;<h<o
`
`\JrIIIIII
` "mhmm99uzu___hmHaonwmmm_u____._zu>mum
`
`
` buxo<m___I'IIIIII'IL\a._+nmo<uzmth
`\Jrullllllallllllaaullli
`u¢>popozm c—+
`
`pmua
`
`mm
`
`vw|1IIL
`
`
`
`mmo<z<zuoH>mo_
`
`=+
`
`mm>po»omm
`
`~_v
`
`mm>hoho¢¢
`
`~+
`
`m>ho~o¢¢
`
`Microsoft Corporation
`
`EXhi
`
`it 1022-00009
`
`Exhibit 1022-00009
`
`Microsoft Corporation
`
`
`

`

`US. Patent
`
`Apr. 11, 1995
`
`Sheet 9 of 9
`
`5,406,643
`
`
`
`4<ZZm_xmA<zzwth
`
`
`
`wz<zpuommm¢gpmom
`
`
`uo<mmuPzHwo<mmuth
`nlllll‘lllJ fillllllllllllllllllll
`mm_.n\\on_an
`xzag<p<o_LT:E.nua“um>ho~oml“______u_Pm“;
`w¢>po~ozm“___________on.
`
`
`
`
`llllllllllllllIlll...zu>zuwbuxo<m___o~¢cw.mmg<z<zMUH>mc_ArllllllllllllllLArllllllll
`
`ZOHmmmm_u__mHJszd<P<c_mHJ
`mmmzu¢»h°p°m¢“_u".._N_+"u_u¢»po_ozl._n3.“2vum=IzH"_onmmmm
`.______n..“mumz
`
`
`
`
`
`.mwx“.“n._a_n~‘
`
`Microsoft Corporation
`
`Exhi it 1022-00010
`
`Exhibit 1022-00010
`
`Microsoft Corporation
`
`

`

`1
`
`5,406,643
`
`METHOD AND APPARATUS FOR SELECTING
`BETWEEN A PLURALI'I'Y OF COMMUNICATION
`PATHS
`
`RELATED INVENTION
`
`invention is related to the following
`
`The present
`inventions:
`(1) “Message Routing And Destination Selection”,
`having Ser. No. 771708, filed Oct. 4th, 1991, and as-
`signed to the assignee of the present invention.
`(2) “Simultaneous Control Of A Communications
`Channel In A Multi-Tasking System”, having Ser. No.
`876662, filed on Apr. 30th, 1992, and assigned to the
`assignee of the present invention.
`(3) “Method of Data Communication For Radio Fre-
`quency Modems Requiring Different Communications
`Protocols”, having Ser. No. 876644, filed Apr. 30th,
`1992, and assigned to the assignee of the present inven-
`tIOn.
`
`(4) “Method For Asynchronous Application Com-
`munication”, having Ser. No. 876889, filed Apr. 30th,
`1992, and assigned to the assignee of the present inven-
`tion.
`
`TECHNICAL FIELD
`
`This invention relates generally to data communica-
`tion and, in particular, to a method for distinguishing
`between a plurality of communication paths and select-
`ing from those a communications path for use.
`BACKGROUND OF THE INVENTION
`
`Data and voice communications technologies have
`advanced rapidly in recent years, leading to the immer-
`gence of different and typically incompatible communi-
`cation systems, such as paging, cellular, telephone data,
`and radio packet data. Initially, the users of such sys-
`tems accepted their inherent incompatibility. The mod-
`ern trend, however, is for system users to expect and
`demand higher levels of compatibility between and
`interconnection to the currently available communica-
`tions platforms. Thus, a cellular radiotelephone commu-
`nication system must interconnect with the land-line
`telephone system, and wireless LAN (local area net-
`work) systems must now operate as extensions of wired
`LANs in order to achieve and sustain commercial via-
`bility.
`In response to this pressure, manufacturers of com-
`munication-capable portable and fixed devices, such as
`personal organizers and laptop computers, are begin-
`ning to incorporate multiple communication technolo-
`gies into their products. It is anticipated that the device
`user will learn to view the different technologies as
`merely alternatives for performing the same type of
`operation.
`As the level of systems interoperability increases, the
`differences between the various communications tech-
`nologies, hereinafter referred to as media or medium,
`will become less important. Ultimately, it is anticipated
`that user involvement in the selection process will di-
`minish to a point where the user may not even know
`which media is being used at any given instant.
`To achieve this end, there is need for a method for
`enabling a portable subscriber unit
`to automatically
`select one of a plurality of available communications
`media based at least partly upon its knowledge of poten-
`tial communication paths. A need also exists for a data
`communications method that creates, for different soft-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`2
`ware applications, a common interface to communica-
`tions systems which typically employ incompatible
`communications protocols.
`Current
`techniques for providing communications
`media selection suggest routing all such inquiries to a
`central host for processing. Selection of the appropriate
`media is performed by the central host, whose decision
`may or may not be returned to the requesting device. As
`is appreciated,
`this process necessitates transmitting
`request traffic over a communications network. Such
`message traffic can significantly impact overall system
`throughput. Moreover, the centralized control of com-
`munications media selection may result in overloading
`during periods of high volume. Such systems typically
`require infrastructure upgrades and modifications in
`order to provide the requisite centralized control.
`It would be extremely advantageous therefore to
`provide a method and apparatus whereby a portable
`subscriber unit automatically selects one of a plurality
`of available communications media based on knowledge
`of the available communication paths.
`SUMMARY OF THE INVENTION
`
`Briefly described, the present invention is a method
`and apparatus for permitting a subscriber unit to select
`from amongst a plurality of communications media, that
`particular media for establishing a communications path
`to a specified end point According to one aspect of the
`invention, the method for permitting a subscriber unit
`having memory and communication resources to select
`one of a plurality communications paths to a designated
`destination comprises the steps of: storing in memory a
`list of communication paths having associated attri-
`butes; receiving a connection command comprising
`destination and communications criteria; selecting from
`the list, at least one communications path, as a function
`of destination; and establishing a connection to the se-
`lected communications path.
`A preferred embodiment of the present invention
`comprises a packet server module and at least one de-
`vice manager module, wherein a number of software
`application programs request data communications by
`interfacing to the packet server. The packet server
`maintains a session list identifying currently available
`connections (virtual links) to a specific end point, and
`selects a communications path based at least partly upon
`knowledge of the destination. The device manager
`maintains a list specifying the possible communications
`paths to specific end points and actually controls the
`communications resources responsible for establishing a
`communications path.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 depicts a subscriber unit in communication
`with an end point through one of a plurality of commu-
`nication paths;
`FIG. 2 is a block diagram of a data processing unit
`employed by the subscriber unit of FIG. 1;
`FIG. 3 is a functional block diagram of the control
`software used by the data processing unit of FIG. 2
`during data communications;
`FIG. 4 depicts the structure of a communications
`path prototype (CPP) record in accordance with the
`present invention;
`FIG. 5 depicts the structure of a data link record in
`accordance with the present invention;
`
`Microsoft Corporation
`
`Exhibit 1022—00011
`
`Exhibit 1022-00011
`
`Microsoft Corporation
`
`

`

`5,406,643
`
`3
`FIG. 6 depicts the structure of a session in accor-
`dance with the present invention;
`FIG. 7 is a flow chart diagram depicting the steps
`performed by the data processing unit of FIG. 2 under
`direction of the control software of FIG. 3 during com-
`munications path selection in accordance with the pres-
`ent invention;
`FIG. 8 is a flow chart diagram depicting the steps
`performed by the data processing unit of FIG. 2 under
`direction of the control software of FIG. 3 during data
`communications in accordance with the present inven-
`tion;
`FIG. 9 is a flow chart diagram depicting the steps
`performed by the data processing unit of FIG. 2 under
`direction of the control software of FIG. 3 during the
`creation of a session in accordance with FIG. 8;
`FIG. 10 is a flow chart diagram depicting the steps
`performed by the data processing unit of FIG. 2 under
`direction of the control software of FIG. 3 during the
`deletion of a session in accordance with FIG. 8;
`FIG. 11 comprises an architecture diagram of a pre-
`ferred embodiment of the present invention in a repre-
`sentative initial state;
`FIG. 12 comprises an architecture diagram of a pre-
`ferred embodiment of the present invention depicting
`the creation of a session;
`FIG. 13 comprises an architecture diagram of a pre-
`ferred embodiment of the present invention depicting
`termination of the session created in FIG. 12.
`
`DETAILED DESCRIPTION OF A PREFERRED
`EMBODIMENT
`
`The present invention has application to data commu-
`nications between personal computers and personal
`communicating devices. The data communications
`method provides a scheme for identifying a desired
`remote point of contact or end point, regardless of the
`devices or networks needed to support such communi-
`cations.
`FIG. 1 depicts a subscriber unit 2 communicating
`with an end point 10 through one of a plurality of com-
`munications paths 4, 6, and 8. Subscriber unit 2 is a
`communicating computer as described in detail below.
`End point 10 is any well-known destination to which
`the subscriber unit 2 wishes to connect, such as an Elec-
`tronic mail system, electronic database, communica-
`tions network, or another subscriber unit. Communica-
`tion paths 4, 6, and 8 represent the set of available com-
`munication paths from the subscriber unit 2 to the de-
`sired end point 10. Communications paths 4, 6, and 8
`may consist of wireless or wireline communications
`media such as, but not limited to,
`telephone lines,
`twisted pair wire, fiber-optic links, infrared channels,
`and radio frequency channels.
`FIG. 2 depicts a block diagram of a data processing
`unit 200 employed by the subscriber of FIG. 1 in order
`to provide communications in accordance with the
`present invention. The data processing unit 200 com-
`prises a central processing unit (CPU) 16, random ac-
`cess memory (RAM) 12, read only memory (ROM) 14,
`data entry device 20, display 22, and input/output (1/0)
`terminal 18.
`The CPU 16 with associated memory may be realized
`using a conventional microprocessor
`such as an
`MC68HC11 microprocessor which has in the past been
`from Motorla Inc. As will be appreciated, the CPU 16
`operates under control of an supervisory control pro-
`gram (Operating System) partially or wholly contained
`
`4
`in ROM 14 and utilizing RAM 12, to control in bound
`and out bound data traffic on terminal 18 and to per-
`form all tasks as initiated by the user, via data entry
`device 20.
`Data entry device 20 may comprise any of the well
`known data entry devices currently available which
`permit a system user to enter data and commands. Such
`devices include, but are not limited to, alphanumeric
`keys, touch screens, pressure or light sensitive pens,
`graphic user interfaces, computerized information pre-
`sentation systems, and voice activation schemes.
`In order to present information in a human perceiv-
`able form, the data processing unit 200 employs a dis-
`play unit 22. This display unit is selectable from, but not
`limited to any of the well-known visual display devices
`comprising CRT displays, LCD displays, LED displays
`and/or television monitors.
`In accordance with the present invention, data and
`control
`information are communicated between the
`processing unit 200 and media communications equip-
`ment (not shown), such as an infrared transceivers,
`fiberoptic transceivers, wire-line modems, and/or RF
`modems via I/O terminal 18. The communications
`equipment connected to I/O terminal 18 enables the
`subscriber unit 2 of FIG. 1 to communicate over the
`communication paths 4, 6, and 8 (FIG. 1).
`It will be appreciated by those skilled in the art that
`the structure of the processing unit 200 is presented as a
`preferred embodiment. The present invention, as here-
`inafter disclosed, will continue to operate as described,
`despite modifications to the processing unit 20 such as,
`for example, the deletion of data entry device 200 or
`display unit 22.
`FIG. 3 is a functional block diagram of control soft-
`ware used by the data processing unit 200 of FIG. 2
`during data communications in accordance with the
`present
`invention. The control software, hereinafter
`referred to as runtime engine 40, comprises functional
`blocks including packet server 34 and device managers
`36 and 38.
`External software for use with the runtime engine 40
`comprises application software 30 and application pro—
`grammer interface software (API) 32. Application soft-
`ware 30 comprises any computer software program
`wishing to communicate data in accordance with the
`present invention. API 32 is a library of communication
`routines which are called by application software 30
`and allow programs written in a specific program 1an~
`guage to access a communications device (not shown)
`through a predetermined set of function calls and net-
`work interface device 42,44. In a preferred embodiment
`the set of library functions comprise functions such as,
`but not
`limited to,
`open—session,
`close—session,
`get_message,
`send_.message, get_number_message,
`get—notification_configuration, set—notification_con-
`figuration, and get—number_messages. One or more
`pairings of application software 30 instructions and API
`32 routines may interface to packet server 34 through
`the external software interface 33 as delimited by run-
`time engine 40.
`Runtime engine 40 provides a uniform abstraction of
`available communication systems by providing a stan-
`dard set of data communication commands for applica-
`tion software 30, which is independent of the computer
`programming language utilized by application software
`30, or the ultimate path selected. During operation, API
`32 library calls are routed to packet server 34, which
`passes requests from one or more application software
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`55
`
`65
`
`Microsoft Corporation
`
`Exhibit 1022—00012
`
`Exhibit 1022-00012
`
`Microsoft Corporation
`
`

`

`5,406,643
`
`5
`programs 30 to one or more device managers 36 and 38.
`Thus, API 32 operates to provide a standard mapping of
`the specific computer programming language in which
`application software 30 is implemented into messages
`that can be passed to the packet server 34.
`Packet server 34 operates to manage a list of sessions.
`A session is a record representing the information re-
`quired by packet server 34 to interact with device man-
`agers 36 and 38 and a specific software application pro-
`gram 30. Device managers 36 and 38 control the wire-
`less and or wireline communications equipment han-
`dling requests from packet server 34 on behalf of appli-
`cation software 34]. Device manager 36 and 38 manage
`path prototypes and data links as described below. A
`path prototype is a record representing a potential phys-
`ical path to a designated end point. A data link is a
`record that represents an actual physical link to a previ-
`ously specified end point.
`Device managers 36 and 38 are independent executa-
`bles that interface to packet server 34 via an internal
`software interface 35 and also interface directly to the
`communications equipment (not shown) via wireless or
`wireline network interface devices 42 and 44. As will be
`appreciated, a single device manager can communicate
`with one or more network interfaces 42 and 44. Each
`network interface provides the necessary registers and
`line drivers for communicating with the communica-
`tions equipment and will
`typically include a CPU,
`RAM, and ROM if these resources are not available in
`the communications equipment. In accordance with the
`present invention, any number of device managers can
`communicate with packet server 34.
`FIG. 4 depicts the structure a communications path
`prototype (CPP) record in accordance with the present
`invention. CPP records 50 are maintained within a list
`in device managers 36 and 38, respectively, and define a
`potential path to a designated end point 10. As shown,
`each CPP record 50 comprises an END POINT
`NAME field 51, ATFRIBUTE LIST 52, CONFIGU-
`RATION LIST 53, STATUS FLAG 54, and PROTO-
`TYPE HANDLE field 55. In accordance with the
`present invention, each CPP record 50 is used to estab-
`lish a link in order to send data packets between applica-
`tion software programs 30 of FIG. 3 and an end point 10
`of FIG. 1.
`The disclosed record structure contains destination
`information, predefined communications path attri-
`butes, communication device commands, status and ID.
`END POINT NAME field 51 designates a specific
`remote message source or destination. Packet server 34
`can select a subset of all CPP records maintained within
`device managers 36 and 38 by using END POINT
`NAME field 51 as a selection criteria. This allows
`packet server 34 to identify those CPP records 50,
`herein also referred to as prototypes, which define di-
`verse physical paths to a designated end point 10.
`ATTRIBUTE LIST 52 is a list of pairs in the form
`(name, information) that describes the characteristics of
`a single actual communications path. Examples of spe-
`cific prototype attributes are (name=DIRECTION-
`ALITY,
`information=TWO-WAY), or
`(name:-
`BAUD, information=4800). The packet server 34 can
`select individual attributes from ATI'RIBUTE LIST
`52 by using the value of “name" as a selection criterion.
`This allows packet server 34 to compare the “informa-
`tion” field of a selected attribute against a value known
`to the packet server.
`
`5
`
`IO
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`CONFIGURATION LIST 53 contains information
`for automatically configuring communication equip-
`ment to establish a communication path to a source or
`destination specified by END POINT NAME field 51,
`whereby the communication path has the characteris
`tics identified in ATTRIBUTE LIST 52.
`
`STATUS FLAG field 54 contains a value indicating
`whether a CPP record 50 has an associated data link 60
`as described herein and below. When STATUS FLAG
`54 indicates the existence of a data link 60, the creation
`of a new data link using the present CPP record 50 is
`inhibited.
`
`PROTOTYPE HANDLE Field 55 is a secondary
`search key whereby packet server 34 can identify and
`select a specific CPP record 50 from the list maintained
`by a device manager 36 or 38.
`FIG. 5 depicts the structure of a data link record in
`accordance with the present invention. Data link re-
`cords 60 are maintained within the device managers 36
`and 38 and define a physical path to a designated end
`point 10. Device manager 36 maintains the list of data
`links, indicating at any given time the open connections
`to end points for a given device manager 36 or 38.
`As shown, the record structure consists of DATA
`LINK HANDLE field 61, ATTRIBUTE LIST 62,
`DATA LINK RESOURCE LIST 63 and PROTO-
`TYPE HANDLE field 64. DATA LINK HANDLE
`field 61 is the primary search key, by which packet
`server 34 can select a given data link from a list of data
`links maintained by device managers 36 and 38. AT-
`TRIBUTE LIST 62 is a list of pairs of the form (name,
`information) describing characteristics of the actual
`communication path represented by this data link, and
`similar to PROTOTYPE ATI‘RIBUTE LIST 52 of
`FIG. 4. DATA LINK RESOURCE LIST 63 is a list of
`parameters describing to device manager 36 or 38 how
`to automatically operate communication equipment
`associated with data link 60. PROTOTYPE HANDLE
`64 is a reference for a data link 60 to locate its associated
`CPP record 50 of FIG. 4 for the purpose of updating
`the STATUS FLAG field 54 of CPP record 50.
`FIG. 6 depicts the structure of a session in accor-
`dance with the present invention. Sessions 70 are main-
`tained within a list in packet server 34 and comprise the
`information required by the packet server 34 to interact
`with a data link 60 found within a device manager 36 or
`38.
`Each session 70 consists of a SESSION HANDLE
`71, DEVICE MANAGER HANDLE 72, DATA
`LINK HANDLE 73 and SESSION RESOURCE
`LIST 74. SESSION HANDLE 71 is the primary search
`key, allowing software application programs 30 of FIG.
`3 to select a particular session from a list of sessions
`maintained by packet server 34. DEVICE MANAGER
`HANDLE 72 provides a unique identifier for packet
`server 34 to select one device manager from a plurality
`of device managers 36 and 38. DATA LINK HAN-
`DLE 73 enables the packet server 34 to access a specific
`data link 60 from the data link list maintained by the
`associated device manager 36, specifically identified by
`the value of DEVICE MANAGER HANDLE 72.
`SESSION RESOURCE LIST 74 is a list of parameters
`specifying for packet server 34 how to interact with the
`selected device manager 36. Specifically, SESSION
`RESOURCE LIST 73 instructs how to perform com-
`munications on behalf of applications software 30 over
`the actual communications path associated with data
`link 60 as identified by the present session 70.
`
`Microsoft Corporation
`
`Exhibit 1022-00013
`
`Exhibit 1022-00013
`
`Microsoft Corporation
`
`

`

`5,406,643
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`7
`FIG. 7 is a flow chart diagram depicting the steps
`performed by the data processing unit of FIG. 2 under
`direction of the control software of FIG. 3 during com-
`munications path selection in accordance with the pres-
`ent invention. Commencing with begin block 80, flow
`proceeds to block 82 where a list of communication
`paths are stored in memory. This step corresponds to
`storing and maintaining prototypes (CPP records 50)
`within device managers 36 and 38. From block 82, flow
`proceeds to block 84 where the packet server 34 of 10
`FIG. 3 receives a connection command from software
`application 30 via API 32. This command contains des-
`tination information,
`i.e., END POINT NAME, and
`various communication criteria as established and de-
`sired by software application 30. Such criteria specify
`acceptable ranges of values for various communication
`attributes such as, for example, “transfer cost” must be
`less than $1.00 per kilobyte or “directionality" must be
`two-way.
`Flow proceeds from block 84 to block 86 where
`packet server 34 selects from said list at least one avail-
`able communications path based as a function of desti-
`nation. In this effort, the packet server 34 requests from
`device managers 36 and 38 all prototypes which have an
`END POINT NAME field 51 comprising information
`which corresponds to the destination information found
`within the connection command at black 82. Based
`upon receipt these prototypes, packet server 34 may
`select a communication path. In accordance with an-
`other aspect of the present invention, packet server 34
`can further delimit selection of a communications path
`based upon a comparison of the communications crite-
`ria in the communications command and the communi-
`cation path attributes as maintained in CPP records 50.
`From block 88, flow proceeds to block 90 where
`packet server 34 establishes the communication path
`connection in preparation for transmission of informa-
`tion between software application 30 of FIG. 3 and end
`point 10 of FIG. 1.
`FIG. 8 is a flow chart diagram of the steps performed
`by processing unit 200 of FIG. 2 under directions from
`the control software depicted in FIG. 3 during data
`communications in accordance with the present inven-
`tion. Commencing with begin block 100 when a sub-
`scriber unit 2 requests communications with an end
`point 10, flow proceeds to block 110 where the process-
`ing unit 200 creates a session 70. In accordance with a
`preferred embodiment of the present invention, at least
`one of the potential communications paths 4, 6, and 8, is
`selected as a function of destination. Such selection may
`further be qualified by criteria specified by software
`application 30. The creation of a new session is de-
`scribed in more detail below.
`When a session 70 has been successfully established,
`data communication can occur. Thus at block 120 a
`communications command is issued specifying the type
`of communication, i.e. send, receive, etc., communica-
`tion parameters,
`i.e. data buffers, etc., and a session
`reference identifying a session 70 over which the com-
`munication is to occur. At block 130, packet server 34
`routes the communication command 130 and the identi-
`fied session’s DATA LINK HANDLE 73 to the appro-
`priate device manager 36 or 38 using the session’s DE-
`VICE MANAGER HANDLE 72 of FIG.6.
`At block 140 the appropriate device manager 36 is-
`sues the proper control sequence to the communications
`equipment in accordance with the DATA LINK RE-
`SOURCE LIST 63 of the specific data link 60 of FIG.
`
`8
`5, as identified by DATA LINK HANDLE 73, allow-
`ing the data transfer to occur over the pre-selected
`communications path. At block 150 the appropriate
`device manager returns the results of the communica-
`tion to the software applications 30 via packet server 34.
`At decision block 160 a test is performed to determine
`whether communications is complete. If software appli-
`cations 30 is finished communicating, the session 70 is
`deleted 170. The session deletion process is described
`below in more detail. If software applications 30 is not
`finished communicating, then flow returns to block 120
`to issue another communications command.
`FIG. 9 is a flow chart diagram depicting the steps
`performed by the processing unit 200 of FIG. 2 under
`directions from the control software depicted in FIG. 3
`during session creation in accordance with the present
`invention. To create a new session, software applica-
`tions 30 issues a request 205 to packet server 34 for a
`new session, specifying communication criteria and an
`end point name 10 with which the subscriber unit 2
`wishes to communicate. The communication criteria
`are various attributes desired by software application 30
`for the new session, such as baud rate, packet size, tran-
`sit time, transfer cost, carrier ID, directionality, end
`point name, channel ID, etc.
`Packet server 34 requests from all device managers
`36, 38 CPP records 50 (prototypes) with the designated
`value of END POINT NAME 51 corresponding to end
`point 10. Each device manager 36, 38 publishes only
`those prototypes having the specified value of END
`POINT NAME 51 and having the value AVAIL-
`ABLE for STATUS FLAG 54. Packet server 34 exam-
`ines at block 210, the resultant prototype list and selects
`at least one prototype at block 215 based upon the
`matched destination information and further in light of
`the communication criteria specified within the new
`session request.
`The remainder of this description assumes that the
`“best match” prototype was published by device man-
`ager 36, although, in the alternative, it could have been
`published by device manager. Packet server 34 requests
`a "binding” at block 220 to the selected “best match”
`prototype from the prototype’s device manager 36,
`passing to device manager 36 a binding request includ-
`ing the value of the “best match” prototype’s PROTO-
`TYPE HANDLE 55.
`Device manager 36 sets the value of STATUS
`FLAG 54 of the “best match” prototype to IN-USE at
`block 225. Next, device manager 36 allocates and initial-
`izes the required communication resources, specified by
`the “best match” prototype’s PATH CONFIGURA-
`TION LIST 53 at blocks 2.30 and 235. At block 240, the
`device manager 36 adds a data link 60, representative of
`the actual communication path now allocated, and cop-
`ies the value of the “best match” prototype’s PROTO-
`TYPE HANDLE 55 to the PROTOTYPE HANDLE
`64 field of data link 60. At block 245, the device man-
`ager 36 return