KR20040104483A - Information objects - Google Patents

Abstract

The present invention provides a method of using a processor to create a linked information object formed from content of each type. The processor is coupled to the display and the store to obtain the information object and allow the processor to assign a unique identifier to the information object according to the information object type. One or more links are then defined between the information object and one or more other information objects using predetermined rules or input commands from the user. The computer then generates link data defining one or more links, which are stored in the store.

Description

Information object {INFORMATION OBJECTS}

Reference to any prior art herein is not an admission or suggestion that the prior art forms part of a common general knowledge and should not be so accepted.

Recent developments in computing and the Internet are rapidly increasing the amount of information that needs to be handled daily, such as email. The time spent finding, organizing, and managing this information is increasing. This is exacerbated by the fact that this piece of information is usually present in different applications in different computers, portable devices and mobile devices, servers, networks, and the like. In addition, it is still very difficult to publish, exchange or share information while keeping the structure of the information shared. For example, when a file has been received by email, the file may need to be organized, renamed, and / or associated with a particular project, task, or group. However, once this is done, there are often no more ways to tell where the file came from because we have forgotten the reasons for the original associations, renames, and so on.

Some attempts have been made to solve this problem. Thus, for example, an occurrence initiated using a software application such as Microsoft Word ™ includes information about the author in the property section. However, this information is usually filed based on the registration on the software application. Thus, if the third party is using a software application, the exact origin of the document does not need to be displayed. In addition, such information cannot be used to create associations such as relationships between the documents.

Some software, such as Microsoft Outlook ™, uses folders to allow received emails to be sorted into categories. Thus, for example, a business may organize emails received from a particular customer to be stored in a particular folder. However, folders can be applied to store only emails, so that other related files, such as attachments, must be stored in a separate directory structure. This means that each directory structure tends to occur for different applications. As a result, there is no relationship other than naming directories and folders that can associate files with a common source.

In addition, the use of folders and directories is usually a manual process that requires that the folder directory be manually configured and used. Thus, the structure used is usually intuitive to the creator of this structure and therefore cannot be easily understood by a third party.

In conclusion, each directory structure should usually be stored separately on the server or on each machine. However, this usually does not allow common directory structures to be different and used over connected networks. Thus, additional problems arise in the organization of files contained within the directory structure.

Thus, the data can be stored as application-centric data managed according to the application generating it, or hierarchically stored in a vertical tree-like structure with no flexibility.

The present invention relates to a method and apparatus for creating and processing a linked information object.

1 is a schematic diagram of one example of a system implementing the present invention;

2 is a schematic diagram of an example of one of the processing systems of FIG. 1;

3 is a schematic diagram of an example of one of the end stations of FIG. 1;

4 is a schematic diagram showing the functionalities of FIG. 1;

5A and 5B are screen shots of an example of the UIM of FIG. 4.

6 is a flowchart of an example of a process of defining an information object using the system of FIG. 1;

7 is a flowchart of an example of a process of linking information objects using the system of FIG. 1;

8 is a flow chart of an example of a process of pivoting an circumference of an information object using the system of FIG.

9 is a flow diagram of an example of a processor that displays a relationship using the system of FIG. 1; and

10 is a flow diagram of one example of a process of viewing the content of an information object using the system of FIG.

In a first broad form, the present invention provides a method of using a processor to create a linked information object, the processor being coupled to a display and a store, wherein each information object is from content having a respective type. And the method causes the processor to:

a) get the information object,

b) assign a unique identifier to the information object according to the information object type based on the type of the content,

c) iii) predetermined rules; And

Ii) an input command from a user; define one or more links defined between at least one of the information object and one or more other information objects,

d) generate link data defining one or more links, and

e) storing the link data in the store.

Usually the method of obtaining the information object causes the processor to:

a) obtain a data object containing one or more content type instances,

b) determine a content type from the data object,

c) comparing the content type instance to an existing information object, and

d) obtaining the information object by determining a new information object from the data object by determining the content type instance to be a new information object in response to the failed comparison.

If an information object includes two or more information objects, then the method of defining one or more links between the information object and one or more other information objects usually includes defining a link between the information objects contained within the data object. .

Defining one or more links between the information object and another information object usually causes the processor to:

a) comparing the information object type of each other information object with the information object type of the information object according to a predetermined rule,

b) allowing a link to be defined between the information object and one of the other information objects according to a successful comparison.

It is desirable that certain rules specify for each information object each condition that must be met in order for the link to be defined as another information object type.

In general, one of the above conditions is that a link is defined between two information objects each having a first information object type and a second information object type if the content of one of the information objects is formed from a part of the content of another information object. It includes.

Defining one or more links between the information object and one or more other information objects usually causes the processor to:

a) display the representation of the information object to the user,

b) enable the user to use the input to select at least two of the information objects, and

c) defining a link between the selected information objects.

The method of displaying a representation to the user causes the processor to:

a) determine the identifier of any information object being displayed,

b) determine any link between information objects determined according to the determined information identifier and link data,

c) iii) generate a representation of each information object based on at least one of the information object type and information object content,

Ii) generating a representation of the information object by generating a representation of the determined link between the information object representations.

Although the representation is a tree type representation and the information object representation is preferably arranged according to a given link, the representation can be formed from any representation.

The information object identifier usually further includes an indication of each processing system for which the information object has been determined.

Usually the processor is adapted to execute the information object processing application software applied to enable the user to process the selected information object type, and the method usually causes the processing application to:

a) the process of defining a new information object,

b) including executing at least one of the processes of viewing the content of the selected information object.

The processor is also typically adapted to run display application software adapted to display information objects.

The processor may be further adapted to execute display software and control application software adapted to cooperate with one or more processing applications.

Usually the method causes the control application to

a) get the data object,

b) determine a content type of one or more content instances from the data object,

c) controlling the determination of a new information object by causing the information object to be sent to a processing application adapted to process the determined content type.

The method causes the control application to:

a) obtain a new information object from each processing application,

b) controlling the determination of the identifier by causing the identifier to be generated according to a predetermined rule and according to the information object type.

Usually the method causes the control application to

a) defining links between information objects,

b) sending the information object to a display application to cause the information object to be displayed,

c) executing at least one of acquiring processing applications to enable different information object types to be processed.

In general, the method includes defining a relationship, each relationship defining a context for a link between a particular information object type, each relationship causing each processing application to:

a) allow the user to select two or more object types;

b) allow the user to specify the relationship to links between selected object types,

c) defined by having the representation of the relationship stored as relationship data.

In a second broad form the present invention provides a processing system for creating a linked information object, the processing system comprising:

a) display;

b) store;

c) a processor adapted to execute the method of the first broad form of the invention.

In a third broad form, the present invention provides a computer program product for creating a linked information object, which computer program product, when executed in a suitable processing system, causes the processing system to, in the first broad form of the invention. Computer executable code for causing a method to be executed.

The computer program product may be provided as containing its own application software, or alternatively, may be implemented as a plug-in to an existing software application.

In a fourth broad form, the present invention provides a method of using a processor to handle linked information objects, the processor being coupled to a display, a store and an input, each information object having a respective type. And a link between the information objects is defined by link data stored in the store, and the method causes the processor to:

a) generating a representation of a number of information objects displayed on the display to the user,

b) allow the user to select an input to select one of the information objects,

c) determine, according to the link data, one or more other information objects linked to the selected information object,

d) generating a representation displayed on the display of the selected information object and at least the linked information object.

Usually, the method causes the processor to:

a) determine an identifier of the selected information object,

b) determining a link determined between the selected information object and the linked information object according to a predetermined identifier and link data,

c) iii) generate a representation of each information object based on at least one of the information object type and the information object content,

Ii) generating a representation by generating a representation of the determined link between the information object representations, thereby generating a representation.

The representation may be formed into a tree type representation, and the information object representation may be arranged according to the determined link.

The processor may further be adapted to display the content of the information object to be displayed on the display in response to a request from the user.

Processors, displays, stores and inputs usually form part of a processing system. In such a case, the processing system may be adapted to be coupled to one or more other processing systems via a communication network, the method comprising causing the processor to obtain required data from other information of the processing system, Data is

a) information object;

b) link data; And

c) at least one of the information object identifiers.

Typically, the identifier includes an indication of a processing system in which the identifier is stored and the method causes the processor to:

a) determine the processing system in which the required data is stored,

b) obtaining the requested data from the processing system.

Typically, the link data specifies an identifier of each linked information object for each link, and the method further includes causing the processor to determine an identifier of the linked information object taken from the link data. .

The processor may be adapted to execute information object processing application software applied to enable a user to process the selected information object type, and the method typically causes the processing application to:

a) the process of defining a new information object;

b) executing at least one of the processes of viewing the content of the selected information object.

The processor may be adapted to generate display application software adapted to display the information object.

The processor may also be adapted to execute display software and control application software adapted to cooperate with one or more processing applications.

In this case, the method usually causes the control application to:

a) determine link data representing each link according to the identifier of the selected information object,

b) determine an identifier of each linked information object from the link data,

c) controlling the occurrence of the representation of the information object linked to the selected information object by sending an indication of the link and the identifier to the display application.

Also, the normal method causes the control application to:

a) determine an identifier of the selected information object,

b) determine if the selected information object is in a store,

Iii) if the selected information object is not in the store,

(1) determine a processing system from which the information object can be obtained,

(2) cause the processing system to obtain an information object from the determined processing system,

Ii) if the selected information object is in a store, obtain an information object from the store,

c) controlling the display of the content of the selected information object by sending the information object to the selected processing application operative to display the content of the processing application.

The processing application is also further adapted to define relationships in general, each relationship defining a context for links between specific information object types,

a) allowing the user to select a relationship type,

b) controlling the generation of the representation such that only links that satisfy the selected relationship are displayed.

Usually, the method causes the control application to:

a) determine the information object type from each identifier,

b) determine whether any processing application executable by the processor can process the determined information object type,

c) causing the processor to acquire a new processing application from one of the other processing systems via the communication system in response to the comparison performed.

The linked information object was created using the method of the first broad form of the invention.

In a fifth broad form, the present invention provides a processing system for handling linked information objects, the processing system comprising

a) display;

b) store;

c) a processor adapted to execute the method of the fourth broad form of the invention.

In a sixth broad sense, the present invention provides a computer program product for handling a linked information object, wherein the computer program product causes the processing system to execute a method in the fourth broad form of the invention when executed in a suitable processing system. Contains computer executable code for execution.

Again, the computer program product may be provided as itself containing application software, or alternatively, may be implemented as a plug-in to an existing software application.

(Detailed Description of the Preferred Embodiments)

One example of the present invention will now be described with reference to FIG. 1, which shows a system suitable for implementing the present invention.

As shown, the system is one or more base stations (only one is shown for illustration) connected to the plurality of end stations 3 through the communication network 2 and through the plurality of LANs 4. It includes.

The base station 1 is typically formed of one or more processing systems 1 connected to a data store 11 that includes a database 12, as shown. In addition to this, database 12A may also be provided in connection with LAN 4, as described in more detail below. In addition, one or more servers 5 may be connected to the communication network 2 and / or LANs 4 as shown.

In use, the user of the end station 3 can access the services provided by the base station 1 so that they can see the details of the information objects IOS stored in the system and can interact with the information objects. IO is a piece of data of each type described in a system in a predetermined manner. Thus, the IO may correspond to any type of content, such as an email, an email address, a "word" document, an invoice, or any other data for which the content may be defined as having a particular type.

This functionality is achieved by allowing a user to share IOs between the end station 3, the server 5 and the base station 1 according to certain predetermined permissions. In addition, the IOs are linked to each other so that the user can browse the related IOs, helping to navigate between the information objects.

Thus, the end station 3 and the base station 1 need to be able to communicate so that data such as IOs and other details can be transferred between them.

Thus, it will be appreciated that the system can be implemented using a number of different architectures. However, in this example, the communication network 2 is the Internet with LANs 4 representing dedicated LANs such as internal LANs in a company or the like.

Thus, the processing system 10 may be any type of processing system, but as shown in FIG. 2, the processor 20, memory 21, input / output (IO) device ( 22) and interface 23. An interface 23, which may be a network interface card or the like, is used to connect the processing system to the Internet 2 and optionally to the LAN 4.

Accordingly, it will be appreciated that the processing system 10 may be formed of any suitable processing system capable of operating the application software to enable the provision of the required services. In general, however, the processing system 10 will be formed of a server such as a network server, a web server, or the like.

Therefore, it will be understood that the server 5 may have a similar structure.

Similarly, the end station 3 should be able to cooperate with the base station 1 to transmit or receive data containing IOs, in particular to be able to communicate with the processing system 1. In addition, similar communication with the server 5 may be required. Thus, in this example, as shown in FIG. 3, the end station 3 is connected to a processor 30, a memory 31, an input / output (I / O) device 32 and an interface connected together via a bus 34. It is formed into a processing system including (33). An interface 33, which may be a network interface card or the like, is used to connect the end station 3 to the Internet 2.

Thus, the application software can be formed into any suitable processing system, such as a suitably programmed PC, an Internet terminal, a laptop, a pocket PC, etc., which is usually operated to transfer data and, in some cases, web-browsed.

In the case where the IOs are e-mails or the like, the processor 30 can run specialized application software specially created to handle the defined IOs. In the alternative, the processor may operate a modified version of an existing email or other application, such as Microsoft Outlook ™, that has been modified to provide a service in accordance with the present invention. This may be accomplished, for example, by providing a plug-in that allows existing application software to achieve the required functionality.

Alternatively, end station 3 may be formed of specialized hardware, such as an electronic touch sensitive screen connected to a suitable processor and memory, as described in more detail below. In addition to this, the end station 3 can be adapted to connect to the Internet 2 or LANs 4 via a wired or wireless connection. Also, for example, if the system is implemented as a peer-to-peer network, a direct connection between the base station 1 and the end station 3 is also possible.

summary

As briefly mentioned above, the present invention provides a technique for the user to view the IOs and associated links using the end station 3. We will now briefly explain how this is achieved.

First, IOs need to be defined in the system.

As mentioned above, each IO represents each type of content described in the system in a certain way. Thus, in order to generate IO, it is necessary to first generate the appropriate definition after determining the respective content.

A user can create content using specialized software applications. Alternatively, the content may be determined from a data object, such as a file, an email or the like, received at the end station 3. The data object may comprise a number of different content instances, some of which may have different types, so that the first process may be for the end station 3 to analyze the data object and determine any content instances contained therein. will be.

Thus, for example, in the case of an email, the email itself is an instance of email type content. Similarly, the sender's and recipient's email addresses are also respective instances of email address type content. It is also possible for an email to contain one or more attachments, again each of which may be an instance of each of a particular type of content.

After identifying all different content instances, the end station 3 will proceed to define each content instance as IO by assigning each identifier to each of the content instances. The end station 3 assigns an identifier according to predetermined criteria. Thus, the identifier of each IO is generally at least,

IO type;

The identifier of the end station 3 assigning the identifier.

This allows each content instance to be defined as each IO whose type depends on the type of each content. Thus, for example, the email IO corresponds to the email content of the email. Similarly, the email address IO corresponds to each email address in the email.

This not only identifies the IO type and IO source, but also uniquely defines each IO.

Once the IO is defined, it can then be linked to other IOs defined in the system of FIG. These other IOs may be stored at each end station 3 and, alternatively, may be stored elsewhere in the system. Thus, for example, it may be stored in the base station 1, the database 12, the database 12A, or in any one of the other end stations 3, or in one of the servers 5.

The link between the IOs can be defined automatically according to certain laws or manually by the user.

A definition of each defined link is then generated, and the link definition is generally one of the base station 1, database 12, database 12A, server 5, or end, along with the defined IO identifier. Stored in each of the stations 3.

Thus, in use, the user of the end station 3 can view the IOs using the end station 3 itself. This is achieved by causing the end station 3 to generate a representation of the selected IO, along with any other IOs linked to the selected IO.

To accomplish this, the end station 3 is adapted to be received so that an indication of the IO is shown. The end station 3 will then use the identifier of each IO to locate the link data defining any associated link. The link data is used at the end station 3 to determine the identifier of the linked IOs, so that the representation of the link and the IOs can be determined. This information can then be displayed to the user.

In general, a procedure for selecting an IO and then viewing any additional IOs linked to that IO is known to "pivot" the perimeter of the IO. This procedure allows the user to navigate around the linked IOs, so the user can find any desired IOs. Once this is accomplished, the content of the IO can be viewed or modified as desired.

Thus, it will be appreciated that, due to this, any type of IO's can be linked into a flexible layer regardless of the application used to handle the IO's and regardless of any predefined hierarchy.

Because the set of IOs linked together is called a pivot universe, it is possible for a user to navigate through the IOs contained within the universe alone by using a defined link.

In general, users of the system will want to see their publicly useful universes as well as define their own universes. In order to allow the user to control the access to his private universe, the user can define access rights to his universe. Each user of the system then has a respective access right subordinate to its access privilege. This allows a user to restrict access to his universe to selected individuals or entities. In this case, only an individual or entity with access to the universe can see or pivot around the IO's contained within the universe.

Thus, for example, companies want to keep their IOs confidential so that their IOs do not form part of their respective companies or can't be viewed by users of the system who are not authorized customers. Likewise, however, this also allows universal access rights to be granted to selected pivot universes, for example, so that a global address book can be implemented.

In general, however, common IOs will link your universes to each other. Thus, for example, the first user and the second user can each cause each universe to be formed from various linked IOs. When the first user receives an email from the second user, the universe of the first user can be updated to include an email address IO based on the email address of the second user. However, the second user's universe will also include an email address IO based on the second user's email address.

Thus, it will be appreciated that the system can be applied to determine that these email address IOs are the same. Thus, when either user pivots around this common email address IO, the user will be able to see the links to the IOs contained in both universes, so that they can assume that the appropriate access rights have been provided.

Thus, if a universe is not defined as dedicated and does not have a corresponding limited access, it will be appreciated that any user of the system can see the IOs contained within the system.

This is of particular benefit when useful information on the system becomes freely viewable. Thus, for example, if a universe is defined as public, the first user may obtain an email address from the universe of the second user.

details

A detailed description of the operation of the system of FIG. 1 will now be described. In particular, the functionality of the system of FIG. 1 will be described in more detail with reference to FIG. 4.

As shown in FIG. 4, the system can be implemented using a number of different techniques. In each case, however, the base station 1 may include an authentication service 40, an identifier service 41, an address mapping service 42, a global object service 43, and a global pivot service 44. Operate to provide a number of services.

Each of the end stations 3 will then operate one or more of the functions shown in 3A, 3B, 3C.

In this example, the end station 3 having the function shown in 3A is applied to operate in a P2P network environment, and the function shown in 3B represents a client / server application, and the function shown in 3C. Represents a web-server application.

In the P2P mode of operation, the end station 3 operates a pivot service 51 connected to a user interaction manager (UIM) 50. The UIM 50 is a pivot client manager 52 and an object interaction engine (OIE) manager. Operate to control the operation of 53. In use, UIM 50 is selectively coupled to database manager 54 and database 55, as shown.

In the client server function shown in 3B, the end station 3 is configured to include pivot service 61, pivot client manager 62, OIE manager 63, database manager 64, and database, as shown. Operate the service manager shown generally at 60, which implements 65. In addition, a client manager 66 that implements an additional pivot client manager 67 and an additional OIE manager 68 is connected to the service manager 60.

Finally, in the web service application function shown in 3C, the web server application is configured with 70 web server applications implementing pivot service 71, OIE manager 73, database manager 74, and database 75. It is provided. In use, the web server application is connected to a web client 80, such as a web browser, via a web server 79.

Each function of the core services 40, 41, 42, 43, 44 operated by the base station 1 will now be outlined.

Authentication Service (40)

Authentication service 40 provides an authentication mechanism for users of the system. This allows access to the system to be controlled by registered users and the like, as well as allowing mechanisms to control access restrictions based on user permissions, as described in more detail below.

Identification Service (41)

The identifier service 41 keeps track of the unique identifier used by the system, allowing information, IOs, OIEs and services to be uniquely identified.

Address Mapping Service (42)

Address mapping service 42 maintains a dynamic map of currently networked and reachable applications. These maps are constantly updated as the application goes online or offline.

Global Object Service (43)

Global object service 43 is the primary registration and distribution point for guaranteed OIEs. Thus, it is used to allow the user of the end station 3 to download OIEs as needed.

Global Pivot Service (44)

The global pivot service 44 includes links and IOs of publicly available universes.

P2P operation

p2p functions

Storing IOs locally,

Provide a dynamic address map,

Operate by providing non-persistent connectivity and access to locally stored IOs.

As described above, the p2p model includes the following components:

P2p pivot service (51),

P2p UIM 50,

P2p database manager 54 (optional)

Each function of this component operated by the end station 3 in the p2p function 3A will now be outlined.

P2P Pivot Service (51)

Pivot service 51 acts as a communication module within the p2p framework. Pivot service 51 operates according to the core services 40, 41, 42, 43, 44 of base station 1 and any of its functions (ie, p2p, client / server or web-server). It will handle all communication between components operated by other end stations 3. this is,

Identification and authentication

Demand for IOs

ㆍ request for link definition

Transmission of OIEs

Include operations such as:

P2P UIM (50)

UIM 50 is an interface presented to the user. The UIM 50 serves to present the IOs and associated links to the user of the end station 3 via the graphical interface. This allows the user to manipulate IOs defined in the system.

UIM 50 has two components, namely

Pivot Client Manager (52)

Object Interaction Engine Manager (53)

It includes.

Pivot Client Manager 52 basically allows the user to select from a list of user interfaces that help the user manage IOs, links, and relationships. Thus, pivot client manager 52 can be tailored to specific requirements and distributed throughout the system, allowing the user to select a preferred pivot client from a useful pivot client.

The OIE Manager 53 manages different types of OIEs useful for handling different IOs types in the system. OIE related to the IO type serves to represent the content of the IO to the user of the end station (3).

P2P Database Manager (54)

The p2p database manager 54 is an optional component that allows a database owner to link up his database 55 as well as create a new database 55 to store IOs, link data, IO identifiers, and the like. . This gives the user flexibility in data storage.

Client-server behavior

Client-server functionality provides the ability to store data centrally within a persistent server and to access data as a non-persistent client. In this model, access to the pivot universe is through the server and only through the server.

This model consists of two main components:

Service manager 60 (forms a server)

Client manager 66 (which forms a client)

Service Manager (60)

The service manager 60,

Continuous service and permanent connection to the base station (1)

Has a persistent database 65 for storing IO data

Manage local pivot information

Handles all communication with non-local services, such as the base station's core services.

Thus, it will be appreciated that the service manager 60 may be implemented, for example, as part of the base station 1 itself, or alternatively, as a processing system connected to one of the LANs 4. Thus, in the case of a company or the like, the service manager is usually implemented on a central server, and the user of each end station 3 is connected to the central server in order to maintain on-word connectivity to the service provided by the base station 1. To operate.

The service manager consists of the following components:

Pivot Service (61)

Pivot Client Manager (62)

OIE Manager (63)

Database manager 64;

Pivot Service (61)

Pivot service is a communication module within the client server framework, and is used by the core services 40, 41, 42, 43, 44 of the base station 1 and other end stations 3 operating according to any of the functions. Handles all communication between components operated by this is

Identification and authentication

Demand for IOs

Request for link definition

Transmission to OIEs

Include operations such as:

OIE Manager (63)

This component manages all OIEs supported by the client server function.

Pivot Client Manager (62)

These components manage pivot clients useful for use in client server functions.

Database manager (64)

The database manager processes all IO data and stores it in the database 65 as required.

Client Manager (66)

Client manager 66 is the main interaction interface with the user, and generally,

Pivot Client Manager (67)

Object Interaction Engine Manager (68)

Consists of

Pivot client manager 67 displays IOs, links and the like and allows the user to manipulate them.

The OIE Manager 68 manages OIEs useful for use within the client server framework.

Web-server behavior

Web-server functionalities are deployed on a web server application framework. Thus, the user communicates with the system via a web browser executed by their respective end station 3.

Web-server functionalities can be implemented using JSP / Java Servlet technology, for example, and generally operate using the following components:

Pivot Service (71)

OIE Manager (73)

Database Manager (74)

JSP / Java Servlet-enabled Web Server (79)

Web Client / Browser (80)

Pivot Service (71)

Pivot services are communication modules within the client server framework, and the core services 40, 41, 42, 43, 44 of the base station 1 and other end stations 3 operating in accordance with one of the functionalities. Handles all communication between components operated by. this is,

Identification and authentication

Demand for IOs

Request for link definition

Transmission to OIEs

Include operations such as:

OIE Manager (73)

These components manage all the OIEs supported by the Web server functionalities.

Database Manager (74)

Process all IO data and control storage in database 75.

JSP / Java Servlet-Enabled Web Server (79)

It acts as a web-server providing access to the required services for the user, via a web client or browser 80. Thus, the web server may alternatively be operated by, for example, a processing system connected to one of the LANs 4, which may provide on-ward connectivity to the base station 1, but may be part of the base station 1. It is usually operated as.

Thus, in the case of a company or the like, the web server application 70 and the web server 79 are usually implemented in a central server, and the user of each end station 3 is connected to the service provided by the base station 1. It operates to access the central server to gain word connectivity.

Web Client / Browser (80)

A web browser is needed to access data from web server 79. This is an interaction platform for users of web-server functionalities.

It will be appreciated that the func- tion outlined above, in particular the func- tion achieved at the user's end station 3, can be achieved using specialized application software. Alternatively, the functionalities can be achieved by providing a software plug-in that serves as an interface with the existing application software to enable the existing application software to execute the required functionalities.

The behavior of the system of defining IOs with associated links and navigating through PivotView universes will now be described for p2p functionalities. However, it will be appreciated that equivalent operations will be obtained using client server or web server functionalities.

5A and 5B described in more detail below show an example of a graphical representation of a screen presented to a user of one of the end stations 3. In the p2p case, this is accomplished by the UIM 50, but in the client and web server functionalities, this is accomplished by the client manager 66 and the web server 80, respectively.

In FIG. 5A, UIM 50 is generally shown at 90 and two pivot client windows are shown at 91A, 91B. In this example, pivot client window 91A lists a number of IOs at 93. When the user pivots around the selected IO 95, the IOs linked to this selected IO are displayed in the second pivot client window 91B.

In the example of FIG. 5B, a graphical representation of the UIM, shown generally at 90, is presented that enables a user to view the content of IOs. In this case, UIM 90 presents the user with two main windows, a pivot client window 91, and an OIE window 92.

As described in more detail below, a pivot client window is used by each pivot client to display a representation of the IOs shown at 93 and a link shown at 94 in window 91. The selected IO is also shown at 95.

Similarly, UIM 50 allows a user to select different OIEs using the selection tab shown at 96. In use, the selected OIE will then be presented in OIE window 92. In this example, the OIE is an email OIE that is applied to allow the user to view the contents of the email IOs and to generate the email IOs. This can be accomplished by providing application software to form the OIE. Alternatively, the OIE can be implemented as a plug-in to existing application software. Thus, for example, an email OIE can be implemented as a plug-in to an existing email package, such as Microsoft Outlook or the like. In this case, the user will be redirected to Outlook to produce email IO or the Outlook in OIE window 92 will be presented.

In any event, assuming that an email OIE is displayed in the OIE window, the OIE window includes a field roughly shown in 97, allowing the user to enter an email option provided by Windows 98 so that the email text can be defined. do. Otherwise, equivalent fields in Microsoft Outlook, etc. are used.

The procedure for defining the IO will now be described with reference to FIG. 6. The way this is achieved will vary depending on whether the IO was created directly using one of the OIEs, or whether the IO was extracted from the data object received or created at the end station 3.

In the latter case, a new data object is received or created at the user's end station 3 in step 100. Thus, for example, it may be an email received via the Internet 2 or, alternatively, an email generated at the user's end station 3 using email software that does not communicate with the UIM 50.

In any event, once received, the data object is reviewed by UIM 50 in step 110 to allow UIM 50 to determine the type of content contained within the data object. In step 120, the UIM 50 determines whether an OIE that can handle the data object, in particular the determined content type, is useful. Accordingly, UIM 50 consults OIE manager 53 to check the currently available OIEs to determine if one of the OIEs can handle each IO type. In general, although not required, currently available OIEs are stored in the database 55 or in the memory 31 of the end station 3.

Thus, for example, if UIM 50 determines that the data object is an email, UIM 50 queries OIE 53 to determine whether an email OIE exists. If there is no email OIE, a suitable OIE is downloaded from the base station 1 or the other of the end station 3 via pivot service 51, as shown in step 130.

In step 140, once a suitable OIE is available, the OIE operates to determine the next IO. This is accomplished by having the OIE identify an instance of each type of content in the data object. Thus, for example, if the data object is an email, the OIE will first act to determine the email representing the email as a whole.

The OIE will then compare the determined IO to existing IOs with the same content type. Thus, the OIE will operate to compare the identified email IO to existing email IOs stored on the system. In step 160, if the same IO already exists, the OIE will send the determined IO to the UIM 50, in step 170. The UIM 50 proceeds at 190 to allow a link to be defined for the IO, at step 180, before proceeding to determine if there are other IOs in the data object.

However, if the IO is determined to be new at step 160, the OIE sends a new IO to UIM 50 at step 200 for identifier determination. In step 210, UIM 50 determines a unique identifier from the OIE based on the type of new IO. The actual format of the identifier may change depending on the implementation of the system. However, in this example, the identifier is based on the pivot service identifier, interaction engine identifier, template identifier and object identifier.

The pivot service identifier is a unique identifier for each pivot service 51 operated by each end station 3. The pivot service identifier is issued by the identifier service 41 and used to allow each end station 3 generating IO to be identified.

The interaction engine identifier is a unique identifier for the associated OIE that generates the IO. Again, the interaction engine identifier allows each OIE used to generate IO to be determined.

Template identifiers Object identifiers are all generated by the OIE. The template identifier represents each type of content associated with the IO, so each identifier will be assigned for email type content. The object identifier itself is the only number assigned to each IO instance and is therefore used to ensure that the identifier issued to each IO is uniquely unique.

The identifier of the new IO is then stored in the database at step 220. In general, the identifier will be stored in a database 55 associated with each end station 3. However, since the presence of the database 55 is optional, the identifier may alternatively be in the memory 31, in one of the other end stations 3, in the base station 1, for example in the database 12, It is possible to store in one of the servers 5 or in the database 12A, as appropriate.

In any event, the end station 3 will always operate to store each identifier generated at the end station in a respective database, so that the identifier can subsequently be located.

In the case of an email data object, it will be appreciated that the data object usually contains multiple IOs. For example, the data object includes the sender's email address and the recipient's email address, each to be an IO. Thus, once the IO has been defined and the UIM 50 has allowed the link to be defined for the IO at step 180, the processor 30 will again operate to determine whether there are any additional IOs. These will then be handled in a similar manner.

Thus, it will be understood that each email address will be used to define each email address IO. Again, when this is done, each defined IO will be compared to existing IOs in step 150, so that a new IO is not generated each time the same email address is received, or whenever the sender's email address is used. Do not.

Once there are no additional IOs, the procedure ends at 230.

Alternatively, the user can create IO using each OIE. In this case, because the user enters an e-mail address in one of the e-mail fields 97, for example, the OIE will automatically operate to define this as IO. The OIE will then proceed to step 150 to determine if the IO is new. The remainder of the procedure is substantially as described above and therefore will not be described in detail.

It will be appreciated that there is one possible way of defining IOs, where each IO is processed sequentially. Alternatively, however, this may be done in parallel, for example, such that each content type instance is determined. Then, each IO is supplied with an identifier before each IO is processed so that a link can be defined. Other variations are also possible.

An example of how a link can be defined will now be described with reference to FIG. 7.

First, in order for a link to be defined for a given IO, the IO must be received by UIM 50 in step 300. This usually occurs automatically when the UIM 50 operates to determine an identifier for the IO as described above with reference to FIG. 6.

In step 510, the UIM 50 determines whether the link will be automatically defined.

In order to automatically define links, certain predefined link rules need to be defined within each OIE that handles each IO type. These link rules can be defined by each user, allowing IOs to be processed in the required way. Alternatively, link rules can be defined by the creator of each OIE, allowing various IO types to be handled in some way.

Thus, if the link rule has not been defined, if certain predetermined settings have been set, the UIM 50 will proceed straight to manual link definition, at step 390. However, in normal circumstances, UIM 50 will proceed to step 320 to obtain link rules from each OIE.

In general, link rules specify the criteria by which IOs should be linked automatically. This is generally the two main criteria, namely

The type of each IOs; And

Any predetermined association between IOs;

Depend on at least one of.

Thus, the first criterion allows IOs to be linked alone based on the IOs being of a predetermined type. For example, if one of the IOs is an email address or the like, it will be automatically linked to the address book IO according to certain rules. As a result, all email addresses are automatically and securely linked to the user's address book.

In contrast, the second criterion allows IOs to be linked if there is an additional association between the IOs. Thus, for example, if a data object such as an email is received, any IOs contained therein are automatically linked if these IOs have a certain type. Thus, for example, email IO is always automatically linked to any corresponding email address IOs. This ensures that a link exists between the sender or recipient email address and each email. Similarly, any attachment to an email will have each IOs of the attachment linked to the IO corresponding to the email.

In step 330, after comparing the selected IO to a given link rule, the UIM 50 operates to determine if the IO can be automatically linked to any other IOs.

If this is the case, the UIM 50 generates a link definition for each new link at step 350. The information contained in the link definition changes depending on each implementation of the present invention.

However, in this example, the link definition is at least,

A traversal rule indicating the direction to the link;

Inheritance expression that indicates whether the traversal rule can use the identifier of the IO to identify itself as the next pivot

An owner identifier which is an identifier of the owner who created the link;

A traversal permission indication indicating that an identifier is capable of executing the traversal of the link;

An identifier of IOs located at each end of the link (also known as source and target identifier).

The traversal rule specifies the direction to the link. Thus, for example, traversal rules can be used to prevent the links from traversing in a particular direction. Thus, for example, the traversal rule may be implemented to allow traversal from the first IO to the second IO while preventing traversal from the second IO to the first IO.

In addition, for example, an email address IO may be defined as a "child" IO with respect to a "parent" address book IO. This is because each email address is one instance of one address in Address Book IO. In addition, directionality can be implied because each email address IO may also be linked to many different address book IOs. Because of this, the identifier of the sign IO can be inherited by the child IO, so that the parent can be easily identified, which is provided by the factorial representation. However, even in this case, the setting can be used so that there is no distinction between the IOs and the way they are handled. Thus, the parent-child relationship is effectively flattened out so that each IO is equal to each other IO.

The link definition is stored as link data in the selected database. Again, as in the case of identifier storage, each database used is subject to the presence of a database in the end station 3. In any event, the database used is generally the same database used to store the identifier. It will be appreciated that this is done for each link that can be defined automatically.

Once the link data has been stored at step 360, UIM 50 prompts the user to determine whether to manually define additional links at step 370. In step 380, if the additional link will be defined manually, the procedure proceeds to step 390, as described below. If not defining additional links, the process ends at step 470. It will be understood from the above description that if the link cannot be defined automatically in step 340 the process will go directly to step 390 to determine if the link will be defined manually.

In step 390, the representation of IO is displayed to the user using pivot client window 91. The user can then operate to define the link between these IOs and the displayed IOs. Other displayed IOs may include any suitable IOs, but generally include selected IOs included in the universe where the user adds new IOs. Navigation of IOs included in the universe will be described in more detail with reference to FIG. 8.

The way this is achieved will vary depending on the implementation of the pivot client. In general, however, this is accomplished by allowing the user to select two of the IOs, for example by highlighting the IOs, as shown by the IO selected at 95. The user can then request that the link be defined between the selected IOs. Thus, in step 400, the UIM 50 determines whether a link will be defined, and if so, the link is passed from the pivot client to the UIM 950 in step 410.

In step 420, the UIM 50 operates to determine if the user has permission to create a link. This can happen, for example, if only the user has the right to see and thus cannot create a link to the selected IO.

In this case, UIM 50 obtains permission to create a link using pivot service 51. To do this, the pivot service 51 queries the authentication service 40 operated by the base station 1. This query will require the authentication service 40 to provide permission for the user to create a link.

Once permission has been obtained, UIM 50 continues to step 440 to generate a link definition that represents the link. The link definition is stored in the database selected at step 450 before the link is presented to the user on the pivot client at 460, as described in more detail below.

The user will understand that permission to create a link may be denied. This can happen, for example, if a user attempts to create a link to an IO contained within another user's private universe. In this case, it may still be possible for the link to be defined automatically, but the user will not be able to manually create additional links. It will be appreciated that a similar authentication process can be executed to automatically define the link.

Once the link has been defined, the process ends at 470.

The manner in which the representation of IOs and links can be used to enable a user to navigate a pivot universe will now be described with reference to FIG.

First, as shown in step 500, a representation of one or more IOs in the pivot client window 91A, shown in FIG. 5A, or in the pivot client window 91, shown in FIG. 5B, will be presented to the user.

It will be appreciated that for the initial representation to be shown, a representation of the required IOs must be provided. In general, the representation is for IOs in a given universe, so the user can provide an indication of the universe the user wants to see, for example, so that the initial representation can be displayed.

In addition, as described above, a link may define a parent-child relationship between IOs. This can be used to define the hierarchy used when viewing a universe. Because the universe usually contains many IOs, the pivot client displays only the selected ones of the parent IOs by default. Thus, for example, if a universe contains address book IOs, multiple address IOs, the pivot client displays only address book IOs by default, so the user can, if required, address them in the manner described in more detail below. Allows you to navigate to the selected IOs.

Thus, when the pivot client is first activated, it is possible for the user to configure the pivot client to display the selected universe as well as the selected one of the IOs in the universe.

However, this is only achieved upon selection of the appropriate setting, and for any event, otherwise, the IOs are treated the same regardless of any defined hierarchy normally used only for controlling the display of IOs.

In any event, once the representation of one or more IOs is displayed, as shown in FIGS. 5A and 5B, the user selects an IO to pivot around, for example, as shown at 95. This is done in step 510.

In step 520, the identifier of the selected IO is used to determine the link definition from the database. Thus, when selecting IOs to pivot around, the UIM 50 determines the identifier of each IO. The identifier is then used to access link data stored in a selected one of the databases, as described above.

In the example where the link data and the identifier are stored in the database 55, the link data can be obtained by having the database manager 54 query the database 55 according to the IO identifier. Since the IO identifier will be stored in the link data of each link connected to the IO, this can determine the link definition of each link connected to the IO. Once determined, the link definition is sent to the UIM 50.

UIM 50 then determines, from the link definition at step 540, an identifier of each IO linked to the selected IO. Once the identifier of each IO has been determined by UIM 50, UIM 50 will cause the pivot client to generate a representation of the IOs to be displayed.

The representation is generated based on the selected information, according to the pivot client itself. Thus, in the example shown in FIGS. 5A and 5B, the representation of each IO is based on the content of the IO. Alternatively, however, the IO representation may be based on an IO identifier, IO type, or predefined IO content indication generated when the IO was initially defined. The representation used will generally depend on any setting of each user end station 3 and each pivot client.

In any event, at step 550 the pivot client determines if any additional information is needed to generate a representation for each of the displayed IOs. In step 560, the pivot client determines whether all required information is known.

If the IOs themselves are not located on the end station 3, it will be understood that the pivot client may only have access to this IO identifier and this may provide insufficient information to generate an expression. Thus, in step 570, the pivot client may request the rest of the required information from one of the other end station 3, the base station 1, the server 5, or the database 12, 12A, depending on the storage location of the IO. Let the pivot server decide

As outlined above, the storage location of the IO can be determined based on the identifier, which allows the generation location of the IO to be determined, which in turn can be used to locate the IO itself. Once this is done at 570, the pivot client will proceed to display a representation of the IOs, joined by the link defined in the associated link definition. Thus, in the case of FIG. 5A, the pivot client will generate a second pivot window 91B containing linked IOs as shown. In the case of FIG. 5B, the pivot client displays IOs in the pivot client window 91 where the link is shown at 94.

In the case of FIG. 5A, if the user selects one of the IOs to pivot in the pivot client window 91B, an additional pivot client window (not shown) may be created, alternatively from the pivot client window 91E. The IOs of may be sent to pivot client window 91A, with the linked IOs shown in 91B. In the example of FIG. 5A, no OIE window 92 is provided, and therefore, when the user wants to edit the IO, the user selects the editing option and, for example, through the use of a third party plug-in application or the like. Such that each OIE is launched in a separate application.

It is also possible for a context to be defined for a particular link. The context is defined in the OIE and for the relationship between each IO type. Thus, for example, in the case of an email, it is possible to define a sender address IO representing the sender's email address and a recipient casting IO representing the recipient's email address.

In this case, the relationship context can be defined for any recipient or sender address IOs linked to any email IOs. Thus, each OIE can be applied to recognize the relationship of a particular form. Relationships can be defined, programmed or customized within the OIE. The purpose of this is to allow context to be applied to the link so that the view of the link can be filtered.

An example of how this is achieved will now be described with reference to FIG. 9.

In this example, the representation of the linked IOs is displayed to the user using the pivot client in the normal way, as shown in step 600.

In step 610, the user selects an IO and requests to see the associated relationship. In step 620, the UIM 50 uses the IO identifier to determine the type of the selected IO. In step 630, the UIM 50 determines whether the end station includes an OIE to handle each type of IO. If not, at step 640, one OIE is downloaded by pivot server 51 from either base station 1 or end station 3.

Then, at step 650, the user selects the relationship defined in the OIE. This relationship will usually simply define a filter that indicates which IO type can form part of the selected relationship. Alternatively, however, the filter can determine specific IOs and not just determine the IO type. Once the relationship has been selected at 650, the UIM determines at step 660 the IOs or IO types associated with each relationship. The UIM then determines the IOs linked to the selected IOs in step 670 and having a particular IO type, and then in step 680, causes the pivot client server to display a representation of these determined IOs.

Thus, it will be understood that rather than showing all the IOs linked to the selected IO, only certain IOs or only IOs with a particular IO type that satisfies the defined relationship will be displayed.

Thus, for example, a user may want to view email received from each individual. Thus, the user will select an email from the sender address IO representing each personal email address. Simply doing this will display any IOs linked to the sender address IO. Thus, this usually includes not only relevant email IOs, but also other IOs that are of no interest to the user at this time.

Thus, the user selects the "received from" relationship. This "received prompt" relationship will specify the relationship to the recipient email address IO, and the pivot client should display any email type IOs linked to that IO. Thus, the pivot client will display a list of email type IOs, so the user can see the IOs of each email received from each individual.

It will be appreciated that this allows the user to define his own context to the link in the form of each relationship definition. The link can then be viewed by any individual who has access to each universe including IOs. However, the context of the link may only be apparent when the individual also has a respective OIE for which the context is defined. If you do not have the OIE, the individual will only know that the IOs are linked and will not know what the link means.

10 illustrates a process for viewing the content of an IO.

In this example, as described with respect to FIG. 5B, a representation of one or more IOs is displayed to the user in pivot client window 91 at step 700. The user then selects the IO to view in step 710. In step 720, the UIM 50 uses the identifier of the selected IO to determine the IO type.

Next, proceed to determine if the end station contains an OIE that can handle the determined IO type. If no OIE is included, a suitable OIE is downloaded at step 740 by the pivot server. The IO may then be sent to the OIE in step 750 where the content may be displayed in step 760.

In this case, if the IO represents an email, for example, the UIM will determine if the email OIE is useful. If an email OIE is useful, this email OIE is displayed to the user in the OIE 92, as shown for example in FIG. Then, the content of the IO is usually obtained by downloading from one of the end station 3, the base station 1, or the database 12, 12A, 55, and then, as appropriate, the window 98 and field ( 97) in the OIE.

Thus, it will be appreciated that the system described above allows a user to view existing IOs, as well as to generate IOs and to define IOs from received or created data objects. The IOs can then be linked to other IOs, allowing the IOs to be seen as well as enabling the navigating universe using the defined link.

This is especially useful for organizing vast amounts of data. Thus, for example, by using the system described above each time an email is received, it can be automatically used to define the associated IOs for the email, any email address or attachments defined within the email. Since the email IO will be automatically linked to each of these IOs, each time an email is received from a given sender, a link will be created between the sender and the IOs representing the new email. Thus, by selecting the sender IO in the pivot universe, this allows each email received from each sender to look like a representation on the pivot client. The user then selects each of the emails so that the email content can be viewed using the associated OIE.

It will then be understood that the relationship can be used to limit the number of emails displayed. Thus, for example, an email can be received from a sender related to a number of different topics. Then, a relationship can be defined for each topic, so if the user selects a relationship, only emails from senders related to the related topic will be displayed.

In addition to the features described above, a number of additional features may also be implemented.

In particular, as briefly described above, an authentication service 40 is provided. This authentication service can be used to authenticate the identifier of a user of the system.

Thus, each user of the system may be provided with a username and password provided to the base station when the user wishes to log on to the system. The username and password will be stored as user data in the database 12. When a user wants to log on to the system, for example, to view a universe stored in the base station 1, the user must provide their respective username and password. Authentication service 40 will use the username to access user data stored in the database. This authentication service will then compare the received password with the password stored in the user data to verify that the user is a true user of the system.

Once licensed, the user will be able to access any publicly available universe.

However, it is possible for a universe to be defined as private, allowing only selected individuals to be granted access or to have certain access requirements, such as payment of a fee. Thus, for example, a company may specify that only its employees and / or customers can see the IOs in each pivot universe. Alternatively, the IOs contained in the universe can be viewed only based on paper view.

In this case, therefore, access rights representing access privileges to the restricted universe can be stored with the user data. When authentication service 40 authenticates a user, the authentication service may also determine the user's access privileges and control the viewing and modification of IOs based thereon.

Thus, for example, access rights may indicate that the pivot view universe selected for each user is granted. The authentication service will then allow user access to these PivotView universes.

In general, access to the Pivot View universe is limited by simply preventing any link data and identifiers to the end station 3 whose user name and password do not meet the access requirements.

In addition to the private universe, the base station 1 also stores details of the aerial universe, which can usually be seen by any individual. The address mapping service is provided to the map information object, for example, from a private private universe to a public pivot universe, as required.

It will be appreciated that companies may wish to present each universe on a corporate LAN 4. In this case, each server 5 may implement the functionalities of the base station 1. Alternatively, the IOs, identifiers and other data may be stored in the database 12A so that these details cannot be accessed by the end station 3 not connected to each LAN 4.

Accordingly, the present invention provides a relationship manager system that allows large capacity collaboration and data publishing capabilities by automatically forming relationships between information owned by users of the system. This, in turn, uses this relationship through the concept of pivoting, allowing users to see and access data.

Thus, a user is allowed to adopt a "point of view" of any information that has access and permission. All piece information is related to other piece information and the user. Thus, the adoption of an information viewpoint may be a power mechanism that allows for traversing a "universe" of related information in any way.

To accomplish this, the system usually includes two components:

1. User Interaction Components-Provides a mechanism for creating new information as well as a front for manipulating the information contained within the PivotView system.

Core services-keep track of matches in the system and ensure that unique matches can occur for all information encapsulated within the system.

Thus, this allows the user to interact with the information using a free-form navigation system (or screen). The user can select any information object in the system, assuming that the user has the right to select any information object in the system.

This will allow all authorized authenticated relationships with other information to be shown, so that the user can select another information object or edit and manipulate the selected object if the user is given permission.

Those skilled in the art will understand that numerous variations and modifications are apparent. All such variations and modifications apparent to those skilled in the art should be considered to be within the spirit and scope of the invention as broadly described above.

Appendix A

Authentication service

Authentication between the pivot server 51, 61, 71 and the identifier service or other pivot server is implemented using an encryption technique such as PGP encryption.

The program flow for authentication between the pivot server and the identifier service is as follows:

Pivot Server achieves a connection to the matching service.

The pivot server issues its identifier key.

The match service issues a challenge phrase encrypted with a pivot public key.

Pivot Server decrypts Challenge Phrase with Pivot Private Key.

The pivot server encrypts the challenge phrase with the match service public key.

The match service decrypts the challenge phrase with the match service private key.

If the challenge phrase matches, the pivot server is authenticated.

The program flow for authentication between pivot servers is as follows:

Pivot achieves connection to matching service.

Pivot authenticates itself with the matching service.

The match service notifies the target pivot server of the incoming connection request and issues a session key to both servers.

The target pivot server makes a connection to the originating pivot server with the session key.

• The connection is alive for five minutes until the children.

Appendix B

Identifier occurrence

Each identifier is a unique number consisting of four main parts that are divided into two 32-bit subparts.

Each identifier is 32 x 8 bits long divided into:

Most significant bit-> least significant bit

-------------------------------------------

| Pivot Server ID | Interaction Engine ID | Template ID | Object ID |

-------------------------------------------

<---- 64 bit ----> <---- 64 bit ---> <-64 bit-> <-64 bit->

Each ID is an unsigned 64-bit long number.

The control is as follows:

Pivot Server ID is issued by the matching service.

The interaction engine ID is issued by the pivot service.

Template ID and Object ID are issued by the interaction engine.

The match bit is further partitioned as follows:

Pivot server ID

---------------------

Pivot Group ID | Server ID |

---------------------

<--- 32 bit ---> <-32 bit->

Interaction Engine ID

---------------------

Interaction group ID | Server ID |

---------------------

<--- 32 bit ---> <-32 bit->

The interaction group ID is an ID uniquely identifying the specific data service.

These IDs are managed manually. This ID is issued to the developer who wants to build an application that talks to the pivot server.

Template ID

-------------------------------

Template group ID Template ID

-------------------------------

<--- 32 bit ---> <--- 32 bit->

This is an object template (type) match that uniquely identifies each object type.

Object id

--------------------------

Object Group ID Object ID

--------------------------

<--- 32 bit ---> <--- 32 bit->

The manner in which the identifier is obtained will now be summarized below.

Registration of Pivot Server

At the first run of the pivot, the pivot server starts up and performs initialization. It should be noted that the Pivot Server was not published successfully as an identifier.

Pivot Server registers itself as a useful nearest matching service.

Next, the pivot server obtains a unique ID (pivot server ID) and confirms acceptance.

The match service issues a certificate that the pivot server will use to authenticate itself.

Such a certificate may come in the form of VeriSign or any industry standard certification.

Interaction Engine Registration

At the time of installation of the IE module, the pivot server issues a server ID based on the interaction group ID if it holds.

Pivot Server performs a check to see if the plug-in contains the same signed certificate as the certificate located in the matching service.

This ensures that the IE module is authenticated before installation.

Registration of Template ID and Object ID

The template ID and object ID are solely the developer's responsibility for the interaction engine (IEs).

Claims (42)

A method of using a processor to create a linked information object, wherein the processor is coupled to a display and a store, each information object is formed from content having a respective type, and the method causes the processor to , a) get the information object, b) assign a unique identifier to the information object according to an information object type based on the type of the content, c) iii) predetermined rules, and Ii) define at least one link between the information object and at least one other information object defined using at least one of an input command from a user, d) generate link data defining the one or more links, and e) storing the link data in the store. The method of claim 1, wherein the method of obtaining the information object causes the processor to: a) obtain a data object containing one or more content type instances, b) determine a content type instance from the data object, c) comparing the content type instance to an existing information object, and d) determining the content type instance to be a new information object in response to the failed comparison, thereby obtaining the information object by determining a new information object from the data object. 3. The method of claim 2, wherein if the data object includes two or more information objects, then the method of defining the one or more links between the information object and one or more other information objects comprises: between the information objects contained within the data object. Defining a link. The method of claim 1, wherein the method of defining one or more links between the information object and another information object causes the processor to: a) comparing the information object type of the information object with the information object type of each other information object according to a predetermined rule, and b) defining a link between the information object and one of the other information objects according to a successful comparison. 5. The method of claim 4, wherein the predetermined rule specifies for each information object type each condition that must be met in order for the link to be defined with a different information object type. 6. The method of claim 5, wherein one of the conditions is that between two information objects having a first information object type and a second information object type, respectively, if the content of one of the information objects is formed from part of the content of another information object. And wherein a link is defined. The method of claim 1, wherein the method of defining one or more links between the information object and one or more other information objects comprises: a) display the representation of the information object to the user, b) enable the user to use the input to select at least two of the information objects, and c) defining a link between the selected information objects. The method of claim 7, wherein the method of displaying a representation to the user causes the processor to: a) determine the identifier of any information object being displayed, b) determining between the information object any link determined according to the determined identifier and the link data, and c) iii) generate a representation of each information object based on at least one of the information object type and the information object content, Ii) generating a representation of the information object by generating a representation of the determined link between information object representations. 9. The method of claim 8, wherein the representation is formed from a tree type representation and the information object representation is arranged according to the determined link. 10. The method of claim 9, wherein the information object identifier further comprises an indication of each processing system for which the information object has been determined. The processor of claim 1, wherein the processor is adapted to execute information object processing application software applied to enable a user to process the selected information object type, the method causing the processing application to: a) the process of defining a new information object, and b) executing at least one of the processes of viewing the content of the selected information object. 12. The method of claim 11, wherein the processor is adapted to execute display application software adapted to display information objects. 13. The method of claim 12, wherein the processor is adapted to execute control application software adapted to cooperate with one or more processing applications and display software. The method of claim 13, wherein the method causes the control application to: a) get the data object, b) determine a content type of one or more content instances from the data object, c) controlling the determination of a new information object by causing the information object to be sent to a processing application adapted to process the determined content type. The method according to claim 13 or 14, wherein the method causes the control application to: a) obtain a new information object from each processing application, b) controlling the determination of the identifier by causing an identifier to be generated according to a predetermined rule and according to the information object type. The method of claim 13, wherein the method causes the control application to: a) defining links between information objects; b) sending the information object to the display application to cause the information object to be displayed; And c) acquiring a processing application to enable different information object types to be processed. 17. The method of any one of claims 11 to 16, wherein the method further comprises defining a relationship, each relationship defining a context for a link between specific information object types, each relationship being a respective one of: Let the processing application a) allow the user to select two or more object types; b) allow the user to specify a relationship to links between selected object types, and c) defining by storing the representation of the relationship as relationship data. A method of using a processor to create a linked information object, wherein the method is substantially the same as described above. In a processing system for creating a linked information object, a) display; b) store; c) a processor adapted to execute the method of any one of claims 1 to 18. A processing system for creating a linked information object, wherein the method is substantially the same as described above. A computer program product for creating a linked information object, comprising: computer executable code for causing the processing system to execute the method of any one of claims 1 to 18 when executed in a suitable processing system. Computer program products. A computer program product for creating a linked information object, the computer program product being substantially as described above. A method of using a processor to handle linked information objects, wherein the processor is connected to a display, a store and an input, wherein each information object is formed from content having a respective type, and between the information objects. The link is defined by link data stored in the store, and the method causes the processor to: a) generating a representation of the plurality of information objects that is displayed to the user on the display, b) allow the user to use the input to select one of the information objects, c) determine, according to the link data, one or more other information objects linked to the selected information object, and d) generating a representation of the selected information object and at least a linked information object, wherein said representation is displayed on said display. The method of claim 23, wherein the method causes the processor to: a) determine an identifier of the selected information object, b) determining a link determined according to the determined identifier and the link data between the selected information object and the linked information object, c) iii) generate a representation of each information object based on at least one of the information object type and the information object content, Ii) generating a representation by generating a representation of the determined link between the information object representations, thereby generating the representation. 25. The method of claim 23 or 24, wherein the representation is formed in a tree type representation and the information object representation is arranged according to the determined link. 26. The method of any one of claims 23 to 25, wherein the processor is further adapted to display the content of an information object for display on a display in response to a request from a user. 27. The system of any one of claims 23 to 26, wherein the processor, the display, the store and the input form part of a processing system, the processing system being adapted to be connected to one or more other processing systems via a communication network. And the method comprises causing the processor to obtain the requested data from other information of the processing system, wherein the requested data is a) information object; b) link data; And c) an information object identifier. 28. The system of claim 27, wherein the identifier comprises an indication of a processing system in which the identifier is stored, the method causing the processor to: a) determine a processing system in which the requested data is stored, b) obtaining the requested data from the processing system. 29. The linked link as claimed in any one of claims 23 to 28, wherein the link data specifies an identifier of each linked information object for each link, and wherein the method causes the processor to obtain from the link data. Determining the identifier of the information object. 30. The processor of any of claims 23 to 29, wherein the processor is adapted to execute information object processing application software adapted to allow a user to process a selected information object type, the method causing the processing application to: a) the process of defining a new information object; And b) executing at least one of the processes of viewing the content of the selected information object. 31. The method of claim 30, wherein the processor is adapted to execute display application software adapted to display information objects. 32. The method of claim 31, wherein the processor is adapted to execute control application software adapted to cooperate with the one or more processing applications and display software. 33. The system of claim 32, wherein the control application causes a) determine link data representing each link according to the identifier of the selected information object, b) determine an identifier of each linked information object from the link data, and c) controlling the occurrence of the representation of the information object linked to the selected information object by sending an indication of the link and the identifier to the display application. 34. The method of claim 32 or 33, wherein the control application comprises: a) determine an identifier of the selected information object, b) determine whether the selected information object is in the store, Iii) if the selected information object is not in the store, (1) determine a processing system from which the information object can be obtained, (2) cause the processing system to obtain the information object from the determined processing system, Ii) if the selected information object is in a store, obtain the information object from the store, c) controlling the display of the content of the selected information object by sending the information object to a selected processing application operative to display the content of the processing application. 35. The method of claim 33 or 34, wherein the processing application is further applied to define relationships, each relationship defining a context for a link between specific information object types, and the method further comprising: a) allowing a user to select a relationship type; And b) controlling the generation of the representation such that only links that satisfy the selected relationship are displayed. 36. The method of any one of claims 32 to 35, wherein when dependent on the method 27, the method causes the control application to: a) determine the information object type from each identifier, b) determine whether any processing application executable by the processor can process the determined information object type, and c) causing the processor to acquire a new processing application from one of the other processing systems via the communication system in response to the failed comparison. 37. The method of any one of claims 23 to 36, wherein the linked information object is created using the method of any one of claims 1-18. A method of using a processor to handle a linked information object, the method being substantially as described above. A processing system for handling linked information objects, a) display; b) store; c) a processor adapted to execute the method of any one of claims 23-38. A processing system for handling a linked information object, wherein the method is substantially the same as described above. A computer program product for handling a linked information object, comprising: computer executable code for causing the processing system to execute the method of any one of claims 23 to 38 when executed in a suitable processing system. Computer program products. A computer program product for handling linked information objects, the computer program product being substantially as described above.