User interface for a distributed messaging framework

Abstract

A computer user interface for handling information objects. The interface allows a user to make a request for information in the form of a one-time query or a persistent query. With the one-time query, the user defines one or more conditions in terms of attributes and values. The appropriate classes of objects are checked and any matching objects are identified as satisfying the query. A persistent query allows such a condition to be active at all times so that when one or more objects are created that satisfy the condition, those objects are identified as meeting the condition. Other features of the user interface allow the user to define objects and publish objects. Objects can be created or edited based on a class whose attributes are inherited. A predefined selection of menu options makes creating, editing and publishing objects simple and efficient. Access controls and settings are provided to control rights to created objects.

Claims

What is claimed is:

1. A method for providing a data browser user interface executing on a first computer system coupled to a computer network including a plurality of interconnected computer systems, wherein a plurality of information objects that are instances of class definitions resides in the plurality of interconnected computer systems, and wherein the class definitions include attribute/value pairs, the method comprising:

displaying one or more information objects in the fist computer system;

selecting a first information object that is a first instance of one of the class definitions;

showing one or more of the attribute/value pairs of the first information object;

making a relational condition based on the attribute/value pairs of the first information object;

transferring the relational condition, an identifier for the first information object and an identifier for the first computer system to the plurality of interconnected computer systems in the network; and

when the relational condition is satisfied by a second information object in the network that is a second instance of the class definition of the first information object, receiving and displaying at least a portion of the second information object that satisfies the relational condition.

2. The method of claim 1, wherein displaying one or more information objects comprises:

displaying a hierarchical tree having a plurality of nodes, wherein each node can represent an information object or a collection of information objects.

3. The method of claim 2, wherein displaying one or more information objects comprises:

displaying additional items at the nodes of the tree, wherein the additional items include files.

4. The method of claim 3, wherein the additional items include hyperlinks.

5. The method of claim 3, wherein the additional items include commands.

6. The method of claim 1, further comprising

saving the relational condition so that it can be recalled at a later time for re-use.

7. The method of claim 1, wherein the selected first information object comprises executable instructions, the method further comprising

executing the executable instructions at the first computer system.

8. The method of claim 1, wherein the class definition has a predetermined convention including a domain name, path, and object name.

Description

COPYRIGHT NOTICE

A portion of the disclosure recited in the specification contains material which is subject to copyright protection. Specifically, a Microfiche Appendix in accordance with 37 CFR Section 1.96 is included that lists source code instructions for a process by which the present invention is practiced in a computer system. The Microfiche Appendix comprises 13 sheets of microfiche containing 377 frames, or pages, of source code. The copyright owner has no objection to the facsimile reproduction of the specification as filed in the Patent and Trademark Office. Otherwise all copyright rights are reserved.

BACKGROUND OF THE INVENTION

This invention relates in general to data processing in networked computers and, more specifically, to an object-oriented approach for handling digital information in large distributed networks such as an Intranet or the Internet.

The evolution of computer systems and computer networks is one of accelerating growth. Individual computer systems are equipped with vast amounts of storage and tremendous processing power. Even as these computing resources have increased, the physical size of the systems has decreased, along with the cost of such systems, so that the number of computer systems has grown dramatically.

Not only has the number of computer systems increased at an astounding rate, but improvements in telecommunications have contributed to making massive worldwide networks such as the Internet a reality. However, these advances in computer systems and computer network technology make an overwhelming amount of information available. So much so that it is difficult for a user to extract desired information from the network or to be able to efficiently use the network to accomplish many tasks. Although the Internet has made it very easy to both publish information as well as access it through content servers and browsers, respectively, this opportunity has given rise to thousands of information publishers and millions of information consumers.

This phenomenal growth is making it increasingly difficult for an information consumer to hook up with the publishers that are of interest. A second problem is that the continuous exchange of information in the form of data or algorithms between the myriad types of computer systems, or platforms, which are foreign to one another and mutually incompatible, means that a user of the Internet needs to be aware of compatibility issues such as which types of applications run on which platform, what data formats can be used with which applications, etc. A third problem with the Internet is that, although computer systems have acquired resources to be able to run very large, resource-intensive application programs, this type of "fat" resident application, or client, on a user's machine does not fit today's Internet paradigm where restricted bandwidth makes it impractical to transfer large amounts of data or programs. Also, the shear volume of information and number of users means that stored space on the various server computers making up the Internet, and used to perform routing of information on the Internet, is at a premium.

Brute-force "keyword" search engines already prove incapable of effectively solving the problems of the Internet. A whole plethora of "push" technologies is emerging that is attempting to provide solutions to this problem within some spectrums. A few "publish-subscribe" solutions exist, but these demand a fair amount of infrastructure at both the publisher and consumer ends. Each of the shortcomings of these approaches is discussed in turn.

Keyword Search

An example of the inefficient data search and retrieval of the popular keyword search engines is illustrated by the following example of performing a simple search to locate job candidates.

Assume, as was done in an actual test case, that the user of a computer system on the Internet wants to locate and hire computer programmers. Using traditional Internet search technology, the user might go to a website such as AltaVista, Yahoo!, HotBot, etc., and enter a search query for "programmer available." This search on AltaVista in February 1998, produced 166 documents matching the query. However, the vast majority of these documents are useless in accomplishing the goal of finding a job candidate. For example, many of the documents are outdated. Other of the documents merely use the phrase "programmer available" in ways other than to identify an actual job candidate. Some of the documents are from "dead" links which no longer exist and are inaccessible. Many of the documents were duplicate documents resulting from peculiarities in the way the database is compiled and maintained.

Many of the documents in the search results would not be useful even if they identified an available programmer candidate. This is because the candidates are from different places in the world and many of the documents are old, meaning the programmers are probably not available anymore or have moved. Of course, the search can be refined by adding additional keywords, such as the specific type of programming language skill desired, region, restricting the documents to a specific timeframe, etc. However, since the only tool available to the user to refine the search is to add keywords, or to place relational conditions on the keywords, a second full-text search of the entirety of documents on the Internet would yield many of the same problems as in the previous search, along with new problems introduced by unpredictable uses of the additional or modified text phrases in the free-form format of documents on the Internet.

Another limitation with the full-text search engines available on the Internet today is that much of the information on the Internet exists in "dynamic" web pages which are created in response to specific one-time requests or actions by human users or automated signals. Even the so-called "static" web pages are updated frequently, or are left on the Internet long after they cease to be supported or cease to be valid or relevant. Since the search engines compile a database based on "robots" or "spiders" visiting sites on the Internet at repeated time intervals many of their results are unrepeatable or outdated and invalid. Also, the spiders are not able to discover all possible web pages such as pages that might be included in a resume database that is not published in the form of one web page per resume. Still further problems exist with keyword search engines in that use of the text language is not fully standardized. An example of this is that many people use the spelling "programers" instead of "programmers" with two `m`s.

The second problem with the Internet, that of compatibility issues between platforms, programs and data types, is encountered by a user of today's Internet whenever a user tries to obtain software, and sometimes data, from the Internet. Although the Internet has provided a wealth of commercial (and free) software, utilities, tools, etc., much of this software requires a great deal of effort the part of the user to get it running correctly, or is of little or no value because of incompatibility problems that must be solved at the user's time and expense.

For example, when a user downloads a piece of software, they must know about their computer, operating system, compression/decompression utility required, etc. in order to determine whether the software being downloaded is going to be usable in the first place. Keeping track of proper versions of the software and utilities further complicates matters. This is especially true when the software obtained is designed to work with data of a certain type, such as where the software is used to access multimedia files of a certain provider's format, is a new driver for hardware from a specific manufacturer, etc. This makes it difficult for would-be manufacturers of third party "value-added" utilities to produce software that can be used with other software, data or hardware made by another manufacture. Thus, although today's Internet is successful in making available a plethora of software, utilities, tools, drivers and other useful programs; and can usually adequately deliver the software to a user, it fails in providing a uniform and a seamless environment that eliminates significant compatibility problems essential to allowing a user to easily obtain added functionality.

The third shortcoming of the Internet is the relatively poor ability of the Internet to download large amounts of digital information which make up the data and programs of interest to a user. Today, because of improvements in storage capacity and processing power, a typical user runs applications that are resource-intensive and thus require large amounts of data and large programs to manipulate the data. For example, it is not unusual for a user to download a demonstration program on the order of 10 to 20 megabytes. Such a download through a 28.8 k bit/sec. modem might take 3-6 hours depending on the speed of the user's overall connection to the Internet, server overload, number of server "hops" to connect with the download server, etc. Thus, although the trend in computer systems has been toward larger-and-larger application programs which manipulate huge data structures, this trend is incompatible with a network such as the Internet which is rather limited in the speed with which it can handle the demands of the many millions of users trying to utilize it.

"Push"

The approach of finding out what information a user desires and "pushing" this information to the user by sending it over the network to the user's computer from time-to-time is epitomized by the application PointCast, available at http://www.pointcast.com/. The application program requires the user to specify areas of interest such as categories of news (e.g., politics, business, movies, etc.), specific sports teams, stocks, horoscope, etc. The user's interests are then recorded at a Pointcast server site. Periodically the user is sent, or "pushed," the specific information from PointCast's server site to the user's computer. The information is compiled and maintained by PointCast although other companies may be involved.

Although "push" technology such as PointCast has the advantage that the user can be updated automatically about specific categories of information, this approach is not very flexible and does not provide much improvement in obtaining information other than providing a tailored version of the daily newspaper. Drawbacks with "push" technology include the inability of the user to specify arbitrary information--the user must pick from a list; there is no mechanism for the user to obtain information from outside of the "push" provider's server site, and the user cannot upload the user's own information for distribution.

"Push" technology provides uniformity across platforms and data types but it does so only by limiting the user to a single application front end and to information controlled by a single main entity. In this sense, "push" technology thwarts the usefulness of a universal interactive network like the Internet and transforms it into a non-interactive traditional information model, such as radio or television.

Because the pushed information comes from a server or servers controlled by a single entity, push technology fails to create a standardized market for information object, information processing products and information services. Instead, the push approach pits different push providers against each other for user share. The push approach, unlike the Internet paradigm, is not an open approach and, in fact, is contrary to what many view as the exciting and valuable qualities of the Internet.

Publish-Subscribe

The Publish-Subscribe approach provides a more powerful information exchange system than the "push" approach. The Publish-Subscribe approach allows a user, in a similar manner to the "push" approach, to specify the type of information to which the user wishes to subscribe. However, the user is not strictly limited to categories presented by an application program front-end. Rather, a typical Publish-Subscribe approach allows a user to specify more general types of information such as by using a plain-text subject description.

In a Publish-Subscribe network, publishers provide information that is freely available for all users. Publishers can make any generalized type of information available and identify such information by a mechanism such as the "subject" line. With publishers publishing information and identifying the information by subject, and subscribers subscribing to information identified by subject, processes within the Publish-Subscribe network perform the task of matching up the subscription requests with the available published information and setting up resources in the form of, for example, "channels," so that the transfer of information can take place. However, Publish-Subscribe has been successful only in relatively small, proprietary networks where the publishers and subscribers are aware of the types of information in the network and agree on how to identify the information. Since Publish-Subscribe is limited in how the types of information are specified, as by plain-text, for example, a subject header ensuring that a proper match takes place introduces problems similar to those discussed above with the keyword search engines. So far, the Publish-Subscribe approach has failed to be scaled up to be suitable for larger, more generalized networks such as a large Intranet or the Internet because the Publish-Subscribe model fails to provide efficient mechanisms allowing simple and versatile unrestricted data subscriptions and efficient, organized and robust distribution of information.

Further, Publish-Subscribe technology relies on custom front-ends that have specific features designed by a single manufacturer. For this reason, Publish-Subscribe technology limits the user in the types of information, and distribution of information, that are possible. Similar to "push" technology, Publish-Subscribe does not provide an "open" information architecture allowing unrelated commercial entities to provide information items, information processing products and information services in a compatible and mutually beneficial manner.

Prior Art Information Processing Models

FIG. 2A shows the prior art models for information processing in networked computer systems.

In FIG. 2A, conventional distributed client/server applications and their manner of processing data are illustrated in diagram form. The execution of a "singleton" application is shown at 160. This represents an application program executing on the user's local computer, such as a desktop computer where almost all of the data and executed instructions reside on the user's computer. The application program has a large amount of data associated with it and typically performs all of its processing on the local data, which may be copies of remote data. The computer is hooked up to a network represented by lines 162. The network, in the singleton application case, is used only to access a common database 163 that might be shared among several uses as, for example, in a workgroup. An example of a singleton application is a database program such as would be common in the late 1980s. The common database 163 can be modified by various database application programs executing at the various user computers. Such updates or modifications are typically made through a limited set of commands such as Get/Set illustrated at 164. Data can also be routed through routing hardware 178 to remote data store servers such as 182 via additional network connections such as 180.

Later models of information processing make more use of the network so that more data can be present at remote locations. As shown at 170 the evolved model has a user operating a client at a local computer, or workstation, as before. However, much of the data 173 now resides in a remote location as, for example, at the user's server. Communication with the server (not shown) is via a local network such as an Ethernet, indicated by line 172. Naturally, various copies of data will exist and some copies of the data will necessarily exist at the user's desktop or workstation such as in the user's random access memory (RAM), cache memory or disk, in local files that the user may have designated or that may be automatically created by the client application. However, the model from the user's and the client's point of view is that remote data is being accessed.

Get/Set operations 174 can be performed on the data 173. The data is often obtained from, and synchronized with, other remote databases through one or more networks and associated routing hardware, indicated by networks 176 and 180, routing hardware 178 and remote data store server 182. Additional networks and servers can be used to transfer data to and from the user's local server database as indicated by additional network 184 and data store server 186.

Note that a property of the approaches shown in FIG. 2A is that the processing entity, namely the clients 190 and 192, resides in the user's local computer system. Also, as is typical with traditional information processing models, each client is specific and dedicated to processing data of certain types and to performing specific limited tasks. In other words, the dozens of processing applications created by different software manufacturers are incompatible with each other in that they cannot, without considerable effort, be made to process a data structure created by a foreign application program.

From the above discussion, it is apparent that a system that provides for data searching and manipulation on the Internet in an efficient, effective and intuitive manner would be most welcome. The system should provide an environment and architecture that is adaptable for different applications and customizable by information providers and consumers to suit the many types of commercial, recreational, educational and other uses that the Internet fulfills. The system should also operate uniformly across the various computer platforms connected to the Internet and so provide a basis for uniform development of algorithms, or computer programs, to make feasible a third-party value-added market for the Internet. Finally, the system should operate efficiently within the boundaries of the Internet's limited bandwidth so as to make today's Internet a truly valuable resource.

SUMMARY OF THE INVENTION

The invention provides a user interface to a system for handling information objects. The interface allows a user to make a request for information in the form of a one-time query or a persistent query. With the one-time query, the user defines one or more conditions in terms of attributes and values. The appropriate classes of objects are checked and any matching objects are identified as satisfying the query. A persistent query allows such a condition to be active at all times so that when one or more objects are created that satisfy the condition, those objects are identified as meeting the condition.

Other features of the user interface allow the user to define objects and publish objects. Objects can be created or edited based on a class whose attributes are inherited. A predefined selection of menu options makes creating, editing and publishing objects simple and efficient. Access controls and settings are provided to control rights to created objects.

One embodiment of the invention provides a method for providing a data browser user interface. The data browser user interface executes on a first computer system. The first computer system includes a processor coupled to a memory, a display device and a user input device. The computer system is further coupled to a computer network including a plurality of interconnected computer systems. A plurality of information objects that are instances of class definitions resides in the computer systems. The class definitions include attribute/value pairs.

The method comprising steps of displaying one or more information objects; accepting signals from the user input device to select an information object, the information object being associated with at least one provider process executing on a computer system in the network; showing one or more of the attribute/value pairs of the selected information object; accepting signals from the user input device to make a relational condition based on the attribute/value pairs of the selected information object; transferring the relational condition, an identifier for the selected information object and an identifier for the first computer system to one or more computers in the network; and when the relational condition is satisfied by one or more information objects in the network, receiving and displaying at least a portion of an information object that satisfies the relational condition.

The user interface operates within an overall system architecture and protocol that uses a Network Addressable Semantically Interpretable Byte-Set (NASIB). A NASIB is defined as any series of bytes that can be semantically interpreted by a pre-existing algorithm given sufficient context. A NASIB by this definition could thus be a traditional data structure or even an algorithm. The human client in a traditional client/server paradigm becomes another NASIB process with a higher degree of foreign (may be human) interactivity than other servers. All processing is then viewed as a distributed task whose completion involves transfer and consumption of relevant NASIB across processes in response to voluntary accesses as well as involuntary distribution. Each process and its NASIB are uniquely addressable and fetchable across connected networks (an example of such a WAN would be the Internet or a company Intranet).

However to achieve this goal the architecture employs a plethora of unique concepts, apparatus and mechanisms:

1. Encapsulating each information unit is a unique specification system using various types of Network Addressable Semantically Interpretable Byte-Sets (NASIBs).

2. NASIB style processing involves movement of objects and consumption of resources. Processes that participate in such processing are called NASIBs processes.

NASIBs have the intrinsic property of being network addressable and serializable.

Any processing entity is network addressable if it can be made available to any requesting algorithm residing on a distributed connected network based on its name, which could be a simple string value or a number identifier. The name in this case needs to contain at least the following two components:

Network Process Identifier: A substring which when handed to an appropriate protocol handler can provide the means to route data packets to that specific process and communication port as identified by the name within the combined name space of the distributed network.

Process Name Space Identifier: A substring which when handed to an appropriate process can provide the means to retrieve a specific set of bytes as identified by this name within the combined name space of that process.

Any processing entity is serializable if, within the same language framework, any of its instances can be converted into a string of bytes that can be stored as an instance of just one underlying language data type and, further, can be recreated back from this one instance to an entity of the original type.

Formal means of encapsulating the state of a NASIB and interacting with it through state-based Equivalency Events and Event Interest Requests (interest in an equivalency).

External Subsystems:

3. Transport and persistence implementations in each NASIB process are looked upon as external subsystems with generic parameterization and switchability being possible. Any physical implementation of a NASIB server usually would possess at least the following external subsystems.

4. Ability to be network addressable as an "outer algorithm."

5. Ability to serve and store any arbitrary byte sets, once identified, within its name space.

6. Ability to garbage collect its content and archive it for later contextual recall based on some predefined policies.

7. Ability to persist and re-create its complete execution state and/or data state to a permanent computer data medium using direct or indirect means.

Pure Data Source/Sink processes, i.e., performing only publishing or providing generic retrieve capabilities are also seen as external to the system. Anyone who can facilitate a byte buffer following a predefined format on a recognizable transport can become a publisher or retriever.

All communications between processes follows four request-reply messaging paradigms, each differentiated from the others on the basis of the life cycle of the transport task:

8. Synchronous Request: Requesting process transmits request message set and waits for reply message set, the transport task expires when a successful or unsuccessful request is sent back from the serving process. No trace of the request or reply is left.

9. Asynchronous Request: Requesting process transmits request message set, sets up a callback rendezvous algorithm and then continues with processing. The transport task expires when a successful or unsuccessful request message set is sent back from the serving process using what is available, until such time the request is cached. The waiting algorithm on the requesting process is then activated. No trace of the request or reply is then left.

10. Asynchronous Cached Request: Requesting process transmits request message set, sets up a callback rendezvous algorithm and then continues with processing. The transport task is persisted by the serving process until the expiration of the cache specification. The cache specification can be in two units.

11. Quality and Quantity of Reply Specification Set

12. Relative or Absolute Time Specification and one push request paradigm.

13. Broadcast Request: Requesting process broadcasts request message sets to one or multiple receivers. Successful transmission (and optional acknowledgement) of the request is considered to be the expiration of the transport task.

Implementation System Assumptions

The logical design of a NASIB server can be implemented in multiple hardware and software systems and in combinations thereof. The logical design is not closely tied to any specific piece of hardware or software. However implementations of such systems assumes certain well-published advances in software technologies representing necessary syntactic or semantic capabilities:

Dynamic Algorithmic Linking: Ability to incorporate new algorithms into virtual address space at run-time.

Basic Polymorphism: Provide basic polymorphism in various types.

Network Socket Interfaces: Provide basic network interfaces and link abstractions, such as sockets for interprocess communications.

Multi-Threading: Ability to run independently schedulable multiple threads of execution in one process which can access the same virtual address space. Also, related synchronization mechanisms like locking are assumed.

Serialization: Capability to serialize a memory object into a persistable string of bytes and vice versa.

Many commercial data languages meet all these requirements; for example, C++, JAVA.

Utility of the Invention

As mentioned earlier, networking technologies have made possible seamless communication between distributed processes running on disparate stations (operating system and CPU), connected through physical or virtual transport schemes. Such networks result in network data streams composed of data structures and algorithms associated with each other through external application semantics. The user picks the necessary applications and then manipulates data in the same process or in a remote process. The invention has multiple applications in multiple application domains, some of which have existed for over two years and some which have become evident only recently, like the Internet and World Wide Web (WWW):

A distributed framework for separation of data structures, algorithms and the association between them.

Specifying a means of dissecting the global name space of knowledge into knowledge domains where all interacting parties agree upon the common nature of data structures, algorithms and their associations. Chaining such domains together creates a unified network wide knowledge domain.

Specifying a canonical description system for self-describing network messages (chunks of raw transport packets) which make it possible for the messages to carry data structures and algorithms anywhere over a connected network.

Facilitating a singular network communication protocol for the meaningful transmission of these canonical messages between NASIBs-aware processes.

Facilitating creation of knowledge domain manager processes (NASIB servers) that provide services built around this canonical knowledge system to knowledge-access applications (NASIB clients).

Service applications built using NASIB architecture to provide the following basic utilities:

Ability to delineate and hook up with an external data structure and algorithm stream.

Ability to selectively call up any global data structure and algorithm and meaningfully manipulate or execute them.

Ability to facilitate changes in data definitions and values to be automatically propagated across all relevant components of the system, by providing for a default-system-enforced synchronization policy.

Multiprocessing virtual address spaces, involving selective memory synchronizations.

Because of the store and forward nature and dynamically mutable characteristics of the system, it is an ideal framework for structured communication applications like Typed Messaging and Structured Workflow. (See FIG. 3.)

An important goal of the NASIB System is to facilitate a singular or limited suite of computer applications, providing a global data structure and algorithm browsing and hosting mechanisms. Presumably, using such an application and employing such a protocol a user can browse and execute data structures and algorithms and combinations thereof (indirectly representing discrete forms of the original applications) to selectively and meaningfully interact with any knowledge domain on the network, a prime example of that being the WWW.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A shows the architecture of a large computer network such as the Internet;

FIG. 1B shows a typical computer such as would be operated by a user on the Internet;

FIG. 1C shows subsystems of the computer of FIG. 1B;

FIG. 2A shows the prior art models for information processing in networked computer systems;

FIG. 2B shows a symbolic diagram of the information processing of the present invention;

FIG. 3 shows a diagram illustrating five basic processing entities upon which the system of the present invention is built;

FIG. 4 is a diagram showing the data place hierarchy based around a root data place;

FIG. 5 shows the five types of components always maintained by a data place;

FIG. 6 shows tables shared among data places;

FIG. 7 shows relationships between tables in diagram form;

FIG. 8 shows a first user interface display;

FIG. 9 shows a second user interface display;

FIG. 10 shows a third user interface display;

FIG. 11 shows a fourth user interface display;

FIG. 12 shows a fifth user interface display;

FIG. 13 shows a sixth user interface display;

FIG. 14A shows a seventh user interface display;

FIG. 14B shows a eighth user interface display; and

FIG. 14C shows a ninth user interface display.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

FIG. 1A shows the architecture of a large computer network such as the Internet. Although the present invention is most often discussed herein with respect to the Internet, it will be readily apparent that the invention can be adapted to any 2 network or system for exchanging data among multiple users at multiple sites by means of communication and processing equipment such as computers. While the invention in its broadest sense is really a scheme for information handling among multiple users, the preferred embodiment is implemented as several types of processes executing on the Internet to enable a user to more effectively use the Internet.

In order to disclose the invention, background on the hardware is first presented and discussed in FIGS. 1A-C. Next, a description of the higher concepts of the information processing model are discussed. Next, more specific details and examples of how different operations are performed is discussed. Finally, a walk-through of the user interface in a "data browser" of the present invention is discussed.

Hardware

FIG. 1A shows an illustration of the Internet as a simplified diagram. In the Internet, multiple users such as USER1, USER2, and USER3, along with other USER machines, are shown. In today's paradigm, a human user typically operates a local computer system such as a desktop, workstation, etc. However, the present invention is suitable for use in user machines with very limited resources as will be shown. Also, it is common for a user to execute programs on a non-networked computer and to connect to the Internet later to exchange information with another computer over the network. As will be apparent, these variations on the users'hardware platform or mode of operation, and other variations, are compatible with the present invention. The system of the present invention can work effectively with any possible distribution of interconnected processors regardless of the specific topology, hardware and protocols used.

Returning to FIG. 1A, a user such as USER1 is connected to a server such as Server1 by a local network represented by line 102. This local network, which may be, for example, an Ethernet, is different from the Internet and is characterized by increased bandwidth and customized fast routing among the users in the group or organization attached to it. Multiple users connected to such a local network are illustrated at 104. Although the users and servers attached to the local network may be distributed over a large territory, they are referred to as "local" to each other for purposes of this document. Thus, USER1 communicates with Server1, which is USER1's local server, over local network 102.

Server1, in turn, transfers information to the Internet 106 routers over a structure known as a "backbone," indicated by line 108. The types of computers, hardware, interconnections, etc. are not critical to an understanding of the present invention. Other local servers, such as Server2, Server3 and Server4, are all connected to Internet routers 106 to collectively form the Internet 100. Each of the servers and user computers can include computer resources such as processors and memory and can transfer data among one other.

FIG. 1B shows a typical computer 10 such as would be operated by a user in the Internet. Computer 10 includes a cabinet 12 housing familiar computer components such as a processor, memory, disk drive, Compact Digital Read Only Memory (CDROM), etc. (not shown). User input devices include keyboard 16 and mouse 18. Output devices include display 20 having a display screen 22. Naturally, many other configurations of a computer system are possible. Some computer systems may have additional components to those shown in FIG. 1B while others will have fewer components. For example, server computers need not have attached input and output devices since they may only be accessed from time to time by other computers over a network. Human interaction with such a server computer can be at another computer that is equipped with input and output devices. Input and output devices exist in many variations from those shown in FIG. 1B. Displays can be liquid crystal displays (LCD), computer monitors, plasma, etc. Input devices can include a trackball, digitizing tablet, microphone, etc. In general, use of the term "input device" is intended to include all possible types of devices and ways to input information into a computer system or onto a network. Likewise the term "output device" includes all possible types of devices and ways to output information from a computer system to a human or to another machine.

The computer itself can be of varying types including laptop, notebook, palm-top, pen-top, etc. The computer may not resemble the computer of FIG. 1B as in the case where a processor is embedded into another device or appliance such as an automobile or a cellular telephone. Because of the ever-changing nature of computers and networks, the description of hardware in this specification is intended only by way of example for the purpose of illustrating the preferred embodiment. Any distributed networked system capable of executing programmed instructions is suitable for use with the present invention.

FIG. 1C shows subsystems of the computer of FIG. 1B. In FIG. 1C, subsystems within box 40 are internal to, for example, the cabinet 12 of FIG. 1B. Bus 42 is used to transfer information in the form of digital data between processor 44, memory 46, disk drive 48, CDROM drive 50, serial port 52, parallel port 54, network card 56 and graphics card 58. Many other subsystems may be included in an arbitrary computer system and some of the subsystems shown in FIG. 1C may be omitted. External devices can connect to the computer system's bus (or another bus or line, not shown) to exchange information with the subsystems in box 40. For example, devices such as keyboard 60 can communicate with processor 44 via dedicated ports and drivers (shown symbolically as a direct connection to bus 42). Mouse 62 is connected to serial port 52. Devices such as printer 64 can connect through parallel port 54. Network card 56 can connect the computer system to a network. Display 68 is updated via graphics card 58. Again, many configurations of subsystems and external devices are possible.

Concepts

As a prelude to presenting higher level concepts of the invention, an example of a specific use of invention is first discussed.

In FIG. 1A, assume that USER1 desires to make available information about job candidates. In the present invention, USER1 would do this by creating a format for presenting the information. This format is more formally called a "data definition." The dated definition specifies a sequence of fields that have names. The fields, also called "attributes," each can be associated with a date of value of a predetermined type. This is similar to records in standard databases where Name/Value pairs are defined. Once the dated definition is complete, it is given a name. The name of the data definition in the example is "Job Candidate."

The job candidate data definition can then be filled in with values according to the defined attributes to create a job candidate "instance." FIG. 1A shows job candidate instance 110 identifying a specific job candidate. Note that job candidate instance 110 has attribute names on the left side of the rose and attribute values at the right side of the rose. The required types for each name/value pair are not shown in job candidate instance 110 but, for example, the attribute name "first name" assumes a character or string value "Jane." The attribute name "when available" assumes a date value (which can also be a text string) of "1-1-98." Any number of instances of the job candidate data definition can be created. This has similarities to object-oriented concepts where the data definition defines a class of objects and, once values are applied to the class definition, object instances are created.

Note that job candidate instance 110 is shown residing within Server1. In the preferred embodiment, the physical location of data definitions and instances is of little importance. In practice, there will often be multiple instances of the same data definition and data object. The preferred embodiment keeps track of "ownership" of data definitions and object instances. "Data Places" are also defined so that an organized information hierarchy is achieved as discussed in more detail below. For purposes of this introductory example, we omit the discussion of such aspects of the invention as ownership, access rights, security and persistence.

Next, assume that USER2 wishes to search for job candidates. The user can locate "places" where job candidate objects reside by using traditional methods such as the key word search engine. Since the present invention works within the existing framework of world wide web (www) sites and documents on the Internet, the user may simply go to a web site of a known entity which can direct the user to desire data objects much as a user on today's Internet is directed toward desired documents or other information. USER2 performs operations to access, collect, create, modify and distribute information objects with an application front and specific to the preferred embodiment of the invention and refer to as a "data browser." The data browser operates seemlessly with today's common Internet browsers such as Netscape Navigator.TM. and MicroSoft Explorer.TM.. Once USER2 has been provided with the job candidate data definition or a job candidate instance, USER2 may make specific queries, or searches, based on the name/value pairs of the definition.

Not only can USER2, or any user for that matter, perform specific searches on job candidate instances, users may also post, or publish, their own instances of job candidate object. Regardless of where the instances physically reside, they will be searchable to anyone who has been provided with the job candidate data definition or a job candidate instance.

One may be begin to understand the power and utility of this system by noting that this scheme provides a controlled yet "open" architecture allowing information to be categorized not only by content but by knowledge of the controlling, or owning, entity.

For example, USER1 can be a job placement company or a well-known newspaper. Alternatively, USER1 may be an individual or a lesser-known company. By obtaining a data definition or instance from a known source, a user has some reassurance of reliability and quality of the information being retrieved. Also, the controlling source may charge for access, provide an infrastructure around the data or provide other value-added products and services associated with the data. Further, such value-added products and services can be provided by third parties who obtain the data definition or data instance as will become apparent in the subsequent discussion.

There can be other data definitions having the same name, "job candidates," which will not be accessed in a search based on the job candidate definition or job candidate instance 110 of FIG. 1A. Changes to a specific data definition are propagated among all instances of the data definition throughout the Internet. The ability to change access and publish to a specific data definition is controlled. Queries can be "persistent" so as to assume some of the characteristics of a publish-subscribe model. For example, USER2 may create a persistent query so that any new instances of the job candidate object showing a "when available" attribute value on or before a specific date are sent to USER2 immediately when such job candidate instances are created. Many other instances of applications of the basic concept of the invention are possible. In fact, this information processing model is so flexible that any application can be constructed within it.

FIG. 2B shows a symbolic diagram of the information processing of the present invention.

In FIG. 2B, a user 190 interacts with data and algorithms at their local computers 192 such as a workstation or desktop computer. Unlike the prior art models shown in FIG. 2A, the information processing model of the present invention allows the user's browser to access, modify, collect, and distribute both data 194 and algorithms 196. The data and algorithms can be the subject of operations such as Get/Set 198 operations, and other operations not shown but discussed below. Data and algorithms are stored throughout networks, such as the Internet, represented at 200. As discussed in detail below, the information processing model of the present invention allows data/algorithm store servers to perform matching and routing functions. The user of the model of FIG. 2B provides greatly improved functionality, flexibility and efficiency as discussed below.

Concepts of the Information Processing Model

Each information object is characterized by three basic properties. These are data place, data definition and data value. A data place is a storage area within the network. Since the network is composed of many computers having their own local storage which can be internal or external storage devices, and these computer systems and devices each have their own ways of naming areas of storage local to them, the data place is uniquely identified within a network by a concatenation, or combining, of network-wide identifiers, device identifiers, directory identifiers, filenames, etc. The Internet's "World Wide Web" (WWW) portion uses place-naming standards according to the HyperText Transfer Protocol (HTTP). With HTTP, Uniform Resource Locators (URLs) are unique identifiers and are a combination of "machine addresses" and paths within a machine to a data place. The machine addresses have "domain name" counterparts which are textual instead of numeric and are easier for users to remember. The URL provides a way to uniquely identify each datum, instruction or other item of information residing under the control of any computer or device in the Internet. Each data definition, data instance or algorithm (collectively referred to as "information objects" ) of the present invention resides in a data place on the network and can be uniquely referred to by processes of the invention.

In the system of the invention, information objects and other entities are said to be "named" when they possess either a number type unique id (optimal for matching) or a number-type symbolic name (optimal for access). The correspondence is always one-to-one. Such names are also generically called Context Assigned Differentiation Tokens or CADTs.

FIG. 3 shows diagram 220 illustrating five basic processing entities upon which the system of the present invention is built. These are Named Data Definition 224, Named Data Instance 226, Named Data Place 228, Named Data Request 230 and Named Algorithm 232. Other components such as Data Values 234 and Named Association 236 support the five basic processing entities. Intrinsic operations of the system employ these basic entities. Other data structures are either built using them or are custom in nature and external to the system.

A named data place is network addressable. Data places are named collections of data residing on a computer system or storage device that can store entities of any type and provide a distinct data input pathway and data output pathway. Data places can also be equated to network addressable subprocesses in traditional parlance. Data places play a very fundamental role in defining the system. A data place can be as small as the smallest possible contiguously addressable process on a given computer system and it cannot span multiple virtual address spaces. Within a data place references to instances of any entity are implicit. An example of a data place is a directory on a hard drive in a computer system. The data place is addressed in the Internet by using the URL format and providing a domain name to a machine, or storage space on a machine, and a path to the directory. A file is also a data place since it describes an area of storage in the network. Files are accessed using the domain name, path, and filename or file handle. Any network addressable space can be a data place.

A named data definition is network addressable. In the preferred embodiment such a definition is made up of a set of typed attributes (i.e., Name/Value pairs representing data or algorithms) including other nested data definitions. This is implemented as a language data structure comprising at least one list structure capable of storing and retrieving named variables of any of the underlying language supported types. Minimum implementation of the data definition should provide the features shown in Table I, below.

    TABLE I
    Data Place Name String representing symbolic name of the
                    owner data place.
                    (CADT in name space of data places)
    Data Definition String representing symbolic name of the
    Name            data definition.
                    (Unique in the name space of the owning data place)
    Ver #           Incrementally assigned for differing mutations of same
                    data definition in holding data place)
                    (CADT in the name space of the owning data place
                    and data definition)
    System Modifier Activation Status. (More)
    Flags
    Host Algorithm.sub.1  Arbitrarily associated algorithm.
    . . .           . . .
    Host Algorithm.sub.n  Arbitrarily associated algorithm.
    Instance Name   Incrementally assigned for differing instances of
                    same data definition in holding owning space.
    Attribute Order (CADT in the name space of the holding data place
    Number.sub.0    and data definition)
    Attribute Order Type  Name  Value System Modifier
    Number.sub.1                      Flags (32 Bits)
    . . .           . . . . . . . . . . . .
    Attribute Order Type  Name  Value System Modifier
    Number.sub.n                      Flags 932 Bits)
    User Space

    TABLE II
    Data Place Name String representing symbolic name of the
                    owner data place.
                    (CADT in name space of data pieces)
    Data Definition String representing symbolic name of the
                    data definition.
    Name            (Unique in the name space of the owning data place)
    Ver #           Incrementally assigned for differing mutations of same
                    data definition in bolding data place.
                    (CADT in the name space of the owning data place
                    and data definition)
    System Modifier Activation Status. (More)
    Flags
    Host Algorithm.sub.1  Arbitrarily associated algorithm.
    . . .           . . .
    Host Algorithm.sub.n  Arbitrarily associated algorithm
    Instance        Typed Condition   Incrementally assigned for
    Name            Specification     differing instances of same data
    Attribute Order (Equal to         definition in holding owning
    Number.sub.0                      space.
                                      (CADT in the name space of the
                                      holding data place and data
                                      definition)
    Attribute Order Type  Name    Typed Condition Value System
    Number.sub.1                                        Modifier
                                                        Flags (32
                                                        Bits)
    . . .           . . . . . .   . . .           . . . . . .
    Attribute Order Type  Name    Typed Condition Value System
    Number.sub.n                                        Modifier
                                                        Flags (32
                                                        Bits)
    User Space

                                   TABLE IIIA
                                  Data Instance
                 New/Create         Update by CADT             Delete
    Owner   Space.sub.N  Space.sub.M  Space.sub.N  Space.sub.M  Space.sub.N
     Space.sub.M
    Space.sub.N  Yes         No        Yes         No        Yes         No
            -Become     -Import   -Run        -Request  -run        -Request
            Owner       -By Data  Algorithm.sub.B  Source    Algorithm.sub.C
     Source
            -Run        State Int.             -By Data              -By Data
     State
            Algorithm.sub.A  Request               State Int.             Int.
     Request
                                              Request
                                 Data Definition


              TABLE IIIB
                  New/Create          Update by Name           Delete
    Owner   Space.sub.N  Space.sub.M  Space.sub.N  Space.sub.M  Space.sub.N
     Space.sub.M
    Space.sub.N  Yes         No          Yes         No        Yes         No
            -Become     -Explicit   -Run        -Request  -Use        -Import
            Owner       -Give Data  Algorithm.sub.E  Source    Algorithm.sub.F
     -Request
            -Run        Definition                                    Source
            Algorithm.sub.D  Synchronize

    Algorithm Sequence of Steps
    A         1.  Add Instances to definition-specific source state table.
              2.  Mark all changes in singleton state change table.
              3.  Assemble all data requests as per foreign data place
                  and data definition.
              4.  Run all resultant data requests and compare previous
                  Count.sub.P and new Count.sub.N.
                  If Count.sub.N - Count.sub.P > 0 generate an Add: Data
                  Instance for the respective data place.
              5.  Factor out common data instances by data place.
              6.  Dispatch to NASIB Communicator.
    B         1.  Add Instances to definition specific source state table.
              2.  Mark all changes in singleton state change table.
              3.  Assemble all data requests as per foreign data place
                  and data definition.
              4.  Run all resultant data requests and compare previous
                  CountP and new CountN If CountN - CountP > 0 mark
                  change as a Add: Data Instance for the respective
                  data place.
              5.  Run all resultant data requests and compare previous
                  CountP and new CountN. If CountN - CountP = 0 mark
                  change as a Del: Data Instance for the respective data
                  place.
              6.  Run all resultant data requests and compare previous
                  CountP and new CountN. If CountN - CountP = 0
                  generate an Upd: Data Instance request for the
                  espective data place.
              7.  Factor out common data instances by data place.
              8.  Dispatch to NASIB Communicator.
    C         1.  Delete instance from definition-specific source
                  state table.
              2.  Mark all changes in singleton state change table.
              3.  Assemble all data requests as per data place and
                  data definition.
              4.  Run all resultant data requests and compare previous
                  CountP and new CountN. If CountN - CountP < 0
                  generate a Del: Data Instance request for the espective
                  data place.
              5.  Factor out common data instances by data place.
                  Dispatch to NASIB Communicator.
    D         1.  Assign first version number for data definition.
              2.  Create data-definition-related source state table.
    E         1.  Assign new version number for data definition.
              2.  Effect data definition change by creating new table with
                  updated version number.
              3.  Assemble list of DDSAs from foreign data places.
              4.  Generate an Upd: Data Definition request for each
                  data place.
              5.  Dispatch to NASIB Communicator.
    F         1.  Delete data-definition-related source state table.
              2.  Assemble list of DDSAs from foreign data places.
              3.  Generate a Del: Data Definition request for each
                  data place.
              4.  Dispatch to NASIB Communicator.

    TABLE VI
    Code                                Name for
    ENT                                 Entity Symbolic Name
    DOM                                 Domain Name, any name space
     segmentation
                                        identifier
    CON                                 Connection Name
    DSN                                 Data Definition Symbolic Name
    LSN                                 Algorithm Symbolic Name
    INS                                 Instance Symbolic Name
    DVS                                 Data Value Symbolic Name
    RNM                                 Request Symbolic Name
    DSP                                 Data Place Symbolic Name
    Protocol Primitive Operands        Return          NASIB Client  NASIB
     Server
                       Data Place Communicator Operations
    Connect           Domain Name     Named           Yes           Yes
                                      Connection(s)
    Disconnect        Connection Name Void
    CreateDataSpace   Data Place Name Void
                           Data Definition Operations
    NewDataDefinition Definition Name Definition Name
    GetDataDefinition Definition Name, Named           Yes           Yes
                      Association Name Definition(s)
    SetDataDefinition Definition Name Definition Name
    delDataDefinition Definition Name Void


                        TABLE VII
                     Data Instance Operations
    NewDataInstance
    GetDataInstance          Instance Name     Named
                                               Instance
    SetDataInstance          Instance Name     Instance Name
    DelInstance              Instance Name     Void
                             Request Name
                     Data Request Operations
    GetEquivalencyRequest    Request Name
                             Association Name
    SetEquivalencyRequest    Definition Name   Named Request
                             Data Value Name
                             Data Place Name
    DelEquivalencyRequest    Request Name      Void
    DoEquivalencyRequest     Request Name      Void
    SetDefaultDefSynchronizer Data Place Name   Void

• Inventors
  Garg, Suneet; Katiyar, Dinesh; Javangula, Pradeep;
• Assignee
  E.piphany, Inc. (San Mateo, CA)
• Published
  Jun-1-2004
• Current US Classes:
  707/103R
  707/3
  709/201
• Application #
  283264
• International Classes
  G06F 017/30
• Field of Search
  707/10 707/103 707/4 707/104 707/101 707/102 707/526 707/3 709/202 709/226 709/201 345/473 717/122
• Examiner
  Maung; Zarni
• Agent
  Bingham McCutchen LLP, Marino; Fabio E.
• US Patent References:
  5787418
  5835910
  5907847
  5944783
  6088698
  6112024
  6119122
  6144968
  6154776
  6205447
  6236989
  6249291
  6279005
  6279016
  6418445
  6457017
  6567846