(12) United States Patent
`Maltby et al.
`
`US006202100B1
`US 6,202,100 B1
`Mar. 13, 2001
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`(54) OBJECT LINKING AND EMBEDDING OVER
`A COMPUTER NETWORK
`
`(75) Inventors: John Maltby, EmsWorth; Simon
`Phipps, Southampton; Vince Singleton,
`Northants, all of (GB)
`
`(73) Assignee: International Business Machines
`Corporation, Armonk, NY (US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl. No.: 08/395,548
`(22) Filed:
`Feb. 28, 1995
`(30)
`Foreign Application Priority Data
`
`Mar. 23, 1994
`
`(GB) ................................................ .. 9405757
`
`Brockschmidt, Kraig, “Introducing OlE 2.0, Part I: Windows
`Objects and the Component .
`.
`. ”, Microsoft Systems
`Journal, v8 n8 p. 15(9), Aug. 1993.*
`
`(no author given), “Microsoft mulls OMG compliance for
`Cairo”, PC Week, v10, n42, p. 3(1), Oct. 1993.*
`
`Orfali, Robert, Dan Harkey, “Client/Server Survival Guide
`With OS/2”, Van Nostrand Reinhold, pp. 745—753, 1994.*
`
`PoWell. James E., “HiJaak 1.0”, WindoWs Magazine, 1992,
`n. 311 p. 310, Dec. 1992.*
`
`Microsoft Visual C++ Programmer’s Guides 1993 pp. 273—
`Ch. 18 Ole Support.*
`
`Welch, Kevin P. “Inter Program Communications Using
`Windows’ Dynamic Data Exchange” Microsoft Systems
`Journal Nov. 1987.*
`
`(51) Int. Cl.7 ...................................................... .. G06F 9/00
`
`* cited by examiner
`
`(52) US. Cl. ............................................................ .. 709/329
`
`(58) Field of Search ................................... .. 395/650, 700;
`709/329, 310—332
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,408,470 * 4/1995 Rothrock et al. .................. .. 370/261
`5,446,896 * 8/1995 Hegarty et al.
`707/1
`5,452,299 * 9/1995 Thessin et al. .................... .. 370/260
`
`FOREIGN PATENT DOCUMENTS
`
`1/1989 (EP) ............................... .. G06F/9/46
`0380211
`0474339 * 11/1992 (EP) ............................... .. G06F/9/44
`
`OTHER PUBLICATIONS
`(no author given) “Object Linking & Embedding”,
`Microsoft Corp. pp. 1—45, Nov. 6, 1991.*
`William, Semich, J ., “Uncertain Future: What’s the Next
`Step After Client/Server?”, Datamation, v40, n6, p. 26(7),
`Mar. 1994.*
`
`Primary Examiner—St. John Courtenay, III
`(74) Attorney, Agent, or Firm—Jeanine S. Ray-Yarletts
`
`(57)
`
`ABSTRACT
`
`A user at computer A submits material from an application
`APPNA onto the clipboard at that machine. A routine CLIP
`SEND, part of conferencing softWare P2P-A at computer A
`obtains a list of available formats for the material on the
`clipboard, and transmits this list to a second machine,
`computer B. This list is received by conferencing softWare
`P2P-B at computer B, and a routine CLIP RECEIVE, part of
`P2P-B, submits the list to the clipboard at that machine. The
`user at machine B can then embed an object originally from
`APPNAby OLE pasting into an application at computer B,
`APPN B. in the normal manner.
`
`10 Claims, 3 Drawing Sheets
`
`CLIP SEND BECOMES VIEWER OF CUPBOARD A
`(SETCLIPBOARDVIEWER)
`
`310
`
`APPN A SUBMITS MATERIAL TO CUPBOARD A
`(SETCLIPBOARDDATA)
`I
`
`,7
`
`CLIPBOARD A SENDS NOTIFICATION TO CLIP SEND
`(WM_DRAWCLI PBOARD)
`
`CLIP SEND OBTAINS LIST OF FORMATS ON CLIPBOARD A
`(ENUMCLIPBOARDFORMATS)
`
`33D
`
`340
`
`T CLIP SEND SENDS LIST OF FORMATS TO CLIP B $1 35”
`I
`I
`CLIP RECEIVE BECOMES OWNER OF CLIPBOARD 541A’
`SETCLI PBOARDOWNER)
`(
`I
`350
`
`‘
`
`CLIP RECEIVE SUBMITS DATA TO CLIPBOARD B
`(SETCLI PBOARDDATA)
`
`370
`
`Petitioner Microsoft Corporation - Ex. 1072, p. 1
`
`

`
`U.S. Patent
`
`Mar. 13, 2001
`
`Sheet 1 of3
`
`US 6,202,100 B1
`
`FIG. 1
`
`12
`
`16
`
`,u p
`
`, 24
`MEMORY /\
`
`T RING
`
`\f‘
`
`\30
`
`NETWORK
`
`A
`
`CLIP
`SEND
`
`P2P-A
`
`COMMS
`
`B
`
`P2P-B
`
`CLIP
`RECEIVE
`
`APPN A CLIPIZOARD
`
`APPN B
`
`CLIPBBOARD
`
`Petitioner Microsoft Corporation - Ex. 1072, p. 2
`
`

`
`U.S. Patent
`
`Mar. 13, 2001
`
`Sheet 2 of3
`
`US 6,202,100 B1
`
`CLIP SEND BECOMES VIEWER OF CUPBOARD A
`(SETCLIPBOARDVIEWER)
`
`/\, 310
`
`v
`APPN A SUBMITS MATERIAL TO CLIPBOARD A
`(SETCLIPBOARDDATA)
`
`CLIPBOARD A SENDS NOTIFICATION TO CLIP SEND
`(WM_DRAWCLIPBOARD)
`
`320
`
`330
`
`V
`CLIP SEND OBTAINS LIST OF FORMATS ON CLIPBOARD A
`(ENUMCLIPBOARDFORMATS)
`
`’\¢ 340
`
`CLIP SEND SENDS LIST OF FORMATS To CLIP B
`
`4’ 35a
`
`cup RECEIVE BECOMES OWNER OF CUPBOARD B
`(SETCLIPBOARDOWNER)
`
`/\. 360
`
`\
`CLIP RECEIVE SUBMITS DATA TO CLIPBOARD B
`(SETCLIPBOARDDATA)
`
`/\~ 370
`
`Petitioner Microsoft Corporation - Ex. 1072, p. 3
`
`

`
`U.S. Patent
`
`Mar. 13, 2001
`
`Sheet 3 of3
`
`US 6,202,100 B1
`
`FIG. 4
`
`USER AT B SELECTS FORMAT
`(GETCLIPBOARDDATA)
`
`4
`\/\ 10
`
`CLIPBOARD B ASKS CLIP RECEIVE FOR FORMAT w
`(WM_RENDERFORMAT)
`42"
`
`I
`CLIP RECEIVE SEND MESSAGE TO CLIP SEND \/\ 430
`
`I
`CLIP SEND REQUESTS DATA FROM CLIPBOARD A
`(GETCLIPBOARDDATA)
`@ 440
`
`I
`CLIP SEND RECEIVES DATA FROM CLIPBOARD A \/\ 450
`
`I
`CLIP SEND FORWARDS DATA TO CLIP RECEIVE \/\ 460
`
`I
`CLIP RECEIVE PASSES DATA TO CLIPBOARD B \/\
`(SETCLIPBOARDDATA)
`47 0
`
`I
`APPN B RECEIVES DATA FROM CLIPBOARD B M 480
`
`Petitioner Microsoft Corporation - Ex. 1072, p. 4
`
`

`
`US 6,202,100 B1
`
`1
`OBJECT LINKING AND EMBEDDING OVER
`A COMPUTER NETWORK
`
`Related applications: Background information useful for
`an understanding of the present invention may be found in
`US. patent application Ser. Nos. 08/149,487 and 08/203,067
`?led on Nov. 9, 1993 and Feb. 28, 1994 respectively in the
`name of IBM Corporation, Which are incorporated herein by
`reference. Copies of these tWo applications are ?led With this
`application.
`The present invention relates to a method of providing
`object linking and embedding (OLE) over a computer
`netWork, in Which an object from a ?rst application at a ?rst
`computer in the netWork is incorporated into a second
`application at a second computer in the netWork.
`A personal computer running a multi-tasking operating
`system such as OS/2 or WindoWs1 can support more than
`one application running simultaneously. It is sometimes
`necessary for a user to be able to copy data from one
`application to another, for example to copy numbers from a
`spreadsheet into a report being prepared on a Wordprocessor.
`One Way of performing this transfer is to Write the data from
`the ?rst application into a ?le on the hard disk, and then
`retrieve the ?le into the second application. This is simple
`but relatively cumbersome.
`1OS/Z is a trademark of International Business Machines Corporation and
`Windows is a trademark of Microsoft Corporation
`The OS/2 and WindoWs operating systems provide a more
`sophisticated facility, knoWn as the clipboard, for perform
`ing such an operation. Applications copy data onto the
`clipboard (effectively a piece of memory Which they then
`surrender to the operating system). Another application can
`then interrogate the operating system to ?nd out What is
`available on the clipboard, and if desired take a copy of the
`data from the clipboard. Normally an application Will Write
`the data into the clipboard in several different formats, and
`the receiving application Will then specify in Which of these
`data formats it Would like to receive the data. There are
`several standard formats, Which are available for all appli
`cations to use. The clipboard can be used for exchanging
`text, images, and so on.
`One slight complication is that the clipboard supports
`delayed rendering. In this case, the data itself is not supplied
`to the clipboard for a particular format, rather only a
`reference to the data. The data itself is supplied by the
`originating application only When that particular format is
`requested by another application. It is possible to use
`delayed rendering for some, all or none of the formats for
`any particular piece of data posted to the clipboard.
`A typical situation in Which a user might employ the
`clipboard function Would be to copy a portion of text from
`one document to another. The user (generally With a mouse
`and cursor) Would ?rst identify the text to be copied from the
`?rst (server) application, and then select the appropriate
`menu option to place this text in the clipboard. The appli
`cation Would then pass the text to the operating system in a
`variety of formats—for example, as a text ?le, as a bit map,
`as a meta?le, as a miniature document complete With format
`information, and so on. The operating system speci?es a list
`of common predetermined formats, but it is also possible for
`the application to use its oWn particular or private format.
`The formats are normally listed in order of preference, the
`most preferred format being that Which preserves most
`information from the server about appearance etc (eg ASCII
`text might be the least preferred format, since it contains no
`formatting information at all). The user in another (client)
`application can then request that the text/data is retrieved
`from the clipboard. Such a request results in the application
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`2
`being asked to select one of the available formats. The
`application may decide automatically Which format to take
`(perhaps it can only accept a particular format), or it may
`pass this choice on to the user; typically the most preferred
`format recognised by the client application Would be
`accepted.
`An application can request (via an operating system call)
`to become the oWner or vieWer of the clipboard. Becoming
`the oWner is necessary for delayed rendering for the appli
`cation to receive noti?cation Whenever text/data is requested
`from the clipboard. Becoming a vieWer of the clipboard
`results in the application receiving noti?cation Whenever
`another application Writes something to the clipboard.
`The clipboard is Well-suited to one-off transfers. HoW
`ever, if a particular piece of data in the ?rst application is
`updated regularly, and each of these updates is to be copied
`across to the second application, then repeated use of the
`clipboard becomes tedious and aWkWard. This problem is
`addressed by the provision in OS/2 and WindoWs of an
`additional function, termed dynamic data exchange (DDE).
`In DDE a link is set up to copy data from a ?rst application
`(the server) to a second application (the client). As the name
`implies the link is dynamic, in that for as long the link is
`maintained, modi?cations to the selected entry in the server
`application are automatically copied to the client applica
`tion. In other Words, the client contains a shadoW or mirror
`of the data in the server.
`An application in OS/2 or WindoWs can initiate DDE by
`one of tWo methods. In the ?rst (Which in practice is hardly
`ever used) an application broadcasts an INITIATE message
`to other applications executing on the node. The message
`contains the folloWing information: Application Name,
`Topic, Item, in an ASCII text string, using Zeroes as delim
`iters. The ?rst of these is used to identify the originating
`application, the topic is then used to specify some particular
`data ?le or Whatever, Whilst the item indicates a position
`Within the data ?le. For example, a spreadsheet program
`Would give the spreadsheet name as the topic and perhaps
`use “R1C1” as the item to identify the data cell in the ?rst
`roW and in the ?rst column. Applications receiving the
`message that Wish to participate in DDE With the originating
`node respond positively, and a DDE conversation can then
`be set up.
`The second method, Which has become the de facto
`standard, is to initiate DDE via the clipboard. When a piece
`of data is copied to the clipboard, one of the formats used is
`a private format representative of DDE (under Microsoft
`WindoWs conventionally this private format is “Link”). The
`data stored With this private format is in fact the Application,
`Topic, and Item parameters described above. When the user
`retrieves this data into the second (client) application, this
`private format is indicated as providing DDE. When this
`option is selected, the client application responds requesting
`the start of DDE. This response is actually performed by
`broadcasting a message including the application and topic
`Which is recognised by the originating server, leading to the
`commencement of the DDE conversation. Note that the
`conversation actually occurs betWeen tWo WindoWs, one
`belonging to the server and one belonging to the client.
`These are accessed by identi?ers knoWn as WindoW handles.
`The user can therefore initiate a DDE connection betWeen
`the server application and the client. At the start of this DDE
`conversation, the server and client negotiate regarding the
`data format to use for data transfer betWeen them. Obviously
`for DDE to Work the client and server must be compatible,
`
`Petitioner Microsoft Corporation - Ex. 1072, p. 5
`
`

`
`US 6,202,100 B1
`
`3
`to the extent that the client recognises the private format
`placed on the clipboard by the server as an invitation to DDE
`and they support at least one data format in common.
`Another approach to the transfer of data betWeen appli
`cations is provided in Microsoft WindoWs and is termed
`Object Linking and Embedding (OLE). OLE is someWhat
`similar to a standard clipboard transfer betWeen applica
`tions, eXcept that instead of transferring the data as a bit
`map, teXt string or Whatever, the data is transferred as an
`object. In OLE a selected piece of data (an object), is cut
`from a ?rst application (the source or server) and added to
`the clipboard in normal fashion. Private formats are used to
`indicate that Object Linking and/or Object Embedding are
`available (OLE actually represents tWo separate facilities);
`the data associated With these formats speci?es the (server)
`application name and topic and item in the same format used
`for DDE. In Object Embedding the data is also added to the
`clipboard in a so-called “native” format, Which contains all
`the information needed to alloW the source application to
`further process the data. If either OLE format is selected
`from a second application (the client or target), the object is
`pasted into the second application. At this stage the pasted
`material is visible as if a normal clipboard transfer had been
`performed: this is achieved by also copying another suitable
`format from the clipboard to alloW display of the data
`(typically this is the format that Would have been adopted
`had OLE not been invoked). HoWever, the object that has
`been incorporated into the target application contains eXtra
`information over and above the bit map, text, or Whatever
`representing the appearance of the object: it also contains the
`name (at least) of the original source application, plus (for
`Object Embedding) a native format including all the original
`control information held by the server application about that
`object. The object therefore contains suf?cient information
`to identify and be further processed by the server applica
`tion. In Microsoft WindoWs it is subsequently possible by
`double clicking on the object as seen from the target
`application to launch the server application and use it to
`process the object. This is effected by the client application
`sending an appropriate request to the Microsoft WindoWs
`operating system.
`An eXample of the use of OLE Would be if a draWing
`application is used to create a graph (ie the object), Which is
`then incorporated using OLE into a Word processor docu
`ment. If it is subsequently decided to update the graph, there
`is no need to repeat this process (ie update the graph in the
`draWing application and then copy it across again into the
`Word processor document); rather double clicking on the
`graph in the document launches the draWing application,
`Which can then be used to update the graph directly. Thus it
`Will be seen that OLE, unlike the normal clipboard or DDE,
`alloWs pasted material to be updated from Within the target
`application, and at some arbitrary future date (DDE, by
`contrast only operates Whilst the link betWeen the tWo
`applications is maintained, and even then only alloWs updat
`ing from Within the server application).
`In Object Linking the object contains a reference back to
`the original ?le containing the relevant data (including disk
`drive, ?lename etc); thus any updates made to the original
`?le are re?ected in the object as vieWed from the client
`application. In Object Embedding by contrast, effectively a
`copy is made of the original data, so that it does not mirror
`updates to the source data. Thus it can be seen that Object
`Linking and Object Embedding, although closely related,
`differ someWhat in the precise details of their operation.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`4
`Further information about OLE under Microsoft WindoWs
`can be found in “Object linking and Embedding: Program
`mer’s Reference, Version 1”, Microsoft Press, 1992.
`To date, OLE has essentially been directed at transferring
`data betWeen tWo applications both running on a single
`machine, although some commercially available products do
`have a limited ability to perform OLE across a netWork. For
`eXample, the Microsoft WindoWs for Workgroups product
`supports OLE across tWo or more machines; hoWever, the
`WindoWs for Workgroups operating system is speci?cally
`designed for use over a netWork. In a sense it can be
`regarded as a single system distributed over multiple hard
`Ware systems (Which must be connected together by a local
`area netWork
`Only systems running WindoWs for
`Workgroups can use this netWork OLE; there is no mecha
`nism for supporting OLE betWeen machines With other
`operating systems.
`Another product, ProShare from Intel Corporation, also
`provides a limited form of OLE over a netWork. This product
`permits sharing of data from one node to another; ie material
`entered into the application at one node is mirrored at the
`other node. This product supports OLE, so that if an object
`is embedded into the application at one node, it likeWise
`appears embedded at the other node. This facility hoWever
`is only useful for providing OLE Within this one application;
`it is not possible to provide OLE betWeen an arbitrary
`application on a ?rst machine and an arbitrary application on
`a second machine.
`Thus it Will be seen that although the prior art has
`addressed the problem of OLE over a netWork to a limited
`eXtent, it has not provided a comprehensive solution that is
`both ?exible and relevant to eXisting applications.
`Accordingly, the invention provides a method of provid
`ing object linking and embedding (OLE) over a computer
`netWork, in Which an object generated by a ?rst application
`at a ?rst computer in the netWork may be incorporated into
`a second application at a second computer in the netWork,
`said ?rst and second computers each running a stand-alone
`operating system supporting a clipboard, the method com
`prising the steps of:
`receiving noti?cation that the ?rst application has sub
`mitted material to the clipboard on the ?rst computer and
`obtaining a list of available formats for said submitted
`material;
`transmitting the format(s) corresponding to Object
`Embedding to the second computer;
`submitting the format(s) corresponding to Object Embed
`ding to the clipboard at the second computer for selection by
`the second application.
`Once the appropriate format(s) for Object Embedding
`have been submitted to the clipboard at the second computer,
`the object is available to be incorporated into the second
`application in the normal manner, by selecting OLE from the
`clipboard. Subsequently, When the object is invoked by
`double clicking, the operating system at the second com
`puter Will look for an application having the same name as
`the ?rst application, but residing on the second computer.
`This application Will then be launched to alloW the object to
`be processed as per normal OLE. In the present invention the
`cross-netWork nature of the OLE is completely transparent
`to the applications and no special operating systems are
`required.
`Clearly it is necessary as described above for the second
`computer also to possess a copy of the ?rst application that
`eXists at the ?rst computer. In practice this Will normally be
`the case; in many organisations, standard softWare packages
`are available to all users, for eXample because they are
`
`Petitioner Microsoft Corporation - Ex. 1072, p. 6
`
`

`
`US 6,202,100 B1
`
`5
`It is not at present
`installed onto a local area network
`supported for double clicking in the second application at
`the second computer to result in the ?rst application at the
`?rst computer being remotely launched to process the
`object. The reason for this is that the operating system at the
`second computer could not successfully resolve the refer
`ence to the ?rst application on the ?rst computer When the
`object Was invoked. Of course, future operating systems
`may be able to handle such references, or alternatively an
`application on the second computer could be used to act as
`an intermediary betWeen the ?rst application on the ?rst
`computer and the operating system on the second computer.
`HoWever, this latter suggestion is not straightforWard and
`has yet to be implemented.
`To support OLE over a network, it is only necessary to
`submit the actual format(s) required for OLE to the clip
`board at the second computer. In Microsoft WindoWs appli
`cations the availability of OLE is conventionally signalled
`by a format named “OWnerLink”. It may be desired to pick
`out just this format from the clipboard at the ?rst computer,
`plus formats for the native and presentation data, and then
`send them to the second computer (this approach minimises
`the siZe of transmissions betWeen the tWo computers).
`HoWever, in a preferred embodiment, the list of all the
`available formats for the material submitted to the clipboard
`is transmitted to the second computer for submission to the
`clipboard at the second computer. This effectively alloWs
`applications on the ?rst and second computers to transpar
`ently share a single clipboard, as described in more detail in
`the afore-mentioned US. application Ser. No. 08/149,487.
`If the Whole list is transferred, it is preferred that the
`method further includes the step of detecting if one of the
`available formats corresponds to Object Linking. In
`Microsoft WindoWs applications such a format is conven
`tionally named “ObjectLink”. If such a format is present, it
`is not submitted to the clipboard at the second computer (eg
`by removing it from the list prior to transmission to the
`second computer, or at the second computer before submis
`sion to the clipboard). Effectively this prevents Object
`Linking being performed over the netWork. Again, the
`reason for this is that the operating system at the second
`computer could not successfully resolve the reference to the
`original data ?le on the ?rst computer When the object Was
`invoked. Of course, future operating systems may be able to
`handle such references, or alternatively an application on the
`second computer could be used to act as an intermediary
`betWeen the ?rst application on the ?rst computer and the
`operating system on the second computer. HoWever, this
`latter suggestion is not straightforWard and has yet to be
`implemented.
`Preferably a check is made to see if one of the available
`formats corresponds to dynamic data exchange (DDE). In
`Microsoft WindoWs applications such a format is conven
`tionally named “Link”. If this format is present, the data
`associated With the format is changed by replacing the
`application name therein (ie denoting the ?rst application)
`With a name containing an identi?er of the ?rst computer.
`The replacement name refers to a substitute application on
`the second computer, Which picks up any DDE requests and
`refers them back to ?rst computer, as described in the
`afore-mentioned US. application Ser. No. 08/203,067.
`Note that a slight complication to the above is that it
`appears that in reality not all Microsoft WindoWs applica
`tions adhere fully to the format naming conventions; some
`use “ObjectLink” to denote a DDE link. Thus it may be more
`effective in some cases to regard “ObjectLink” as denoting
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`6
`DDE and to process it accordingly, rather than to drop it as
`denoting Object Linking.
`Preferably the formats are submitted to the clipboard on
`the second computer using delayed rendering, and further
`comprising the steps of:
`responsive to receiving a request from the second appli
`cation for a copy of the clipboard material in a particular
`format, sending a corresponding request to the ?rst com
`puter;
`obtaining the requested material from the clipboard at the
`?rst computer;
`transmitting the requested material obtained from the
`clipboard on the ?rst computer to the second computer;
`and submitting the requested material to the clipboard on
`the second computer, for passing to the second application.
`The advantage of using delayed rendering is that it avoids
`super?uous netWork traf?c in relation to clipboard formats
`that are never actually requested. If material is submitted to
`the clipboard in the form of a bit map for example, this
`saving can be quite signi?cant. In fact, the data associated
`With the OLE format per se is simply the string containing
`the application name, topic and item, and so the delayed
`rendering for this format does not save much bandWidth per
`se. Thus it Would be quite feasible to send the data associated
`With OLE format (even if it Was obtained from the clipboard
`on the ?rst computer using delayed rendering) at the same
`time as the format itself, and submit both together to the
`clipboard on the second computer. HoWever the presentation
`and native data associated With OLE may Well be extensive,
`favoring the use of delayed rendering, Which furthermore
`alloWs the same approach to be used for OLE as for all the
`other clipboard formats, including those such as bit map.
`In a preferred embodiment, both ?rst and second com
`puters run conferencing applications, Which are responsible
`for exchanging messages betWeen the ?rst and second
`computer. The conferencing applications are also respon
`sible for interacting via the clipboard With the ?rst and
`second applications at their respective computers; ie the
`conferencing application at the ?rst computer obtains the list
`of available formats and then the associated data from the
`clipboard at the ?rst computer, Whilst the conferencing
`application at the second computer submits the list of
`available formats and then the associated data to the clip
`board at the second computer.
`A detailed description of an embodiment of the invention
`Will noW be provided by Way of example, With reference to
`the folloWing draWings:
`FIG. 1 is a schematic block diagram of a typical computer
`Workstation;
`FIG. 2 is a simpli?ed diagram of the major softWare
`components running on the Workstation of FIG. 1;
`FIG. 3 is a How chart illustrating the process for copying
`a clipboard entry at a ?rst machine to the clipboard at a
`second machine;
`FIG. 4 is a How chart illustrating the processing of a
`request at the second machine for a clipboard entry from the
`?rst machine;
`FIG. 1 is a simpli?ed schematic diagram of a computer
`system, With a system unit 10, a display screen 12, a
`keyboard 14 and a mouse 16. The system unit 10 includes
`microprocessor 22, semi-conductor memory (ROM/RAM)
`24, and a bus over Which data is transferred 26. The
`computer of FIG. 1 may be any conventional Workstation,
`such as an IBM PS/1 computer. The computer of FIG. 1 is
`equipped With a netWork adapter card 30. This card, together
`With accompanying softWare, alloWs messages to be trans
`mitted onto and received by the computer Workstation.
`
`Petitioner Microsoft Corporation - Ex. 1072, p. 7
`
`

`
`US 6,202,100 B1
`
`7
`Various forms of network adapter card are available for use
`With networks such as Token Ring, Ethernet, ISDN, and so
`on. The operation of the netWork adapter card is Well-knoWn
`and so Will not be described in detail.
`FIG. 2 illustrates the main softWare components on tWo
`terrninals A, B, necessary for an understanding of the
`invention. Both terrninalsA and B are typically Workstations
`as shoWn in FIG. 1, and have clipboards (“CLIPBOARD A”
`and “CLIPBOARD B” respectively) supported by the oper
`ating system (eg Microsoft WindoWs) at the respective
`terminals. The tWo terminals are connected by a netWork
`link
`With
`appropriate
`cornrnunications
`softWare
`(“COMMS”) at each terminal to provide data communica
`tions between terminal A and terminal B. Such communi
`cations softWare interfaces With the netWork adapter card
`and is again Well-knoWn in the art.
`Terrninals A and B also run conferencing softWare, Which
`is responsible for implementing the OLE betWeen the tWo
`terrninals. This conferencing softWare is designated as
`P2P-A and P2P-B on terrninals A and B respectively. P2P-A
`and P2P-B are simply additional applications as far as the
`operating system is concerned, although for present pur
`poses they are perhaps most simply regarded as enhance
`rnents to the COMMS softWare. P2P-A and P2P-B interact
`With the COMMS softWare to exchange messages betWeen
`terrninals A and B using conventional cornrnunication pro
`tocols. The operation of P2P-A and P2P-B is described in
`more detail beloW. An example of commercially available
`suitable conferencing softWare is Person to Person2 for
`Windows from IBM Corporation, Which supports confer
`ences betWeen tWo or more people over a variety of corn
`rnunications links (eg LAN, ISDN, asynchronous).
`2Person to Person is a trademark of International Business Machines Corpo
`ration
`An application program (“APPN A”) and a routine
`(“CLIP SEND”), part of P2P-A, run on terrninal A, With an
`application program (“APPN B”) running on terrninal B.
`CLIP SEND uses the COMMS system to send a message to
`terminal B to activate another routine (“CLIP RECEIVE”),
`part of P2P-B, at terrninal B. CLIP SEND makes an oper
`ating system call to become a vieWer of CLIPBOARD A in
`accordance With conventional clipboard manipulation. The
`user at terrninal A selects the appropriate material from
`APPN A and copies this into CLIPBOARD A in the con
`ventional rnanner. Because the CLIP SEND routine is a
`vieWer of CLIPBOARD A, it is noti?ed of any updates to
`CLIPBOARD A. When it is alerted to a change to CLIP
`BOARD A, it requests the list of available formats Which it
`sends to CLIP RECEIVE. CLIP RECEIVE noW takes oWn
`ership of CLIPBOARD B and inserts the list of formats
`using delayed rendering (ie it passes a null pointer to the
`operating system). This avoids the bandWidth overheads
`associated With sending the actual data itself. The contents
`of CLIPBOARD A are thus reproduced on CLIPBOARD B.
`In the Microsoft WindoWs operating environment the
`speci?c calls for netWork OLE are as given beloW, and are
`listed in FIGS. 3 and 4, although it should be noted that the
`invention is not limited to this operating system. CLIP
`SEND becomes a vieWer of CLIPBOARD Ausing SetClip
`boardVieWer (step 310), and APPN A inserts data onto
`CLIPBOARD A using SetClipboardData (step 320). This
`causes a noti?cation WMiDRAWCLIPBOARD to be sent
`to CLIP SEND (step 330). CLIP SEND interrogates CLIP
`BOARD A using EnurnClipboardForrnats (step 340) to
`obtain the list of formats in Which the data on the clipboard
`is available. It passes this list to the remote terminal B using
`standard messaging software (step 350). CLIP RECEIVE
`then uses the call SetClipboardOWner to become the oWner
`of CLIPBOARD B (step 360). The formats are then inserted
`onto CLIPBOARD B (step 370) using the delayed rendering
`option in SetClipboardData, and become available for user
`selection.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`8
`The various clipboard formats are noW available from
`Within APPN B. One of these formats is recognised by
`APPN B as corresponding to OLE (Object Ernbedding). For
`the purpose of the present invention We assume that the user
`at terrninal B selects Object Ernbedding (the processing
`associated With other possible selections is described in the
`afore-rnentioned applications US. application Ser. Nos.
`08/149,487 and 08/203,067.
`The processing involved With satisfying the OLE request
`is illustrated in FIG. 4. Initially the user selects the clipboard
`entry corresponding to Object Ernbedding, either irnplicitly
`or explicitly, resulting in a GetClipboardData call from
`APPN B to CLIPBOARD B (step 410). Since all the formats
`are inserted onto CLIPBOARD B using delayed rendering