DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

OBJECT-ORIENTED AND SEMANTICALLY-BASED UNIVERSAL MODELLING SOFTWARE FRAMEWORK

This application claims the benefit of U.S. Provisional Application No. 60/339,889, filed on December 10, 2001, and titled “’Selfsim’ Self simulation distributed agent software”, the contents of which are incorporated by reference as if fully disclosed herein.

This application also claims the benefit of U.S. Provisional Application No. 60/339,998, filed on December 10, 2001, and titled “’Simverse’ universal simulation engine software”, the contents of which are incorporated by reference as if fully disclosed herein.

This invention relates generally to object-oriented software programming and, more specifically, to a software framework for modeling and simulating the world, including natural laws and human behavior.

A long-standing goal in the computer science field is the creation of artificial intelligence agents that model human behavior. To be effective, artificial-intelligence agents need to understand the human world and how entities within it relate and interact with each other. It is also desirable for them to be able to communicate with each across multiple domains and understand the context of such communications.

Known software applications do not enable software agents to have the aforementioned understandings. Although many object-object oriented software applications, such as those based on Prolog, include software objects modeled upon real-world concepts, such objects only include the information and behavior needed for their specific application. Agents within such applications have neither a universal protocol with which to communicate with outside agents, nor a framework to understand how all entities fit and relate to each other in the universe. Therefore, they cannot interact with and learn from foreign agents and objects without manual integration.

One known framework for modeling the world is OpenCyc. The CycTechnology allows the user to build expert systems on almost any topic. However, none of the current Cyc technology products allow you to dynamically build object-oriented models of real world concepts, run simulations, and learn from the outcome.

Consequently, there is a need for a software framework that provides software agents with a standardized protocol with which to communicate across different domains and that enables agents to understand and learn about the nature of entities and the way they act or are acted upon within the world and the universe.

The present invention provides an object-oriented software framework for modeling the world, including humans and human society. The framework includes a collection of object-oriented, physically-based software classes, where each class is based on a concept that exists in the world (e.g., physical things, time, space, distance, etc.) and is associated with a natural language word, such as an English word, for that concept. The attributes, methods, and interfaces supported by a class relate to the real-world concept with which the class is associated. The software classes include a Context class that can be used as a filter to focus interactions between agents or people in a given situation.

The framework of the present invention is based upon an ontology that defines how the classes are related to each other and interact with each other. The ontology is based on natural laws and a common sense understanding of the world and universe. The classes are semantically bound together in accordance with the ontology.

The semantically-bound classes of the framework, as well their corresponding attributes, methods, and interfaces, form an object-oriented grammar which can be used as the basis for describing any entity (living or non-living), concept, or process. This object-oriented grammar is the primary means of representing knowledge within the software-simulated universe and the primary means of communication between software agents in the software-simulated universe. The object-oriented grammar provides a universal protocol which agents use to communicate with each other and understand how objects related to each other. The object-oriented grammar is also a means of communication between people and software agents.

When the framework is implemented as a software engine, it provides a software-simulated universe (referred to as the “Simverse” herein). Objects (i.e., instances of the software classes) within the software-simulated universe interact with each other in accordance with rules dictated by the object-oriented grammar.

The Simverse can be thought of as (i) a collection of software class taxonomies (where the software classes are natural-language based), (ii) software agents that create and use software objects based on the software classes, and (iii) a temporally-driven engine that tracks the passage of time. The taxonomy can be large and include numerous classes. The computer resources of a user of a framework-based application may not be able to effectively handle the entire taxonomy. Consequently, the Simverse enables the taxonomy stored on the user’s computer to dynamically grow or shrink depending on a user’s computer resources and preferences.

The present invention also provides a self-simulation software application (referred to as the “SelfSim” hereinafter), which is based on the above-described framework and which simulates a person’s life. The primary function of the SelfSim application is to determine the requirements of the person being simulated (the “host”) and to assist the host in satisfying its requirements. The SelfSim uses a model of a person to simulate the host and uses a model of a person’s requirements to determine the host requirements. The SelfSim builds upon the host’s model by monitoring the host’s application usage habits. As some of the host’s requirements will depend on the life stage of the host, the SelfSim tracks the life stages of the host in one embodiment. The SelfSim identifies strategies that will satisfy the host requirements and executes these strategies in accordance with applicable host routines.

The SelfSim is a type of meta-application in that it dynamically changes its functionality based on the contextual situation of the host and feedback from the host. Unlike traditional applications that are “start-stop” and manual in nature (i.e., the user has to launch the application, manually manipulate it (e.g., enter text in a word processor), and then exit the application), the SelfSim runs continuously in the background twenty-four hours a day, seven days a week.

Because the Simverse is based upon an ontology that reflects the real-world, the SelfSim is capable of achieving a real-world understanding of a host’s routines, activities, and possessions and the context in which they exist. Instead of running single-task oriented applications, the SelfSim continuously monitors the host’s requirement and plans ways to assist the host, dynamically reconfiguring tasks to serve the host. Consequently, the SelfSim is far more flexible and useful than traditional software applications.

Figure 1 illustrates a software framework in accordance with one embodiment of the invention.

Figure 2 illustrates a portion of an example ontology in accordance with one embodiment of the invention.

The present invention provides an object-oriented, software framework for modeling the world, including humans and human society. The invention also includes an application based on this framework for simulating a person and its life, where such application determines a person’s requirements and assists them in satisfying their requirements.

As illustrated in Figure 1, the framework 140 of the present invention is built by (i) identifying real-world concepts 110 and natural language words for such concepts, including fundamental concepts necessary to model the world; (2) creating an ontology 120 that semantically organizes and binds these concepts in a way that reflects the real world (and universe), where each node in the ontology is a natural language word representing one of the concepts, and (3) creating software classes 130 that reflect the meaning of the natural language words in the ontology, where the software classes are semantically bound and interrelate with each other in accordance with the ontology.

The framework includes a collection of object-oriented software classes. Each class is based on a concept that exists in the world (e.g., physical things, time, space, distance, etc.) and has a natural language (such as English) name that corresponds in meaning to the concept represented by the class. The attributes, methods, and interfaces (if applicable) supported by a class relate to the concept represented by the class, and, hence, reflect the meaning of the natural language name with which the class is associated. For instance, attributes of a physical container, such as a box, include boundaries (i.e., sides of the container), a compartment (i.e., the space within the container), and a three dimensional shape (e.g., a rectangular prism). Consequently, attributes of the class “ContainerPhysical” might include “boundaries,” “compartment,” and “three dimensional shape.” A method associated with the ContainerPhysical class could be one that calculates and returns the volume of the physical container, and an interface implemented by the ContainerPhysical class could be one that indicates that a physical container has a physical location (e.g., on desk, in room).

All known phenomena in the universe can be categorized into a relatively small group of fundamental concepts, such as physical things, space, time, distance, agents, and actions. For each of such fundamental concepts, the framework includes a software class that corresponds to such concept. The concepts represented in the framework can (and do in the preferred embodiment) extend beyond such fundamental concepts, but the classes representing the additional concepts are subclasses of the classes representing the fundamental concepts. For instance, the class ContainerPhysical might be a subclass of a class called ThingPhysical.

In one embodiment, the software classes in the framework are Java-language classes, but other object-oriented languages, such as C++, could be used. The term “interfaces” used above and throughout the application is a term from the Java programming language. However, this invention is not limited to a Java implementation, and those skilled in the art will appreciate that the concepts represented by “interfaces” in Java can be represented in other ways in other object-oriented programming languages.

Having classes that represent concepts in the world is not enough to model the world. The classes (and instances of the classes) must relate and interact with each other in a manner that reflects the real world. In other words, the classes must relate and interact with each other in the same way that the real-world concepts that the classes represent do.

The framework of the present invention incorporates an ontology that organizes and binds together real-world concepts in a manner that reflects the real world (and universe). The ontology is based on natural laws and a common sense understanding of the world and universe, and it defines how the classes are related to each other and interact with each other. Each of the classes in the framework represents one of the real-world concepts in the ontology, and the classes are semantically bound together in accordance with the ontology. The semantically-bound classes of the framework, as well their corresponding attributes, methods, and interfaces, form an object-oriented grammar which can be used as the basis for describing any entity (living or non-living), concept, or action.

The ontology is based on the theory that all phenomena in the universe can be broken down into a defined number of fundamental concepts. The top level of the ontology includes these fundamental concepts, and everything else is categorized under these fundamental concepts. In the other words, the ontology is hierarchical, with the most fundamental, high-level concepts at the top and the most specific, low-level concepts at the bottom. Thus, the ontology enables software agents within the framework to understand the nature of things because they can learn that that a particular, specific thing is a type of larger fundamental concept. The ontology provides the software agents with the ability to understand and dynamically generate inferences about real world objects, abstract concepts, actions, and relationships.

Figure 2 illustrates a portion of an example ontology. In this example, “space,” “physical things,” “time,” and “distance” are fundamental concepts 210 in the ontology. The ontology specifies that “Container” is a type of “Physical Thing” and that it includes “Physical Space,” which in turn can include “Physical Things.” Similarly, it specifies that “kilometer” and “centimeter” are “Distance Types” which relate to “Distance.”

As stated above, the semantically-bound classes of the framework, as well their corresponding attributes, methods, and interfaces, form an object-oriented grammar which can be used as the basis for describing any entity (living or non-living), concept, or action. This object-oriented grammar is the primary means of representing knowledge within the software-simulated universe and the primary means of communication between software agents in the software-simulated universe. The object-oriented grammar provides a universal protocol with which software agents can communicate and understand other objects, enabling the software agents to communicate across multiple applications and domains. As all knowledge is represented within this universal, semantically-based grammar, all agents can learn from and use the knowledge. The object-oriented grammar is also a means of communication between people and software agents.

The software classes in the framework (e.g., the Thing classes and subclasses in the below example) are the nouns in the object-oriented grammar. The attributes of a software class are object-oriented adjectives of the concept modeled by the software class, as an adjective is a word that expresses an attribute of something. This is the case even though the value of the attribute is an instance of a software class that is an object-oriented noun (e.g., “volume” can be an attribute of a physical thing, even though “volume” is a noun). Also, a state of a software object is as an object-oriented adjective, such as open, alive, heavy, light, small, and large. With respect to states such as light, heavy, small, and large that have meaning only relative to another object (e.g., a feather is light relative to a person, but heavy relative to a flea), the methods for obtaining such states would expect a “relative to” argument that would specify such other object.

The action methods (e.g., move, put, attach, use) in the framework are object-oriented verbs. Some of the arguments that an action method takes can be thought of as object-oriented adverbs or prepositions. An argument that tells the method how the object of the action relates to another argument of the method (e.g. put cat in bag) is an object-oriented preposition, and an argument that tells the method how to perform the action (e.g., quickly, slowly, lightly) is an object-oriented adverb (e.g., put cat in bag quickly). In one embodiment, the framework includes a Preposition class and an Adverb class, in which specific types of prepositions and adverbs are subclasses of these respective classes. In this embodiment, the object-oriented grammar specifies that the arguments received by some of the action methods are of the type Preposition and Adverb (e.g., put (ThingPhysical, Preposition, ThingPhysical, Adverb).

Through subclassing and combining the various object-oriented grammar elements, more complex classes can be created, such as Adjective Demonstrative, Distributive, and Interrogative.

As the meaning of interactions between agents or people often depends on the context in which they interact, the framework includes a Context class to represent the concept of a context. A Context (i.e., an instance of the Context class) can be used as a filter to focus interactions between agents or people in a given situation.

In one embodiment, a Context is a taxonomy of classes relating to a particular activity. For instance, as illustrated in Figure 3, a “Chess” Context 310 can be represented as a taxonomy of classes relating to the game of chess, such as Chess Board 320, Chess Rules 330, Chess Pieces 340, and Chess Players 350.

In the illustrated embodiment, the Chess Context 310 is a subclass of the Context class, which is a subclass of the Taxonomy class 370 because a Context is a type of taxonomy (note: in accordance with standard Unified Modeling Language (UML), the white arrowheads indicate subclasses). The class TaxonNode 410 is related to the concept of taxonomies and is discussed in more detail below.

Natural laws can be built into the framework classes and used to automatically generate attribute values. E=mc² is an example of a natural law, where “m” is mass and “c” is the speed of light, which is a constant. A Mass class representing the concept of mass (i.e., “the property of a body that causes it to have weight in a gravitational field,” as defined in WordNet 1.6) can include a method that automatically calculates the energy of a thing having mass once its mass is known. Other laws and rules can also be built into classes and used to automatically generate attribute values.

When the framework is implemented as a software engine, it provides a software-simulated universe (referred to as the “Simverse” herein). The Simverse includes (i) the above-described, natural-language-based software classes representing real-world concepts, where such classes are organized in accordance with the ontology as a collection of software class taxonomies; (ii) software agents that perform functions and create, use, and interact with software objects that are based on the software classes; and (iii)a temporally-driven engine that tracks the passage of time within the Simverse. The software agents and the temporally-driven engine are also instances of the software classes within the Simverse.

Objects (i.e., instances of the software classes) within the Simverse can interact with each other in accordance with rules dictated by the object-oriented grammar. Because of the ontology incorporated into the Simverse, software agents within the Simverse understand how Objects related to each other. For instance, a software agent representing a person will understand that a physical container is a physical thing in which other physical things can be placed. Because a software agent representing a person will include or inherit methods that enable the agent to perform actions, the action of a person placing a physical object in a container can be simulated.

The Simverse can dynamically build models and simulations when linked to a knowledge base such as OpenCyc. By querying for things with attribute that have a temporal component, it can build models and then run simulations on them. By observing the results of the simulations, the Simverse can draw brand new interferences that may not exist in the knowledge base.

Knowledge bases traditionally have rules inserted by hand. Interference engines can draw conclusions from the knowledge base, but the potential links already have to be there for them to be discovered. By dynamically building models, running simulations on the temporal components of such models, and observing the results, the Simverse can discover completely new rules. This is not possible with existing common knowledge bases built with declarative languages, as they do not run simulations.

Figures 6a-c illustrate an example implementation of the framework of the present invention. The classes and ontology associated with this framework reflect only one way in which the framework can be implemented, and those skilled in the art will appreciate that the universe can be modeled by using a different ontology and set of classes.

The example implementation below uses Java classes, and, consequently, the discussion of this implementation uses some Java terminology (e.g., “interfaces”). However, as stated above, this is done for the purpose of example and the invention is not limited to a Java implementation. Furthermore, the term “linked list” is sometimes used below to refer to a collection of items, but this also is intended only as an example of a way to represent a collection of items, as there are other ways to represent collections in object-oriented programming languages.

Everything in the example framework is a subclass of the Thing class 605. The Thing class has two attributes: “name” and “taxonNode.” The value of the “name” attribute is the name of that instance of the Thing class. The value of the Thing.taxonNode attribute is an instance of the TaxonNode class, which is described in more detail below.

The framework can be thought of as a collection of software class taxonomies, where each class in the framework is a node in one of the taxonomies. The taxonomies can be large as they can include a large number of classes. The computer resources of a user of an application based on the framework may not be able to effectively handle all the taxonomies in their entirety. The TaxonNode class enables portions of the taxonomies to be stored on the user’s computer while still enabling the application to access the entire taxonomy tree if needed. The taxonomies stored on the user’s computer can dynamically grow or shrink depending on a user’s computer resources and preferences, and the applicable attribute values in TaxonNodes are modified as the taxonomy changes.

As illustrated in Figure 4, an instance of the TaxonNode class 410 includes information about a subject class’ parent class, child classes (i.e. subclasses), and sibling classes, as well as the subject class’ position within the taxonomy relative to the root node. This information reflects the taxonomy stored on the applicable host computer (the “local taxonomy”), not the overall taxonomy implemented in the Simverse. The attributes of the TaxonNode class include “Thing,” “taxonRoot,” “taxonParent,” “taxonChildren” “taxonSiblings,” “taxonServiceURL,” “taxonBranch,” and “host resources.” The value of the “Thing” attribute is the software class to which the TaxonNode corresponds. The value of the taxonRoot attribute is the TaxonNode that corresponds to the root class in the local taxonomy, and the value of the “taxonParent” attribute is the TaxonNode that corresponds to the parent class of the subject class in the local taxonomy. If there is no parent class, this attribute is set to the null value. The values of the “taxonChildren” and “taxonSiblings” attributes are a collection of TaxonNodes that correspond to the subclasses and sibling classes, respectively, of the subject class in the local taxonomy. If a class does not have subclasses or sibling classes in the local taxonomy, then these attributes are set to the null value, as applicable.

The value of “taxonServiceURL” attribute is a link to where the taxonomy service for this taxonomy resides. In other words, this is a link to the entire “unabridged” taxonomy upon which the local taxonomy is based. This feature allows the Simverse to easily be distributed over multiple computers. The value of the “taxonBranch” attribute is a linked list of TaxonNodes from the root of the local taxonomy to the subject node.

The value of the “host resources” attribute is an instance of the Computer class 420 that tracks the user’s computer resources, such as the CPU speed and the amount of ROM and RAM. A Simverse application (such as the SelfSim application described below) uses the information about the host’s computer resources to manage and load-balance the local taxonomy stored on a host’s computer. The more computer power a host computer has, the larger the taxonomy that can be stored on the host computer. In one embodiment, before a taxonomy is downloaded onto a host computer, the taxonNode that will be the “parent” node in the downloaded taxonomy, retrieves the value of the hostResources attribute.

If host computer resources are limited, the taxonomy will be “pruned” to fit, depending on application and context. Each node that is deemed to be a “leaf” node in the pruned tree (i.e., a childless node in the local taxonomy) has the taxonChildren attribute set to the null value and has the taxonServiceURL attribute set to the location of the taxonomy service for that node. This non-null value for the taxonServiceURL attribute serves as a marker that the “true” tree extends beyond this node and can be discovered through the taxonomy service offered at the URL.

Figure 5 illustrate an example of how a Simverse application, such as the SelfSim application described below, uses the TaxonNode class. In this example, the host (i.e., the user) indicates that he would like to learn how to care for an aquatic frog. The Simverse application determines 510 whether the model of an aquatic frog (the “FrogAquatic model”) is in the local taxonomy. The FrogAquatic model includes the FrogAquatic class and any classes used by the FrogAquatic class. If the FrogAquatic model is in the local taxonomy, the application retrieves 520 the FrogAquatic Model and presents 530 an indication of it to the host. The host can now use the FrogAquatic model to create a “FrogSim,” which is like the SelfSim application described below, except that it simulates a frog’s life instead of a host’s life. The FrogSim can educate the host about aquatic frogs and remind the host when it is time to feed the frog, replace its water, clean its tank, etc.

If the FrogAquatic model is not in the local taxonomy, the Simverse application first searches 540 the full taxonomy upon which the local taxonomy is based, and if the model is not found there it, searches 540 the Internet for it. If it cannot find it, it notifies 550 the host that the FrogAquatic model was not found. In the illustrated example, the Simverse application finds the FrogAquatic model on the Internet. In such case (or if found in the full taxonomy), it downloads 560 it and adds it to the local taxonomy if there are sufficient resources. Specifically, assuming a “Frog” class exists in the local taxonomy, the application alters the TaxonNode of the Frog class to reflect that the FrogAquatic class is a subclass of the Frog class. In other words, the Simverse application alters the linked list associated with the Frog.taxonNode.children attribute to include FrogAquatic.taxonNode (i.e., the TaxonNode that corresponds to the FrogAquatic class). In addition, as indicated in Figure 5, the application alters the TaxonNode of the FrogAquatic model (i.e., FrogAquatic.taxonNode) to reflect that that the Frog class is the parent of the FrogAquatic class. If FrogAquatic class has any sibling classes in the local taxonomy, then the application sets the value of FrogAquatic.taxonNode.siblings to a link list of TaxonNodes that correspond to the sibling classes. The TaxonNodes of any such sibling classes are also altered to reflect that FrogAquatic is a sibling class. After the FrogAquatic model is downloaded, it is presented 530 to the host.

Space is the ultimate container, and it is the “space” between things that allow them to be discrete entities. The Space Class 610 is the highest abstraction of the concept of space.

Physical space is the type of space that the world inhabits in the observable universe. The SpacePhysical class 615, which is a subclass of the Space class, represents the concept of physical space, and an instance of this class would represent a particular area of physical space. Physical space has a three dimensional geometry and a volume, and it can include physical things. Consequently, attributes of the SpacePhysical class include “geometry,” “volume,” and “contents.”

The value of the “contents” attribute is a representation of a collection of physical things. The value of the “geometry” attribute is an instance of a Shape3D Class, which represents three dimensional shapes, such as spherical or rectangular prism. Classes representing the shapes spherical 619 and rectangular prism are subclasses of the Shape3D class and could include methods for calculating their respective volumes.

The ThingPhysical class 620 represents the concept of a physical thing, and an instance of this class represents a particular physical thing (e.g., a paperclip). Physical things have a shape, a mass, a physical location, and a volume. A physical thing also can include parts or be contained by another item. Consequently, the attributes of the ThingPhysical class include “shape,” “mass,” “locationPhysical,” “parts,” “volume,” and “containedBy.”

The ContainerPhysical class 625 represents the concept of a physical container, and an instance of this class represents a particular physical container (e.g., a cup or a room). The ContainerPhysical class is a subclass of the ThingPhysical class because a physical container is a type of physical thing. As a physical container has boundaries (e.g., the floor, walls, ceiling, doors, and windows of a room) and a compartment (e.g., the physical space within a room), attributes of the ContainerPhysical class include “boundaries” and “compartment.” The value of the “boundaries” attribute is a collection of physical things (e.g., floor, walls, ceiling, doors, and windows), and the value of the “compartment” attribute is an instance of the SpacePhysical class. Because the SpacePhysical class only allows physical things to be placed in a SpacePhysical object, the Simverse knows that only physical things can be placed in a ContainerPhysical object. The ContainerPhysical class also inherits all the attributes of the ThingPhysical class. As it is useful to know the volume of container so as to know how much the container can hold, a method to return the volume of the ContainerPhysical could be part of the ContainerPhysical class.

As stated above, a ThingPhysical object can include a list of parts. The list of parts for a ThingPhysical object called “Desk Lamp” might include a base, stem, shroud, light bulb, and power cord. A part of a ThingPhysical object can be a ContainerPhysical Object as well. For instance, a light bulb, which is a part of a desk lamp, is also a container for a filament and inert gas.

To obtain access to a fully-bounded PhysicalContainer object, at least one of the boundaries has to be an “access provider.” For instance, in order to enter a room, one has to walk through an open door, which is an “access provider” for the room. This example framework includes an Access class 626, which is a subclass of a Function class (because providing access is a type of function), that identifies the access provider (e.g., door), the PhysicalContainer Object to which the access provider relates (e.g., room), and the requirement for obtaining access to the room (e.g., the door must be in the “open” state).

The ThingLiving 627 class represents living things and is a subclass of the ThingPhysical class because a living thing is a physical thing. The ThingLiving includes a “requirements” attribute that is associated with a list of required states for the living thing. An Organism class 628 representing organisms is a subclass of the ThingLiving class, and an Animal class 629 representing animals is a subclass of the Organism class.

Distance is the property created by the space between two objects or points. (see WordNet 1.6, Overview for “Distance.”) The Distance Class 630 is an abstract class under which all classes related to distance are categorized. The DistanceType class 635 is a subclass of Distance, and it is also an abstract class under which classes representing various distance types, from a planck length to a light year, are categorized. These subclasses 640 include attributes and methods that define the relationship between them (e.g., 1 millimeter=1/1000 meter).

The DistanceUnits class 645 is also a subclass of Distance, and it represents a distance measurement. An instance of the DistanceUnits class is a particular distance measurement (e.g., 5 meters). Attributes of the DistanceUnits class include “units” and “distancetype.” The value of the “units” attribute is a number, such as “5.” The value of the “distancetype” attribute is an instance of one of the DistanceType subclasses, such as “Meters.”

The Time Class 650 is an abstract class under which all classes related to time are categorized. The TimeType class 655 is a subclass of Time, and it is also an abstract class under which classes representing various time types, from a femtosecond to an epoc, are categorized. These subclasses 660 include attributes and methods that define the relationship between them (e.g., 1 second=1/60 minute).

The TimeUnits class 665 is also a subclass of Time, and it represents measure of time in time units. Attributes of the TimeUnits class include “units” and “timetype.” The value of the “units” attribute is a number, such as “5.” The value of the “timetype” attribute is an instance of one of the TimeType subclasses, such as “Seconds.”

The State class 670 represents the concept of a state, which represent a summary of a Thing’s attributes. For instance, if a Door object is rotated on its hinges away from the wall, an instance of StateOpen 671 is returned. If an Animal’s metabolic processes are disrupted, an instance of StateDead 672 is returned.

This example framework also includes a StateMachine interface 673, which is what is referred to in Java as a “marker interface.” The StateMachine interface is used to “mark” Things that have States. Each time an Agent object (described below) performs an action on a Thing that supports States (i.e., a Thing that implements the StateMachine interface), the agent calls a method that calculates the state of the Thing. The ThingPhysical class implements the StateMachine interface because physical things experience State changes as they exist in a SpaceTimeContinuum (described below), where they are typically acted upon by Agents (described below) over time.

Figure 7 illustrates the SpaceTimeContinuum class 680 and related classes in more detail. The SpaceTimeContinuum class represents the space-time continuum. The Past, Present, and Future730, 740, 750 are attributes of the SpaceTimeContinuum class. The Simverse includes a temporal engine that uses an instance of the SpaceTimeContinuum as its timeline, which is essentially a linked list of WorldSlice objects.

A WorldSlice object a collection of physical things that represent the software-simulated universe at a particular instance in time. Consequently, the attributes of the WorldSlice class 682 include “slice” and “pointInTime.” The value of the “pointinTime” attribute is a fine-grained moment in time, as might be represented by a date/time stamp expressed in terms of the Gregorian calendar. The value of the “slice” attribute is a collection of physical things that exist at the specified pointInTime.

The Past, which is a linked list of WorldSlices at points in that correspond to the past, is used by applications based on the software-simulated universe to record temporal events. The Present is an instance of the WorldSlice class that represents the software-simulated universe at the current point in time. The Future, which is a class including a linked list of WorldSlices at points in time that correspond to the future, is used for recording future events and for making predictions into the future. Project management and personal assistant applications are examples of applications that would make use of a Future instance.

As each Present WorldSlice slips from the present into the past, it is added to the past collection of WorldSlices. A new Present WorldSlice is created for the new pointInTime, as the present marches into the future in temporal intervals. If the pointInTime of a WorldSlice in the Future linked list of WorldSlices matches the pointInTime in the Present WorldSlice, its contents are compared to the contents of Present WorldSlice for potential correlations. For example, an appointment date (e.g., Friday, 2pm, 6 December 2002) to see the dentist is stored in a Future WorldSlice, and, when this matches the current pointInTime, a Simverse application can notify a user of the appointment. Also, the appointment could include a warning which would be inserted in an appropriate WorldSlice before the appointment.

The Agent class 684 represents entities that can perform actions through mechanisms. Only Agents can perform Actions (described below), and they do so through mechanisms. Consequently, one of the attributes of the Agent class is “Mechanisms,” where the value of this attribute in an Agent object is a collection of Mechanisms (i.e., instances of the Mechanism class 686) that are associated with the Agent.

Examples of Agents include people, forces, and devices (e.g., drill, robot, etc.). People are Agents associated with a state of sentience (i.e. “StateSentient”).

Agents can perform actions ranging from low-level actions to high-level actions. Low-level actions correspond to the natural forces, such as gravity and electromagnetism. High-level actions correspond to sentient entities, such as actions performed by people. For each level of action, there is a corresponding Agent that implements an interface for that level of action.

In embodiments that support interfaces (e.g., a Java implementation), interfaces can be used as markers to indicate that the implementing class is a certain type of agent. Examples of such marker interfaces include:

Action is the highest abstraction of all activity in the Simverse. In one embodiment of a Java version of the framework, Actions are a set of Java interfaces that are implemented only by Agents. Figure 8 illustrates a diagram of the Action Interface 805 and some of its subclasses with examples of what the corresponding methods and attributes might look like. Move 810, Put 820, Attach 830, Use 850, and Mix 840 are all subclasses of the Action interface. An agent that can move Things would implement the Move interface. The Put interface is a subclass of the Move interface and can utilize classes representing proximity terms, such as the prepositions “on,” “near,” and “under.” Agents that can place things would implement the Put interface. An Agent that can attach Things with a tool-like mechanism would implement the Attach interface. An Agent that can mix Thing A with Thing B would implement the Mix interface. The Use interface is a kind of meta-Action interface, and it is implemented by Agents that can perform Actions on other Agents (e.g., a Person uses a Drill on Wood). Agents can perform Actions on other Agent(s), which in turn may cause the second Agent to perform action(s) on other Thing(s), and so on.

As further illustrated in Figure 8, the ActionSequence class 860 represents a linked list of Actions, and the Procedure class 870 represents a linked list of Action Sequences. The Process class 880 is a subclass of the Procedure class, where a Process is a Procedure executed in a cyclic fashion in order to maintain a collection of states.

Figure 9 illustrates an example in which Gravity, an Agent, Moves a Thing through a GravityMechanism. The Gravity Class 910 is a subclass of the Force Class 930, which is a subclass of the Agent class 684. Gravity is a Force with a Field, where the Field class 940 is a subclass of the SpacePhysical class because a field is an area of physical space. Gravity includes a GravityMechanism 920, which retrieves the masses of all PhysicalThings in the Field, and then calculates how they influence each other’s positions. The Gravity Mechanism calls the Move method 970 to move such PhysicalThings to the new positions calculated in accordance with the foregoing.

In the example illustrated in Figure 9, the Mechanism class 950 is an abstract class that implements an “operate()” method (in which the Mechanism is operated) in a Mechanism interface 960.

The CoordinateSystem Class 690 represents the concept of a coordinate system. As a coordinate system exists in a physical space and has a number of dimensions (e.g., 2, 3, 4, etc.), attributes of the CoordinateSystem class are “space” and “numberOfDimensions.” The value of the “space” attribute is an instance of the Space class, and the value of the “numberOfDimensions” attribute is an integer.

The CoordinateSystemPhysical class 692 is a subclass of the CoordinateSystem class, and it represents a physical coordinate system (i.e., a three dimensional coordinate system). Attributes of the CoordinateSystem Physical class are “coordinateUnits” and “space.” The value of the “coordinateUnit” attribute is an instance of the DistanceUnits class or one of its subclasses, and the value of the “space” attribute is an instance of the SpacePhysical class or one of its subclasses. The CoordinateSystemPhysical class can be used to describe a position in physical space.

The above-described classes represent some basic concepts in the real-world. These are meant to be illustrative, and those skilled in the art will appreciate that the implementation details can vary and that a framework to model the universe will include many more classes representing other concepts. Moreover, classes representing basic concepts are the building blocks for classes representing more complex concepts used to model humans and human society. Human tools and language can be modeled as devices, engines, or machines. Human society can be modeled as a taxonomy of Agents, including government, commerce, law, entertainment, education, and research. Human interactions can be modeled as subclasses of Actions, Procedures, Processes, and Activities, where Activities can be implemented as a taxonomy of Processes.

The present inventions also include a self-simulation software application (referred to as the “SelfSim” hereinafter), which is based on the above-described framework and which simulates a person’s life. The SelfSim is a software agent within the Simverse. The primary function of the SelfSim application is to determine the requirements of the person being simulated (the “host”) and to assist the host in satisfying its requirements.

Figure 11 illustrates the basic operation of the SelfSim. When a host first establishes a SelfSim application, the SelfSim creates 1105 a model of the host. A Simverse in which a SelfSim application operates includes a Person class that represents facts related to a person. The SelfSim uses an instance of the Person class to model the host, and, as it operates, the SelfSim extracts or stores information in the created Person object to perform functions for or on behalf of the host. Initially, information stored in the created Person object is based on input from the host, but as the SelfSim operates and monitors the host’s activities, it adds learned information automatically to the Person object.

Figure 10 illustrates one example of the Person class 1010 and some of the related classes. The depicted collection of classes and their interrelations reflect one way in which a person can be modeled. Those skilled in the art will appreciate that there are other ways to model a person and that implementation of the Person class and related classes depends on the model selected by the programmer.

In the example illustrated in Figure 10, the Person class has the attributes “name,” “profile,” and “requirements.” The value of the “name” attribute is an instance of a Name class 1020, in which its attributes “first,” “middle,” “last,” and “name” are set to the first, middle, last. and whole name, respectively, of the host. The Name class also is associated with methods for setting and retrieving the first, middle, last, and whole names. The value of the “requirements” attribute is a collection of required states of the host, as is further described below.

The value of the “profile” attribute is an instance of the Profile class, which represents facts related to the host, such as information that might be found in the host’s wallet, calendar, or filing cabinet. In this example, the attributes of the Profile class are “relatives,” “home,” “employment,” “socialSecurity,” “personalFinance,” “automobile,” “healthHistory,” “contactsEmergency,” “dateOfBirth,” “placeOfBirth,” “phoneNumber,” “email,” “calendar,” and “driversLicense” As depicted in Figure 10, the values of these attributes are instances of classes representing concepts corresponding to the attribute names. For example, the value of the “personalFinance” attribute is an instance of the PersonalFinance class 1040. The PersonalFinance class includes a collection of instances of the AccountFinancial class 1050, where an instance of the AccountFinancial class is associated with a particular account, such as a credit card, a savings account, or a checking account.

The SelfSim identifies 1110 requirements of the host by determining the conditions that must be met for the host to maintain certain required states, such as “Comfortable” and “Happy.” Specifically, as stated above, each Person object is associated with a “requirements” attribute that is set to a collection of required states, which are instances of a RequiredStates class. In order to achieve a RequiredState, certain conditions must be met. The conditions associated with a RequiredState are based on a model of a person’s requirements (a “Requirements Model”).

Figure 12 depicts an example of such a model, which can be built into the RequiredStates classes and subclasses. In this example, “Comfortable” is one of the RequiredStates 1205. From the model, the SelfSim realizes that (1) the host must have Food 1220, Shelter 1230, and Clothing 1240 to be Comfortable 1210; (2) Food 1220, Shelter 1230, and Clothing 1240 are Products 1245; (3) Products 1245 cost Money 1250; (4) obtaining Money 1250 requires an Income 1255; and (5) Employment 1260 allows the host to generate Income 1255. Consequently, having Food 1220, Shelter 1230, Clothing 1240, Money 1250, Income 1255, and Employment 1260 are conditions necessary for the host to be Comfortable 1210 and are, therefore, requirements of the host.

“Happy” 1215 is another RequiredState 1205. It is the highest of the subjective states, but most people’s pursuit of happiness includes at least one product and/or service, whether it be buying vintage cars, studying art in Venice, or Zen meditation. In the depicted model, Happiness depends on the host pursuing Interests 1270 and having Entertainment 1275. The specific Interests 1270 of the host would be determined by input and feedback from the host. Regardless of the nature of the Interests, most of them will require Money 1250, Income 1255, and Employment 1260.

The example model, which is simplified for illustration purposes, is an “income-dependency model” because it ties product and most services to money. Consequently, generating Income, whether from Employment or Savings is one of the most important requirements for the host. As most people in the world require money to obtain the goods and services they need, the model should work for most adults in the world.

Figure 12 depicts only one way to model a person’s requirements, and other models can be used. In fact, the conditions for a RequiredState to be met depend on the life stage of the host. As shown in Figure 13, a human life cycle can be modeled as a sequence of development stages (e.g., birth, baby, toddler, child, preteen, teen, adult, elderly, and death). Each stage in between birth and death is associated with a duration of time that corresponds to human life. The SelfSim tracks the life stage of the host and identifies requirements and select strategies that correspond to the life stage. Figure 13 illustrates examples of the way in which the SelfSim can assist the host at different life stages.

After the SelfSim determines the host’s requirements, it identifies 1120 strategies to satisfy the requirements. In one embodiment, the Simverse includes a Strategy class which represents the concept of a strategy, and the SelfSim searches for instances of the class (i.e., Strategies) that correspond to the host’s requirements. For example, assuming there are employment Strategies for keeping the host employed, the SelfSim would identify these as applicable Strategies because employment is crucial to the host generating Income, unless the host a child or is retired. Each Strategy includes processes with which the SelfSim attempts to assist it hosts.

Strategies are associated with a particular routine (e.g., daily, weekly, or monthly routine). Consequently, the SelfSim executes Strategies in accordance with the routine the host is performing. As illustrated in Figure 14, a Routine 1420 is a cyclic Process 1410 with a time interval. A daily routine includes a morning routine, a lunch time routine, an afternoon routine, and an evening routine. Similarly, a weekly routine consists of a Monday routine, a Tuesday routing, a Wednesday routine, and so on. The SelfSim attempts to execute a strategy for every routine.

One of the employment Strategies might include a “GetReadyforWork” process which is associated with a person’s morning routine. Figure 15 illustrates an example of such a process in which this example is set in the near future where “smart” appliances that are connected to the Internet exist.

The SelfSim executes this process during the time interval that corresponds to a host’s morning routine. In executing the process, the SelfSim determines 1505 whether the current day is a workday for the host. Since the SelfSim maintains the host’s calendar (through the “profile” attribute in the Person class), it knows which days are workdays. If it is not a workday, the SelfSim does nothing with respect to this process. If the SelfSim determines it is a workday, it calls 1510 a WakeUPHostWorkDayWakeTime method, which is a method in the GetReadyforWork process. This method would likely involve instructing the host’s alarm clock to ring at the time in which the host has specified as its workday wake-up time. The SelfSim then calls 1515 the CoffeeMachineMakingCoffee method which would tell the coffee machine to start making coffee.

The next step of the process is for the SelfSim to check 1520 the weather and the room temperature. If the room is cold, the SelfSim calls 1525 the TellHeaterHeatRoom method of the GetReadyforWork process, which instructs the heater to heat the room to a select temperature. If the room is cold, the SelfSim calls 1530 the TellAirConditionerCoolRoom method, which would tell the air conditioner to cool the room to a select temperature. As depicted in Figure 15, the process continue in assisting the host in heating a shower, notifying the host of urgent email, displaying the email if desired, making breakfast, and calling the host’s car.

As the SelfSim executes strategies and monitors the host’s routines and activities, it updates 1140 the host model, including the host’s requirements as applicable.

In the preferred embodiment, the SelfSim continuously monitors the host’s requirements and searches for strategies to satisfies the requirements. As a host has multiple requirements (e.g., Food, Shelter, Clothing, Entertainment, Interests, Employment, Savings, etc.), the SelfSim is executing multiple strategies. The SelfSim runs seven days a week, twenty-four hours a day, executing strategies that correspond to every granularity of routines (morning routine, afternoon routine, evening routine, daily routine, weekly routine, monthly, yearly, etc.). As there can be multiple strategies that correspond to a particular routine, the SelfSim prioritizes requirements and selects among strategies in accordance with such priorities.

The SelfSim prioritizes the host’s requirements based on the Requirements Model and feedback from the host. For example, employment would be considered a high priority because it is necessary to generate income, which is needed to obtain most of the host’s other requirements (e.g., food, clothing, shelter, etc.). Also, the host may indicate that a particular interest (e.g., golf) is a high priority.

As illustrated in Figure 16, the SelfSim assigns a PriorityValue 1605 (i.e., an instance of the PriorityValue class illustrated in Figure 16) to each requirement based on the Requirements Model and feedback from the host. The PriorityValue is a number on a PriorityScale 1610 (e.g., 0-1), which has a minimum number corresponding to the lowest priority and a maximum number corresponding to the highest priority. The SelfSim sorts the requirements from highest to lowest PriorityValue. It then distributes the most resources to the highest priority requirements and the least resources to the lowest priority requirements. Resources include time, personal finances, and computing power.

Through the ontology upon which the Simverse is based, the SelfSim is capable of achieving a real-world understanding of a host’s routines, activities, and possessions and the context in which they exist. Instead of running single-task oriented applications, the SelfSim continuously monitors the host’s requirement and plans ways to assist the host, dynamically reconfiguring tasks to serve the host.

As the Simverse enables a distributive computing environment, the SelfSim can run on multiple host computing resources. For instance, the SelfSim can perform some operations on the host’s desktop computer and others on the host’s PDA (e.g., a Palm Pilot).

The Simverse could be used as an engine for an immersive three-dimensional user interface. The objects and environments of the user interface are based on the physically-based, semantically-bound classes in the Simverse. As discussed above, some of the more\ fundamental concepts in the Simverse are:

(3) Things can have parts, physical things have mass, physical containers have boundaries and capacity, etc.

These concepts map intuitively to three dimensional objects, gestures and actions, enabling a three dimensional interface. For example, when the engine places the user in a room, it understands that when the user wants to leave room they have to first walk across the room, then open the door, etc.

Also, concepts that are considered abstract can be mapped onto the three dimensions of physical space and the forth dimension of time, and they can be represented as objects having size, shape, color, texture, etc. By mapping abstract concepts onto intuitive senses, the user can analyze data and find patterns that may not be obvious in other forms.

The above-described immersive user interface can be used to create a visual software development environment, in which the program is represented in three-dimensional shapes. In such an environment, each three-dimensional shape represents a concept in object-oriented programming languages.

For instance, classes could be represented by cubes. The name of a class, and its attributes and methods, could be displayed on the different faces of a cube. The “privateness” of attributes could be represented visually, with public attributes on clear faces, and private attributes on frosted faces.

Higher cubes would represent super classes, and lower cubes, connected to higher cubes with three dimensional tubes, would represent subclasses The tubes connecting classes could be colored to reflect the nature of the connection. Also, when the environment is in run/debug mode, the movement and value of data can be depicted visually by changing the color, size, and/or texture of the three dimensional shapes.

By mapping object-oriented programming language principles to geometry, color, texture and animation, the programmer is able to see and capture a software application more intuitively than through traditional two-dimensional views.

Because an understanding of real-world concepts is build into the Simverse, it can be used to develop an educational environment which teaches children about the laws of nature and how real-world entities relate to each other. For instance, it can teach young users about how objects occupy space and volume, how they can be stacked, or used as containers to place objects within, and how states can change due to agent interactions over time. As the Simverse is capable of tracking time and recording history (see SpaceTimeContinuum discussion above), it can be used to track the user’s progress and plan a future learning curriculum.

More sophisticated knowledge for adult education may be modeled in the educational environment, which can also function as a research recording tool. If a researcher is studying a subject that is not in the educational environment, they can model their studies and enter it into the educational environment.

The researcher and the educational environment both benefit from this. Through the user building semantic bindings between the new material and the existing Simverse ontology, the Simverse includes a more complete model of the world and can mine for novel correlations. The researcher benefits from this by seeing new and holistic relationships and having a more encompassing body of modeled knowledge.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms than those described herein without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative and not limiting of the invention.

1. An object-oriented framework for modeling entities, concepts, and processes comprising:

an ontology that organizes and binds together real-world concepts in a manner that reflects the real world;

a plurality of software classes that interrelate in accordance with the ontology, wherein each of the software classes is associated with one of the real-world concepts in the ontology and has a natural language name that corresponds in meaning to the real-world concept associated with the software class, and wherein, for each software class having methods and attributes, such methods and attributes relate to the real-world concept associated with the software class.

2. The framework of claim 1 wherein the ontology is hierarchical with lower-level real-world concepts categorized under higher-level real world concepts.

3. The framework of claim 2 wherein the software classes are semantically bound in accordance with the ontology.

4. The framework of claim 3 wherein the software classes and their corresponding methods and attributes form an object-oriented software grammar in which all knowledge within the framework can be represented.

5. The framework of claim 1, wherein the plurality of software classes include software classes representing fundamental concepts necessary to model the world.

6. The framework of claim 5, wherein the plurality of software classes include classes representing the concepts of space, time, distance, physical things, and living things.

7. The framework of claim 1, wherein the plurality of software classes include a context class that represents the concept of a context and that can be used as a filter to focus interactions between software objects within the framework.

8. The framework of claim 1, wherein the ontology and the plurality of software classes incorporate natural laws.

9. The framework of claim 1, wherein the framework is implemented as a software engine and further comprises a temporally-driven engine and at least one software agent that creates and uses software objects based upon the software classes.

10. A method for determining a human user’s requirements and assisting the user in satisfying the requirements, the method comprising:

creating a model of the user, where the model of the user is implemented as instances of a plurality of software classes relating to information associated with a person;

creating a model of the user’s requirements, where the model of the user’s requirements is implemented as instances of a plurality of software classes representing requirements of a person;

determining the user’s requirements based on the model of the user’s requirements;

11. The method of claim 10 further comprising monitoring routines of the person and executing the strategies in accordance with the priorities and the person’s routines.

12. The method of claim 10 further comprising monitoring life stages of the user and determining the user’s requirements based on such life stages.

a model of a person implemented as a plurality of software classes representing information associated with a person;

a model of a person’s requirements implemented as a plurality of software classes representing required states of a person and represents things that are required by a person to achieve and maintain the required states; and

strategies for assisting a person in satisfying requirements implemented as a collections of software processes;

wherein each of the software classes in the framework are associated with a natural language word for the concept represented by the software class and wherein any attributes and methods of the software class relate to the concept represented by the class.

14. The framework of claim 13 wherein the model of a person includes classes representing a person’s name, a person’s contact information, a person’s calendar, a person’s driver’s license, and a person’ s employment information.

15. The framework of claim 13, wherein the model of a person’s requirements is an income-dependency model that indicates a person must generate income to obtain many of the required things.

16. The framework of claim 13 further comprising a model of a human lifecycle, implemented as a plurality of software classes representing life stages of a human.

17. A computer program embodied in a tangible medium and capable of being read by a computer for performing the method of claim 10.

A software framework for modeling the world includes a collection of object-oriented, software classes, where each class is based on a concept that exists in the world (e.g., physical things, time, space, distance, etc.) and is associated with a natural language word, such as an English word, for that concept. The attributes, methods, and interfaces supported by a class reflect the meaning of the natural language word with which the class is associated. The software classes, as well their corresponding attributes, methods, and interfaces, form an object-oriented grammar which can be used as the basis for describing any entity (living or non-living), concept, or action. The framework incorporates an ontology, which is based on natural laws and a common sense understanding of the universe, that defines how instances of such classes are related to each other and interact with each other. A self-simulation application based on such framework is used to identify a person’s requirements and assist the person in satisfying them.

Illustrations