WO2001095126A1 - A system and method for network collaboration based on reciprocal relationships defined between software agents - Google Patents

Abstract

A system and method are disclosed for creating persistent, bidirectional relationships (425) between software agent (114,134,154, and 174) objects in a computer network (115) of compuer nodes (102 and 192). Each object is a software agent that represents a collaborative workspace. The software agent can represent a project, a person, a group of persons, an event, or a chat session and each of these objects is configured to provide a collaborative workspace. Each collaborative workspace is associated with other collaborative workspaces through reciprocal relationships that are created in respective pairs of the objects.

Description

A System and Method for Network Collaboration Based On Reciprocal Relationships Defined Between Software Agents

FIELD OF THE INVENTION

The invention disclosed broadly relates to computer network collaboration systems.

BACKGROUND OF THE INVENTION

Network collaboration systems have been developed in the past to enable participants at mutually remote locations in a network to work on common documents together. Examples of this are disclosed in US Patent 5,446,842 entitled "Object- Oriented Collaboration System", in US Patent 5,781,732 entitled "Framework For Constructing Shared Documents That Can Be Collaboratively Accessed By Multiple Users", and US Patent 5,732,229 entitled "Method And Apparatus For Displaying Business Cards". Such systems typically create isolated encapsulated objects representing places where other objects representing people and objects representing things can interact. These objects are typically configured as isolated programming constructs which are accessible by users for network collaboration. Such collaboration systems use the modeling capabilities of object oriented programming to develop human interface metaphors. A "People" object represents a person. A person's attributes, such as name, telephone number, address, email address, and so on can be summarized in a "Things" object such as a "Business Card" object that provides references to a particular person. The "Place" objects are collaborative environments, based on models such as chat session rooms, stores, and offices, that allow users to organize shared information and tasks.

A problem with such prior art collaboration systems is that the people, places, and things objects in such systems are not reciprocally related. An example of the type of problem that is not solved by the prior art is how to represent the multifaceted relationships between a particular person to other persons. The prior art people objects are designated to join team place objects to which they have been assigned and the people objects are assigned a user ID and a password that enables them to enter the place object. But, such collaboration systems do not address what are the organizational characteristics relating the people objects to each other and to the place object. The people objects may have a few properties such as a name and a telephone number, but the people objects, themselves, are not reciprocally related. The prior art collaboration systems emulate a "bricks and mortar" room as a virtual room. This is an easy metaphor to contemplate, but that is not what is needed to solve the problems of the prior art.

Network document transfer systems have been developed in the past to enable users to securely transmit documents between computers in a network. Examples of this are disclosed in US Patent 5,892,900 entitled "Systems And Methods For Secure Transaction Management And Electronic Rights Protection". Such systems typically create isolated encapsulated objects containing encrypted documents. The objects are exchanged between computers which run host programs that are configured to send, receive, encrypt, and decrypt such objects. But, such document transfer systems do not address what are the organizational characteristics relating the users who are exchanging the documents. The objects typically contain only encrypted documents and executable code that controls the security protection applied to the documents, but there is nothing about these objects that establishes reciprocal relationships between the users exchanging the documents.

An example of the type of problem that is not solved by the prior art is how to represent the multifaceted relationships between a particular person to other persons. Tliree example relationships of a particular person are: first, to his or her fellow workers in an employment setting; second, to his or her physicians in a medical setting, and third, to his or her banker in a financial setting. The particular person plays a different role in each relationship, as a fellow worker, as a patient, or as a client. The respective other persons respond in their corresponding roles as a fellow employee, as a physician, or as a banker. The particular person can communicate with these other persons over a network interconnecting their computers. But, how can a software object represent the particular person consistently in playing each respective role in each of the multiple relationships with such other persons. Correspondingly, how can software objects representing each respective other person play his or her role consistently with the particular person. Each of these other persons has his or her own respective set of multifaceted relationships as a parent, a club member, and the like. How can software objects consistently represent each respective person in playing each respective role. The prior art has not solved this problem.

SUMMARY OF THE INVENTION

The invention is a system and method for creating persistent, bidirectional relationships between software agent objects in a computer network, wherein each software agent object is its own collaborative workspace. The software agent object can represent a project, a person, a group of persons, an event, or a chat session and each of these objects is configured to provide a collaborative workspace. The collaborative workspace is a software agent object. Each collaborative workspace is associated with other collaborative workspaces through reciprocal relationships that are created in respective pairs of the software agent objects.

As an example of reciprocal relationships, one software agent object can represent a project and another software agent object can represent a person. The person object includes a reciprocal relationship tag that has a forward verb designating that the person object implements the project object. Correspondingly, the project object includes a reciprocal relationship tag that has a reverse verb designating that the project object is implemented by the person object. Each reciprocal relationship is based on two verbs, a forward verb and a corresponding reverse verb.

h addition to the collaborative workspace and the reciprocal relationship tags, each software agent object contains properties that are associated with the object. For example, an object representing a person will include properties such as a name, an address, and telephone number. Additional properties of the object can include the ability to publish rules or events and the provision of a security policy for the object.

A project object, for example, might include a publish rule that publishes the occurrence of an event by transmitting notification of the occurrence to listening objects. The project object would have a reciprocal relationship tag with a "watched- by" forward verb and a designation of the identity of the listening objects. Each of the listening objects would have a corresponding reciprocal relationship tag with a "watches" reverse verb and a designation of the project objects. If the event occurs in the project object, then the publish rule causes the project object to send a message to the listening objects notifying them of that event. There can be consecutive project objects, one following the other in a project schedule. The first occurring project object would have a reciprocal relationship tag with a "followed-by" forward verb and a designation of the second occurring project object. The second occurring project object would have a corresponding reciprocal relationship tag with a "follows" reverse verb and a designation of the first occurring project object. Listening objects to the second project object, for example, can include programmed methods to take certain actions in response to receiving event messages from the second project object.

The method for creating such reciprocal relationships between software agent objects in a computer network is carried out by a service module program residing in the memory of a computer node in the computer network. For example, the computer node can be a desktop computer linked to other desktop computers and server computers in the computer network. As another example, the computer node can be one of the server computers in such a network. The service module program receives a request to create a relationship between a local object in the computer memory and another object in the network, residing in the memory of another computer node. The request can be originated by a user or it can be originated by another computer program. The request typically will specify the type of reciprocal relationship to be established and the identity of the other object in the desired relationship. The type of reciprocal relationship is specified by the forward verb to be applied to the local object, hi response to the request, the service module program writes a local relationships tag with the forward verb into the local object and it writes another relationships tag with a reverse verb into the other object. The operation of remotely writing the relationships tag with the reverse verb into a remote object is performed by the service module in the local computer node issuing a remote procedure call to a corresponding service module in the remote computer node in the network where the other object resides.

Some examples of forward and reverse verb pairs are as follows. If the forward verb confers an owning relationship on the local object then the reverse verb confers an owned-by relationship on the other object. If the forward verb confers a "follows" relationship on the local object then the reverse verb confers a "followed- by" relationship on the other object. If the forward verb confers a "manages" relationship on the local object then the reverse verb confers a "managed-by" relationship on the other object. If the forward verb confers an "approves" relationship on the local object then the reverse verb confers an "approved-by" relationship on the other object. If the forward verb confers an "implements" relationship on the local object then the reverse verb confers an "implemented-by" relationship on the other object. If the forward verb confers a "watches" relationship on the local object then the reverse verb confers a "watched-by" relationship on the other object. This is an example of the many other forward and reverse verb pairs which are possible.

In another aspect of the invention, each software agent object can include a security policy for the object, hi responding to the request to establish a reciprocal relationship, the service module will retrieve the security policy for the local object with access restrictions for accessing the local object. A person object, for example, may state as an access restriction, that the object will not allow Internet advertiser objects to establish a reciprocal relationship with the person object. As another example, a strategy object may state as an access restriction, that the object will not allow a person object to establish a reciprocal relationship with it, without the presentment of a cryptographic key. The service module will then form an access criterion for permitting the establishment of the requested relationship based on the access restrictions. The service module will then access information from the other object sufficient to apply the access criterion. This information may be that the other object does not represent an Internet advertiser or that the other object does possess a suitable cryptographic key. Then the service module determines if the access criterion is satisfied. If so, then it writes a local relationships tag with the forward verb in the local object and it writes another relationships tag with a reverse verb in the other object. If the access criterion is not satisfied, then the service module will perform an alternate step, such as aborting the fulfillment of the request or modifying the requested relationship, such as granting read privileges but prohibiting write privileges for the other object.

One benefit of the invention is the ability to locate software agent objects in a computer network based on the reciprocal relationships established between such objects. The service module carries this out by selecting a reciprocal relationship tag in a local software agent object in the computer memory, the tag being associated with a particular relationship verb for the local object. The service module then forms a query using the identity of the other object in the relationship. The service module then searches the network for another software agent object having that identity. The search is done based on the identity of the object in the reciprocal relationship tag inside the first object. Relationships can have multiple verb pairs that apply between them, e.g. Harry works for George (in the context of their company) and George works for Harry (in the context of Harry's jazz band). Here, there are two reciprocal relationships: Harry would be able to find whom he works for by looking at all relationships with the "works-for" verb, gathering the identities specified in the relationship tag, and then using that object identity to discover which computer the other object resides on.

A significant benefit of the invention is in creating collaborative workspaces in the computer network. The service module in the memory of a computer in the network carries this out by instantiating a software agent object that is a collaborative workspace. The workspace is logically part of the software agent object. The collaborative workspace can either be instantiated as a part of the program construct of the software agent object itself, it can be a separate object in a separate buffer partition in the same computer memory, or it can be a separate object in a separate buffer established in another computer memory in the network. The relationships tags in the software agent object govern which other software agent objects in the network can access the workspace.

A second service module in the memory of either the same computer or a second computer in the network creates a second software agent object in its computer memory. This can be done in response to a remote procedure call sending a request from the service module in the first computer. The second object is created having a relationships tag with a reverse relationship verb and a reference to the first software agent object, to enable collaboration between the first object and the second object in the workspace. A conversation buffer can be created in the workspace for storing conversations conducted in the collaborative workspace between the first object and the second object. An audit trail program can be associated with the first object for maintaining an audit trail of the conversations stored in the conversation buffer. A document buffer can be created in the workspace for storing documents exchanged between the first object and the second object.

There is great flexibility in configuring multiple workspaces for diverse combinations of software agent objects in a network. For example, a third service module in the memory of a third computer in the network can create a third software agent object in its computer memory, the third object having a relationships tag with a second forward verb and having a second collaborative workspace. The second software agent object in the second computer has a second relationships tag written into it with a reverse relationship verb and a reference to the third object, to enable collaboration between the third object and the second object in the second workspace.

One example application of the invention is in the health care field. Patients are represented by patient objects that are configured to store the patient's medical records, dental records and the like in their own workspaces. Physicians are represented by physician objects that do not store the patients' records but which must be authorized to access them. A group of physicians in a group practice would be represented by a group object that would have shared access rights to the medical records of patients of any physician in the group. Specialist physicians are represented by specialist objects that are given access rights to those patient objects of patients referred to the specialist by physician obj ects representing primary care physicians. The security policy of the patient object would govern the ability of any physician object to access the workspace belonging to that patient object. Each patient object would store the patient's x-rays and other medical records, the date of the last exam, and other medical information in its workspace belonging to the patient object. The patient object can have a chat room buffer in its workspace where the patient can meet with the physician to have an online conversation about the patient's health. The conversation can be recorded in the patient's workspace for future reference by the physician or by the specialists whose respective software agent objects are given access to the workspace belonging to the patient object.

Another aspect of the invention is the ability to specify a point of view to be displayed of a selected object with respect to other objects related to the selected object. The relationships file of the selected object is accessed and all of the relationships tags for that selected software agent object are scanned to identify the other software agent objects which are related to the selected object. A map image is prepared depicting those relationships. Then, the display buffer provides an image of the map to the display monitor of the desktop computer.

The resulting invention enables network collaboration in an improved manner by creating persistent, bidirectional relationships between software agent objects that represent collaborative workspaces.

DESCRIPTION OF THE FIGURES

Figure 1 shows a simplified functional block diagram of the invention's architecture which includes a network of computer nodes, each of which has software agent objects in an object layer and a service module. Persistent, bidirectional relationships are established between the software agent objects. Each software agent object is a collaborative workspace. The collaborative workspaces are associated with other collaborative workspaces tiirough the reciprocal relationships that are created in respective pairs of software agent objects.

Figure IA shows an example implementation of the architecture of Figure 1, where both of the computer nodes are desktop computers in the network.

Figure IB shows another example implementation of the architecture of Figure 1, where one of the computer nodes is a desktop computer and the other computer node is a server computer in the network.

Figure 2 shows network diagram of an example hub-and-spoke network topology of desktop computers and server computers. The network is a federation of servers and desktops over which four organizational relationships are established for Alice's desktop. A first example organizational relationship is for Alice in project planning. A second example organizational relationship is for Alice as a patient consulting her two physicians. A third example organizational relationship is for Alice as a patient consulting a radiologist. A fourth example organizational relationsliip is for Alice as a client of two institutions, a venture capital company and an investment bank. Alice's software agent object can collaborate with other objects throughout the network.

Figure 2A shows network diagram of an example diverse topology network of desktop computers over which the same four organizational relationships are established for Alice's desktop, as is illustrated in Figure 2. The network includes a peer-to-peer subnetwork and a hub-and-spoke subnetwork.

Figure 2B shows network diagram of an example universal peer-to-peer network topology of desktop computers in a network over which the same four organizational relationships are established for Alice's desktop, as is illustrated in Figure 2. Figure 3 shows a flow diagram of an example sequence of operational steps illustrating how the service module 106 in any computer node in the network loads an XML object file such as Alice's person object XML file 800 (a simplified example is shown in Table 2) and converts it into an instance of Alice's person object 114 in the memory of the computer node.

Figure 3 A shows a flow diagram of an example sequence of operational steps illustrating how the service module in any computer node in the network creates a reciprocal relationship between two software agent objects in a network.

Figure 3B shows a flow diagram of an example sequence of operational steps illustrating how the service module in any computer node in the network sets up a chat session in a workspace located anywhere, for software agent objects located anywhere.

Figure 3C shows a flow diagram of an example sequence of operational steps illustrating how the service module in any computer node in the network dispatches software agent objects for scheduled chat sessions.

Figure 3D shows a flow diagram of an example sequence of operational steps illustrating how the service module in any computer node in the network deletes a local object.

Figure 4 illustrates an example software agent object 114 representing the user

Alice.

Figures 4A, 4B, and 4C are functional block diagrams illustrating a first example organizational relationship for project planning established between Alice's person object and three coworker person objects and one Plan Activity object. Figure 4D is a functional block diagram illustrating a second example organizational relationship for a patient consulting a radiologist who practices at a local hospital, established between Alice's person object, radiologist's person object, and a hospital's person object.

Figure 4E is a functional block diagram illustrating a third example organizational relationship for a patient consulting her two physicians, established between Alice's person object and two physician person objects.

Figure 4F is a functional block diagram illustrating a fourth example organizational relationship for a client of two institutions, a venture capitalist and an investment bank, established between Alice's person object and two person objects.

Figure 5 A is a detailed functional block diagram of Alice's desktop computer 102, illustrating an example off-line operation and the hosting of Alice's collaborative workspace software agent object 114.

Figure 5B is a detailed functional block diagram of the ABC Co.'s server computer 192, illustrating the hosting of the Plan Activity's collaborative workspace software agent object 190.

Figure 5C is a detailed functional block diagram of Alice's desktop computer 102, illustrating an example on-line operation where Alice's collaborative workspace software agent object 114 has been dispatched to the server 192.

Figure 5D is a detailed functional block diagram of the ABC Co.'s server computer 192, illustrating the hosting of Alice's collaborative workspace software agent object 114 and the Plan Activity's collaborative workspace software agent object 190. Figure 5E is a detailed functional block diagram of Bob's desktop computer 122, illustrating an example on-line operation and the hosting of Bob's collaborative workspace software agent object 134.

Figure 5F is a detailed functional block diagram of Alice's desktop computer

102, illustrating an example on-line operation and the hosting of Alice's collaborative workspace software agent object 114. The figure features the display of an object map 522 depicting the point of view from Alice's object 114, of the relationships between Alice's object 114 and all other objects for which Alice's object 114 has relationships tags.

Figure 5G is a detailed functional block diagram of Alice's desktop computer 102, of Figure 5F, which features the display of an object map 562 depicting the point of view from the Plan Activity's object 190 of Figure 4B, of the relationships between the Plan Activity's object 190 and all other objects for which the Plan Activity's object 190 has relationships tags.

Figure 5H is a detailed functional block diagram of Alice's desktop computer 102, of Figure 5F, which features the display of an object map 572 depicting the point of view from the Chuck's object 154 of Figure 4A, of the relationships between Chuck's object 154 and all other objects for which the Chuck's object 154 has relationships tags.

Figure 6 is a functional block diagram of the service module 106, showing an example of the loading of Alice's XML object file 800, the instantiation ofJavascri.pt code objects 1040 for Alice's person object instance 114 using an XML processor 820 and an XML application program interface 1000, and the dispatching of a modified version 800' of Alice's XML object file to other nodes in the network.

Figure 7 is a data flow diagram illustrating an example of how Alice's XML object file 800 (shown in Table 2) is loaded by the service module 106 and converted into Javascript code objects 1040 for an instance of Alice's person object 114 in the memory of a computer node 102. An example layout of the memory partitions of Alice's person object 114 is shown in Figure 7.

Figure 7A shows another example layout of the memory partitions 830, 832, 834, 836, 838, and 840 of Alice's person object 114, wherein the partitions are distributed in non-contiguous locations in the address space of the memory 104.

Figure 7B shows still another example layout of the memory partitions 830, 832, 834, 836, 838, and 840 of Alice's person object 114, wherein Alice's workspace partition 840 is located in the memory 194 of a remote computer node, such as the server 192.

DISCUSSION OF THE PREFERRED EMBODIMENT

Overview

The invention is a distributed, collaborative system that promotes enterprise- wide and network wide coordination of initiatives, strategies, projects, goals and objectives. The technology is based on the concept that information sharing and interactivity is a more appropriate perspective than mere information "storage and filing" paradigms. This "view" of the world enables the invention to offer new ways of working with one another and with information in general.

At the most basic level, the invention is a virtual distributed file system, allowing users to share information without regard to which computer actually stores the information. Information sharing occurs within the context of the business of an organization. By organizing activities by strategy, initiative, and project, the organizational metaphor becomes the navigational technique in the invention. In this way, information in the invention is naturally and inevitably in the context of another object or entity so that it can not be orphaned. In the invention, information is stored in an object that possesses context, it maybe a project, a strategy, an initiative, etc. Thus objects are discovered, managed, and maintain currency and relevancy through their reciprocal relationships with other objects. The content of an object is it's a set of properties and methods that define its behavior, user interface, and interaction with other objects.

A distributed object approach allows objects to evolve independently. Objects can run either on-line or off-line. Objects can communicate with each other without the need for a centralized administrator. Objects can model a variety of enterprise entities (tasks, initiatives). As each new object enters the system it can easily interact with existing objects. The ultimate flexibility of the system is preserved with this approach, allowing the system to grow organically within an enterprise or across a network.

Components

Figure 1 shows a simplified functional block diagram of the invention's architecture which includes a network 115 of computer nodes 102 and 192, each of which has collaborative workspaces implemented as software agent objects 114, for example, in an object layer 125 and a service module 106. Persistent, bidirectional relationships 425 are established between the software agent objects, such as between 134 and 154. Each software agent object, 114 for example, is its own collaborative workspace. Software agent object 134 is its own collaborative workspace, software agent object 154 is its own collaborative workspace, and software agent object 174 is its own collaborative workspace. The collaborative workspaces are associated with other collaborative workspaces through the reciprocal relationships 425 that are created in respective pairs of the software agent objects 134 and 154. Figure IA shows an example implementation of the architecture of Figure 1, where both of the computer nodes 102 and 122 are desktop computers in the network 115. Each desktop computer, for example desktop 102, has a visualization layer 155, in addition to the service module 106. The visualization layer 155 includes a web browser 165 that interfaces with an HTTP server 145 in the service module 106. Figure IB shows another example implementation of the architecture of Figure 1, where one of the computer nodes is a desktop computer 102 and the other computer node is a server computer 192 in the network 115.

The Objects

All objects in the inventive system are interrelated software agent objects, hi Figure IB, for example, the object 134 in the desktop 102 has a reciprocal relationship with the object 154 in the server 192. Similarly, the object 174 in the server 192 can have a reciprocal relationship with the object 114 in the desktop 102. Within the object layer 125 of the desktop 102 and the object layer 125' of the server 192, there are many objects, each of which has a reciprocal relationship defined with one or more other objects. Within the inventive system it is impossible to create an object that is an orphan. By enforcing the idea that all objects must have at least one reciprocal relationship, the invention prevents islands of knowledge within an enterprise or network and assures that the systems orientation toward collaboration is maintained.

Software agent objects represent resources, assets, ideas, or entities within the system such as a person, a group or team, a project, a strategy, an initiative, a goal, or an event. A software agent object defines its behavior for the entity it is modeling with scripted methods, properties and HyperText Markup Language (HTML)-based user interfaces. Each software agent object is its own collaborative workspace that is logically a part of it, but which can be optionally located in a separate computer memory. Objects reside on any computer node in the network.

Examples of the inventive feature of the reciprocal relationship tags interacting with collaborative workspaces. The user can setup a collection of software agent objects to notify each other via reciprocal relationships for a simple purpose of rolling up a status. Several software agent objects acting autonomously use the reciprocal relationship tags between them to notify each other of their status, allowing one or more of these objects to compute an aggregate status. The reciprocal relationships act as sensors, allowing each software agent input from other software agents as to the nature of the world around it. This allows one agent to affect another, updating each other's workspaces as appropriate.

A similar example is one software agent object, a news searcher, searches a collection of data three times a day, autonomously. It has a reciprocal relationship to two person software agent objects and one activity object. When the search yields some new data, it stores that data in the activity object and sends notifications to each of the person objects via the reciprocal relationships. It is the reciprocal relationship in this case that tells the news searcher object which other objects care about the results of a search.

Another example is two activity objects, related to one another through a "follows/folio wed-by" reciprocal relationship. When one activity's status is set to finished, the reciprocal relationship is used to set any object's that are "followed-by" to a status of started. The predecessor object uses the reciprocal relationship to know which object might inherit the payload of the first activity (imagine a document going through revisions, but being archived at each step of the process).

The principle is that reciprocal relationship tags enable software agent objects to work together. Software agents typically lack good sensory input and this problem is solved with reciprocal relationships to allow them to competently understand each other and the surrounding world. These objects can move tiirough the network (complete with a payload) and using the reciprocal relationships tags to understand which object to interact with and when is correct. The invention provides both mobility in objects (enabling them to jump from network node to node) as well as the remote procedure call interface allowing objects to call functions between network nodes, if mobility isn't important in completing an operation. Mobility can be important, even if communication is available, there are places for both.

The invention has the capability to provide a person object with multiple reciprocal relationships, each with a reciprocal relationship property indicating when to do something with each one and a reciprocal relationship property indicating what to do with them. So at 8AM, Alice's person object notes that the first reciprocal relationship it has is to a weather software agent object and is supposed to call the "getTodays Weather" function to retrieve a weather summary into Alice's person object. Likewise, a search object in the system notes that at 11 AM it's reciprocal relationship to Alice's person object indicates that it is to place the results of a web search into Alice's object as a file. At 10AM, Alice's object is set to deliver a document (stored in Alice's object at first) into a project object, because Alice promised that she would update the document with the most current revision at 10AM every day. Alice's object can have a reciprocal relationships to a project object, which each day at close of business is checked for new documents and measured for the amount of interaction that occurred in that object. Each of these actions is an autonomous operation taken by a software agent object in the system and uses the reciprocal relationships to understand the role that software agent with respect to others and for access to each other's payloads. The functions listed above are what two software agents can do with each other at scheduled intervals.

Each software agent object is a workspace where the user's documents can be parked. The user can put documents into his or her own person object or into another user's person object. The user's display is configured within the context of his or her person object and is a set of data that's part of his or her person object. Those are elements in the person object's workspace, although they are not explicitly identified to the user as such. If the user adds documents, they are placed in a binder, which is also a software agent object that contains a collection of documents. Every workspace is a software agent object and every software agent object is a workspace.

The invention uses an event model which is a collection of sensors on a software agent object that provide receptacles for understanding changes to itself. For example, before a property on one of the software agent objects can change, the software agent object is notified through its "onChangeProperty" handler to determine if it wants the property to change and then is notified again through its "onChangedProperty" handler to indicate that the change was completed. This is similar to the perception of touch where the nerves signal in advance that you might be touching something hot (a preliminary warning) and then the nerves signal again that in fact you have touched something hot. This is exactly like how the invention's software agent object operates.

The reciprocal relationships are coupled into additional sensors so that a software agent object knows that reciprocal relationships have been added to it and can take appropriate action. But the reciprocal relationships also allow two software agent objects to know that each other exist and to talk to each other. Reciprocal relationships also convey credentials. If two person objects are related to a group software agent object that has permissions to work in a particular workspace, then the two person objects get credentials to the group object. Reciprocal relationships are used for diagramming collections of software agent objects (vis a vis the map view). Reciprocal relationships can be used to determine where a software agent object lives. For example, if a new software agent object is related to two other objects that happen to live on a particular node, then the new software agent object can choose to take up residence there.

The key point is that reciprocal relationships allow two software agent objects to know of each other's existence. This assumes that each object has a sufficient amount of intelligence to care. Two software agent objects, knowing of each other's existence, can alter the each other's contents, hence collaborate. For example, software agent object A is "OWNED-BY" software agent object B. When software agent object A gets a new document or updates a document, it archives a copy in software agent object B. Object "A" needed to use the reciprocal relationship to determine semantically that object "B" is properly situated in the universe (the verb relationships) and is of the correct type (perhaps it's a document archive) so that object "A" knows how to take the appropriate actions.

The Desktop The desktop computer 102 of Figure IB is a user's primary route to view his or her working world and to access the virtual arena of the invention. In addition to the object layer 125, the desktop 102 includes the service module 106 and the visualization layer 155. The service module 106 includes object services 135 which provides services to the objects, such as "load object", "delete object", "create object", and "add relationship to object". The object services 135 of the desktop 102 provides the connection over the communication link 115 to other Desktops 122, 142, and 162 tiirough a Server 192 in a hub-and-spoke setup, as shown in Figure 2.

Figure 2 shows a network diagram of an example hub-and-spoke arrangement of desktop computers 102, 122, 142, and 162 and the server computer 192 in a network 115. The network 115 includes a federation of servers 192 A, 192B, 192C, and 192D and desktops 102, 122, 142, 162 and 102 A through 102G over which four organizational relationships are established for Alice's desktop. A first example organizational relationship 425 is for Alice in project planning, shown in Figure 4 A. A second example organizational relationship 455 is for Alice as a patient consulting a radiologist, shown in Figure 4D. A third example organizational relationship 435 is for Alice as a patient consulting her two physicians, as shown in Figure 4E. A fourth example organizational relationship 445 is for Alice as a client of two institutions, a venture capital company and an investment bank, as shown in Figure 4F. The workspace of Alice's software agent object 114 provides a forum for the exchange of documents and messages with other objects throughout the network shown in Figure 2 by means of message transmissions and remote procedure calls. If the location of Alice's software agent object needs to be changed to another computer node in the network, Alice's XML object file 800 is transmitted from one computer node to another, where it is instantiated into the Javascript code objects 1040 for Alice's person object instance 114, as detailed in Figure 6.

Figure 2A shows network diagram of an alternate example diverse topology network of desktop computers over which the same four organizational relationships 425, 455, 435, and 445 are established for Alice's desktop, as is illustrated in Figures 2, 4A, 4D, 4E, and 4F. The network includes a peer-to-peer subnetwork 115PP wherein desktop computers 102, 122, 142, and 162 and the server computer 192 are interconnected via the ABC Co.'s LAN 192'. The network also includes a hub-and- spoke subnetwork 115HS wherein desktop computers 102F and 102G and the server computer 192D are connected as the spoke nodes to the server 192C which is the hub node. Figure 2B shows network diagram of another alternate example universal peer- to-peer network topology of desktop computers in a network over which the same four organizational relationships 425, 455, 435, and 445 are established for Alice's desktop, as is illustrated in Figures 2, 4A, 4D, 4E, and 4F.

In Figure IB, the object services 135 of the service module 106 in the Desktop

102 provides an interface to other applications in the visualization layer 155, for example Microsoft Windows applications 175. Examples of these applications are a word processor program, for example Microsoft Word, a spreadsheet program, for example Microsoft Excel, and the like. The service module 106 in the Desktop 102 provides a HyperText Transfer Protocol (HTTP) server 145 that provides an interface to a web browser 165, for example Microsoft Internet Explorer, in the visualization layer 155. It is through the desktop 102 that users organize, create, delete and interact with the invention directly, or in conjunction with other applications. While objects on the Desktop may appear to the user as "local", the system may really store it virtually anywhere in an enterprise or network.

The Servers

While the invention is capable of operating in a direct peer-to-peer configuration between desktops 102, the servers 192 can act as super peers, generally housing larger, shared collections of objects. In addition to the object layer 125' in the server 192 of Figure IB, the server 192 includes the service module 106'. The service module 106' includes object services 135' which provides services to the objects, such as "load object", "delete object", "create object", and "add relationship to object". The object services 135' of the server 192 provides the connection over the network or communication link 115 to the Desktops 102, 122, 142, and 162 in a hub-and-spoke configuration, as shown in Figure 2.

A Server can also act as a directory service, helping Desktops locate objects within an enterprise or network. Servers form federations, as shown in Figure 2, sharing directory spaces and offering connectivity in an extended Intranet that extends between enterprises, or over wide area networks such as the Internet. As is seen in the network diagram of Figure 2, the server 192 is connected over the communication link 115 to the other servers 192 A, 192B, and 192C. The server 192A connects desktops 102 A and 102B to the network 115. The server 192B connects desktops 102C, 102D, and 102E to the network 115. And the server 192C connects remote server 192D and desktops 102F and 102G to the network 115.

The Service Module

As an application extends beyond its own internal content, the service module 106 allows external data sources to provide information. Service module 106 can tap into both structured and unstructured data sources. Structured data sources can include financial and enterprise resource planning (ERP) systems, such as SAP R/3 (an integrated suite of applications developed by the German software company, SAP AG), while unstructured data sources can include web search engines and document databases.

The service module 106 includes program support for establishing workspaces, enforcing security policy, creating reciprocal relationships, sending and receiving messages and notifications, updating the status of attributes, and searching for other objects based on their reciprocal relationships.

The functions performed by service module 106 in the desktop computer 102, server computer 192, and other computer nodes in the network, are provided by programs of executable instructions written in C++, Javascript, or other suitable programming languages. These programs implement the service module 106 and other components in the desktop or server. Other components in the desktop of server include an XML parser to interpret the XML tags and elements in XML object files and an XML processor to convert those XML object files into instances of software agent objects in the memory 104. A simplified example of an XML file 805 for base person object is shown in Table 1. A simplified example of an XML file 800 for instance of Alice's person object 114 is shown in table 2. The desktop and server programs can also be configured with parameters provided by XML files, simplified examples of which are shown in Tables 6 and 7, respectively. Additional details concerning the loading of XML object files, the instantiation of software agent objects from those XML object files, and the modification and dispatching of those XML object files to other nodes in the network, will be discussed later with reference to Figures 6 and 7.

THE ARCHITECTURE

The Desktop Architecture

The invention is accessible in the desktop 102 from the Windows systems 175, the web browsers 165, and any device capable of a network connection. By creating a separate visualization layer 155 in the desktop 102, critical activities can be viewed by any of these devices or alerts sent to any of these devices, and displayed (or otherwise captured) in accordance with the capability of the receiving device.

The desktop 102 can be viewed through Windows Explorer or other browsers 165. hi the Windows 175 view, drag and drop operations permit the user to create and delete relationships between objects. Double-click operations allow a user to open the contents of the system just as if he or she were working from a local disk. The Windows 175 view supports multiple views of the contents in the system, in addition to the usual "list", "details", "small icon", and "icon" views, the invention adds additional views that show relationships in graphical formats.

The HTML view is provided by the web page browser 165 interface for interacting with objects. An object can support multiple HTML views within the system, defined by the "view" tag within the object's Extensible Markup Language (XML) Web formatting specification file. A browser or the Windows Explorer can ask an object to render itself as HTML for viewing. From a standard web browser, a user can see, configure and use all of the features of the invention. XML is a reduced version of Standard Generalized Markup Language (SGML), used for defining and inteφreting tags according to SGML rules. A tag is a command inserted in a document that specifies how the document should be formatted. XML permits the creation of customized tags, enabling the definition, transmission, validation, and interpretation of data between applications. A more detailed description of XML can be found on the Internet web site of the World Wide Web Consortium, http://www.w3.org/XML/. A tutorial for XML is available in the book by Simon North and Paul Hermans, "Teach Yourself XML in 21 Days", Macmillan Computer Publishing, 1999. Another instructive text on XML is the book by Hiroshi Maruyama, Kent Tamura, Naohiko Uramoto entitled "XML and Java: Developing Web Applications", Addison- Wesley Pub Co, 1999.

Object Architecture

An object 114, for example, is persisted as a folder or directory on a file system. Every object in the system possesses a Globally Unique Identifier (GUTD), which is used to name the collection of elements that comprise the object. The GUID can be a 128 bit numeric value generated by the one-way hash function of the MD5 Message-Digest Algorithm, as described in the Internet Engineering Task Force (IETF) Request For Comments (RFC) 1321. Every object is structurally represented as an XML file, defining the behavior of the object, its reciprocal relationships to other objects, and its other parts, hi addition to the XML file, an object may be composed of other files that form its user interface and contain larger sets of data. Objects within the invention can inherit behaviors and properties from other objects. This allows a blanket set of functionality to be applied to a collection of objects. For example, all tasks may have the same basic user interface, properties, and methods. A single object can be defined for all tasks, reducing the amount of code within a derived object.

Software agent objects contain scripts that are coded in JavaScript. The service module is coded in C++. When an object loads, an XML processor opens the XML file associated with the persistent form of the software agent object. That XML file identifies the relationships, properties, JavaScript script, security policy, published rules, title and description of the software agent object. This XML file when loaded creates in memory representations of these things within the Service Module. In addition, and on an as needed basis, files, documents, chat buffers, etc. are loaded from the persistent representation of the software agent object. For example, when a user wants to open a file for editing within a software agent object, the Invention Service Module locates the file (in a pre-defined location within the persistent representation of the object) and loads it at that time, passing the contents through to a word processor. The persistent form of software agent objects in the system are really a file system directory containing an XML file, a script (optionally), and a collection of files, documents, chat buffers, notification buffers, etc. One can think of this as the serialized form of a software agent object. These files and the like can be referred to as either "documents" or "ancillary files". "Documents" are usually shown to a user and "ancillary files" (such as chat buffers) are not. But they are all part of the structure of an object. Each software agent object, itself, is the collaborative workspace. The software agent object is a container for files, documents, and other data elements that would otherwise be too large to encode in the XML file, which defines the object's structure. These files and documents can be thought of as being extra large properties that would waste space in an XML file. The object is a collaborative workspace implemented as a software agent object. The part of the object that contains customized records, documents and other things is the software agent object's payload and is actually part of the software agent object.

The Service Module

The Service Module 106 is the communications hub of the desktop 102. All requests for objects and their contents ultimately pass through the Service Module 106. The Service Module looks at the objects it possesses locally and attempts to return the requested content. If the object is remote, the Service Module passes the request on to a remote Service Module, either another Desktop 122, for example, or to a Server 192.

Internally, the Service Module 106, in desktop 102, maintains a single instance of each object, for example objects 114 and 134. It preserves the singleton nature of the objects and manages multiple accesses of the same object. By maintaining this architecture, external updates to objects are handled easily. The registry 116 keeps track of all of the objects in the desktop memory.

On a network level, the Service Module 106 can act as the primary router for Desktops and Servers. The registry 118 keeps track of all of the objects in the network or a given region of the network. Upon starting, the Service Module 106 in desktop 102, it seeks out other desktops 122, 142, 162, 102A, and 102B, for example, or servers 192, 192 A, 192B, 192C, and 192D, for example. If only Desktops are found, the Service Module 106 establishes peer connections with the other Desktops and shares a list of objects with them. For hub-and-spoke network topologies, if a Server is found, the Service Module 106 of Desktop 102 connects to the Server, such as server 192, and relies on the Server 192 to find remote objects for the Desktop.

The Server

The service module 106' in the Server 192 architecture is a higher performance version of the Desktop's service module 106. The service module 106' is capable of communicating with Desktops for returning object requests as well as talking with other Servers to form a federation. The federation of servers shown in Figure 2, allows object requests to be routed from a Desktop 102 through a local Server 192, to a remote Server 192D, all transparently to the user. The Server 192 also contains a list of object names and their locations culled from other servers 192A, 192B, 192C, and 192D in a federation network shown in Figure 2.

THE OBJECT STRUCTURE

Objects are the basic programmatic unit for the invention. Each object contains a complete definition of its properties and methods as well as explicit references to base objects. Every object is identified by a globally unique identifier (GUTD), which is used to access the object.

Objects generally fall into two categories within the invention, instances and base objects. A base object is used to define a class or type within the invention. Objects may be derived from one or more base objects. A base object may be opened directly and have its methods called. Base objects are developed by software engineers for use by users. Examples of base objects are person, activity, group, and enterprise. An instance is substantially the same as a base object except that it is usually created by a user. An instance also only inherits from one base object. In contrast, base objects may be multiply inherited.

OBJECT INSTANCE STRUCTURE

The following are examples of XML tags that are inserted into an XML object file to specify the software agent object's properties and reciprocal relationships. Every software agent object is originally written as an XML file. When the XML file is instantiated in the memory, the instance object contains a complete definition of its properties and methods as well as explicit references to its base object. An instance object is substantially the same as a base object and inherits generic features from its base object. The content of Alice's instantiated person object 114 is defined by the combination of the information in a base XML file 805 (a simplified example of which is shown in Table 1) for a generic person object and the information in an instance XML file 800 (a simplified example of which is shown in Table 2) which specifies the unique features of Alice's person object 114.

Each XML file for a software agent object begins with an XML declaration, an example of which is "<?XML VERSION="1.0"?>". The declaration identifies what follows as XML code and states the version of the XML standard the code complies with. It also specifies whether the document can be treated as a stand alone document or whether a document type definition (DTD) must also be retrieved in order to make full sense of the contents. The XML declaration is a processing instruction which is identified by the "?" at its start and end. The service module 106 shown in Figure 7, includes an XML processor 820 and an XML parser 815 to interpret the XML tags and elements in the object's XML file 800 and to convert it into an instance 114 of the object in the memory 104. The XML processor 820 derives the instance of Alice's person object 114 from generic information in the base XML object file 805 (a simplified example of which is shown in Table 1), filling in the details which are unique to the instance of Alice's person object as they are specified in the instance XML object file 800 (a simplified example of which is shown in Table 2). One example of this function performed by the XML Processor 820 is the method 200 in the flow diagram of Figure 3.

Every object specified in an XML object file is surrounded with a beginning object tag portion "<OBJECT> " and an ending object tag portion "</OBJECT> ". An example of an XML file for a base person object is shown in Table 1. Simplified examples of XML files for instances of person objects are shown in Tables 2 and 3. A simplified example of an XML file for an instance of a document object is shown in Table 4.

Each object specified in an XML object file has a title with a beginning title tag portion "<TITLE>" and an ending title tag portion "</TITLE>". An example of its use is as follows:

<TITLE>Alice</TITLE>

Each object specified in an XML object file has a description with a beginning description tag portion "<DESCRIPTION>" and an ending description tag portion "</DESCRIPTION>". An example of its use is as follows:

<DESCRIPTION>Department Manager</DESCRIPTION>

Each object specified in an XML object file may have one or more types. A type indicates a base object from which the object was derived. Instance objects generally only have one TYPE tag with a beginning tag portion "<TYPE>" and an ending tag portion "</TYPE>. An example of its use is as follows:

<TYPE>_person </TYPE>

The relationships section of an object is a persistent collection of pointers to other objects. Each relationship consists of at least a verb. Each object specified in an XML object file has a relationships tag with a beginning relationships tag portion "< RELATIONSHIPS >" and an ending relationships tag portion "</ RELATIONSHIPS >". The GUTD of the other object in the relationship is specified. A verb tag is included that has a beginning verb tag portion "<VERB >" and an ending verb tag portion "</ VERB >". An example of its use is as follows:

<RELATIONSHIPS>

<XO_58107350FFFFE5471ID381EOC45B86D24ABA OBJTYPE="_person"> <VERB>WATCHED-BY</VERB> </XO_58107350FFFFE5471ID381EOC45B86D24ABA> </RELATIONSHIPS>

Verb tags for an object specified in an XML object file are those verbs that are appropriate for a particular object type. Verbs for an activity object, for example enable the activity object to own or to be owned by another object. The activity object may follow or may be followed by another activity object. The activity object may be managed by a person object, but of course it cannot manage. The activity object can be approved by, it can be implemented by, it can be watched by a person object. Each verb also has its inverse verb. A matching algorithm in the service module 106 determines whether there are matching reverse verbs in two objects when a reciprocal relationship is being established between the two objects. For example, if an owning reciprocal relationship is to be established between an activity object and a person object, the service module 106 establishes matching reverse verbs in the two objects. The person object <OWNS> the activity and the activity object is <OWNED_BY> the person object. A direction is also associated with the reciprocal relationship. There are four directions: parent, child, proceeds and follows. This is used as a graphical clue when rendering a drawing of the reciprocal relationship in the Windows Applications 175, for example. "Parent" and "child" directions are top and bottom, respectively, and "proceeds" and "follows" directions are the left and the right, respectively.

An object may publish certain events. This indicates for an object specified in an XML object file that a related object (as identified by its GUTD) is interested (as specified by the "WATCHED-BY" verb) in receiving notification when some change or action takes place in the publishing object. The PUBLISH tag has a beginning tag portion "<PUBLISH>" and an ending tag portion "</PUBLISH>. In this example, this object publishes two events for a particular sibling. The sibling (the related object) will receive the event notifications defined by the PUBLISH tag.

<RELATIONSHIPS>

<XO_58107350FFFFE5471ID381EOC45B86D24ABA OBJTYPE="_person"> <VERB>WATCHED-BY</VERB> <PUBLISH NAME="Status Changed" VERB= ' "></PUBLISH>

<PUBLISH NAME=" Approval Status Changed" VERB=""></PUBLISH> </XO_58107B50FFFFES4711D381EOC45B86D24ABA>

<XO 688715BOFFFFE5681ID381EDC45B86D24ABA OBJTYPE="bc_activity"> <VERB>OWNS</VERB> <PUBLISH NAME="Status Changed" VERB= '"></PUBLISH>

</XO 688715BOFFFFE5681ID381EDC45B86D24ABA>

</RELATIONSHIPS>

A project object, for example, might include a publish rule that publishes the occurrence an event by transmitting notification of the occurrence to listening objects. The project object would have a reciprocal relationship tag with a "watched-by" forward verb and a designation of the identity of the listening objects. Each of the listening objects would have a corresponding reciprocal relationship tag with a "watches" reverse verb and a designation of the project objects. If the event occurs in the project object, then the publish rule causes the project object to send a message to the listening objects notifying them of that event. There can be consecutive project objects, one following the other in a project schedule. The first occurring project object would have a reciprocal relationship tag with a "folio ed-by" forward verb and a designation of the second occurring project object. The second occurring project object would have a corresponding reciprocal relationship tag with a "follows" reverse verb and a designation of the first occurring project object. Listening objects to the second project object, for example, can include programmed methods to take certain actions in response to receiving event messages from the second project object.

Each object specified in an XML object file may contain an arbitrary collection of properties, defined by <PROPERTIES> </PROPERTIES> tags. These properties may contain XML style attributes that further define the type of property. An example of the properties portion of an XML file for an object is shown in Table 5.

The outer PUBLISH tag defines any events that the object may publish to other objects. Tins section is used to define outbound objects.

<PUBLISH> </PUBLISH>

For an object specified in an XML object file, the ATTRIBUTES section defines attributes of the object, in particular change times for certain object sections.

<ATTRIBUTES>

<LASTOBJECTUPDATE>950798751397.000000</LASTOBJECTUPDATE> <LASTPROPERTYUPDATE>950798751367.000000</LASTPROPERTYUPDATE > <LASTRELATIONSH1PUPDATE>0.000000</LASTRELATIONSHIPUPDATE> <LASTSECUMTYΠ^OUPDATE>O.OOOOOO</LASTSECURITYΓNFOUPDATE> <LASTPUBLISHEDRULESUPDATE>0.000000</LASTPUBLISHEDRULESUPDA

TE> </ATTRIBUTES>

One important property of an object is its security policy. For an object specified in an XML object file, the SECURITY- POLICY section of the object's properties indicates the access level that other objects have been granted. The SECURITY-POLICY tag has a beginning tag portion "<SECURITY-POLICY>" and an ending tag portion "</SECURITY-POLICY>.The security policy in an particular object states the access restrictions which must be met by another object in order to successfully establish a reciprocal relationship with the particular object. A person object, for example, may state as an access restriction, that the object will not allow Internet advertiser objects to establish a reciprocal relationship with the person object. As another example, a strategy object may state as an access restriction, that the object will not allow a person object to establish a reciprocal relationship with it, without the presentment of a cryptographic key. Still another example is as follows:

<SECURITY-POLICY>

<ALLOW TYPE-"R"> </ALLOW> <ALLOW TYPE="RW"> </ALLOW>

<ALLOW TYPE="RWD">

<XO_58107B50FFFFE54711D3818OC45B86D24ABA>READWRITEDELETE</XO

_58107B50FFFFE54711D3818OC45B86D24AB A </ALLOW> </SECURITY-POLICY>

BASE OBJECT STRUCTURE

The following is an annotated sample XML file that describes a base object. Every object is surrounded with <OBJECT> tags.

<OBJECT>

Base objects have titles ...

<TITLE>Person Name</TITLE>

and a descriptions.

<DESCRIPTION>General Base Person Obj ect</DESCRIPTION> Base objects may have one or more types. A type indicates a base object from which the object was derived. While instance objects generally only have one TYPE tag, base objects may have several, indicating multiple inheritance.

<TYPE>_personBase </TYPE>

Base objects may have specific views defined within them. Views can be inherited from base objects. The view tag defines the MIME-type of data that can be retrieved from the object, a description or DISPLAY-NAME for that data, and a FUNCTION that may be called to retrieve that information.

<VIEW NAME="small icon"> <TYPE>application x-engenia-icon</TYPE> <DISPLAY-NAME>Small Icon</DISPLAY-NAME> <FUNCTION>getSmalllcon</FUNCTION> </VIEW>

<VIE NAME="large icon"> <TYPE>application/x-engenia-icon</TYPE> <DISPLAY-NAME>Large Icon</DISPIAY- NAME> <FUNCTION>getLargeIcon</FUNCTION> </VIEW>

The VERB tag defines the verbs that are valid for the object. The verbs defined indicate directionality, defining whether the verb is a PARENT, CHILD, or PEER relationship type. The reverse verbs are used to match other objects to decide whether two objects may be related.

<VERB NAME="OWNS" REVERSE=" OWNED-BY" DIRECTION="PARENT"> </VERB>

<VERB NAME="OWNED-BY" REVERSE="OWNS" DIRECTION="CHILD"> </VERB>

<VERB NAME="FOLLOWS" REVERSE="FOLLOWED-BY" DIRECTION="PEER"> </VERB>

<VERB NAME-"FOLLOWED-BY" REVERSE="FOLLOWS" DIRECTION="PEER">

< VERB>

<VERB NAME="MANAGED-BY" REVERSE="MANAGES" DIRECTION="CHILD">

</VERB>

<VERB NAME="APPROVED-BY" REVERSE=" APPROVES"

DIRECTION="CHlLD"> </VERB>

<VERB NAME-"IMPLEMENTED-BY" REVERSE="IMPLEMENTS" DIRECTION="CHILD"> </VERB>

<VERB NAME="WATCHED-BY" REVERSE^" WATCHES" DIRECTION="CHΓLD"> </VERB>

An object may publish certain events. The events are defined by a called event handler and the value of the arguments when that event handler is called. In the example below, two published rules are defined. The first indicates that when the onChangedProperty( ) event is triggered, if the first argument of that event is "status", then the rule is to be fired. The second indicates that when onChangedProperty( ) event is triggered, if the "approval-status" has been set to approved, then the published rule is to be fired. Published rales fire through the onReceiveMessage( ) event handler to the recipient object.

<PUBLISH> <RULE NAME-'Status Changed' EVENT="onChangedProperty">

<CONDITION>(arg().toUpperCase() = 'STATUS')</CONDITION> <ACTION>#PASSTHROUGH#</ACTION>

</RULE>

<RULE NAME=' Approval Status Changed' EVENT="onChangedProρerty"> <CONDITION>( (arg().toUpperCase( ) = 'APPROVAL-STATUS') && (argl = =... ) <ACTION>#PASSTHROUGH#</ACTION>

</RULE>

</PUBLISH>

Base objects may have reciprocal relationships defined, just like instances, except that these relationships typically are to other base objects.

<RELATIONSHIPS> </RELATIONSHIPS>

Each object may point to a script file, where the JavaScript code is kept defining the object's behavior.

<SCRIPT LANGUAGE="jscript" SRC="jperson.js"/>

Each object may contain an arbitrary collection of properties. These properties may contain XML style attributes that further define the type of property. For base objects properties may be defined as inherited by instance objects. To do this, the property attribute private must be set to false. This in effect copies the property into the instance object with the defined value.

<PROPERTIES>

<ACTIVITY-TYPE private="false" track="true" TYPE="_pti_freeformat">. <ACTUAL-START_DATE private="false" track="true" TYPE="_pti_dateplus">.... <ACTUAL-COMPLETE-DATE private="false" track="true" TYPE="- Pti_dateplus">.... <APPROVAL-STATUS private="false" track="true" TYPE="- pti_review" >.... COMPLETION STATUS private-' alse" track="true" TYPE="_pti_review" > ....

<STATUS FUNCTION

track="true" TYPE="jpti_function">.... <STATUS OWN FUNCTION private="false" track="true" TYPE="_pti freeformat"> <STATUS ρrivate="false" track="true">notstarted</STATUS> </PROPERTIES>

EXAMPLES OF ACTUAL XML AND JAVASCRIPT FILES

Table 8 is an example of an actual XML file "_bc_person.xml" for a base person object. Table 9 is an example of a Javascript file "_bc_person.js" which is included in the XML base file "_bc_person.xml" (Table 8). Table 10 is an example of an XML file "xo_guidl .xml" for an instance of a person object which is based on the XML base file "_bc_person.xml" (Table 8) and which is related to the activity object XML file "xo ask.xml" (Table 11). Table 11 is an example of an XML file "xo_task.xml" for an instance of an activity object that is related to the person object XML file "xo_guidl.xml" (Table 10).

SERVICE MODULE METHOD TO LOAD AND INSTANTIATE AN OBJECT

The computer nodes in the network, such as a desktop 102 or server 192, frequently receive XML object files, such as XML file 800 for Alice's software agent object 114. The transfer of Alice's object 114 from the desktop computer 102 of Figure 5 A to the server computer 192 of figure 5D, is one example. The service module 106 loads the XML file 800 into its local memory 104 and instantiates it as an instance of the software agent object 114. The service module 106 then writes a reference to the addition of the newly instantiated object into its registry 116. The host desktop or server may receive the XML object file 800 in a transfer from another desktop or server, such as would result from the object dispatching method 390 of Figure 3C. Alternately, the receiving host desktop or server may read the object from its disk drive storage 506 or 606, respectively. If the receiving host is a desktop 102, then the service module 106 writes the reference into its registry 116. If the receiving host is a server 192, then the service module 106' updates its registry 118. Optionally, the desktop of server can also broadcast the update to other computer nodes in the network to update their respective registries.

The method 200 of Figure 3 shows an example flow diagram of a sequence of operational steps illustrating how the service module 106 in any computer node in the network can load an XML object file such as Alice's person XML object file 800 and can convert it into an instance of Alice's software agent object 114 in the memory of the computer node. Table 2 shows a simplified example of an XML object file 800 written for Alice's software agent object 114. The service module 106 shown in Figure 7, includes an XML processor 820 and an XML parser 815 to interpret the XML tags and elements in the object's XML file 800 and to convert the XML object file into an instance of the software agent object 114 in the memory 104. The XML processor 820 derives the instance of Alice's software agent object 114 from information in the base person XML object file 805 (a simplified example of which is shown in Table 1), filling in the details which are unique to Alice's person object 114 as they are specified in Alice's instance XML object file 800 (a simplified example of which is shown in Table 2). The instance XML object file is substantially the same as its base XML object file except that it is customized with properties and attributes that are unique to the particular instance of the object. The derivation of the instance object from the generic code and data of the base object is similar to the object-oriented programming principle of inheritance, except that the inheritance is from a base object instead of a parent class. The base object's structure and behavior are inherited by the instance object. New data structures and actions specified in the XML object file 800 are then added to the inherited ones from the base object 805 to result in the desired instance object 114. Where the underlying programming code for the base and instance objects is written in an object-oriented language such as Javascript, the code and data underlying the base objects define the actions and data structures that are inherited by the instance object. An example of a processor that can load and instantiate an XML object file is the XML Processor 820 of Figures 6 and 7. The XML Processor 820 is a computer program in the service module 106 that performs methods such as the method 200 in the flow diagram of Figure 3. This is just one example of how an XML object file can be loaded and instantiated in a computer node in the network. A discussion of the flow diagram of Figure 3 follows.

SERVICE MODULE METHOD TO LOAD AN XML FILE AND

INSTANTIATE THE SOFTWARE AGENT OBJECT THAT IT DEFINES

METHOD 200: TO LOAD AN XML FILE AND INSTANTIATE THE SOFTWARE AGENT OBJECT THAT IT DEFINES

STEP 201 : RECEIVE XML OBJECT FILE AND LOAD INTO MEMORY

STEP 202: READ THE NEW OBJECT'S TYPE FROM THE XML FILE AND RETRIEVE THE BASE OBJECT TEMPLATE FOR THAT TYPE

STEP 204: ALLOCATE LOCAL MEMORY AREA BEGF NTNG AT ADDRESS "X" FOR THE NEW OBJECT TO BE INSTANTIATED

STEP 206: PARTITION ALLOCATED MEMORY AREA INTO HEADER PARTITION 830, RELATIONSHIPS PARTITION 832, PROPERTIES PARTITION 834, SCHEDULE PARTITION 836, SCRIPT PARTITION 838, AND WORKSPACE PARTITION 840 (SEE FIGURE 7)

STEP 208: P STANTIATE THE BASE OBJECT ELEMENTS IN THE CORRESPONDING PARTITIONS OF THE ALLOCATED MEMORY AREA STEP 210: READ GUTD, TITLE, AND DESCRIPTION FROM THE XML FILE AND INSTANTIATE THEM IN THE HEADER PARTITION 830

STEP 212: READ RELATIONSHIPS FROM THE XML FILE AND INSTANTIATE THEM IN THE RELATIONSHIPS PARTITION 832

STEP 214: READ PROPERTIES, SECURITY POLICY, AND PUBLISH RULES FROM XML FILE AND INSTANTIATE IN PROPERTIES PARTITION 834

STEP 216: READ SCHEDULE FILE LOCATION FROM THE XML FILE AND IMPORT SCHEDULE OBJECTS INTO THE SCHEDULE PARTITION 836

STEP 218: READ SCRIPT FILE LOCATION FROM THE XML FILE AND IMPORT SCRIPT OBJECTS INTO THE SCRIPT PARTITION 838

STEP 220: READ WORKSPACE FILE LOCATION FROM XML FILE AND IMPORT WORKSPACES INTO WORKSPACE PARTITION 840

STEP 222: OPEN DOCUMENT COLLABORATION BUFFERS 842 AND CHAT BUFFERS 844 T THE WORKSPACE PARTITION 840

STEP 224: WRITE REFERENCE TO NEWLY INSTANTIATED OBJECT INTO REGISTRY FOR LOCAL NODE 102 AND UPDATE REGISTRIES IN ALL NODES THROUGHOUT NETWORK

The result of the method 200 is to load an XML object file and instantiate the software agent object that it defines. The method 200 and the XML processor program 820 are embodied as computer programs in the service module 106, consisting of a sequence of executable instructions which, when executed in the CPU processor running the computer node 102, carries out the steps of the method. There are other ways to load an XML object file and instantiate the object in a computer node in the network. SERVICE MODULE METHOD FOR CREATING RECIPROCAL RELATIONSHIPS BETWEEN OBJECTS

The service module 106 in the desktop 102 of Figure IB can create a reciprocal relationship between two software agent objects, for example objects 114 and 174. Correspondingly, the service module 106' in the server 192 can create a reciprocal relationship between two objects, for example objects 134 and 154. If the user at desktop 102, who is represented by a person object "OBJECT 'A' ", makes the request to the service module 106, then the service module 106 in the desktop 102 is programmed to perform the following method 300, described in the flow diagram of Figure 3A. This method 300 can also be requested by any application program or software agent object which is local to the service module or which is remote from the service module. The script code would look like this:

invention.add_Relationship("xo_guid_l","OWNS","xo_guid_2");

The reverse verb would be looked up against xo_guid_2 to obtain "OWNED-BY" and then the relationships would be added to each party.

Remote operations are conducted through remote procedure calls between the service modules. Method 300 of Figure 3A follows.

METHOD 300: TO CREATE A RECIPROCAL RELATIONSHIP BETWEEN OBJECTS

Step 302: RECEIVE REQUEST TO CREATE RELATIONSHIP BETWEEN OBJECT "A" AND ANOTHER OBJECT

Step 304: GET SECURITY POLICY FOR OBJECT "A" AND READ ACCESS RESTRICTIONS FOR ACCESSING OBJECT "A" Step 306: FORMULATE ACCESS CRITERION FOR PERMITTING ESTABLISHMENT OF RELATIONSHIP BASED ON ACCESS RESTRICTIONS

Step 308: RECEIVE REQUESTED RELATIONSHIP VERB AND

DIRECTION FOR OBJECT A

Step 310: RECEIVE GLOBALLY UNIQUE IDENTIFIER OF OTHER OBJECT

Step 314: GET LOCATION OF OTHER OBJECT

Step 316: ACCESS INFORMATION FROM OTHER OBJECT SUFFICIENT TO APPLY TO ACCESS CRITERION

Step 318: IF ACCESS CRITERION SATISFIED, THEN WRITE RELATIONSHIPS TAG WITH FORWARD VERB AND DIRECTION IN OBJECT "A" AND

WRITE RELATIONSHIPS TAG WITH REVERSE VERB AND REVERSE DIRECTION IN OTHER OBJECT

Step 319: IF ACCESS CRITERION IS NOT SATISFIED, THEN DENY USER REQUEST

The result of the method 300 is to establish a reciprocal relationship between the two objects. The method may use a remote procedure call to write the relationships tag for the other object into a remote computer via its remote service module. The method 300 is embodied as a computer program in the service module 106 consisting of a sequence of instructions which, when executed in the processor running the desktop 102, carries out the steps of the method. SERVICE MODULE METHOD TO SET UP A CHAT SESSION AT A WORKSPACE

Figure 3B shows a flow diagram of the sequence of operational steps illustrating how the service module in a desktop sets up a chat session in a workspace located anywhere, for objects located anywhere. A chat session is a type of messaging done over the network, involving short messages sent from one node to another. The messages can be exchanged in real time, sometimes with short messages replied to quickly. A chat session can be spontaneously invoked in RAM-resident chat buffers at the called party's location, where the called party is notified of an incoming message by a beep and a notice at the bottom of his or her screen. The method described here for Figure 3B provides for scheduling a chat session between two or more parties at a future time, where the chat buffers are to be located in a designated workspace. Either the user, an application program, or a particular software agent object can request a service module to set up a chat session between two or more objects. The objects to participate in the chat session can be located in any part of the network, not necessarily near the service module setting up the chat session, h addition to the identity of the objects which are to participate in the chat session, several scheduling parameters must be specified to set up a chat session: [1] the starting time of the chat session, [2] the ending time of the chat session, [3] the identity of the collaborative workspace for the chat session, and [4] whether the objects are to participate remotely from the workspace or be transported to the same computer node as the location of the workspace. The workspace may be designated by its GUTD. The method of Figure 3B must check the security policy of the workspace to determine that each requested object is authorized to have access to the requested workspace. Then the method writes the chat session parameters into the scheduling buffer of each participating object. The method also writes an entry into the security policy for each participating object to enable that object to access the designated workspace. For objects remote from the service module setting up the chat session, the service module uses a remote procedure call to the remote service module where the remote object is currently located, to write the chat session parameters into the scheduling buffer of each participating object. The steps of the method 360 of Figure 3B are as follows: METHOD 360: TO SET UP A CHAT SESSION AT A WORKSPACE

STEP 362: RECEIVE REQUEST TO SET UP CHAT SESSION AT WORKSPACE BETWEEN IDENTIFIED OBJECTS

STEP 364: RECEIVE [1] THE STARTING TIME OF THE CHAT SESSION, [2] THE ENDING TIME OF THE CHAT SESSION, [3] THE IDENTITY OF THE COLLABORATIVE WORKSPACE FOR THE CHAT SESSION, AND [4] WHETHER THE OBJECTS ARE TO PARTICIPATE REMOTELY FROM THE WORKSPACE OR BE TRANSPORTED TO THE WORKSPACE.

STEP 370: GET SECURITY POLICY FOR WORKSPACE AND READ ACCESS RESTRICTIONS FOR ACCESSING WORKSPACE

STEP 372: FORMULATE ACCESS CRITERION FOR ACCESSING WORKSPACE BASED ON ACCESS RESTRICTIONS

STEP 374: BEGIN LOOP: PROCESS NEXT OBJECT FOR CHAT SESSION

STEP 376: IF NEXT OBJECT HAS NO RECIPROCAL RELATIONSHIP TAG PN WORKSPACE, THEN DENY ACCESS TO NEXT OBJECT AND NOTIFY REQUESTER

STEP 378: ACCESS INFORMATION FROM NEXT OBJECT SUFFICIENT TO APPLY TO ACCESS CRITERION

STEP 380: IF ACCESS CRITERION IS SATISFIED, THEN WRITE SECURITY-POLICY PROPERTY TN NEXT OBJECT TO ALLOW READ/WRITE ACCESS BY NEXT OBJECT TO WORKSPACE STEP 382: WRITE INTO NEXT OBJECT'S SCHEDULING BUFFER [1] THE STARTING TIME OF THE CHAT SESSION, [2] THE ENDING TIME OF THE CHAT SESSION, [3] THE IDENTITY OF THE COLLABORATIVE WORKSPACE FOR THE CHAT SESSION, AND [4] WHETHER THE OBJECTS ARE TO PARTICIPATE REMOTELY FROM THE WORKSPACE OR BE TRANSPORTED TO THE WORKSPACE.

STEP 384: IF ANY MORE OBJECTS REMAIN TO BE SET UP FOR THE CHAT SESSION THEN GOTO STEP 374, ELSE END

The method 360 is embodied as a computer program in the service module 106 consisting of a sequence of instructions which, when executed in the processor running the desktop 102, carries out the steps of the method.

SERVICE MODULE METHOD TO DISPATCH A LOCAL OBJECT TO A SCHEDULED CHAT SESSION

The method 390 of Figure 3C can be initiated either by the host service module 106 in the desktop or server where the object is currently residing, or it can be initiated directly by the requesting software agent object, itself. The method of Figure 3C provides for both options: [1] The method starts at the beginning step 392 when the requesting object allows the service module in a desktop to perform the clock and schedule monitoring steps. [2] The method starts at the step 395 when the requesting object performs the clock and schedule monitoring steps, itself. The host service module typically performs the dispatching function for local objects currently residing in the same desktop or server. When the local object is sent from a host desktop 102, the service module 106 deletes the local object from registry 116 in the desktop and the server 192 servicing the host desktop 106 updates its registry 118. Optionally, the server 192 can broadcast the update to all servers throughout network to update their respective registries 118. When the local object is sent from a server 192, the service module 106' updates its registry 118 and broadcasts the update to all servers throughout network to update their respective registries 118. The method 390 of Figure 3C follows.

METHOD 390: TO DISPATCH A LOCAL OBJECT TO A SCHEDULED CHAT SESSION

STEP 392: MONITOR THE LOCAL CLOCK

STEP 393: MONITOR THE CHAT SESSION SCHEDULE BUFFERS OF THE LOCAL OBJECTS

STEP 394: IF ANY CHAT SESSION IS SCHEDULED TO START NOW, THEN NOTIFY EACH OBJECT

STEP 395: CONTINUE: (STARTING POP T FOR THE DISPATCHING

METHOD IF THE CLOCK AND SCHEDULE MONITORING STEPS ARE DONE BY THE OBJECT)

STEP 396: IF THE DESIGNATED WORKSPACE LOCATION IS REMOTE AND THE LOCAL OBJECT(S) ARE TO PARTICIPATE REMOTELY FROM THE WORKSPACE, THEN USE REMOTE PROCEDURE CALLS AND MESSAGES TO THE WORKSPACE FOR THE SCHEDULED CHAT SESSION

STEP 398: IF THE DESIGNATED WORKSPACE LOCATION IS REMOTE AND THE LOCAL OBJECT(S) ARE TO BE TRANSPORTED TO THE

WORKSPACE, THEN SEND THE LOCAL OBJECTS TO THE WORKSPACE'S LOCATION FOR THE CHAT SESSION.

STEP 399: DELETE LOCAL OBJECT(S) FROM REGISTRY IN DESKTOP AND UPDATE REGISTRY F SERVER FOR OBJECTS SENT TO CHAT SESSION This is just one example of how object locations can be updated in registries for those objects sent to a chat session at a remote workspace. Other options include broadcasting updated object locations to other servers in the network. The method 390 is embodied as a computer program in the service module 106 consisting of a sequence of instractions which, when executed in the processor running the desktop 102, carries out the steps of the method.

SERVICE MODULE METHOD TO DELETE A LOCAL OBJECT

Whenever a desktop 102 or server 192 deletes an existing software agent object from its local memory, its service module writes a reference to the deletion of the local object into its registry. The host desktop or host server will typically write into its disk drive storage 506 or 606, respectively, an archive copy of the XML object file 800 representing the current state of the software agent object 114 and then will delete the software agent object 114 from its memory 104 or 194, respectively. The creation of an archive copy of the XML object file 800 representing the current state of the software agent object 114 will be discussed further with respect to Figure 6. If the host is a desktop 102, then the service module 106 writes the reference into its registry 116. If the host is a server 192, then the service module 106' updates its registry 118 and broadcasts the update to all servers throughout network to update their respective registries 118. The method 320 of Figure 3D follows. This is just one example of how object locations can be updated in registries for those objects deleted.

METHOD 320: TO DELETE A LOCAL OBJECT

STEP 322: RECEIVE A REQUEST TO DELETE A LOCAL OBJECT

STEP 324 DELETE LOCAL OBJECT AND DEALLOCATE MEMORY AREA FOR LOCAL OBJECT STEP 326: WRITE REFERENCE TO DELETION OF LOCAL OBJECT INTO REGISTRY (REGISTRY FOR LOCAL NODE 102) AND UPDATE REGISTRIES IN ALL NODES THROUGHOUT NETWORK FOR OBJECT DELETED

EXAMPLE NETWORK AND RECIPROCAL RELATIONSHIPS

Figure 2 shows network diagram of an example arrangement of desktop computers and server computers in a network 115. The network is a federation of servers and desktops over which four organizational relationships are established for the user Alice. A first example organizational relationship shown in Figure 4A is for Alice in project planning for her employer the ABC Co., working with her fellow employees Bob, Chuck and Dan. A chat session with her fellow employees at the ABC Co. server is shown in Figure 5D. A second example organizational relationship shown in Figure 4D is for Alice as a patient who needs to pick up her xray medical records from her radiologist at her local hospital. A chat session between Alice's object and her radiologist's object in Alice's workspace at Alice's desktop is shown in Figure 5F. A third example organizational relationship shown in Figure 4E is for Alice as a patient consulting her two physicians at their group practice. A chat session between Alice and her general practice physician in Alice's workspace at Alice's desktop is shown in Figure 5F. A fourth example organizational relationship shown in Figure 4F is for Alice as a client of two institutions, a venture capital company and an investment bank. A chat session between Alice and her bank in Alice's workspace at Alice's desktop is shown in Figure 5F. Alice's workspace of her software agent object 114 can be scheduled to be the forum for chat sessions with software agent objects representing these other users throughout the network 115 at the scheduled times as set forth in Alice's schedule buffer 900.

Figure 4 illustrates an example instance of the collaborative workspace implemented as the software agent object 114 representing the user Alice. Alice's software agent object 114 includes Alice's reciprocal relationships tags file 420 which represents all of her relationships with other persons, places and things, each of which has its own software agent object. Examples of the user Alice's relationships, that are represented by the reciprocal relationship tags 134A, 174A, 190A, etc. in relationships file 420 in Alice's software agent object 114, are shown in Figures 4A - 4F. Alice's software agent object 114 is a workspace and the region 113 shown in Figure 4 stores all of the documents and recorded chat room conversations that the user Alice has conducted through the agency of her software agent object 114. Alice's workspace stores the project plan file 404, Alice's medical records file 406, the ABC Co.'s financial records 408, and Alice's work file 410. An example layout of the memory partitions of Alice's software agent object 114 is shown in Figure 7. The user Alice can remain at her desktop computer 102 while her software agent object 114 autonomously executes the commands in Alice's script 112 to interact with other software agent objects over the network 115 shown in Figure 2. This can include automatically carrying out the tasks specified in Alice's schedule 900. The script 114 can issue calls to the service module 106' in the server computer where the object 114 is currently located, calling the program methods of Figures 3 and 3 A to 3D, to support the commands in the script.

Figure 4A illustrates the organizational relationships 425 between four people who are respectively represented by four objects. Alice's desktop 102 includes the memory 104 which stores service module 106 including methods 108 and data 110. Memory 104 also includes Alice's script 112. Alice's person object 114 includes 3 reciprocal relationship tags 134A, 174 A, and 109 A. Table 2 illustrates a simplified example of an XML object file 800 for an instance of Alice's person object 114. hi the organizational relationships 425, Alice works with two other people, Bob and Dan on the company plan. However, in this example Alice does not work with Chuck. These organizational relationships are embodied in the reciprocal relationship tags included in the person object for each respective person, Alice, Bob, Chuck and Dan, as shown in Figure 4A. Bob's desktop 122 includes the memory 124 which includes service module 106, Bob's script 132 and Bob's person object 134. Chuck's desktop 142 includes the memory 144, containing the service module object 106, Chuck's script 152 and Chuck's person object 154. Dan's desktop 162 includes the memory 164 which contains the service module object 106, Dan's script 172, and Dan's person object 174. A simplified XML object file for an instance of Bob's person object 134 is shown in Table 3.

Alice's person object 114 includes three reciprocal relationship tags. The first reciprocal relationship tag 134A establishes the relationship between Alice's person object 114 and Bob's person object 134, by means of a forward verb and a designation of Bob's person object. Correspondingly, Bob's person object 134 includes a reciprocal relationship tag 114B that specifies a reverse verb corresponding to Alice's forward verb in relationship tag 134A. In addition, Bob's reciprocal relationship tag 114B includes the address of Alice's person object 114. Referring to Figure 4 and Figure 7 which show an instance of Alice's person object 114, it is seen that the workspace is provided in Alice's person object 114. The instance of Bob's person object 134 also has a workspace 133. Bob's person object 134 can meet Alice's person object 114 in Alice's workspace 113 to exchange information and to carry out collaborative projects. Correspondingly, Alice's person object 114 can meet Bob's person object 134 in Bob's workspace 133 to carry out other collaborative projects.

Dan's desktop 162 shown in Figure 4A includes memory 164, service module object 106, Dan's script 172 and Dan's person object 174. Dan's person object 174 includes reciprocal relationship tag 114D which includes a reverse verb and Alice's object address, the reverse verb corresponding to Alice's forward verb in reciprocal relationship tag 174A. Dan's person object 174 also has a reciprocal relationship tag 154D with a forward verb and the address of Chuck's person object 154. Correspondingly, Chuck's desktop 142 includes Chuck's person object 154 that includes a reciprocal relationship tag 174C with a reverse verb and the address of Dan's person object 174. The reciprocal relationship tags 114D and 154D and Dan's person object 174, establishes reciprocal relationships with Alice's person object 114 and with Chuck's person object 154, respectively. The reciprocal relationship tags 134C and 174C in Chuck's person object 154, establish reciprocal relationships with Bob's person object 134 and with Dan's person object 174, respectively. The reciprocal relationship tags in the person objects for Alice, Bob, Chuck and Dan in Figure 4A, establish the organizational relationships 425. h the first organizational relationship Alice works with Bob and Dan on the company plan but does not work with Chuck. In the second organizational relationship, Chuck works with Bob and Dan on the company plan but not with Alice.

Figure 4B illustrates the physical network 115 within which the desktops 102, 122, 142 and 162 of Figure 4A are implemented, h addition, Figure 4B shows the ABC Co.'s server 192 which includes a memory 194 which stores the service module 106' which includes methods and data, the Plan Activity object's script 196, and the Plan Activity 190. The Plan Activity object 190 includes reciprocal relationship tags which establish the relationship between the Plan Activity object 190 and the person object's for Alice, Bob, Chuck and Dan. hi Figure 4B it is seen that Alice's person object 114 includes the reciprocal relationship tag 190A which includes a forward verb and the address of the Plan Activity object 190 in the server 192. The Plan Activity object 190 in the server 192 includes a reciprocal relationship tag 114P which includes a reverse verb and the address of Alice's person object 114. This reciprocal relationship established by these two reciprocal relationship tags 190A and 114P establish the organizational relationship between Alice's person object and the Plan Activity object. Because Alice's person object 114 is a workspace, documents from the Plan Activity object 190 can be transferred into the document buffer of Alice's workspace so that Alice may work on them. Table 4 shows a simplified version of an object XML file of an instance of the Plan Activity object 190. Table 4 shows that a security policy is provided in the Plan Activity object 190 which gives Alice's person object 114 read/write access to documents stored in the Plan Activity object 190. Corresponding reciprocal relationships are established by the reciprocal relationship tags 134P and 190B between Bob's person object 134 and the Plan Activity object 190, between reciprocal relationship tags 154P and 190C for the relationship between Chuck's person object 154 and the Plan Activity object 190, and between reciprocal relationship tags 174 and 190D for the relationship between Dan's person object 174 and the Plan Activity object 190. As will be noted in Figure 4B, Alice's desktop 102 includes an instance of Alice's workspace 113 implemented as the software agent object 114, which is created during the loading of Alice's XML file 800 by a loading method such as the method 200 of Figure 3. Similarly, Bob's desktop 122 includes Bob' workspace 133 implemented as the software agent object 134 in the memory 124. Chuck's desktop 142 contains Chuck's workspace 153 implemented as the software agent object 154 in the memory 144. And Dan's desktop 162 includes Dan's workspace 173 implemented as the software agent object 174 in the memory 164. Each of the workspaces 133, 153, and 173 is created during the loading of the corresponding XML file for the instance person object 134, 154, and 174, respectively, by a loading method such as the method 200 of Figure 3.

Figure 4C shows an alternate physical network 115' for the organizational relationships discussed in Figures 4A and 4B. In Figure 4C, instead of connecting the desktops 102, 122, 142 and 162 directly to the server 192 in a hub-and-spoke configuration as is shown in Figure 4B, Figure 4C shows connecting the desktops and the server 192 in a peer-to-peer configuration in the network 115'. The network 115' can be either a local area network or a wide area network, such as an intranet within an enterprise or the Internet.

Figure 4D is a functional block diagram illustrating a second example organizational relationship 455 for Alice as a patient consulting a radiologist who practices at a local hospital. This relationship is represented by the reciprocal relationship tags 120A', 140A, 114RA, 140RA, 114HO, and 120HO established between Alice's software agent object 114, radiologist's software agent object 120RA, and a hospital's software agent object 140HO. Patients are represented by patient objects such as Alice's software agent object 114, that are configured to store the patient's medical records, dental records and the like in their workspace 113. Physicians are represented by physician objects, such as the Radiologist's software agent object 120RA that do not store the patients' records but which must be authorized to access them. Physician software agent objects are workspaces, such as the Radiologist's workspace 113RA, that can store professional references such as radiology treatises and which can include chat buffers for remote medical consultation with other physicians. The hospital software agent object 140HO has a workspace 193HO where physicians accredited to the hospital can remotely conduct professional association chat sessions in a chat buffer in the hospital workspace 193HO. A group of physicians in a group practice would be represented by a group software agent object that would have shared access rights to the medical records in the workspace 113 of a patient software agent object 114, for patients of any physician in the group. Specialist physicians are represented by specialist software agent objects that are given access rights to the workspace 113 of those patient software agent objects 114 for patients referred to the specialist by other software agent objects representing primary care physicians. The security policy of the patient software agent object 114 would govern the ability of any physician software agent object 120RA to access the workspace 113 of the patient software agent object 114. Each patient software agent object 114 would store in the patient's workspace 113 the patient's x-rays and other medical records, the date of the last exam, and other medical information. The patient software agent object 114 is a workspace with a chat buffer where the patient can remotely conduct chat sessions with the physician, having a conversation about the patient's health. The chat session conversation can be recorded for future reference by the physician or by specialists who are given access to the workspace 113 of the patient software agent object 114. Document buffers in the patient's workspace 113 can store the patient's medical records, insurance information, and treatment and billing details.

Figure 4E is a functional block diagram illustrating a third example organizational relationship 435 for Alice as a patient consulting her two physicians. This relationship is represented by the reciprocal relationship tags 120A, 130A, 114SP, 130SP, 140SP, 114GP, 120GP, and 140GP established between Alice's software agent object and two physician software agent objects and the hospital software agent object. The physicians are accredited at the local area hospital, which is shown by their relationship tags to the hospital software agent object. The physician software agent objects 120SP and 130GP are workspaces 113SP and 113GP, respectively, that can store professional references such as the Merck Manual and the Physician's Desk Reference, and which can include chat buffers for remote medical consultation between the physicians.

Figure 4F is a functional block diagram illustrating a fourth example organizational relationship 445 for Alice as a client of two institutions, a venture capital company and an investment bank. This relationship is represented by the reciprocal relationship tags 120A', 130A', 114VC, 130VC, 140VC, 114IB, 120IB, and 140IB established between Alice's software agent object 114 and the two software agent objects 120VC and 130 IB for the venture capital company and for the investment bank, respectively. The venture capital company and the investment bank have an investment in the Genome biotech venture, which is shown by their relationship tags to the Genome object. The venture capital company and the investment bank software agent objects 120VC and 130IB are workspaces 193VC and 193IB, respectively, that can store professional references such as Dunn and Bradstreet reports and which can include chat buffers for remote professional consultation with other financial institutions.

Figure 5 A is a detailed functional block diagram of Alice's desktop computer 102, illustrating an example off-line operation at 7:00 AM and the hosting of Alice's collaborative workspace software agent object 114. Alice's desktop 102 includes the memory 104 which is connected by means of the bus 504 to the disk drive storage 506, the display and keyboard adapter 508, the processor 510 and the network adapter 512, which is, in turn, connected to the network 115 (A, S). In the memory 104, the visualization layer 155 is stored, which includes the web browser 165 and the windows applications 175. Also stored in the memory 104 is the service module 106 which includes the http server 145 and the object services 135. The service module 106 stores the program instructions for the methods 200, 300, 320, 360, and 390 which are shown in flow diagrams of Figures 3 and 3 A to 3D, respectively. These methods are each stored as a program sequence of operational steps in the object services 135. The memory 104 of Figure 5A also includes Alice's collaborative workspace implemented as Alice's software agent object 114. Alice's software agent object 114 includes the reciprocal relationship tags 134A, 174A and 190A, and it also includes the properties 530 and the security policy 532. The memory 104 of Figure 5A also includes Alice's script 112 and the operating system 526. As is shown in Figure 5 A, the off-line work product of Alice is stored in Alice's workspace document buffer 538. This work product will become part of the project plan, when Alice goes on-line with the server 192. The record of prior chat messages are stored in the journal buffer 540. A chat buffer 542 is also included in Alice's workspace. As is seen in Figure 5 A, the object services 135 and the service module 106 can exchange messages over the path 524 through the network adapter 512 to the network 115 when the desktop 102 is on-line.

The display buffer 520 shown in Figure 5A buffers images for display on the display monitor of the desktop computer 102. The properties 530 of the software agent object 114 specify a point of view to be displayed of a selected object with respect to other objects related to the selected object. The relationships file of the selected object is accessed and all of the relationships tags for that selected software agent object are scanned to identify the other software agent objects which are related to the selected object. A map image is prepared depicting those relationships. Then, the display buffer 520 provides an image of the map to the display monitor of the desktop computer 102, via the adapter 508. h the example shown in Figure 5A, the properties 530 specify that the point of view selection is of Alice's software agent object 114. The service module 106 and the visualization layer 155 access the relationships file 420 of Alice's software agent object 114 to identify the other software agent objects which are related to the selected object. The are Bob's, Dan's, and the Plan Activity's software agent objects 134, 174, and 190, respectively. Icons are assembled in a map image 522 which is written into the display buffer 520 for display on the display monitor.

Figure 5B is a detailed functional block diagram of the ABC Co.'s server computer 192, illustrating the hosting of the Plan Activity's collaborative workspace software agent object 190. The example shown occurs at 7:00 AM, before Alice has gone on-line. Server 192 includes the memory 194 which is connected by means of the bus 604 to the disk drive storage 606, the display and keyboard adapter 608, the processor 610, and the network adapter 612 which is connected in turn to the network 115(A, S). The memory 194 of Figure 5B includes the service module 106' which includes the object services 135'. Object services 135' stores the program instructions for the methods 200, 300, 320, 360, and 390, which are shown in flow diagrams of Figures 3 and 3A to 3D, respectively. These methods are each stored as a program sequence of operational steps in the object services 135'. Also stored in the memory 194 of Figure 5B is the Plan Activity object 190 which includes reciprocal relationship tags 114P, 134P, 154P and 174P, as well as the properties 630 and security policy 632. The memory 194 also includes the plan script 196 and the operating system 626. The memory 194 of Figure 5B also includes the collaborative workspace implemented as the Plan Activity's software agent object 190. The Plan Activity's software agent object 190 stores the collaboration work product of Alice, Bob and Dan in the document buffer 638. The record of prior chat messages are stored in the journal buffer 640. A chat buffer 642 is also included in the Plan Activity's workspace. It can be seen in Figure 5B that the service module 106' can exchange messages over the path 624 through the network adapter 612 to the network 115.

Figure 5C is a detailed functional block diagram of Alice's desktop computer 102, illustrating an example on-line operation where Alice's collaborative workspace software agent object 114 has been transferred to the server 192. Alice's desktop 102 went on-line at 8:00 AM. When the Alice's desktop 102 transfers the existing instance of Alice's software agent object 114 from its local memory 104, its service module writes a reference to the deletion of the local object into its registry 116. Alice's desktop 102 writes into its disk drive storage 506, an archive copy of the XML object file 800 representing the current state of Alice's software agent object 114 and then deletes the software agent object 114 from its memory 104. The archive copy of the XML object file 800 representing the current state of Alice's software agent object 114 is then transmitted to the server 192, where it is instantiated into the Javascript code objects 1040 for Alice's person object instance 114. The creation of an archive copy of the XML object file 800 representing the current state of the software agent object 114 will be discussed further with respect to Figure 6. Figure 5D is a detailed functional block diagram of the ABC Co.'s server computer 192, after Alice's desktop 102 went on-line at 8:00 AM. Figure 5D illustrates the hosting of Alice's collaborative workspace software agent object 114 and the Plan Activity's collaborative workspace software agent object 190. Alice can conduct chat sessions in the journal buffer 540 of her software agent object 114 with Bob. Alice can conduct other chat sessions in the journal buffer 640 of the Plan Activity software agent object 190 with Bob and Dan. A relationship creates a persistent identification of partnership between two objects. A "meeting" might be well defined as a time interval where those two objects are actually communicating with each other. For example, the first person object is adding information to a second person object. Or two users are using the Journal for a chat at a specific activity object. The users' relationships to the activity object would enable the users to have permission to alter the activity object's contents, hence collaborate.

Figure 5E is a detailed functional block diagram of Bob's desktop computer

122, illustrating an example on-line operation and the hosting of Bob's collaborative workspace software agent object 134. Bob can conduct chat sessions with Alice after Alice's desktop 102 went on-line at 8:00 AM. Bob can conduct chat sessions in the journal buffer 540 of Alice's software agent object 114. Bob can conduct other chat sessions in the journal buffer 640 of the Plan Activity software agent object 190 with Alice and Chuck.. Bob can conduct still other chat sessions in the journal buffer 740 of his own software agent object 134 with Alice and Chuck.

In Figure 5E, Bob's desktop 122 includes the memory 124 which is connected by means of the bus 704 to the disk drive storage 706, the display and keyboard adapter 708, the processor 710 and the network adapter 712, which is, in turn, connected to the network 115 (B, S). In the memory 124, the visualization layer 155 is stored, which includes the web browser 165 and the windows applications 175. Also stored in the memory 124 is the service module 106 which includes the http server 145 and the object services 135. The service module 106 stores the program instructions for the methods 200, 300, 320, 360, and 390 which are shown in flow diagrams of Figures 3 and 3 A to 3D, respectively. These methods are each stored as a program sequence of operational steps in the object services 135. The memory 124 of Figure 5E also includes Bob's collaborative workspace implemented as Bob's software agent object 134. Bob's software agent object 134 includes the reciprocal relationship tags 114B, 154B, and 190B, and it also includes the properties 736 and the security policy 744. The memory 124 of Figure 5E also includes Bob's script 132 and the operating system 726. As is shown in Figure 5E, the work product of Bob's is stored in Bob's workspace document buffer 738. The record of chat messages are stored in the journal buffer 740. A chat buffer 742 is also included in Bob's workspace. As is seen in Figure 5E, the object services 135 and the service module 106 can exchange messages over the path 724 through the network adapter 712 to the network 115 when the desktop 122 is on-line.

The display buffer 720 shown in Figure 5E buffers images for display on the display monitor of the desktop computer 122. The properties 736 of the software agent object 134 specify a point of view to be displayed of a selected object with respect to other objects related to the selected object. The relationships file of the selected object is accessed and all of the relationships tags for that selected software agent object are scanned to identify the other software agent objects which are related to the selected object. A map image is prepared depicting those relationships. Then, the display buffer 720 provides an image of the map to the display monitor of the desktop computer 122, via the adapter 708. In the example shown in Figure 5E, the properties 736 specify that the point of view selection is of Bob's software agent object 134. The service module 106 and the visualization layer 155 access the relationships file 420B of Bob's software agent object 134 to identify the other software agent objects which are related to the selected object. They are Alice's, Chuck's, and the Plan Activity's software agent objects 114, 154, and 190, respectively. Icons are assembled in a map image 722 which is written into the display buffer 720 for display on the display monitor.

Figure 5F is a detailed functional block diagram of Alice's desktop computer

102, illustrating an example on-line operation and the hosting of Alice's collaborative workspace software agent object 114. The figure features the display of an object map 522 depicting the point of view from Alice's object 114, of the relationships between Alice's object 114 and all other objects for which Alice's object 114 has relationships tags, h the example shown in Figure 5F, the properties 530 specify that the point of view selection is of Alice's software agent object 114. The service module 106 and the visualization layer 155 access the relationships file 420 of Alice's software agent object 114 to identify the other software agent objects which are related to the selected object. They are Bob's, Dan's, the Radiologist's, the Hospital's, the specialist Physician's, the General Practice Physician's, the Venture Capital company, the Bank, and the Plan Activity's software agent objects. Icons are assembled in a map image 522 which is written into the display buffer 520 for display on the display monitor.

Figure 5G is a detailed functional block diagram of Alice's desktop computer 102, of Figure 5F, which features the display of an object map 562 depicting the point of view from the Plan Activity's object 190 of Figure 4B, of the relationships between the Plan Activity's object 190 and all other objects for which the Plan Activity's object 190 has relationships tags. In the example shown in Figure 5G, the properties 530 specify that the point of view selection is of Plan Activity's object 190. The service module 106 and the visualization layer 155 access the relationships file 420P of Plan Activity's object 190 in figure 5D to identify the other software agent objects which are related to the selected object. They are Alice's, Bob's, Chuck's, and Dan's, software agent objects. Icons are assembled in a map image 562 which is written into the display buffer 520 for display on the display monitor of Alice's desktop 102.

Figure 5H is a detailed functional block diagram of Alice's desktop computer 102, of Figure 5F, which features the display of an object map 572 depicting the point of view from the Chuck's object 154 of Figure 4A, of the relationships between Chuck's object 154 and all other objects for which the Chuck's object 154 has relationships tags. In the example shown in Figure 5H, the properties 530 specify that the point of view selection is of Chuck's object 154. Alice's security policy 532 must provide a record of the permission necessary to access Chuck's software agent object 154. The service module 106 and the visualization layer 155 can then access the relationships file of Chuck's software agent object 154 to identify the other software agent objects which are related to the Chuck's object. They are Bob's, Dan's, and the Plan Activity software agent objects. Icons are assembled in a map image 572 which is written into the display buffer 520 for display on the display monitor of Alice's desktop 102.

Alice's script 112 in Alice's software agent object 114, implements the customized behavior of Alice's software agent object. Alice's script 112 can include a schedule monitor and a chat session actions dispatcher. Alice's script 112 can include an off-line actions module and a replica behavior module. When Alice's software agent object 114 terminates on-line operation, the script code 112 causes the service module 106 to send a notification to the server 192 to intercept any messages directed to the software agent object 114 during the period of off-line operation. If the user, Alice, then turns off the desktop computer 102 and later turns it back on, the script code 112 determines that the software agent object 114 is operating off-line. When operating off-line, the script code 112 invokes a replica mode of operation. In the replica mode the script code 112 blocks making any changes to Alice's software agent object 114 that would affect the state of other objects elsewhere in the network, such as by modifying a schedule for a future chat session with another object. The script code 112 monitors for the resumption of on-line operation of the desktop 102 and when on-line operation resumes, the script code 112 disables the replica mode of operation.

In the replica mode, if Alice wishes to send a message to a second software agent object 134 in the network which whom she has a relationship defined by a relationships tag, the script code functions to block the sending of the message.

Instead, the blocked message is archived locally in the desktop 102. The script code 112 monitors for the resumption of on-line operation of the desktop 102 and when online operation resumes, the script code 112 disables the replica mode of operation. This unblocks the sending of archived messages and any accumulated messages are sent to the second software agent object. Additionally, when the software agent object 114 resumes on-line operation, the script code 112 requests the server 192 to forward any messages to the software agent object 114, that were directed to the object 114, but which were intercepted by the server 192 during the off-line operation of the object 114.

Alice's script 112 can include a custom object behavior code module. Alice's script 112 can be written in JavaScript code, to define the software agent object's behavior. The JavaScript programming language can implement a wide variety of functions, objects, methods , and event handlers for the customized behavior of Alice's software agent object. A good background source for Javascript is the book by David Flanagan entitled "Javascript : The Definitive Guide - 3rd edition", O'Reilly & Associates, 1998. Alice's script 112 is embodied as a computer program loaded into the service module 106, consisting of a sequence of instructions which, when executed in the processor running the desktop 102, carries out the steps of the method.

Figure 6 is a functional block diagram of an example of the service module 106, showing the loading of Alice's XML object file 800, the instantiation of

Javascript code objects 1040 for Alice's person object instance 114 using an XML processor 820 and an XML application program interface 1000, and the dispatching of a modified version 800' of Alice's XML object file to other nodes in the network. In the example shown in Figure 6, Alice's XML object file 800 initially has two relationships tags, 134A directed to Bob's object and 130A directed to the General

Practitioner's object. When Alice's XML object file 800 arrives at the computer node, the service module 106 loads it using the method 200 of Figure 3.

The service module 106 in Figure 6 includes an XML parser 815 which analyses the XML tags and elements in the XML object file 800 and creates a parameter list for the XML processor 820 from the information. The XML processor 820 takes the parameter list and calls the XML application program interface (API) 1000. The API 1000 accesses Javascript code objects 1015 from the Javascript code library 1010 which implement the functions represented by the XML tags and elements in the XML object file 800. The XML processor 820 then outputs the

Javascript code objects 1040 for Alice's person object instance 114 to the object layer 125 in the computer node 102. There are two major types of XML APIs: (1) tree-based APIs and (2) event- based APIs. A tree-based API compiles an XML document into an internal tree structure, then allows an application to navigate that tree. The Document Object Model (DOM) includes a standard tree-based API for XML documents. An event- based API reports parsing events (such as the start and end of elements) directly to a Javascript application program through callbacks, and does not usually build an internal tree. The Javascript application implements handlers to deal with the different events. An example of suitable tree-based API is given in the Document Object Model (DOM) Level 1 Specification Version 1.0, W3C Recommendation 1 October, 1998, at http://www.w3.org/TR REC-DOM-Level-l/. An example of a suitable event-based API is "SAX2 - the Simple API for XML" which is a Java-based XML processor at http://www.megginson.com/SAX/index.html. Also see the book by

Hiroshi Maruyama, Kent Tamura, Naohiko Uramoto entitled "XML and Java: Developing Web Applications", Addison- Wesley Pub Co, 1999.

When the service module 106 loads Alice's XML object file 800, it stores a copy in the XML object file buffer 1020. The buffered copy 800' of the XML file 800 represents the current state of Alice's software agent object 114. Whenever the XML processor 820 makes a change to an XML tag or element originally expressed in

Alice's XML object file 800, that change is written into the buffered copy 800' of the XML file stored in the XML object file buffer 1020. In the example shown in Figure 6, Alice's XML object file 800 needs to be modified by the addition of a third relationships tag, 120A directed to the Specialist Physician's object. The XML processor 820 adds the XML relationships tag 120A to Alice's XML object file 800, using the method 300 of Figure 3A. That change is written into the buffered copy 800 of the XML file stored in the XML object file buffer 1020, creating the modified version 800'. Thereafter, when the XML processor 820 executes a dispatching function, such as method 390 of Figure 3C, the modified version 800' of the XML file is output from the XML object file buffer 1020 and transmitted to the next computer node in the network. At the next computer node, the XML processor 820 in the service module 106 loads the modified version 800' of the XML file using the method 200 of Figure 3, and instantiates the Javascript code objects 1040 for the modified version of Alice's person object instance 114, which includes the third relationships tag, 120 A directed to directed to the Specialist Physician's object. The network diagram of Figure 2 shows Alice's XML object file 800 being transmitted from one computer node to another, where it is instantiated into the Javascript code objects 1040 for Alice's person object instance 114.

Figure 7 is a data flow diagram illustrating an example of how Alice's XML object file 800 (a simplified example is shown in Table 2) is loaded by the service module 106 and instantiated as Javascript code objects 1040 for Alice's person object instance 114 in the memory of a computer node 102. The service module 106 shown in Figure 7, includes an XML processor 820 and an XML parser 815 to interpret the XML tags and elements in the object's XML file 800 and to convert it into an instance 114 of the object in the memory 104. The XML processor 820 derives the instance of Alice's person object 114 from the base person object whose XML file 805 is shown in Table 1. The base person object serves as a template for the instance person object. The XML processor 820 fills in the details which are unique to Alice's person object as they are specified in Alice's XML object file 800 (a simplified example is shown in Table 2). Figure 6 is a functional block diagram of an example of the service module 106, showing the loading of Alice's XML object file 800 and the instantiation of Javascript code objects 1040 for Alice's person object instance 114. The XML processor 820 performs the method 200 in the flow diagram of Figure 3.

Figures 6 and 7 are just one example of how an XML object file can be loaded and instantiated in a computer node in the network. The XML processor 820 and the method 200 allocate local memory area beginning at address "x" in the memory 104 for the new object to be instantiated. Then the XML processor 820 and the method 200 partition the allocated memory area into a header partition 830 at address x, a relationships partition 832 at address x+xl, a properties partition 834 at address x+x2, a schedule partition 836 at address x+x3, a script partition 838 at address x+x4, and a workspace partition 840 at address x+x5. These address offsets are default values that can be derived from the base person object 805. The XML processor 820 and the method 200 can then instantiate the elements from the base person object 805 into the corresponding partitions of the allocated memory area. The XML processor 820 and the method 200 can then overwrite the some of the information instantiated from the base person object 805, with corresponding customized information read from the XML object file 800. The XML processor 820 and the method 200 can import the schedule and the script into the corresponding partitions of the allocated memory area. The XML processor 820 and the method 200 can then read the workspace file location from the XML file 800 and import workspace 113 into the workspace partition 840. Document collaboration buffers 842 and chat buffers 844 can then be opened in the workspace partition 840. This is one example of the instantiation ofJavascri.pt code objects 1040 for Alice's person object instance 114.

Figure 7A shows another example layout of the memory partitions 830, 832, 834, 836, 838, and 840 of Javascript code objects 1040 for Alice's person object 114, wherein the partitions are distributed in non-contiguous locations in the address space of the memory 104. Figure 7B shows still another example layout of the memory partitions 830, 832, 834, 836, 838, and 840 of Javascript code objects 1040 for Alice's person object 114, wherein Alice's workspace partition 840 is located in the memory 194 of a remote computer node, such as the server 192.

The base person-type XML file defines the generic person object. It includes pointers to files for the generic workspace of a person object. Other base object types are respectively defined by their own base XML files, e.g., base activity-type software agent objects are defined by base activity-type XML files, etc.

Typically the base object includes properties that are the defaults for a specific person object as well as a pointer to a JavaScript file. The files that are in the workspace of the base object tend to be things like icons that would be used for all person objects. The following are example base objects that can be provided by the invention: person, activity, discussion, event, binder, enterprise, and group. A project can be a collection of activities created with relationships between them. When the desktop computer is shut down, the persistent information for Alice's object includes the XML file as well as files, chats, discussions and the like that would be in the Alice object's workspace. Each object is persisted in its entirety, including all of the files.

When the desktop computer is turned on, it reads in Alice's person object. Alice's person object is located in a directory on the file system (which contains the XML file, the workspace files, etc.) and reads in the XML file. The XML file includes a TYPE tag, which would indicate that the Alice object is a base person object, which would then be loaded, and so on down the entire tree of base objects. The XML processor interprets the XML elements and creates an in memory representation of the Alice object (and any other objects that were loaded in that process). The in memory representation caches the properties, relationships, JavaScript code, etc. in memory buffers. Access to these in memory elements is exposed through an API that is accessible through JavaScript. The invention creates a C++ object to represent the runtime version of Alice's object. This loading process also resolves the base objects to create a single code base for the Alice object that includes all of the appropriate JavaScript. The API exposes a set of functions for manipulating this in memory version of the object (e.g. add_Relationship, put_Property, Save) as well as the functions that are included in the JavaScript code. This creates an object that can be manipulated from JavaScript in the following way:

var obj = invention.get_Object("xo_guidalice"); // this retrieves a handle to the object identified by "xo_guidalice"

var taskguid = invention. create_Object("_bc_activity"); // creates an activity object

obj.add_Relationship("OWNS",taskguid); // adds a relationship to the xo_guidalice object and the activity object The best way to think of the XML file is not as an object, as in the Document Object Model (DOM), but just simply a structured file that identifies each part of an object clearly. This could have been done without XML, but XML provides a good shorthand notation for this sort of thing.

Objects are loaded from the most derived to the least derived. So Alice's instance XML object file would load first, then the base person object, then any object that the base person object might inherit from. Each derived object doesn't actually fully load until all of its base objects are loaded. The contents of the Alice object's workspace are actually in multiple files. Each of those objects is stored in its own file, but all of the workspace files are organized into two directories per object on the hard drive. These files are loaded as needed. For example, the "Journal" panel opens a file in Alice's workspace that contains the persistent contents of that journal. It only does this when someone is displaying the journal, not in advance.

The resulting invention enables network collaboration in an improved manner by creating persistent, bidirectional relationships between software agent objects that represent collaborative workspaces.

Although several specific embodiments of the invention are disclosed herein, those having skill in the art will understand that there are many ways to implement those specific embodiments without departing from the spirit and the scope of the invention.

TABLES

TABLE 1 : SIMPLIFIED XML FILE 805 FOR BASE PERSON OBJECT

<?XML VERSION=" 1.0"?>

<OBJECT>

<TITLE>Default</TITLE> <DESCRIPTION> Default </DESCRIPTION>

<TYPE>base_person</TYPE>

<RELATIONSHIPS> Default</RELATIONSHlPS>

<PUBLISH> Default</PUBLISH>

<SECURITY-POLICY> Default </SECURITY-POLICY> <PROPERTLES>

<SERVERGUID>1234567890....0987654321</SERVERGUTD>

<SERVERLOCATION>1.160.10.240</SERVERLOCATION>

<SCHEDULE_FILE_LOCATION> Default </SCHEDULE_FTLE_LOCATION>

<SCRTPT_FILE_LOCATION> Default </SCPJPT_FILE_LOCATION> <WORKSPACE_FILE_LOCATION> Default </WORKSPACE_FILE_LOCATION>

</PROPERTEES>

</OBJECT>

TABLE 2: SIMPLIFIED XML FILE 800 FOR INSTANCE OF ALICE'S PERSON OBJECT 114

<?XML VERSION=" 1.0"?> <OBJECT>

<TITLE>Alice </TITLE>

<DESCRIPTION>Department Manager< DESCRIPTION> <TYPE>_person</TYPE> <RELATIONSHIPS>

<MANAGES>p_Bob </MANAGES> <MANAGES>p_Chuck</MANAGES> <MANAGED_BY>p_Dan</MANAGED_BY> <APPROVES>d_Bob's_Work_Product_Document</APPROVES> <APPROVES>d_Bob's_Work_Product_Document </APPROVES>

<OWNS>d_Department_Plan_Document</OWNS> <WATCHES>d_Forcast_Document</WATCHES> <OWNED-BY>g_Company_Performance_Goal</OWNED-BY> </RELATIONSHIPS> <PUBLISH> <RULE NAME=*Status Changed' EVENT="onChangedProperty"> <CONDITION>(arg()toUpperCase == 'STATUS')</CONDITION> <ACTION>#PASSTHROUGH#</ACTION></RULE> </PUBLISH> <SECURITY-POLICY> <ALLOW TYPE="R"> </ALLOW>

<ALLOW TYPE="RW"> </ALLOW> <ALLOW TYPE="RWD">

<XO_OBJECT_GUJD>"READWRITEDELETE"</XO_OBJECT_GUID> </ALLOW> </SECURITY-POLICY> <PROPERTIES> <SERVERGUTD>1234567890....0987654321</SERVERGUTD> <SERVERLOCATION>l .160.10.240</SERVERLOCATION> <SCHEDULE_FILE_LOCATION>_Server _</SCHEDULE_FILE_LOCATION> <SCRJPT_FILE_LOCATION>_Server _</SCRIPT_FILE_LOCATION> <WORKSPACE_FILE_LOCATION>_Server </WORKSPACE_FILE_LOCATION >

</PROPERTIES> </OBJECT>

TABLE 3: SIMPLIFIED XML FILE FOR INSTANCE OF PERSON OBJECT FOR BOB

<?XML VERSION="1.0"?>

<OBJECT>

<TITLE>Bob</TITLE> <DESCRIPTION> Engineer </DESCRIPTION>

<TYPE> jperson</TYPE>

<RELATIONSHIPS>

<MANAGED_BY>p_Alice</MANAGED_BY>

<WATCHES>d_Department_Plan_Document</WATCHES> <WATCHES>d_Forcast_Document</WATCHES>

<OWNED-BY>g_Company_Performance_GoaK/OWNED-BY>

</RELATIONSHIPS>

<PROPERTIES>

<SERVERGUID>1234567890....0987654321</SERVERGUTD> <SERVERLOC ATION> 1.160.10.240</SERVERLOC ATION>

<SCHEDULE_FILE_LOCATION>_Server </SCHEDULE_FILE_LOCATION>

<SCRIPT_FILE_LOCATION>_Server _</SCRIPT_FILE_LOCATION>

<WORKSPACE_FILE_LOCATION>_Server _</WORKSPACE_FILE_LOCATION

> </PROPERTΓES>

</OBJECT> TABLE 4: SIMPLIFIED XML FILE FOR INSTANCE OF DOCUMENT OBJECT FOR PLAN

<?XML VERSION="1.0"?>

<OBJECT>

<TITLE>Department_Plan_Document</TITLE> <DESCRIPTION>Document; Department Plan</DESCRIPTION>

<TYPE> _document</TYPE>

<RELATIONSHIPS>

<OWNED_BY>Alice </OWNED_BY>

<WATCHED_BY>Alice </WATCHED_BY> <WATCHED_BY>Bob</WATCHED_BY>

</RELATIONSHIPS>

<PROPERTIES>

<SERVERGUID>1234567890....0987654321</SERVERGUID>

<SERVERLOCATION>l .160.10.240</SERVERLOCATION> <SCHEDULE_FILE_LOCATION>_Server _</SCHEDULE_FILE_LOCATION>

<SCRIPT_FlLE_LOCATION>_Server </SCRIPT_FILE_LOCATION>

<WORKSPACE_FILE_LOCATION>_Server _</WORKSPACE_FILE_LOCATION

>

<SECURITY-POLICY> <ALLOW TYPE="R"> </ALLOW>

<ALLOW TYPE="RW"xXOALICES_GUID

>READWRITE</XO_ALICES_GUID> </ALLOW>

<ALLOW TYPE="RW"xXO_BOBS_GUTD

>READWRITE</XO_BOBS_GUTD> </ALLOW> <ALLOW TYPE="RWD">

<XO_ALICES_GUID>READWRITEDELETE</XO_ALICES_GUTD>

</ALLOW> </SECURITY-POLICY>

</PROPERTIES>

</OBJECT>

TABLE 5: EXAMPLE OF PROPERTIES PORTION OF AN INSTANCE XML FILE

Each XML object file may contain an arbitrary collection of properties. These properties may contain XML style attributes that further define the type of property.

<PROPERTIES>

<ACTUAL_START_DATE TYPE="_pti_dateplus" private="false" track="true">.... <ACTUAL_COMPLETE_DATE TYPE="_pti__dateplus" private="false" track- 'true">....

<EXPECTED_START_DATE TYPE="_pti dateplus"

track- 'true">....

<STATUS_FUNCTION TYPE="_pti_dateplus" private="false" track="true">.... <PROCESS_STATUS TYPE="-Pti-status" UI_NAME="Status" UPDATE="true" >

<COMPLETFON_STATUS TYPE="_pti_percent" UI_NAME="Percent Comρlete">....

<STATUS private="false" track="true">notstarted</STATUS>

<ACTIVITY_TYPE TYPE="-Pti-freeformat" UI-HEIGHT="I" UI-NAME=" Activity

Type" </ACTIVITY_TYPE>

<PRIORITY_PTDISPLAY>High</PRIORITY-PTDISPLAY> <DESIRED_START_DATE >02/17/2000 00.00:00</DESIRED_START_DATE>

<DESIRED_COMPLETE_DATE >02/17/2000 00:00:00</

DESIRED_COMPLETE_DATE>

</PROPERTIES> TABLE 6: XML FILE FOR EXAMPLE BASE DESKTOP OBJECT

<?XML VERSION="1.0"?> <OBJECT> <TITLE>Desktop Object</TITLE>

<DESCRTPTION>The base administrative object for any desktop. Primary object interface with infrastructure / service module.</DESCRIPTION>

<TYPE>_system</TYPE>

<VEW NAME="default"> <TYPE>text/htmK/TYPE>

<DISPLAY_NAME>Web View</DISPLAY_NAME>

<FUNCTION>geωefaultView</FUNCTIONx/VIEW>

<SCRIPT LANGUAGE="j script" src="_desktop.js"x/SCRTPT>

<PROPERTIES> <SERVERGUTDx/SERVERGUID>

<SERVERLOCATIONx/SERVERLOCATION>

<CACHOBJECTLOCATION>K/CACHOBJECTLOCATION>

<PRIMARYHTTPPORT>8080</PRIMARYHTTPPORT>

<SECONDARYHTTPPORT>8090</SECONDARYHTTPPORT> <UDPTRANSMITPORT>805 l</UDPTRANSMITPORT>

<UDPRECEIVEPORT>805 K/UDPRECEIVEPORT>

<SLEEPTME>10000</SLEEPTIMEx/PROPERTIES>

</OBJECT>

TABLE 7: XML FILE FOR INSTANCE OF EXAMPLE DESKTOP OBJECT

<?XML VERSION=" 1.0"?> <OBJECT>

<TITLE>Untitled</TITLE>

<DESCRJPTION/>

<TYPE>_desktoρ</TYPE>

<RELATIONSHIPS> <OWNS>xo_wol_566c74c404661 Id3969a0080c88d6ebl</OWNS>

</RELATIONSHIPS>

<PROPERTJES>

<COMPUTERLOCATION>216.88.42.134:8080</COMPUTERLOCATION>

<GUIDLISTGUID>xo_90adb982047711d3969a0080c88d6ebl</GUIDLISTGUID> <INITIALIZED>-1</INITIALIZED>

<PEEPJNFO>

<XO_SYSTEM_6399C8E3048611D3ABC60008C7494782>

<ACTIVATED>-K/ACTIVATED>

<LOCATION>216.88.42.146:8080</LOCATION> <OBJLISTGUID>xo_6399c8e504861 Id3abc60008c7494782</OBJLISTGUID>

</XO_SYSTEM_6399C8E3048611D3ABC60008C7494782>

</PEERJNFO>

<WORKORDERLISTGUID>xo_wol_566c74c4046611d3969a0080c88d6ebl

</WORKORDERLISTGUTD> </PROPERTIES>

</OBJECT> TABLE 8 EXAMPLE OF XML FILE "_bc_person.xml" FOR BASE PERSON OBJECT

<OBJECT>

<TITLE>Person</TITLE>

<DESCRJPTIONx/DESCRIPTION>

<TYPE>_b_businessBase</TYPE>

<VERB NAME="MANAGED-BY" REVERSE="MANAGES" DIRECTION="CHILD">

</VERB>

<VERB NAME="IS-PEER-OF" REVERSE="IS-PEER-OF" DIRECTION="PEER">

</VERB>

<VERB NAME="OWNS" REVERSE="OWNED-BY" DIRECTION="PARENT"> </VERB>

<VERB NAME="MANAGES" REVERSE="MANAGED-BY"

DIRECTION="PARENT">

</VERB>

<VERB NAME=" APPROVES" REVERSE="APPROVED-BY" DIRECTION="PARENT">

</VERB>

<VERB NAME="IMPLEMENTS" REVERSE="FMPLEMENTED-BY"

DIRECTION="PARENT">

</VERB> <VERB NAME="TNCLUDED-BY" REVERSE="INCLUDES"

DIRECTION="CHILD">

</VERB>

<VERB NAME="WATCHES" REVERSE="WATCHED-BY"

DIRECTION="PARENT"> </VERB>

<VIEW NAME="small icon">

<TYPE>application/x-engenia-icon</TYPE> <DISPLAY_NAME>Small Icon</DISPLAY_NAME>

<FUNCTION>getSmallIcon</FUNCTION>

</VIEW>

<VIEW NAME="large icon"> <TYPE>application/x-engenia-icon</TYPE>

<DISPLAY_NAME>Large Icon< DISPLAY_NAME>

<FUNCTION>getLargeIcon</FUNCTION>

</VIEW>

<RELATIONSHIPS> </RELATIONSHIPS>

<PROPERTIES>

<PASSWORD private="false">swaprods</PASSWORD>

<FIRSTNAME UI_ORDER="0,0" private="false" track-"trae"

TYPE="jpti_freeformat" UI_NAME="First Name" UI_WIDTH="16" UI_HEIGHT=" 1 " UPD ATE="true"x/FIRSTNAME>

<LASTNAME UI_ORDER="0,1" private="false" track="true"

TYPE="_pti_freeformat" UI_NAME="Last Name" UI_WTDTH="28"

UI_HEIGHT=" 1 " UPDATE="true"x/LASTNAME>

<EMAIL UI_ORDER="1,0" private="false" track="true" TYPE="_pti_freeformat" UI_NAME="E-Mail Address" UI_WIDTH="28" UI_HEIGHT=" 1 "

UPDATE="true"x/EMATL>

<WORKNUMBER UI_ORDER="2,0" private="false" track="true"

TYPE="jpti_freeformat" UI_NAME="Work Number" UI_WIDTH="16"

UI_HEIGHT=" 1 " UPDATE="true"x/WORKNUMBER> <EXTENSION UI_ORDER="2, 1 " private="false" track="true"

TYPE="jpti_freeformat" UI_NAME="Extension" UI_WIDTH="8" UI_HEIGHT="1"

UPDATE="true"x/EXTENSION>

<NOTES UI_ORDER="3,0" private="false" track="trae" TYPE="_pti_freeformat"

UI_NAME="Notes" UI_WIDTH="28" UI_HEIGHT="2" UPDATE="true"x/NOTES>

</PROPERTIES> <SCPJPT LANGUAGE-"jscript" TYPE-"local" SRC="_bc_person.js"/> </OBJECT>

TABLE 9: EXAMPLE OF JAVASCRIPT FILE "_bc_person.js" INCLUDED IN XML BASE FILE "_bc_person.xml" (TABLE 8)

/* Copyright (c) 1998-2000

* Engenia Software Inc.

* ALL RIGHTS RESERVED

* This software is the property of Engenia Software, Inc. (ENGENIA) and is * furnished under license by ENGENIA; this software may be used only in

* accordance with the terms of said license. This copyright notice may not

* be removed, modified or obliterated without the prior written permission

* of ENGENIA. * * This software may not be copied, transmitted, provided to or otherwise made

* available to any other person, company, corporation or other entity except

* as specified in the terms of said license. *

* No right, title, ownership or other interest in the software is hereby * granted or transferred. *

* The information contained herein is subject to change without notice and

* should not be constraed as a commitment by ENGENIA. */

function onAddedRelationship(guid, verb)

{ parent.onAddedRelationship(guid,verb);

// Notify user via the messenger view. try { var date = new Date(); var sfrMessage - '{!unityname- 'srcObject"} {.'unity name- 'changedTo"} ' + '{! unity name- ' destObj ect" }.' ; var obj = unity. get_Object(guid); var strEventParms = guid + "," + obj .title + "„" + verb; eventNotifier_NotifyByMessage(this.name, "onAddedRelationship", date.toStringO, strMessage, strEventParms);

} catch (e)

{ svclog(4, "Unable to inform " + this.name +

" about added relationship .\n" + e.toString() ); }

}

*

function toString()

{ var sfrRetVal = this.Title; if (this.Description != "") sfrRetVal += " (" + this.Replace(this.Description, "<BR>", "&nbsp;") + ")"; return sfrRetVal; }

function onLoad()

{ parent.onLoadQ;

var objThis = unity.get_Object(this.name); // Assume this will always succeed if (objThis.name.toLowerCase() ⁼⁼ "_bc_person") return;

if (objTlιis.AccessLevel == "R" || objTlιis.AccessLevel = "NONE") return;

var bDoConvert = false; if (objThis.has_Property("personversion"))

{ if (parsel t(this.personversion) < 1005) bDoConvert = trae; } else

{ bDoConvert = trae;

}

if (bDoConvert)

{ if (! objThis.has_Property("firstname") )

{ ConvertPersonFroml004Tol005();

} objThis.personversion = 1005;

} objThis. close(); }

function ConvertPersonFroml 004To 1005()

{ // Add new properties CreateFreeFormatPropertyC'FIRSTNAME", "First Name", 1, ""); CreateFreeFormatPropertyC'LASTNAME", "Last Name", 1, ""); CreateFreeFormatPropertyC'EMAIL", "E-Mail Address", 1, ""); CreateFreeFormatPropertyC'WORKNUMBER", "Work Number", 1, ""); CreateFreeFormatPropertyC'EXTENSION", "Extension", 1, "");

CreateFreeFormatPropertyC'NOTES", "Notes", 2, "");

// Turn off cache var objThis = unity. get_Object(this. name); // Assume this will always succeed if (!objThis.has_Property("preferences"))

{ objThis.preferences = null;

} objThis.preferences.cacheEnabled = "false"; objThis.close();

}

/ /rf: rf: rf rf: rf: rf: rf; rf_* rf; rf; rf; rf; rf: rf: rf: rf; rf rf; rf_* rf; rf; rf; rf; rf; rf: rf; rf rf; rf; rf; rf; rf: rf; rf; rf; rf; rf_* rf; rf: rf: rf: rf; rf; rf: rf; rf; rf; rf* rf; rf: rf; rf: rf* rf; rf; rf; rf_* rf; rf_* rf; rf; rf: rf: rf: rf; rf; rf_* rf;

function CreateFreeFormatProperty(strName, strDisplayName, nUIHeight, strValue)

{ var objThis = unity. get_Object(this. name); // Assume this will always succeed objThis[strName] = strValue; objThis.put_PropertyAttribute(strName, "PRIVATE", "false"); objThis.put_ProρertyAttribute(strName, "TRACK", "true"); objThis.ρut_PropertyAttribute(strName, "TYPE", "jpti_freeformat"); obj Ms.put_PropertyArtribute(strName, "UI SfAME", strDisplayName); objThis.put_PropertyAttribute(strName, "UI_HEIGHT", nUIHeight.toString()); objThis.put_PropertyAttribute(strName, "UPDATE", "true"); objThis. close(); } TABLE 10: EXAMPLE OF XML FILE "xo_guidl.xml" FOR INSTANCE OF PERSON OBJECT WHICH IS BASED ON THE XML BASE FILE "_bc_person.xml" (TABLE 8) AND WHICH IS RELATED TO THE ACTIVITY OBJECT XML FILE "xo_task.xml" (TABLE 11)

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE UnityObject [

<!ENTITY UnityRelationships SYSTEM objectdir/relations"> <!ENTITY UnityPublishRules SYSTEM "/obj ectdir/rules"> <!ENTITY UnityProperties SYSTEM "/objectdir/properties"> <!ENTITY UnitySecurityhifo SYSTEM "/objectdir/securityinfo">

]>

<OBJECT> <TITLE> Jeffrey Kay</TITLE>

<DESCPJPTION></DESCRIPTION>

<TYPE>_bc_person</TYPE>

<ATTPJBUTES>

<LASTOBJECTUPDATE>959810864401.000000</LASTOBJECTUPDATE> <LASTPROPERTYUPDATE>959810833797.000000</LASTPROPERTYUPDATE

>

<LASTRELATIONSHIPUPDATE>959810864401.000000</LASTRELATIONSHIP

UPDATE>

<LASTSECUMTYP FOUPDATE>0.000000</LASTSECURITYTNFOUPDATE> <LASTPUBLISHEDRULESUPDATE>0.000000</LASTPUBLISHEDRULESUPDA

TE>

</ATTRTBUTES>

<PROPERTIES STRUCTURED="true">

<PASSWORD PRIVATE="false">swaprods</PASSWORD> <FIRSTNAME PPJVATE="false" TRACK="true" TYPE=" _j)ti_ freeformat"

UI_HEIGHT="1" UI_NAME="FirstName" UI_ORDER="0,0" UI_WIDTH="16"

UPDATE="trae"x/FIR.STNAME> <LASTNAME PRJVATE-"false" TRACK="true"

UI_HEIGHT="1" UI_NAME="Last Name" UI_ORDER="0,1" UI_WTDTH="28"

UPDATE-"trae"x/LASTNAME>

<EMAIL PRIVATE="false" TRACK="trae" TYPE="_pti_freeformat" UI_HEIGHT=" 1 " UI_NAME="E-Mail Address" UI_ORDER=" 1 ,0"

UI_WIDTH="28" UPDATE="true"x/EMAIL>

<WORKNUMBER PRIVATE="false" TRACK="true" TYPE="_pti_freeformat"

UI_HEIGHT="1" UI_NAME=" Work Number" UI_ORDER="2,0" UI_WIDTH="16"

UPDATE="trae"></WORKNUMBER> <EXTENSION PRJVATE="false" TRACK="trae" TYPE="_pti_freeformat"

UI_HEIGHT="1" UI_NAME="Extension" UI_ORDER-"2,l" UI_WIDTH="8"

UPDATE="trae"x/EXTENSION>

<NOTES PPJVATE="false" TRACK-"trae" TYPE="_pti_freeformat"

UI_HEIGHT="2" UI_NAME="Notes" UI_ORDER="3,0" UI_WIDTH="28" UPDATE-"true"x/NOTES>

<PERSONVERSION>1005</PERSONVERSION>

<EMAIL_PTDISPLAYx/EMAIL_PTDISPLAY>

<WOPJCNUMBER_PTDISPLAYx/WORKNUMBER_PTDISPLAY>

<CACHEGUID>xo_cache_dl7b4b80373flld4b9ca99af5cl2ab01</CACHEGUID> </PROPERTIES>

<RELATIONSHIPS>

<XO_TASK_E352B6F0373F11D4B9CA99AF5C12AB01

OBJTYPE="_bc_activity">

<VERB>MANAGES</VERB> </XO_TASK_E352B6F0373Fl 1D4B9CA99AF5C12AB01>

</RELATIONSHIPS>

<PUBLISH>

</PUBLISH>

<SECURITY-POLICY> <ALLOW TYPE="RWD">

<XO_SYSTEM_BADA5BB0373F11D4B9CA99AF5C12AB01>READWRITEDEL

ETEACCESS</XO_SYSTEM_BADA5BB0373F11D4B9CA99AF5C12AB01> </ALLOW>

</SECURITY-POLICY> OBJECT>

TABLE 11: EXAMPLE OF XML FILE "xo task.xml" FOR INSTANCE OF ACTIVITY OBJECT THAT IS RELATED TO PERSON OBJECT XML FILE

"xo_guidl.xml" (TABLE 10)

<?xml version-" 1.0" encoding="UTF-8" ?> <!DOCTYPE UnityObject [

<!ENTITY UnityRelationships SYSTEM "/objectdir/relations"> <!ENTITY UnityPublishRules SYSTEM "/objectdir/rules"> <!ENTITY UnityProperties SYSTEM 7objectdir/properties"> <!ENTITY UnitySecurityhifo SYSTEM "/objectdir/securityinfo">

]> <OBJECT>

<TITLE>Test</TITLE> <DESCRIPTION></DESCRJPTION>

<TYPE>_bc_activity</TYPE>

<ATTRLBUTES>

<LASTOBJECTUPDATE>959810864791.000000</LASTOBJECTUPDATE>

<LASTPROPERTYUPDATE>959810864361.000000</LASTPROPERTYUPDATE >

<LASTRELATIONSHIPUPDATE>959810864781.000000</LASTRELATIONSHIP

UPDATE>

<LASTSECUmTYINFOUPDATE>0.000000</LASTSECURITYINFOUPDATE>

<LASTPUBLISHEDRULESUPDATE>0.000000</LASTPUBLISHEDRULESUPDA TE>

</ATTRIBUTES>

<PROPERTIES STRUCTURED="true">

<ACTrVITY_TYPE PRJVATE="false" TRACK="true" TYPE="_pti_freeformat"

UI_HEIGHT="1" UI_NAME=" Activity Type" UI_ORDER="0,0" UI_W1DTH="24" UPDATE="trae">Activity</ACTIVITY_TYPE> <APPROVAL_STATUS PRTVATE="false" TRACK="true" TYPE="_pti_review"

UI_NAME=" Approval Status" UI_ORDER="6,l"

UPDATE="trae">not_reviewed</APPROVAL_STATUS>

<COMPLETION_STATUS PRIVATE="false" TRACK="trae" TYPE="_pti_percent" UI_NAME="Percent Complete" UI_WIDTH="20"

UPDATE="false">0</COMPLETION_STATUS>

<NEEDS_REVIEW PRrVATE="false" TRACK="trae" TYPE="_pti_boolean"

UI_NAME=" Approval Required" UI_ORDER="6,0"

UPDATE="trae">trae</NEEDS_REVIEW> <PRIORITY_CUTOFF PRIVATE="false" TRACK="true" TYPE="_ptijpriority"

UI_NAME="Rollup Cutoff UI_ORDER="5,0"

UPDATE="trae">0</PRIORITY_CUTOFF>

<PROCESS_STATUS PRTVATE="false" TRACK="true" TYPE="_pti_status"

UI_NAME="Manual Status" UI_ORDER="4,l" UPDATE="trae">0</PROCESS_STATUS>

<STATUS_FUNCTION PRTVATE="false" TRACK="true" TYPE="_pti_function"

UI_NAME="Status Rollup" UI_ORDER="4,0"

UPDATE="trae">manual</STATUS_FUNCTION>

<STATUS_OWN_FUNCTION PPJVATE-"false" TRACK="true" TYPE="_pti_freeformat" UI_NAME="Own Status Function"

UPDATE="false"x/STATUS )WN_FUNCTION>

<STATUS PRIVATE="false" TRACK="trae">notstarted</STATUS>

<ACTIVITYVERSION>1008</ACTιVITYVERSION>

<PRIORITY PPJVATE="false" TRACK="trae" TYPE-"_pti_priority" UI_NAME="Priority" UI_ORDER="3,0" UPDATE="true">3</PRIORITY>

<DESIRED_COMPLETE_DATE PRIVATE-" false" TRACK="trae"

TYPE="_pti_dateplus" UI_NAME="End Date" UI_ORDER="2,0"

UPD ATE="trae">959961601000< DESIRED_COMPLETE_D ATE>

<DESIRED_START_DATE PRTVATE="false" TRACK="trae" TYPE="_pti_dateplus" UI_NAME=" Start Date" UI_ORDER=" 1 ,0"

UPDATE="trae">95981086436K DESIRED_START_DATE>

</PROPERTΓES> <RELATIONSHIPS>

<XO_CD5CEC20373F11D4B9CA99AF5C12AB01 OBJTYPE="_bc_person">

<VERB>MANAGED-BY</VERB>

</XO_CD5CEC20373FllD4B9CA99AF5C12AB01> </RELATIONSfflPS>

<PUBLISH>

</PUBLISH>

<SECURITY-POLICY>

<ALLOW TYPE="RWD"> <XO_CD5CEC20373F11D4B9CA99AF5C12AB01>READWRITEDELETEACCES

S</XO_CD5CEC20373F11D4B9CA99AF5C12AB01>

</ALLOW>

</SECURITY-POLICY>

</OBJECT>

Claims

What is claimed is:

L A method for creating software agent objects in a computer network, comprising:

instantiating a first software agent object in a computer memory to represent a first person, the first software agent object being a collaboration workspace;

representing an organizational relationship between the first person and a second person by writing a relationships tag with a relationship verb in the first software agent object and writing another relationships tag with a reverse verb in a second software agent object representing the second person; and

enabling the second person to exchange information with the first person in the collaboration workspace, by means of the second person exchanging the information through the second software agent object.

2. The method of claim 1, wherein the second software agent object is in a different computer memory in the network than the first software agent object.

3. The method of claim 1, wherein the collaboration workspace is logically part of the first software agent and is an object instantiated in a different computer memory in the network than the first software agent object.

4. The method of claim 1, which further comprises: representing a second organizational relationship between the first person and a group of persons by writing a relationships tag with a relationship verb in the first software agent object and writing another relationships tag with a reverse verb in a third software agent object representing the group of persons; and

enabling the group of persons to exchange information with the first person in the collaboration workspace, by means of the group of persons exchanging the information through the third software agent object.

5. The method of claim 1, which further comprises:

representing a second organizational relationship between the first person and a project by writing a relationships tag with a relationship verb in the first software agent object and writing another relationships tag with a reverse verb in a third software agent object representing the project; and

enabling the project to exchange information with the first person in the collaboration workspace, by means of the project exchanging the information through the third software agent object.

6. The method of claim 1, which further comprises:

representing a second organizational relationship between the first person and an event by writing a relationships tag with a relationship verb in the first software agent object and writing another relationships tag with a reverse verb in a third software agent object representing the event; and

enabling the event to exchange information with the first person in the collaboration workspace, by means of the event exchanging the information through the third software agent object.

7. The method of claim 1, which further comprises:

representing a second organizational relationship between the first person and a chat session by writing a relationships tag with a relationship verb in the first software agent object and writing another relationships tag with a reverse verb in a third software agent object representing the chat session; and

enabling the chat session to exchange information with the first person in the collaboration workspace, by means of the chat session exchanging the information through the third software agent object.

8. A method for creating reciprocal relationships between software agent objects in a computer network, comprising:

receiving a request to create a relationship between a collaborative workspace implemented as a software agent object in a computer memory and another software agent object, the request associated with a relationship verb for the local object;

retrieving a security policy for the workspace with access restrictions for accessing the workspace;

formulating an access criterion for permitting establishment of the requested relationship based on the access restrictions;

accessing information from the other object sufficient to apply the access criterion;

if the access criterion is satisfied, then writing a relationships tag with the relationship verb in the workspace and writing another relationships tag with a reverse verb in the other object; and if the access criterion is not satisfied, then performing an alternate step.

9. A method for locating software agent objects in a computer network, comprising:

selecting a reciprocal relationship tag in a local software agent object in a computer memory, the tag being associated with a particular relationship verb for the local object;

forming a query using an identity of another object identified in the relationsliip tag;

searching the network for another software agent object having that identity and a reverse verb to the relationship verb.

10. A method for creating a collaborative workspace in a computer network, comprising:

creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb; and

writing a second relationships tag with a reverse relationship verb in a second software agent object, the second relationships tag referencing the first object, to enable collaboration between the second object and the first object's workspace.

11. The method of claim 10, which further comprises: associating a conversation buffer with the workspace for storing conversations conducted in the workspace between the first object and the second object.

12. The method of claim 11, which further comprises:

associating an audit trail program with the first object for maintaining an audit trail of the conversations stored in the conversation buffer.

13. The method of claim 10, which further comprises:

associating a document buffer with the first object for storing documents exchanged between the first object and the second object.

14. The method of claim 10, which further comprises:

writing a third relationships tag with a reverse relationsliip verb in a third software agent object, the third relationships tag referencing the first object, to enable collaboration between the third object and the second object in the first object's workspace.

15. The method of claim 14, which further comprises:

associating a security policy with the first object providing access restrictions governing the third object accessing the first object.

16. A method for creating a collaborative workspace in a computer network, comprising: creating a first software agent object in a computer memory, the first object having a relationships tag with a relationship verb and including a collaborative document buffer for storing documents; and

creating a second software agent object in a computer memory, the second object having a relationships tag with a reverse relationship verb and a reference to the first object to enable collaboration between the first object and the second object on documents stored in the document buffer.

17. The method of claim 16, which further comprises:

the first software agent object including a conversation buffer for storing conversations conducted between the first object and the second object.

18. The method of claim 17, which further comprises:

associating an audit trail program with the first software agent object for maintaining an audit trail of the conversations stored in the conversation buffer.

19. The method of claim 16, which further comprises:

associating a security policy with the first software agent obj ect providing access restrictions governing the second object accessing the first object.

20. A method for creating software agent objects in a computer network, comprising: instantiating a plurality of software agent objects in a computer memory to represent a plurality of persons, each software agent object being a collaboration workspace;

representing an organizational relationship between respective pairs of the plurality of persons by writing a pair of relationships tags between respective pairs of the plurality of software agent objects, each pair of tags having a relationship verb and a corresponding reverse verb; and

enabling each respective pair of the plurality of persons to exchange information with each other in one collaboration workspace of their respective pair of the plurality of software agent objects, by means of each respective pair of the plurahty of persons exchanging the information through their respective software agent object.

21. A method for creating a collaborative workspace in a computer network, comprising:

creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb;

writing a second relationships tag with a reverse relationship verb in a second software agent object, the second relationships tag referencing the first object, to enable collaboration between the second object and the first object's workspace, and

including a publish rule in the first software agent object that publishes an occurrence an event by transmitting notification of the occurrence to the second software agent object.

22. The method of claim 21, which further comprises: said relationship tag being a "watched-by" forward verb and including a designation of the identity of the second software agent object and said second relationships tag being a corresponding reciprocal relationship tag with a "watches" reverse verb and a designation of the first software agent object.

23. The method of claim 22, which further comprises:

said publish rule causing the first software agent object to send a message to the second software agent object notifying it that the event has occurred.

24. A method for creating a collaborative workspace in a computer network, comprising:

creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb, to be used by a person for a first chat session;

writing a second relationships tag with a reverse relationship verb in a second software agent object, the second relationships tag referencing the first object, to enable collaboration between the second object and the first object's workspace during the first chat session;

instantiating a second instance of the first software agent object, the second instance of the first object being a second collaborative workspace having a relationships tag with a relationship verb, to be used by the person for a second chat session; and

writing a fourth relationships tag with a reverse relationship verb in a fourth software agent object, the fourth relationships tag referencing the second instance of the first object, to enable collaboration between the fourth object and the second instance of the first object's workspace during the second chat session;

whereby the person can actively participate in two chat sessions, simultaneously communicating to both the second and the fourth software agent objects in the first and second workspaces, respectively.

25. A method for creating a collaborative workspace in a computer network, comprising:

creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb;

writing a second relationships tag with a reverse relationship verb in a second software agent object, the second relationships tag referencing the first object, to enable collaboration between the second object and the first object's workspace, and

including a security policy in the first software agent object that defines access restrictions for accessing the collaborative workspace.

26. A system for creating software agent objects in a computer network, comprising:

a first computer in the network instantiating a first software agent object in a computer memory to represent a first person, the first software agent object including an associated collaboration workspace;

said computer representing an organizational relationship between the first person and a second person by writing a relationships tag with a relationship verb in the first software agent object and a second computer in the network coupled to the first computer, writing another relationships tag with a reverse verb in a second software agent object representing the second person; and

said second computer enabling the second person to exchange information with the first person in the collaboration workspace, by means of the second person exchanging the information through the second software agent object.

27. A system for creating a collaborative workspace in a computer network, comprising:

a first computer in the network creating a first software agent object, the first object being a collaborative workspace having a relationships tag with a relationship verb; and

a second computer in the network coupled to the first computer, writing a second relationships tag with a reverse relationship verb in a second software agent object, the second relationships tag referencing the first object, to enable collaboration between the second object and the first object's workspace.

28. A system for creating a collaborative workspace in a computer network, comprising:

a first computer in a network, creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb, to be used by a person for a first chat session; a second computer in the network coupled to the first computer, writing a second relationships tag with a reverse relationship verb in a second software agent object, the second relationships tag referencing the first object, to enable collaboration between the second object and the first object's workspace during the first chat session;

said first computer instantiating a second instance of the first software agent object, the second instance of the first object being a second collaborative workspace having a relationships tag with a relationship verb, to be used by the person for a second chat session; and

a third computer in the network coupled to the first computer, writing a fourth relationships tag with a reverse relationship verb in a fourth software agent object, the fourth relationships tag referencing the second instance of the first object, to enable collaboration between the fourth object and the second instance of the first object's workspace during the second chat session;

whereby the person can actively participate in two chat sessions, simultaneously communicating to both the second and the fourth software agent objects in the first and second workspaces, respectively.

29. A system comprising:

a memory device having embodied therein information relating to representing an organizational relationship between a first person and a second person;

a processor coupled to said memory device, said processor configured to:

instantiate a first software agent object in the memory device to represent a first person, the first software agent object being a collaboration workspace; represent the organizational relationship between the first person and a second person by writing a relationships tag with a relationship verb in the first software agent object and writing another relationships tag with a reverse verb in a second software agent object representing the second person; and

enable the second person to exchange information with the first person in the collaboration workspace, by means of the second person exchanging the information through the second software agent object.

30. A computer readable article of manufacture to for creating a collaborative workspace in a computer network, comprising:

a computer readable medium;

computer programming code in the computer readable medium for creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb; and

computer programming code in the computer readable medium for writing a second relationships tag with a reverse relationship verb in a second software agent object, the second relationships tag referencing the first object, to enable collaboration between the second object and the first object's workspace.

31. A method for creating a collaborative workspace in a computer network, comprising:

creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb to enable collaboration in the first object's workspace with a second software agent object having a second relationships tag with a reverse relationship verb referencing the first object; and

determining that the first software agent object is operating off-line from the second software agent object; and

archiving messages to be sent from the first object to the second object if the first software agent object is operating off-line.

32. The method of claim 31, which further comprises:

determining that the first software agent object is resuming on-line operation, and;

sending the messages to the second software agent object.

33. The method of claim 32, which further comprises:

requesting a server to send messages directed to the first software agent object, but which were intercepted by the server during the off-line operation of the first object.

34. A method for creating a collaborative workspace in a computer network, comprising:

creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb to enable collaboration in the first object's workspace with a second software agent object having a second relationships tag with a reverse relationship verb referencing the first object; and

determining that the first software agent object is operating off-line;

invoking a replica mode of operation to block making changes in the first software agent object that would affect a state of the second software agent object.

35. A method for creating a collaborative workspace in a computer network, comprising:

creating a first software agent object in a computer memory, the first object being a collaborative workspace having a relationships tag with a relationship verb to enable collaboration in the first object's workspace with a second software agent object having a second relationships tag with a reverse relationship verb referencing the first object; and

specifying a point of view to be displayed of a selected software agent object with respect to other software agent objects related to the selected object;

accessing relationships tags for the selected software agent object to identify the other software agent objects which are related to the selected object;

constructing a map image depicting the identified relationships; and

displaying an image of the map.