PCT
`INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PC1)
`
`WORLD INTELLECTUAL PROPERTY ORGANIZATION
`International Bureau
`·
`
`(SI) International Patent Classification S :
`G06F9/46
`
`Al
`
`(11) International Publication Number:
`
`WO 94/11814
`
`(43) International Pu.blication Date:
`
`26 May 1994 (26.05.94)
`
`·~
`
`(21)Intematlona1Application Number:
`
`PCT/GB93/023 15
`
`(22) International Filing Date:
`
`10 November 1993 (IQ.11.93)
`
`(74)Agent: BURT, Roger, James; IBM United Kingdom Li-
`mited, Intellectual Property Department, Hursley Park,
`Wrnchester, Hampshire S021 2JN (GB).
`
`(30) Priority data:
`9223521.7
`
`10 November 1992 (10.11.92) GB
`
`(81) Designated States: JP, US, European patent (AT, BE, CH,
`DE, DK. ES, FR, GB, GR, IE, IT, LU, MC, NL, PT,
`SE).
`
`(71) Applicant (for all designated States except US): INTERNA(cid:173)
`TIONAL BUSINESS MACHINES CORPORATION
`[US/US]; Armonk, NY 10504 (US).
`.
`
`(72) Inventors ; and
`(7S) Inventors/Applicants (for US only): ALDRED, Barry, Keith
`[GB/GB); Dolphins, Malmesbury Gardens, Winchester,
`Hampshire S022 5LE (GB). BONSALL, Gordon, Willi(cid:173)
`am [GB/GB); 2 Court Road, Kings Worthy, Winchester,
`Hampshire S023 7QJ (GB). LAMBERT, Howard [GB/
`GB); 22 Nordik Gardens, .Hedge End, Southampton,
`Hampshire S03 4LQ (GB). MITCHELL, Harry, Davidd
`[GB/GB]; 18 The Hermitage, Richmond Upon Thames,
`Surrey TWIO 6SH (GB).
`
`Published
`.
`With international search report.
`Before the expiration of the time limit for amending the
`claims and to be republished in the event of the receipt of
`amendments.
`
`(S4)Title: COLLABORATIVE WORKING IN A NETWORK
`
`I APP PROG ~18
`18 ~ APP PROG I
`I (All MGR ~32
`__ --_-_=: = =-=------=:::. =~ -_-: .= _:] __ API ___ ~ :_-=_ ---=---~ ~ -==------.-=_-= -
`
`20
`
`RESOURCES
`
`SUPPORT SYSTEM
`
`LOGICAL
`DEVICES
`
`' · ..
`
`(57) Abstract .
`
`- -
`
`- --- -
`TOKEN RING
`
`~WlR
`
`I RS232 OEVl(E
`- - - - - - ___ @1 _ -- - - - - - - - . ------- ----T
`I ISDN DEVICE
`I OTHER OEVICE
`21
`211 DRIVERS
`
`28
`
`25 DRIVER
`
`6 DRIVER
`
`A programmable workstation for collaborative working in a network comprises a conventional operating system and a ne(cid:173)
`twork control program layer. Additionally, the workstati.on includes a collaborative application support subsystem for interfacing
`with application programs. The subsystem is responsive to predetermined application program calls to create a logical network
`model of a collaborative environment The model comprises sharing sets of application programs, which share data and resources
`across nodes and logical dedicated data channels connecting members of the s haring set. The subsystem cooperates with the ne(cid:173)
`twork layer to establish the physical links necessary.to implement the model in a physical network, transparently to the applica(cid:173)
`tion program.
`
`Petitioner Riot Games, Inc. - Ex. 1009, Cover-I
`
`

`

`FOR THE PURPOSES OF INFORMATION ONLY
`
`Codes used to identify States party to the PCT on the front pages of pamphlets publishing international
`applications under the PCT.
`
`AT
`AU
`BB
`BE
`BF
`BG
`BJ
`BR
`BY
`CA
`CF
`cc
`CH
`Cl
`CM
`CN
`cs
`CZ
`DE
`DK
`ES
`Fl
`FR
`CA
`
`Austria
`Australia
`Barbados
`Belgium
`Burkina Faso
`Bulgaria
`Benin
`Brazil
`Belarus
`Canada
`Central African Republic
`Congo
`Switzerland
`Cote d'Ivoire
`Cameroon
`China
`Czechoslovakia ·
`Cu:ch Republic
`Germany
`Denmark
`Spain
`Finland
`France
`Gabon
`
`CB
`CE
`CN
`CR
`HU
`IE
`IT
`JP
`KE
`KC
`KP
`
`KR
`KZ
`LI
`LK
`LU
`LV
`MC
`MD
`MC
`ML
`MN
`
`United Kingdom
`Georgia
`Guinea
`Greece
`Hungary
`Ireland
`Italy
`Japan
`Kenya
`Kyrgystan
`Democratic People's Republic
`of Korea
`Republic of Korea
`Kazakhstan
`Liechtenstein
`Sri Lanka
`Luxembourg
`Latvia
`Monaco
`Republic of Moldova
`Madagascar
`Mali
`Mongolia
`
`MR
`MW
`NE
`NL
`NO
`NZ·
`PL
`PT
`RQ
`RU
`SD
`SE
`SI
`SK
`SN
`TD
`TC
`TJ
`TT
`UA
`us
`uz
`VN
`
`Mauritania
`Malawi
`Niger
`Netherlands
`Norway
`New Zealand
`Poland
`Portugal
`Romania
`Russian Federation
`Sudan
`Sweden
`Slovenia
`Slovakia
`Senegal
`Chad
`Togo
`Tajikistan
`Trinidad and Tobago
`Ukraine
`·
`United States of America
`U7.bekistan
`Viet Nam
`
`Petitioner Riot Games, Inc. - Ex. 1009, Cover-2
`
`

`

`WO 94/11814
`
`PCT/GB93/02315
`
`1
`
`COLLABORATIVE WORKING IN A NETWORK
`
`DESCRIPTION
`
`This invention relates to collaborative working in a network and more
`specifically to a programmable workstation and a method for use in such a
`collaborative working environment.
`
`Background of the Invention
`
`Personal computers are now widespread throughout the business community and
`many are able to intercommunicate, either through fixed connections e.g.
`local area networks, or through dynamically established links e.g. ISDN or
`async lines over the public switched telephone network. Increasingly, these
`connected personal computers can be used to enhance collaborative working
`between remote individuals; a typical example being the use of desk top
`. conferencing software. Successful collaborative work generally requires
`more than a simple data link between the participants; voice capabilities
`are normally essential and video links are frequently required. Thus remote
`collaborative working can often be regarded as an extension to the
`traditional telephone call - it being enhanced with the data and programs
`available at the desktop via the personal computer - and, on occasions,
`enriched with video services.
`
`A broad spectrum of collaborative applications can be envisaged, ranging
`from utilities taking advantage of the data and applications on a
`workstation, e.g. sharing of screen windows and files, through to new
`collaborative applications designed to meet the needs· of specific classes
`of remote user e.g. just-in-time education, remote presentations, executive
`broadcasts or help desk. The common requirements behind these examples are:
`
`o
`
`o
`
`o
`
`the support of a wide variety of personal computer platforms - both
`hardware and software.
`
`operation over the existing communication networks.
`
`group communications and multi-media data services.
`
`Although desk top conferencing systems employing multi-media devices and
`communications channels exist, generally they are provided with a fixed set
`of system software and utility applications which is insufficiently
`
`SUBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 1
`
`

`

`WO 94/11814
`
`PCT/GB93/02315
`
`flexible to meet the needs of all potential applications.
`
`2
`
`Accordingly the present invention provides a programmable workstation for
`collaborative working in a network of workstations forming the nodes of the
`.ne~work, the network being connected by physical links for the transmission
`of data between nodes;
`the workstation comprising an operating system;
`a network control program layer, running on the operating system, for
`controlling physical routing of multi-medii data between nodei; and
`a collaborative application support program _layer for interfacing
`with application programs running on the workstation and responsive to
`predetermined application program calls to create a logical network model
`of a -collaborative environment comprising sharing sets of application
`programs, which share data and resources within and across nodes, and
`logical dedicated data channels connecting members of a sharing ~et of
`application programs, each ·data channel being defined by a sending port and
`a receiving port each associated with an application program, the
`collaborative application suppqrt program layer being adapted to cooperate
`with the network control program layer to establish the physical links
`necessary to implement the logical network model in a physical network,
`transparently to the application programs.
`
`According to another aspect,. the. invention also provides A method in which,
`in response to a predetermined program call by a first application program
`through which data is being transferred, via receiving and sending ports of
`the first application, between two other applications, the receiving port
`of the first application is reversibly directly connected to its sending
`port so that the data transfer bypasses the first application programs.
`
`The invention will now be described by way of example only with reference
`to Figures 1-25 of the accompanying_drawings.
`
`Detailed Description of the Invention
`
`In Figure 1 are shown two programmable workstations 10 and 12 connected by
`link 11 in a network, such as a LAN or WAN. The principal components of
`the workstations are conventionally described as layers, starting with the
`hardware 13. The hardware which is not illustrated in detail, consists of
`a processor unit with main memory, secondary storage such as a disk file, a
`display unit and input/output devices such as keyboard and mouse. Device
`support software 14 enables the hardware devices to function within a known
`operating system 15, such as IBM's Operating system/2 (OS/2).
`
`SUBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 2
`
`

`

`WO 94/11814
`
`PCT /GB93/02315
`
`3
`
`Also part of a conventional workstation, when used in a network, is
`networking software 16 for supporting connection to the network 11 and
`communication over the network between workstations. Typical networking
`software 16 could be the Netbios program product from IBM. Up to this
`point all that has been described is a conventional networking workstation
`capable of executing application programs 18.
`
`In order to implement the present invention, each workstation also includes
`collaborative application support system software 17 which facilitates the
`development of application programs for creating a distributed
`collaborative working environment.
`In this environment, end-users of the
`workstation may communicate with users of other workstations in the network
`over multi-media channels and may work collaboratively on shared data and
`tasks.
`
`The overall .structure of support system 17 in relation to other software
`components of the workstation with which it interfaces directly is shown in
`Figure 2. Further details of the internal structure of the support system
`are shown in Figure 10. Broadly speaking, the main functional components of
`system 17 lie between two interfaces 20 and 21, illustrated by dashed
`lines.
`
`An application programming inter.face 20 allows applications 18 to request
`support servic·es. A device driver interface 21 allows the system to
`support an extensible range of software and hardware communications sub(cid:173)
`systems through device drivers such as token ring driver 25, ISDN driver
`26, RS232 driver 27 and other device drivers 28.
`Link support modules
`228, 229 interface with the device drivers. These are replaceable, (Figure
`10 shows only a possible selection) depending on the hardware options
`available at the workstation, and serve to isolate the support system from
`needing to know precisely which hardware is present. Through an implicit
`resources interface, (not illustrated) details of the communications
`network, such as node addresses and directory data may be requested by both
`the support system, the applications and the device drivers from resource
`files 29.
`
`The API 20 allows applications 18 to initiate peer applications and share
`resources, on a variety of hardware and software platforms, located on
`nodes across a diverse and complex communications networks.
`It allows them
`to define multiple dedicated logical data channels between shared
`applications, suitable to a broad range of multi-media traffic,
`independently of the structure of the underlying physical network.
`
`It
`
`SUBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 3
`
`

`

`WO 94/11814
`
`PCT/GB93/02315
`
`4
`
`allows them to serialise, synchronise, merge or copy the data streaming
`between shared applications. It also allows them to support a range of
`attached devices and to allow the interception and redirection of the
`device data.
`
`The support system includes other components to assist application
`development such as an extensible set of logical devices 30, interfacing to
`external ·applications and devices. Also provided is a set of end-user
`utilities, written to the API (not illustrated}, which can also invoked
`from applications through a command interface.
`
`Network. nodes and applications·
`
`At the highest level, the programming model presented by the API consists
`of a communicating set of nodes. A node is the addressable entity
`representing a user, and comprises an instance of the support system
`software, and a set of resources such as application programs, data etc.
`Usually a node is typically a dedicated programmable workstation 10,
`capable of communicating with its peers; in a multi-user system a node is
`associated with each user.
`
`Nodes are either supported nodes or non-supported nodes; a supported node
`is one where the support system _software 17 is being executed. A
`collection of inter-communicating supported nodes is called a supported
`network.
`
`Nodes are identified by name; ideally all node names should be unique but
`duplicates can be tolerated as long as their associated nodes are never
`required to inter-communicate. The choice of node naming scheme is not
`directly relevant to the present invention, although a hierarchical system
`such as that defined by the Internet protocol has many benefits. It is
`fundamental to the architecture that a node can dynamically join or leave
`the network.
`
`Nodes can contain logical devices 30. A logical device is a software
`extension to the support system that allows an application to manipulate or
`manage software or equipment, in a manner consistent-with other entities in
`the architecture. There is an extensive range of possible logical devices
`including: presentation windows, printers, disk drives, modems, and
`application programs.
`
`Multiple applications can be executed at a node, subject to the constraints
`
`SUBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 4
`
`

`

`..
`
`WO 94/11814
`
`PCT /GB93/02315
`
`5
`
`imposed there by the operating and windowing system. Applications are
`either aware or unaware; an aware application uses the services of the API;
`an unaware application does not. Both aware and unaware applications will
`generally be executing simultaneously at a node.
`
`When the support system is fully active at a node, one particular aware
`application must be running at that node. This application plays a unique
`role at that node and is known as call manager 32. Many call managers may
`be available .for execution at a particular node but only one can execute at
`.a time. The distinguishing feature of a call manqger is that it responds to
`certain events generated by the support system; for example, it resolves
`any requests that are not directed specifically at an instance of an
`application, and optionally it may also handle resource management for the
`node. Call manager responsibility can be transferred from one call manager
`to· another; also the role can be combined with user application ·function if
`that is appropriate.
`
`The support software 17 may request that the resources of one node are made
`available for communication between two other nodes; this is termed passive
`operation and permission is controlled by the call manager at the passive
`node. As an example, consider two nodes A and Bon a LAN, with a third node
`C connected to B by an asynchronous communications link. If applications at
`A and C wish to communicate., the. traffic will need to be routed via B. The
`consent of the call manager at Bis required for this use of its node.
`
`Aware applications can share data and resources with other aware
`applications at the same or different nodes. A collection of applications
`sharing is called a sharing s~t. An aware application initiates a share
`request, naming an application sharing set, a target application and a
`destination node. This request is first passed by the support software to
`the call manager at the sending node, which will typically transfer it to
`the call manager at the destination node. Usually this second call manager
`will launch the requested application and the source application will be
`informed. The participation of .the call managers in this process allows
`both local control of the sharing process and other actions to be initiated
`if necessary. The call managers play a vital role in resolving the names
`used by applications to idnetify other nodes and applications. The sh.aring
`mechanism can be cascaded; for example, if two applications are already
`sharing, one of them can initiate a share with a third application naming
`the same sharing set, with the result that all three applications are then
`sharing with each other.
`
`SJJBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 5
`
`

`

`WO 94/11814
`
`PCT/GB93/02315
`
`6
`
`Applications may also make lo~al share requests on behalf of other
`applications thereby allowing membership control of the sharing set to be
`delegated; Facilities exist for either the issuer, or the· target of the
`share request, to name the application sharing set. These names are not
`required to be unique: thus multiple sharing sets with the same name can
`exist.
`
`Individual applications can cease sharing at any time, withdrawing from a
`~haring s&t; the other applications in the set are informed of the
`withdrawal. Figure 3 shows a number of applications A-E sharing. This
`results in two sharing sets, irrespective of the order in which the shares
`were requested, as illustrated in Figure 4.
`
`Communications. channels and ports
`
`As illustrated in the schematic example of Figure 5, applications in a
`sharing set such as 40, 41 and 42 can establish data communication links
`with each other known as channels. Channels such as 43 and 44 are
`logically dedicated and uni-directional pipes, with application specified
`transmission characteristics. A channel is always defined by the sending
`application and it goes from a sending application to a receiving
`application. The ends of channels are known as ports; thus all channels
`have one sending port and one receiving port. A sending port such as 45
`sends data packets down the channel; a receiving port such as 46 receives
`data packets from the channel in the order in which they were sent. There
`may be no direct mapping between the logical channel structure seen by the
`aware applications and the physical communication network in existence
`between the nodes ..
`
`An application may establish multiple channels .to another application as a
`convenient way to separate data traffic of different types. The system
`network manager 31, Fig. 2 may map some or all of the logical channels on
`to a single physical link such as link 11, Fig. 1 but this will be
`invisible to the application.
`
`Channels have a number of quality of service characteristics, initially
`negotiated with the support system 17 during the creation process, which
`allow data transmission characteristics to be tailored to the requirements
`of the expected traffic. These characteristics include encryption,
`compression hints. Encryption allows the data to be encrypted during
`transmission along the channel; compression·hints allow the system the
`option of compressing the data over narrow bandwidth links.
`
`SPBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 6
`
`

`

`WO 94/11814
`
`PCT/GB93/02315
`
`7
`
`Quality of service parameters are defined according to signal type, which
`distinguishes analog from digital data. They need not be specified
`explicitly, but can be notified to the support system in terms of data
`classes. This mechanism allows video channels; voice channels and other
`data channels to be sensibly established. Channel characteristics can be
`re-negotiated after channel creation. The data transmission characteristics
`are implemented in the real .network by means of the data transformation
`manager 32, Fig. 2 in response to the characteristics specified in the
`channel c1·eation calls over the API.
`
`Four types of channel are supported: standard, merged, synchronous and
`serialised. Standard channels ·are the default case; the other types are
`used in conjunction with collections of channels, known as channel sets.
`Through a merged channel set data packets are combined from multiple
`channels and delivered to each receiving application through a single port.
`There is no guarantee that each application receives all the data packets
`in the same sequence, only that each application receives all the packets.
`Through a serialising channel set data packets are combined from different
`channels, serialised, and delivered to each application such that each
`receiving port receives the same sequence of data. Through a synchronising
`channel set data is synchronised, so that the data packets on separate
`channels are tied together in time (for example voice with video), but
`delivered through the individual ports belonging to the channels.
`
`An example of data serialisation is illustrated by a shared drawing board
`application illustrated in Figure 6. Two identical applications, A and B
`(SO and 52), allow their users to draw on a single shared surface. In order
`that the users at A and B see identical results, all the drawing orders at
`A must be sent to B via ports 53 and 54, and vice versa via ports.55 and
`56, in such a way that the sequence processed at A and Bis identical. This
`is accomplished by each transmitting their own data both to each other and
`to themselves, over two channels 57 and 58 which are members of a common
`serialising channel set 59.
`
`With reference to Figure 4, data synchronisation is illustrated by an
`application A (60), that needs to send lip-synchronised video and voice to
`application B (61). Two channels 62 and 63 are used for the transmission,
`each being a member of the same synchronising channel set 64.
`
`Channels can be explicitly created by an API call to the support system,
`specifying the required channel characteristics, and new channels can also
`be added to an existing port. The latter mechanism allows a port to be
`
`SµBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 7
`
`

`

`WO 94/11814
`
`PCT/GB93/02315
`
`8
`
`shared across channels belonging to different channel sets; for example
`data can be sent from a single port to one set of destinations belonging to
`a merged channel set, and to a second set of destinations belonging to a
`serialised channel set. Digital channels and analog channels cannot be
`members of the same channel set. A channel can be deleted, the channel
`being uniquely identified by specifying its sending and receiving ports.
`
`Channels can be implicitly created as a consequence of an application
`being, or becoming, a member of an application sharing set. For example, if
`unshared applications already ahve a merged or ·serialized channel, and the
`channel set name iused is identical across these applications, then when
`the applications share with each other, the additional channels required
`will be created automatically. Appli~ations are notified of channels
`implicitly created in. this way.
`
`Ports have an assigned connect type: event, command or null. Event ports
`generate an event when data is either available or is required; command
`ports allow the application to drive the receipt or supply of data to the
`port. Null ports are reserved· for ports that are unable to supply data to
`an application e.g. ports associated with analogue channels, such as the
`sending port of a video camera. Ports can be controlled through
`"signal_port" commands sent to their port event handler. These can be
`issued to the local port and can be passed to any other port in the
`channel. Normally, the singal commands for channel ports will be sent to
`the port event handler of the application either supplying or receiving
`data, and may be used for· example to stop, start, decrease or increase the
`data flow. The order of signals between a source and target is maintained.
`Signals sent to receiving ports in a serialising channel set are serialised
`themselves, so that all.sources receive the same sequence of commands.
`Other typical signals are "rewind" or "pause" to a tape drive, or "change
`paper size" to a printer device.
`
`User exits can be optionally associated with ports. This allows monitoring
`or manipulation of the data, after it has been supplied to a sending port,
`or before being presented by a receiving port. In the case of synchronised
`channels, synchronisation is performed from after the dat~ leaves the
`sending port user exit, and up to the data being presented to the receiving
`port user exit ..
`
`The overall structure of a standard sending command port is shown in Figure
`8. In response to a 11 send_data 11 command from an application, data is queued
`in a buffer 71 of port 70. The application empties the buffer to send data
`
`S_µBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 8
`
`

`

`WO 94/11814
`
`PCT /GB93/02315
`
`9
`
`Incoming
`asynchronously over a channel-73 via a user exit 72.
`11 signal_port 11 commands are received by the port event handler 74,
`independently of channel 73 on line 75 and can be retransmitted outwardly
`on line 76.
`
`..
`
`Receiving ports are effectively the mirror image of the corresponding
`*sending port. For a standard receiving event port the structure is
`similar, but in this case the event handler processes both the data and the
`port commc:nds.
`
`The situation is more complex when synchronisation is involved. In this
`case a standard receiving buffered port must be modified by the inclusion
`of the synchronisation process on the incoming channel prior to the user
`exit and the buffer.
`
`Serialisation logically involves the collection of all events in a central
`point, followed by the broadcast of each event to all the destinatio~s for
`that event. Diagrammatically, this is represented by Figure 9 for the case
`of two ports A and Bon channels 80 and 81, serialising their output at 82
`and 83 to port C (84) and another port (not shown) in serialising process
`85. Serialisation can be implemented at a single central point with all
`data being sent there for serialisation and subsequent distribution;
`alternatively the serialisation process itself can be distributed.
`
`A receiving port can cause the sending port to stop sending data down the
`channel, with the option to either discard or deliver the remaining data in
`the channel. Suspended data transmission can be resumed subsequently.
`
`An alternative method of application inter-communication, avoiding the use
`of channels and ports, is provided through a "signal" command which allows
`control information to be sent between applications.
`
`Ports are associated with a data class which specifies data type and data
`sub-type. The data type identifies the nature of the data, e.g. voice,
`video, file etc. and also distinguishes analogue from digital data. The
`data types are further subdivided according ~o the precise format of the
`data; thus examples of voice sub-types are G.711, G.721, G.722.
`
`The data class may be queried by an application to obtain the data format,
`independently of the data stream itself, without relying on other
`applications. Additionally, the data type may be different at the sending
`and receiving ports, with Lakes performing the conversions below the AP!.
`
`Sf.JBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 9
`
`

`

`WO 94/11814
`
`PCT /GB93/02315
`
`10
`
`Certain characteristics of ports and channels can be changed after they
`have been initially established; for example, quality of service, data
`class and compression hints. This provides the flexibility for an
`application to modify its communications usage during execution; an example
`being the temporary degradation of video quality to improve file exchange
`performance.
`
`Ports can be connected together to establish extended communication links,
`so that an application may route its inputs through to anothei application
`for processing. When ports are connected in this way, and providing user
`exits have not been established, no further application involvement is
`required after the routing has been established. This allows the
`streaming of data between applications and devices. Connection is permitted
`between channels in different channel sets, of different types, having
`different quality of.service characterist~cs, of different data class or
`different connect types (unless one of the ports is null), provided only
`that one port is sending and one port is receiving. Connected ports can
`also be welded, so that the connection is permanent and persists even when
`the local application has terminated. The channel behaves in all respects
`as though it had been originally created from its source directly to its
`destination. Any user exits which may_be present are removed.
`
`Logical Devices
`
`Logical Devices 30 (Fig. 2) are supported by the support system to enable
`(i) easier access to system resource and devices, such as clipboard, DDE,
`printer and video devices, (ii) unaware applications to be used for
`collaborative working, for example by giving access to the window contents
`and file activity of an unaware application, and (iii) end to end data
`streaming without application involvement. Frequently used devices include:
`video capture, video playback, audio playback etc. and facilities are
`provided for additional devices to be defined.
`
`Logical devices are identified by type; the type names are local to a node.
`When opened, they present a port to the application; a single logical
`device can have multiple ports, moreover a device can simultaneously
`present ports to different applications at the same node. The relevant API
`call to open a port allows characteristics to be established, peculiar to
`that device, for example the data formats to be used. Opened logical
`devices can be controlled through commands sent to the signal port, the
`commands being specific to the particualr logical device. Typical commands
`to a device port are rewind or pause to a tape drive. The device status,
`
`SJJBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 10
`
`

`

`·,,
`
`WO 94/11814
`
`PCT/GB93/02315
`
`for example whether data is available, can also be queried.
`
`11
`
`Devices are exactly like channel ports, except that no user exit is
`present. Applications can connect ports on logical devices to a channel
`port; this enable data to flow to or from the device and across the
`channel. This data flow does not require further application involvement
`once the connection has been made. For example, data can be streamed from a
`camera through a camera logical device, across a channel, and displayed by
`a window logical device. The application can control the two logical
`devices via there signal ports; when the transmission is no longer
`required, the application can disconnect the ports, close the devices and
`remove the channel.
`
`Device ports cannot be welded to channel ports, since this would allow a
`device to exist outside the control of a local application. Logical devices
`are permitted to issue AP! calls to the support system, and in this regard
`act on behalf of the owning application (ie the application which opened
`the device). Devices for example can cause their owning application to
`share with other applications,·create channels, and send or receive data.
`
`Potential devices include:
`
`system clipboard
`DDE
`shared clipboard
`serial emulator
`video
`audio
`
`LPTx
`window
`printer
`file
`codec
`telephone
`
`Shared use of the clipboard is facilitated by the system clipboard and the
`shared clipboard devices. The system clipboard device may be opened by an
`application to provide a sending and a receiving port, giving access to the
`windowing system clipboard data at that node. Only one sending port may
`exist at any time, but any application at that node may open receiving
`ports. Through the use of channels, system clipboard data from one node,
`can be simply routed across to other members of an application sharing set.
`
`Another device, the shared clipboard, is provided to ease data sharing. It
`is unique to a sharing set; only one sending port is allowed but multiple
`receiving ports are supported. Apart from these distinctions, it behaves in
`a similar manner to the system clipboard and provides a simple mechanism
`
`SpBSTITUTE SHEET
`
`Petitioner Riot Games, Inc. - Ex. 1009, p. 11
`
`

`

`WO 94/11814
`
`PCT/GB93/02315
`
`for applications to share common data.
`
`12
`
`The window device, allows a window, defined on the screen, to be associated
`with a sending or a receiving port (or.in some circumstan