1
`
`GOOGLE-1020
`Google Inc. v. Micrografx LLC
`IPR2014-00532
`
`

`

`EP 0 567 699 A1
`
`Technical Field
`
`based environments. such as Hewlett-Packard's NewWave. enabling software developers to implement
`
`is possible to define a
`When designing an object based system, as an optimisation feature it
`hierarchical classification system of class objects in which class objects lower down the hierarchy (sub-
`classes) "inherit" characteristics from their superclasses. An example from the field of biology is shown in
`Figure A.
`The Class Object Animate has certain data and methods associated with it which are generic to all
`Animal Objects.
`Its sub-classes. Class Object Vertebrates and Class Object
`Invertebrates inherit
`the
`characteristics of their superclass Animals and.
`in addition. each contains extra data andlor methods
`specific to their specific sub-class and so on down the classification tree. Each of the links in Fig A is an
`“AKO” (a kind of) link. eg. a mammal is a kind at vertebrate and a primate is a kind of mammal.
`When it is desired to create an instance of a class. eg. a particular Kangaroo called Hoppy. this can be
`done by taking a copy of a Kangaroo Class Object and specifying Hoppy's characteristics of interest. eg.
`height, weight or whatever. The Hoppy Object has an "ISA" (is a) link to the Kangaroo Class Object.
`Such a system reduces the amount of code needing to be written for new objects since objects
`automatically use generic code of superclasses (AKO Links) and relevant Class Objects (ISA Links).
`A reference for further information on the advantages and underlying principles of object based systems is
`Object oriented design with applications - Grady Booch. ISBN 0-8053-0091-0. An example of an object
`based software product is Hewlett-Packard's NewWave Environment. A useful reference is the NewWave
`General Information Manual for Software Developers. Reference No. 5952-2667.
`As well as ISA and AKO links which may be inherent in the system design there may be other kinds of
`specific object links designed into a system. A link between two objects normally takes the form of one or
`both of the objects having a reference to the other one. One type of link which is a feature of Hewlett-
`Packard,s NewWave software is a "parent-child“ or "containership" link (or sometimes referred to as a
`"Ownership" link). A parent-child link has several properties. It is existence-preserving ie. an object will not
`be destroyed while it is a child of some other object. Parent-child links also have an effect on move and
`copy operations eg. copying a child object automatically causes the copy object to have links to the same
`parent objectts) as the original objects. In NewWave software. an object can have parent links to more than
`one other object.
`An object may comprise two parts - one to hold semantic data and the other to hold presentation data.
`As used herein. a "semantic object" or a "semantic part" of an object is an object or object part which has
`stored data and which is. by virtue of the stored data, persistent. A “presentation object“ or "presentation
`part" is created to present to a user the data of a semantic object or semantic object part and has no
`persistence in the system on termination of the user session.
`A large number of commercially available systems now possess a windows-based graphical user
`interface. A system can be arranged so that software windows are also treated as objects and have inter
`object links with other windows.
`In this specification. when there is a risk of confusion between window objects and other objects the
`latter will be termed “semantic objects". Generally. however. the term "object" means “semantic object".
`
`The present invention relates to an object based computer system. An object based computer system
`is one which comprises several software components or "objects". The term 'obiect—based' can mean that
`the system is written using an object-oriented programming language, such as C+ +. Alternatively, a more
`conventional procedural programming language may be used in such a way as to portray the system to a
`user as comprising a collection of objects each of which has its own functionality and is able to interact with
`other objects in the system. Either approach can be taken in connection with the present invention. In any
`case. the present invention reiates to a system which has an object oriented user interface.
`The principles of object-oriented programming are now well-known and widely practised. Only a short
`introduction to the pn‘nciples will be given here.
`A software object has its own data and associated methods. The system operates by objects sending
`"messages" to one another eg. data. instructions. requests etc. Generally. an object can be regarded as a
`discrete entity eg.
`it can incividually be moved. copied. destroyed etc, and each object has a unique
`identifier.
`
`Brief Description of Prior Art
`
`There are several object-based software products already on the market and in use. These include
`object-based languages. such as C+ 4-. enabling programmers to write object-based applications; object-
`
`2
`
`

`

`EP 0 567 699 A1
`
`modelled by the system.
`
`applications using the object-based environment. and object-based applications software. such as AmiPro
`word processing software. written for specific business applications.
`Systems exist which allow users to define tasks to be handled by a software application. These tend to
`be one of two types:
`i) high-level programming languages which are written specifically for a particuhr field of application and
`tailored to Suit that application eg. Hewlett-Packard's NewWave Agent Task Language;
`ii) systems which allow a user to perform a sequence of actions and which subsequently repeat or
`emulate this sequence eg. Hewlett-Packard‘s NewWave Agent Task Recorder or Microsoft Windows
`Recorder application.
`Problems exist with both of the approaches described above. The key problem with the first approach is
`that it is one which requires the skills of specialists in the particular programming language and it is not an
`approach available in practice to the non-programmer.
`The key problem with the second approach is that it is limited to very specific activities and is therefore
`rather restricted in scope.
`Generally speaking, software packages are becoming increasing rich in functionality. However this
`additional functionality is not always exactly what is required by users. What is lacking in the marketplace is
`software which the non-programming user can employ to define the functionality required to meet specific
`user needs. This is what the present invention aims to provide.
`According to the present invention we provide an object based-computer system comprising means for
`storing objects. handling inter-object messaging and object processing and a graphical user interface for
`representing objects to a user comprising:
`a first class of object for holding user data andior performing an application-level function and which is
`capable of maintaining references to other objects;
`a second class of object for acting as an intermediary between two objects of the first class so as to
`transfer another object between the two objects of the first class:
`a user interface enabling a user to select objects of the first class and to link these together using
`objects of the second class in order to configure a user-defined task. and
`means for transferring objects between objects of the first class via objects of the second class in a
`manner so that the progress of such transfers is indicated graphically to the user.
`A system according to the present invention has the advantage that it permits a user to configure tasks
`to be performed by the system and allows a user to monitor the progress of tasks being performed. In this
`way. user interaction with the system is facilitated and. in addition, any problems can be identified quickly.
`A system according to the present invention has the further advantage that objects can be transferred
`between other objects via an intermediary object so that the objects on the giving and receiving ends of the
`transfer need not know each others identity in order for the transfer to take place.
`Another advantage of using intermediary objects for transferring objects between other objects is that
`this provides a degree of buffering as will be more fully explained in the description of an implementation of
`the present invention which follows.
`Preferably, the system comprises a mechanism for recognising user input events concerning the
`intermediary objects and for responding to such events whilst user-defined tasks are being performed. This
`feature enables a user to interact with the system during operation 99. a user can choose to select an
`object and to ‘drop'
`it directly onto an intermediary object.
`In this regard the system is not restricted to
`operating in only one of two possible modes. namely configuration by a user and execution of a task.
`In the embodiment to be described an intermediary object is configured to accept an object directly as
`a result of a specified user action as well as from an object of the first class. In that case the specified user
`action is to drag the object across the screen and drop it onto an intermediary object. This feature provides
`greater flexibility for a user to bypass elements in a process as required.
`In addition, in the embodiment to be described an intermediary object is configured so that an object
`can be removed therefrom by a user. This feature allows a user to remove an object from an intermediary
`object in order to transfer it somewhere else. In practice. this may be achieved by the user clicking on the
`object and dragging it off the intermediary object.
`Preferably, the system comprises means for animating the display of the progress of transferring an
`object via an intermediary object. In the embodiment to be described an intermediary object is configured
`for holding a plurality 01 objects at one time.
`Preferably. the system comprises a plurality of intermediary objects having standardised behaviour. In
`this way. the intermediary objects form buiicling blocks for interconnecting other components in a process
`
`3
`
`

`

`EP 0 567 699 A1
`
`Brief Description of the Drawings
`
`invention will now be described, by way of example. with
`A specific embodiment of the present
`reterence to the accompanying drawings of which:
`Figure 1 is a diagram showing the software components of a system according to the present invention:
`Figure 2 shows an example presentation of a configuration of system objects:
`Figure 3 is a diagram showing the ownership links for the objects of Figure 2;
`Figure 4 shows a Pipe Component displayed at an angle;
`Figure 5 shows a Mobile Object offset from a Pipe Gomponent:
`Figures 6-48 show screens in a user session.
`
`System Components
`
`In the embodiment to be described, the system is configured so that the transfer of objects via an
`intermediary object proceeds as a background task whilst other operations are being performed. This
`feature exploits the facilities available in known object-based and windows packages.
`In a system according to the present invention, preferably one or more classes of object is designed to
`support at least one generic semantic interface enabling persistent coupling between two objects which
`both support the some generic semantic interface. By 'persistent' is meant that the coupling survives the
`closing down of a user session. This feature has the advantage of reducing the interdependence of objects
`in the system ie. objects need less intormation about other objects' capabilities, they just need to know
`whether another object supports the relevant generic semantic intertace.
`In the embodiment
`to be
`described. the capacity for a persistent coupling is represented to a user by a connector associated with an
`object as visually displayed. In particular. input socket and output plug connectors will be described.
`
`“Form A" 46
`
`Figure 1 shows the software components in a distributed object based system 10 according to the
`present invention.
`It should be noted that the present invention is also applicable to standalone systems.
`The system 10 may run on networked personal computers each of which is provided with a hard disc. a
`flexible disc and a networking card. Each personal computer is loaded with the following software:
`operating system software 12. MSDOS in this example:
`windows interface software 14, Microsoft Windows in this example;
`local area networking software 16:
`distributed message switching sottware 18:
`an object based software environment 20, Hewlett-Packard NewWave in this example;
`system objects 24.
`
`System Objects
`
`There are three classes of system objects 24, namely:
`"Contigurer Objects"
`"Mobile Objects“
`"Activity Objects"
`Each of these three main classes of object will be described in detail. Within these classes are sub-classes
`of object having predetermined functionality and, of oeurse,
`in use specitic instances of these types of
`object are created. First. in order to provide context for these descriptions, reference will be made to Figure
`2 which represents an example ot a winddw seen by a user using a system according to the present
`invention.
`
`A window 26 of well-known type appearing on the user interface of a computer system comprises a
`border 28. a title bar 30. a menu bar 32 and horizontal and vertical scroll bars 34 and 38 respectively.
`Mobile Objects are represented by a simple icon. The user can use a mouse input device to select. drag.
`and drop the icons representing Mobile Objects within the window 26. Activity Objects are also represented
`by an icon in the window 26. The user can also use the mouse to select and drag Activity Objects within the
`window 26. In the window 26 are displayed system objects in the form of icons as tollows:
`Activity Objects:
`"Generator" 38
`"Folder" 40
`"Watcher" 42
`“Actionsr” 44
`
`Mobile Objects:
`
`4
`
`

`

`EP 0 567 699 A1
`
`“Form B" 48
`
`From the user viewpoint, there are two types of system object - 'static' objects (referred to here as 'Activity
`Objects') and 'mobile‘ objects (referred to here as ‘Mobile Objects‘). Mobile Objects are generally passive
`carriers of data. such as documents or forms. Mobile Objects may have data contents that are accessible
`andior modifiable by other objects. Activity Objects are used to store and route Mobile Objects. and
`sometimes to access and manipulate the data they carry.
`It
`is by establishing persistent relationships
`between Activity Objects that support fora specific task can be built.
`In this system persistent relationships between objects are presented and manipulated by a special
`object called a Contigurer Object. Figure 2 shows the appearance of an open Configurer Object. displaying
`the configuration it contains.
`Hence sub-classes of Activity Objects are Generator. Folder. Watcher and Actioner objects, and specific
`instances of these are shown in Figure 2.
`Interconnecting the Generator 38 and Folder 40 is a first "Pipe Component“ 50. A second Pipe
`Component 51 interconnects the Watcher 42 and the Actioner 44. The Pipe Components are not separate
`objects but are each part of a Configurer Object.
`Pipe Components must. however. have a more complex display within the configurer window. A Pipe
`Component is shown as a line with an input socket 52 at one end. and an output plug 53 at the other.
`Mobile Objects in the Pipe Component's queue are displayed in order along the length of the Pipe
`Component, starting with the object at the head of the queue next
`to the output plug 53. The Pipe
`Component normally displays the Mobile Objects so that they do not overlap each other. but are just butting
`up to their neighbours. However. it this is not possible due to the large number ot Mobile Objects on the
`Pipe Component. the Mobile Objects are displayed overlapping.
`As Mobile Objects enter the Pipe Component. and are removed from it. the Pipe Component animates
`the display of these Objects. When a Mobile Object lands on the Pipe Componem it starts moving towards
`the output end of the Pipe Component. When a Mobile Object reaches the end of the Pipe Component. it
`can be handed on to an Activity Object connected to the output plug 53 of the Pipe Component.
`If the
`Activity Object is refusing to accept Mobile Objects. or there is no Activity Object connected. the Mobile
`Objects are queued up at the end of the Pipe Component. The head of the queue is at the output plug 53 of
`the Pipe Component. As more Mobile Objects arrive, and travel down the Pipe Component. they stop when
`they reach the tail of the queue. As Mobile Objects are removed from the queue at the end of the Pipe
`Component, the remaining Objects in the queue are shuffled up to fill up the gap.
`For a Pipe Component within the wind0w 26, the user is able to:
`1) Select the Pipe Component
`2) Drag the whole Pipe Component
`3) Drag the plug or socket at the end of a Pipe Component. The other and stays where it is. and the
`body of the Pipe Component stretches between the tw0.
`If any Mobile Objects are in the queue, they
`also move with the body of the Pipe Component.
`4) Select a Mobile Object in the Pipe Component and drag it out of the Pipe Component‘s queue.
`5) Drag a Mobile Object over a Pipe Component. and drop it onto the Pipe Component.
`In this example,
`the system objects have been used to provide a network of Activity Objects
`interconnected by Pipe Components along which Mobile Components can be transferred. The system
`could. tor example. be one for processing stationery orders in a large organisation. Form A could be a
`request for more memo paper and Form B could be an order for paper to be sent to an external supplier.
`The inter-object messages referred to in the fol|0wing description are detailed in Appendix A. Appendix
`A refers to the HIWOHD and LOWORD of parts of a message. In the present embodiment a single word (16
`bits) and a double word (32bits) is available for specifying the message parameters. A double word is
`available for specitying the return value of the message. The windowing software permits more than one
`message to be accommodated in this double word and the LOWORD (lowest 16 bits) or HIWORD (highest
`16 bits) can be retrieved selectively.
`
`Objects are encapsulated as 0+ + objects. A NewWave object is often written as several C+ + objects. In
`
`Configurer Objects
`
`Oontigurer Objects are used to construct a processing system to suit user requirements. They are part
`of the infrastructure of system objects and have standardised behaviour. Configurer Objects are container
`objects which each have the capacity for containing a plurality of Pipe Components. Mobile Objects and
`Activity Objects.
`In this embodiment. the contigurer objects are written in 0+ + using an object-oriented
`design. Each of the Pipe Components is a C+ 4- object and each of the Mobile Objects and Activity
`
`5
`
`

`

`EP 0 567 699 A1
`
`this embodiment Pipe Components are examples of 0+ + objects forming part of a Configurer Object.
`which is a NewWave object. To facilitate processing. representations of other NewWave objects. eg. Mobile
`Objects and Activity Objects, are also included in Configurer Objects in the form of 0+ + objects. Such
`0+ + objects form the focal point for communications between the Configurer Object and the NewWave
`object which they represent. The C + + objects store certain data relating to their states. including a unique
`object identifier. bounding b0): details and a Current selection flag. The bounding box information is stored
`as:
`
`windows HECT = {top.left:bottom.right}
`where the four entries in the list are integers and define the lines forming a rectangle.
`The bounding has information is used when repainting the screen to decide which objects need
`repainting and for approximate 'hit testing' - deciding which objects may be the target of user actions. such
`as mouse clicks. The current selection flag is set for those objects which are currently selected by a user.
`Figure 3 shows the ownership links for the objects displayed in Figure 2. The Configurer Object
`maintains a list indicating the Z-order in which its child objects are to be displayed ie. where two objects
`would overlap on the screen, which one appears above the other. Objects at the back of the list are of lower
`2 order than those at the front. When an object is'dragged‘ on the screen by a user it is removed from its
`previous place in the list and inserted at the trout of the list ie. it rises above all of the other items displayed
`on the screen.
`It is the responsibility of each oi the presentation parts of the various objects to:
`i) maintain their display within the Configurer Object window;
`ii) provide hit-testing for user actions in the Gonfigurer Object window so as to locate the target of user
`actions;
`iii) implement the consequences from the display viewpoint of user actions eg. when an object icon is
`dragged across the screen or when one object icon is dropped on to another.
`iv) update the underlying semantic object.
`System Objects in the system interact with each other via generic semantic interfaces.
`A generic interface is one that is not specific to one particular kind of system object. The use of generic
`interfaces is important to enable interworking between system objects.
`It would be impractical to require
`each system object to understand all the specific interfaces of all the other system objects with which it
`may be required to interact.
`A semantic interface is one that concerns the attributes which are important to the functionality of the
`system object offering the interface. This distinguishes a semantic interface from, for example. a presenta-
`tion interface. The latter is concerned with the appearance of the system object
`to a user, and may
`introduce attributes (such as colour) which ease interpretation by people. but which are strictly unnecessary
`to the correct functioning of the system object.
`The generic semantic interface pr0vides a well-defined mechanism whereby one system object can
`directly interact with another. A single system object may otter several such interfaces. with different
`tunctionalities.
`
`- Connector identity number;
`
`Each generic semantic interface is implemented as a set of calls that may be invoked on system
`objects which support the interface. A generic interface may be defined so that it allows the maintenance of
`a two-way relationship between a system object and one or more other system objects and this requires
`that all of the relevant system objects know each others identity. Alternatively. a generic semantic interface
`may be defined so that it allows a system object to interact with another system object without the latter
`object needing to know the identity of the former in advance. Such interfaces support transient interactions
`between system objects.
`In this embodiment, for one system object to be visually connected to another in a task configuration.
`as shown for example in Figure 2, both of the system objects must support the 'contiguration interlace'.
`which will now be described.
`
`Each Configurer Object has a plurality of generic semantic interfaces for interacting with other system
`objects. Certain ones of these interfaces enable interconnection between system objects and. for the
`purposes of this description. these interfaces will be termed 'Connectors'. Each Connector is attached to a
`parent object and has a detined set of messages which can be sent via that Connector to another system
`object. Each Connector also has associated with it a screen position. The shape of Connectors as displayed
`to a user is chosen so as to indicate the relevant connection capabilities. Connectors provide persistent
`couplings between system objects to establish the context for communication. The input socket and output
`plug at the ends of each Pipe Component are examples of Connectors. The Contigurer Object maintains
`information about its Connectors. including:
`
`6
`
`

`

`EP 0 567 699 A1
`
`the identity of the object or part-object of which the Connector is a part;
`-
`the x and y screen positions of the Connector;
`-
`In this embodiment. Connectors are implemented as C+ + objects which are children 01 a system object
`eg. an Activity Object. To the user, the Connector is portrayed as a part of the relevant System Object.
`There is a 0+ + object class called ’Connector' which provides facilities relating to Connectors for all
`the system objects:
`1) - it can draw any one of a predefined set of Connector shapes in a variety of orientations (left. right.
`up or down) in a window. There are plug and socket Connector shapes for each type of interface
`enabling interconnection which is supported by the Configurer object. The plug and socket Connectors
`on Pipe Components represent
`the interfaces for passing Mobile Objects into and out of Pipe
`Components;
`2) -
`it maintains information about each instance of Connector that is part of a Pipe Component or an
`Activity Object. This information includes the screen position of each Connector. its orientation and the
`inter-object connections with which it is currently involved.
`the parent system object constrains the
`It Connectors are dragged across the screen by a user.
`movement of the Connector so as to travel around the border of the icon of the parent system object. If the
`parent system object is dragged, it moves its Connectors accordingly.
`
`Pipe Components
`
`horizontal the bounding box is treated as of negligible width.
`
`Pipe Components form part of Configurer Objects in this embodiment and have standardised behaviour.
`Each Pipe Component forms part of the same NewWave object as an instance of a Configurer Object. This
`approach is expedient since a Pipe Component must represent a relatively complex interface in the window
`of the relevant Configurer (laject. One way of implementing Pipe Components is to use objects provided by
`an object-based programming language such as C + +.
`In this embodiment.
`there are four program
`elements involved in implementing Pipe Components:
`1) the top-level NewWave and Wind0ws message dispatcher
`2) the z-order display list of the relevant Configurer Object
`3) the code for the Pipe Component itself
`4) the Connector code module referred to above.
`The top level dispatcher receives Windows and NewWave message via the Microsoft Windows
`messaging mechanism. Some of these messages are destined for the Configurer Object. but other message
`are destined for Pipe Components contained within the Configurer Object. Although Pipe Components and
`Configurer Objects are implemented in the same program, the messages are not defined assuming that. All
`extemai messages to Pipe Components are in the context of a particular Connector of a Pipe Component.
`The Connectors of a Pipe Component are identified by a number as described previously. By allocating
`ditierent numbers for the Connectors provided by a Configurer Object and by the Pipe Components within
`it.
`it is possible to distinguish which messages should go where. Pipe Components will now be described in
`detail.
`
`At the highest level. Pipe Components are the means for transferring Mobile Objects between Activity
`Objects.
`Mobile Objects can arrive in a Pipe Component via its input socket or they can be dropped directly onto
`a Pipe Component by a user. A Pipe Component can hold more than one Mobile Object at any one time.
`Once a Pipe Component has been given a Mobile Object it must place it in an ordered Queue with all
`the other Mobile Objects it has been given so far. Mobile Objects arriving in the Pipe Component are put at
`the end of the queue. The queue of Mobile Objects is bounded. If the queue is full. a Pipe Component can
`refuse to take any more Mobile Objects.
`There are two ways in which Mobile Objects can leave 3 Pipe Component. The first is if a user drags a
`specific Mobile Object out of the Pipe Component. The second is when a Mobile Object is taken from the
`head of the queue, and given to the Activity Object attached to the Pipe Components output plug.
`If there is no Activity Object currently attached to the Pipe Components output plug. Mobile Objects
`can only be removed from the Pipe Component queue by the user. Even if an Activity Object is connected
`to a Pipe output plug, it can refuse to take Mobile Objects from the Pipe Component.
`Each Pipe Component maintains the following state:
`1) Two Connector instances (which includes the position of the Connectors in the window).
`2) Bounding box information. The size and position of the bounding box is derived from the postion of
`the Connectors, which define the diagonally opposite corners of the box.
`If the Pipe Component is
`
`7
`
`

`

`EP 0 567 699 A1
`
`CF-CONNECTOFI-ADDED
`
`3) A list of references to Mobile Objects that are currently on the Pipe Component The list includes
`those Mobile Objects that are moving towards the ends of the Pipe Component (the moving queue) and
`also those Mobile Objects that have stopped moving, and are sitting at the end of the Pipe Component
`(called the end-queue). Eadi Mobile Object on the Pipe Component appears only once in the list.
`4) The length of the Pipe Component occupied by the icons of the Mobile Objects in the end-queue.
`5) The state of any transaction in progress for handing over the Mobile Object at the head of the queue
`to the Activity Object attached to the output plug of the Pipe Component.
`6) The maximum number of Mobile Objects that can be on the Pipe Component. The number can either
`explicitly be specified as part ot the Pipe Components configuration. or as a percentage 01 the length of
`the Pipe Component divided by the size of the icons of the Mobile Objects on it.
`7) For each Mobile Object, a reference to that Mobile Object and a record of the distance it has so far
`travelled along the Pipe Component.
`In order to re-display itself. the Pipe Component:
`1) Finds out where its Connectors are - and draws a line between their centres.
`2) Requests each Connector to draw itself.
`3) For each Mobile Object on the Pipe Component. it uses the Mobile Object's distance along the Pipe
`Component to work out where to display it. A Mobile Object is displayed by updating the origin of it‘s
`bounding box. and asking the presentation part of the Mobile Object to re-display itself.
`In order to present and manipulate task configurations. objects must provide information about the
`interfaces they support and the specific connection points that will be visible to the user. They also need to
`offer details of the inter-object relationships in which they are currently involved.
`The "configuration interface“ allows the other interfaces which an object supports to be identified, and
`allows inter—object relationships to be assessed and changed. All classes of static objects in this embodi-
`ment support this interface.
`The set of messages designed to support configuration are:
`CF-CONNECTOH-INFO
`request general Connector information
`CF-CONNECTOFt-CHANGED
`indicate a Connector has changed
`CF—CONNECTOFl-STATUS
`request current state of Connector
`CF-ENUM-CONNECTORS
`request a list of Connectors lrom an object
`CF-ENUM-INTERFACES
`request a list of interfaces from an object
`CF-UNPLUGGED-FFIOM
`advise object of a lost connection
`CF-PLUGGED-TO
`advise object at a new connection
`CF-CONNECTION-UPDATE
`advise an object
`that
`its set of existing connections have been
`changed
`advise Configurer Object in which an object appears that that object
`has established a new connection
`
`the Pipe Component by a preset step value. The step value is set up as a configuration value of the main
`
`CF-CONNECTOH-REMOVED
`
`CF-DFtOP-ALL—CONNECTIONS
`
`advise Configurer Objects in which an object appears that one of its
`existing connections has been rem0ved
`advise an object
`that
`its set of existing connections are to be
`rendered invalid
`
`When configuring the system. user actions cause 'plug' and ‘un-plug' messages to be sent to Pipe
`Components.
`The Pipe Component has to respond to seven types 01 external stimuli:
`1) An idle-timer tick
`2) A user dragging the Pipe Component. or one of the Pipe Oomponent‘s Connectors
`3) A user dragging a Mobile Object oh the Pipe Component
`4) A user dropping a Mobile Object onto the Pipe Component
`5) An Activity Object connected to the input socket attempting to deliver a Mobile Object
`6) An Activity Object connected to the output plug being able to accept a Mobile Object from the head of
`the queue
`7) A Connector being plugged or un-plugged.
`In order to present the illusion of animation, the Pipe Component pertorms one step of the animation of
`Mobile Objects in the moving queue every time it gets notified of an idle timer-tick.
`The idle timer-tick is generated at pre-set intervals only when the Configurer Object is waiting for