Movement of an agent that utilizes as-needed canonical rules

RELATED APPLICATION

0001This is a continuation of and claims priority to U.S. patent application Ser. No. 11/645,190, entitled “Movement of an Agent that Utilizes As-Needed Canonical Rules,” filed on Dec. 22, 2006, the disclosure of which is incorporated by reference herein.

BACKGROUND

0002Agents

0003A software agent is a software abstraction, similar to the object-oriented programming concept of an object. The concept of an agent provides a convenient and powerful way to describe a complex software entity that is capable of acting with a certain degree of autonomy in order to accomplish tasks on behalf of its user. But unlike objects, which are defined in terms of methods and attributes, an agent is defined in terms of its behavior.

0004Various authors have proposed different definitions of agents, commonly including concepts such as:

0005Persistence—code is not executed on demand but runs continuously and decides for itself when it should perform some activity

0006Autonomy—agents have capabilities of task selection, prioritization, goal-directed behavior, decision-making without human intervention

0007Social Ability—agents are able to engage other components through communication and coordination, they may collaborate on a task

0008Reactivity—agents perceive the context in which they operate and react to it appropriately.

0009Agents may also be mobile. They can move from one execution environment to another carrying both their code and their execution state. These execution environments can exist in a variety of devices in a data network including, but not limited to, servers, desktops, laptops, embedded devices, networking equipment and edge devices such as PDAs or cell phones. The characteristics of these platforms may vary widely in terms of computational capacity, networking capacity, display capabilities, etc. An agent must be able to adapt to these conditions.

0010Historically, agents have been programmed in a procedural manner. That is, agents are programmed with a series of steps that will ultimately result in a goal being achieved. This approach has limitations though as the logic for each agent must be compiled into the agent software and is therefore static. Complex goals can also become intractable for a programmer as the set of rules the agent must follow grows.

0011Rule-Based Systems

0012In his tutorial, Introduction to Rule-Based Systems, James Freeman-Hargis defines a rule-based system to consist of a set of assertions and a set of rules for how to act on the assertion set. When a set of data is supplied to the system, it may result in zero or more rules firing. Rule based systems are rather simplistic in nature, consisting of little more than a group of if-then statements, but form the basis of many “expert systems.” In an expert system, the knowledge of an expert is encoded into the rule-set. When a set of data is supplied to the system, the system will come to the same conclusion as the expert. With this approach there is a clear separation between the domain logic (a rule set) and the execution of the agent. As mentioned, the procedural agent approach tightly couples the two.

0013The rule-based system itself uses a simple technique. It starts with a rule-set, which contains all of the appropriate knowledge encoded into If-Then rules, and a working memory, which may or may not initially contain any data, assertions or initially known information. The system in operation examines all the rule conditions (IF) and determines a subset, the conflict set, of the rules whose conditions are satisfied based on the working memory. Of this conflict set, one of those rules is triggered (fired). The rule that is chosen is based on a conflict resolution strategy. When the rule is fired, any actions specified in its THEN clause are carried out. These actions can modify the working memory, the rule-set itself, or do just about anything else the system programmer decides to include. This loop of firing rules and performing actions continues until one of two conditions are met: there are no more rules whose conditions are satisfied or a rule is fired whose action specifies the rule engine execution should terminate.

0014Rule-based systems, as defined above, are adaptable to a variety of problems. In some problems, working memory asserted data is provided with the rules and the system follows them to see where they lead. This approach is known as forwardchaining. An example of this is a medical diagnosis in which the problem is to diagnose the underlying disease based on a set of symptoms (the working memory). A problem of this nature is solved using a forward-chaining, data-driven, system that compares data in the working memory against the conditions (IF parts) of the rules and determines which rules to fire.

0015In other problems, a goal is specified and the system must find a way to achieve that specified goal. This is known as backward-chaining. For example, if there is an epidemic of a certain disease, this system could presume a given individual had the disease and attempt to determine if its diagnosis is correct based on available information. A backwardchaining, goal-driven, system accomplishes this. To do this, the system looks for the action in the THEN clause of the rules that matches the specified goal. In other words, it looks for the rules that can produce this goal. If a rule is found and fired, it takes each of that rule's conditions as goals and continues until either the available data satisfies all of the goals or there are no more rules that match.

0016The Rete algorithm is an efficient pattern matching algorithm for implementing forward-chaining, rule-based systems. The Rete algorithm was designed by Dr. Charles L. Forgy of Carnegie Mellon University in 1979. Rete has become the basis for many popular expert systems, including JRules, OPS5, CLIPS, JESS, Drools, and LISA.

0017A naive implementation of a rule-based system might check each rule against the known facts in the knowledge base, firing that rule if necessary, then moving on to the next rule (and looping back to the first rule when finished). For even moderate sized rules and fact knowledge-bases, this naïve approach performs far too slowly.

0018The Rete algorithm (usually pronounced either ‘REET’ or ‘REE-tee’, from the Latin ‘rete’ for net, or network) provides the basis for a more efficient implementation of an expert system. A Rete-based expert system builds a network of nodes, where each node (except the root) corresponds to a pattern occurring in the left-hand-side of a rule. The path from the root node to a leaf node defines a complete rule left-handside. Each node has a memory of facts which satisfy that pattern.

0019As new facts are asserted or modified, they propagate along the network, causing nodes to be annotated when that fact matches that pattern. When a fact or combination of facts causes all of the patterns for a given rule to be satisfied, a leaf node is reached and the corresponding rule is triggered.

0020The Rete algorithm is designed to sacrifice memory for increased speed. In most cases, the speed increase over naive implementations is several orders of magnitude (because Rete performance is theoretically independent of the number of rules in the system). In very large systems, however, the original Rete algorithm tends to run into memory consumption problems which have driven the design of Rete variants.

0021Therefore, what is needed is an ability to move an agent that utilizes as-needed rules from a first execution environment to a second execution environment. More specifically what is needed is movement of an agent that utilizes a supplied set of as-needed canonical rules from a first execution environment to a second execution environment.

BRIEF DESCRIPTION OF THE DRAWINGS

0022<figref idref="DRAWINGS">FIG. 1</figref> is a diagram illustrating an example process of constructing an agent locally with a set of canonical rules supplied during construction in accordance with one or more embodiments;

0023<figref idref="DRAWINGS">FIG. 2</figref> is a diagram illustrating an example process of constructing an agent remotely with a set of canonical rules supplied during construction in accordance with one or more embodiments;

0024<figref idref="DRAWINGS">FIG. 3</figref> is a diagram illustrating an example process of constructing an agent in a remote execution environment during which a set of canonical rules is retrieved from outside the execution environment in accordance with one or more embodiments;

0025<figref idref="DRAWINGS">FIG. 4</figref> is a diagram illustrating an example process of moving an agent carrying canonical rules from a first execution environment in accordance with one or more embodiments;

0026<figref idref="DRAWINGS">FIG. 5</figref> is a diagram illustrating an example process of moving an agent carrying canonical rules to a second execution environment in accordance with one or more embodiments;

0027<figref idref="DRAWINGS">FIG. 6</figref> process of an agent execution in accordance with one or more embodiments;

0028<figref idref="DRAWINGS">FIG. 7</figref> is a diagram illustrating an example process of constructing an agent locally with a set of compiled rules supplied during construction in accordance with one or more embodiments;

0029<figref idref="DRAWINGS">FIG. 8</figref> is a diagram illustrating an example process of constructing an agent remotely with a set of compiled rules supplied during construction in accordance with one or more embodiments;

0030<figref idref="DRAWINGS">FIG. 9</figref> is a diagram illustrating an example process of constructing an agent remotely during which a set of compiled rules that are retrieved from outside the execution environment in accordance with one or more embodiments;

0031<figref idref="DRAWINGS">FIG. 10</figref> is a diagram illustrating an example process of moving an agent carrying compiled rules from a first execution environment in accordance with one or more embodiments;

0032<figref idref="DRAWINGS">FIG. 11</figref> is a diagram illustrating an example process of moving an agent carrying compiled rules to a second execution environment in accordance with one or more embodiments;

0033<figref idref="DRAWINGS">FIG. 12</figref> is a diagram illustrating an example process of constructing an agent remotely with a set of canonical rules carried by the agent and a set of canonical execution environment rules resident in a remote environment in accordance with one or more embodiments;

0034<figref idref="DRAWINGS">FIG. 13</figref> is a diagram illustrating an example process of constructing an agent remotely with a set of canonical rules fetched by the agent and a set of canonical execution environment rules resident in a remote environment in accordance with one or more embodiments;

0035<figref idref="DRAWINGS">FIG. 14</figref> is a diagram illustrating an example process of moving an agent carrying canonical rules from a first execution environment that includes execution environment rules in accordance with one or more embodiments;

0036<figref idref="DRAWINGS">FIG. 15</figref> is a diagram illustrating an example process of moving an agent carrying canonical rules to a second execution environment that includes a repository of canonical execution environment rules in accordance with one or more embodiments;

0037<figref idref="DRAWINGS">FIG. 16</figref> is a diagram illustrating an example process of constructing an agent at a remote location with an as-needed set of canonical rules supplied during construction in accordance with one or more embodiments;

0038<figref idref="DRAWINGS">FIG. 17</figref> is a diagram illustrating an example process of constructing an agent at a remote location with an as-needed set of canonical rules fetched during construction in accordance with one or more embodiments;

0039<figref idref="DRAWINGS">FIG. 18</figref> is a diagram illustrating an example process of moving an agent with supplied as-needed canonical rules from a first execution environment in accordance with one or more embodiments;

0040<figref idref="DRAWINGS">FIG. 19</figref> is a diagram illustrating an example process of moving an agent with supplied as-needed canonical rules to a second execution environment in accordance with one or more embodiments;

0041<figref idref="DRAWINGS">FIG. 20</figref> is a diagram illustrating an example process of moving an agent from a first execution environment with a fetched as-needed set of canonical rules in accordance with one or more embodiments;

0042<figref idref="DRAWINGS">FIG. 21</figref> is a diagram illustrating an example process of moving an agent to a second execution environment with a fetched as-needed set of canonical rules in accordance with one or more embodiments;

0043<figref idref="DRAWINGS">FIG. 22</figref> is a diagram illustrating an example process of a rule-based agent updating rule history when rule processing is halted in an execution environment in accordance with one or more embodiments;

0044<figref idref="DRAWINGS">FIG. 23</figref> is a diagram illustrating an example process of a rule-based agent identifying and carrying only needed canonical rules during as part of movement to another execution environment in accordance with one or more embodiments;

0045<figref idref="DRAWINGS">FIG. 24</figref> is a diagram illustrating an example process of an agent using a set of survival rules to determine its lifespan in accordance with one or more embodiments; and

0046<figref idref="DRAWINGS">FIG. 25</figref> is a diagram illustrating an example process of an agent using a set of data narrowing rules to determine how much data should be sent over the network in accordance with one or more embodiments.

DETAILED DESCRIPTION

0047Construction

0048Agents which utilize rule based systems may be constructed locally or remotely. In order to operate, these agents need an initial set of canonical rules that can be compiled and loaded into an associated rule engine. These rules can either be supplied at construction or a rule repository location can be supplied so that the rules may be fetched during construction or at a later time.

0049Referring now to <figref idref="DRAWINGS">FIG. 1</figref>, a diagram illustrating an example process of constructing an agent locally with a set of canonical rules supplied during construction is shown. An application <b>110</b>, in an execution environment <b>112</b>, requests a set of rules for an agent from a rule repository <b>116</b> based on the goals of the agent that is being created. The result is a collection of canonical rules, known as a rule set <b>118</b>. The rule set <b>118</b> is passed to the agent <b>120</b> during construction. The agent <b>120</b> takes the rule set <b>118</b> and requests that it be compiled by the local rule compiler <b>122</b>. This results in the creation of a compiled rule set <b>124</b>. At this point the agent creates the rule engine <b>126</b> that will be used to execute the rule set. Note that if the execution environment <b>112</b> includes a rule engine, then one may not need to be created. After the rule engine <b>126</b> is created or located, the agent <b>120</b> supplies the engine <b>126</b> with the compiled rule set <b>124</b>. Finally, the agent <b>120</b> requests a new working memory <b>128</b> from the rule engine <b>126</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>120</b> is ready to be moved to another execution environment or to execute the rule engine. Both of these processes are described in detail in later sections.

0050Referring now to <figref idref="DRAWINGS">FIG. 2</figref>, a diagram illustrating an example process of constructing an agent remotely with a set of canonical rules supplied during construction is shown. An application <b>218</b>, in execution environment <b>212</b>, requests a set of rules for an agent from a rule repository <b>220</b> in execution environment <b>214</b> based on the goals of the agent that is being created. The result is a collection of canonical rules, known as a rule set <b>222</b>. The rule set <b>222</b> is passed to the agent <b>224</b> during construction in execution environment <b>216</b>. The agent <b>224</b> in execution environment <b>216</b> takes the rule set <b>222</b> and requests that it be compiled by the local rule compiler <b>226</b>. This results in the creation of a compiled rule set <b>228</b>. At this point the agent creates the rule engine <b>230</b> that will be used to execute the rule set. Note that if execution environment <b>216</b> includes a rule engine, then one may not need to be created. After the rule engine <b>230</b> is created or located, the agent <b>224</b> supplies the engine <b>230</b> with the compiled rule set <b>228</b>. Finally, the agent <b>224</b> requests a new working memory <b>232</b> from the rule engine <b>230</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>224</b> is ready to be moved to another execution environment or to execute the rule engine.

0051Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, a diagram illustrating an example process of constructing an agent in a remote execution environment during which a set of canonical rules is retrieved from outside the execution environment is shown. An application <b>318</b>, in execution environment <b>312</b>, requests the creation of an agent <b>324</b> in execution environment <b>316</b>. Agent <b>324</b> is passed the location of a rule repository <b>320</b> during construction. During construction, the agent <b>324</b> requests a set of rules based on its goals from the rule repository <b>320</b> in execution environment <b>314</b>. The result is a collection of canonical rules, known as a rule set <b>322</b>. The agent <b>324</b> in execution environment <b>316</b> takes the rule set <b>322</b> and requests that it be compiled by the local rule compiler <b>326</b>. This results in the creation of a compiled rule set <b>328</b>. At this point the agent creates the rule engine <b>330</b> that will be used to execute the rule set. Note that if execution environment <b>314</b> includes a rule engine, then one may not need to be created. After the rule engine <b>330</b> is created or located, the agent <b>324</b> supplies the engine <b>330</b> with the compiled rule set <b>328</b>. Finally, the agent <b>324</b> requests a new working memory <b>332</b> from the rule engine <b>330</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>324</b> is ready to be moved to another execution environment or to execute the rule engine.

0052Movement

0053An agent may move from one execution environment to another. This process may be initiated by a variety of means including but not limited to an application, another agent, another object, the existing agent itself, a human interacting with the execution environment or a rule executing in the agent's rule engine.

0054Referring now to <figref idref="DRAWINGS">FIGS. 4 and 5</figref>, diagrams illustrating an example process of moving an agent carrying canonical rules from one execution environment to another are shown. An application <b>418</b> in execution environment <b>412</b> requests that an agent <b>424</b> in execution environment <b>414</b> move to execution environment <b>416</b>. The location of execution environment <b>416</b> may be described in the move request by an IP address and port, Uniform Resource Locator (URL), or any other means of addressing. The agent <b>424</b> discards its rule engine <b>430</b> along with the associated compiled rule set <b>428</b> and working memory <b>432</b>. The agent <b>424</b> then encodes itself along with its canonical rule set <b>422</b> into a transferable form <b>434</b>. Though a byte array is shown, the encoded agent could take any form that can be transferred between the two execution environments. Once the agent <b>424</b> has created an encoded version of itself <b>434</b> in execution environment <b>414</b> it transfers the encoded version <b>434</b> to an agent manager <b>426</b> residing in execution environment <b>416</b>.

0055Referring now to <figref idref="DRAWINGS">FIG. 5</figref>, the process continues with the agent manager <b>522</b> receiving the encoded agent <b>534</b>. Upon receipt of the encoded agent <b>534</b>, the agent manager <b>522</b> decodes the encoded agent <b>534</b> into a new version of the agent <b>524</b> and the agent's canonical rule set <b>526</b> in execution environment <b>516</b>. Once the agent <b>524</b> and rule set <b>526</b> have been materialized, the agent manager <b>522</b> requests that the agent <b>524</b> initialize. This request prompts the agent <b>524</b> to go to the execution environment's rule compiler <b>520</b> and request compilation of its canonical rule set <b>526</b>. The result is a compiled rule set <b>528</b>. The agent then creates a new rule engine <b>530</b> and subsequently passes the compiled rule set <b>528</b> to it. As during construction, if the execution environment has a rule engine, then one may not need to be created. Once the engine <b>530</b> has been located/created and the compiled rule set <b>528</b> has been added to it, the agent <b>524</b> requests a new working memory from the rule engine. As before, the working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>524</b> is ready to execute the rule engine. Once the move operation completes, the old version of the agent <b>518</b> in execution environment <b>514</b> indicates to the requesting application <b>518</b> in execution environment <b>512</b> that the move operation has completed. Once the notification has been made, the old agent <b>534</b> is destroyed.

0056Execution

0057Once an agent has been initialized in an execution environment through either creation or movement, it can be sent requests to perform different tasks. These tasks mayor may not require sending one or more responses. Recall that during construction an agent is associated with a newly created or resident rule engine and that a rule set is provided to that engine.

0058Referring now to <figref idref="DRAWINGS">FIG. 6</figref>, a diagram illustrating an example process of an agent utilizing a rule-based system engine for execution is shown. An application <b>616</b> in execution environment <b>612</b> sends a request to an agent <b>618</b> in execution environment <b>614</b>. Upon receiving the request, the agent <b>618</b>, collects an initial set of data and asserts it into its working memory <b>624</b> in order to accomplish the task requested. Note that this data may be collected from the local execution environment, from an accessible database, from other objects, from other agents, from a human via a man machine interface, from a computer readable medium or any combinations of the above. With a provided compiled rule set <b>620</b>, and an initial set of data in working memory <b>624</b>, the rule engine <b>622</b> is then started by the agent <b>618</b>.

0059When the engine <b>622</b> starts, it processes the objects in working memory against the rule set <b>620</b>. This may result in one or more rules being fired by the engine <b>622</b>. When a rule is fired it may add, modify or delete objects in working memory <b>624</b>. Additionally, the engine <b>622</b> can inform the agent <b>618</b> which may result in a number of actions being taken by the agent <b>618</b> including, but not limited to, the collection and assertion of additional data into the working memory <b>624</b> (shown) and/or sending of a preliminary response back to the application. This sequence will continue until the task is completed, there are no more rules available to fire, or the agent receives an event, such as move or terminate, causing it to halt rule engine processing. Upon completion of the task, the agent <b>618</b> may send a response back to the application <b>616</b> that initiated the request (shown).

0060Pre-Compiled Agent Rule Set Usage

0061As noted above, the process of adding rules to the rule engine can be expensive in terms of CPU utilization on the execution environment in which the operation is performed. This can be problematic for less powerful hosts such as personal devices (cell phones, PDAs, etc.) and servers with limited available CPU resources. Therefore, another embodiment of the invention creates the compiled rule set in the execution environment of the application that creates an agent instead of in the environment in which the agent is constructed or moved.

0062Referring now to <figref idref="DRAWINGS">FIG. 7</figref>, a diagram illustrating an example process of constructing an agent locally with a set of compiled rules supplied during construction is shown. An application <b>712</b>, in execution environment <b>714</b>, requests a set of rules for an agent from a rule repository <b>720</b> based on the goals of the agent that is being created. The result is a collection of canonical rules, known as a rule set <b>724</b>. The application <b>712</b> takes the rule set <b>724</b> and requests that it be compiled by the local rule compiler <b>722</b>. This results in the creation of a compiled rule set <b>724</b>. The rule set <b>724</b> is passed to the agent <b>718</b> during construction. At this point the agent creates the rule engine <b>726</b> that will be used to execute the rule set. Note that if the execution environment <b>714</b> includes a rule engine, then one may not need to be created. After the rule engine <b>726</b> is created or located, the agent <b>722</b> supplies the engine <b>726</b> with the compiled rule set <b>724</b>. Finally, the agent <b>110</b> requests a new working memory <b>728</b> from the rule engine <b>726</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>718</b> is ready to be moved to another execution environment or to execute the rule engine.

0063Referring now to <figref idref="DRAWINGS">FIG. 8</figref>, a diagram illustrating an example process of constructing an agent remotely with a set of compiled rules supplied during construction is shown. An application <b>812</b>, in execution environment <b>814</b>, requests a set of rules for an agent from a rule server <b>828</b> in execution environment <b>818</b> based on the goals of the agent that is being created. The rule server <b>828</b> queries a rule repository <b>830</b> for the rules. The result is a collection of canonical rules, known as a rule set <b>832</b>. The rule server <b>828</b> in execution environment <b>202</b> takes the rule set <b>832</b> and requests that it be compiled by the local rule compiler <b>834</b>. This results in the creation of a compiled rule set <b>826</b>. The compiled rule set <b>826</b> is passed to the agent <b>820</b> during construction in execution environment <b>204</b>. At this point, the agent <b>820</b> creates the rule engine <b>822</b> that will be used to execute the rule set. Note that if execution environment <b>816</b> includes a rule engine, then one may not need to be created. After the rule engine <b>822</b> is created or located, the agent <b>820</b> supplies the engine <b>822</b> with the compiled rule set <b>826</b>. Finally, the agent <b>820</b> requests a new working memory <b>116</b> from the rule engine <b>822</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>820</b> is ready to execute the rule engine.

0064Referring now to <figref idref="DRAWINGS">FIG. 9</figref>, a diagram illustrating an example process of constructing an agent in a remote execution environment during which a set of compiled rules is retrieved from outside the execution environment is shown. An application <b>912</b>, in execution environment <b>914</b>, requests the creation of an agent <b>920</b> in execution environment <b>916</b>. Agent <b>920</b> is passed the location of a rule server <b>928</b>, resident in execution environment <b>918</b>, during construction. During construction, the agent <b>920</b> requests a set of compiled rules based on its goals from the rule server <b>928</b> in execution environment <b>918</b>. The rule server <b>928</b> queries a rule repository <b>930</b> for a set of rules. The result is a collection of canonical rules, known as a rule set <b>932</b>. The rule server <b>928</b> in execution environment <b>918</b> takes the rule set <b>932</b> and requests that it be compiled by the local rule compiler <b>934</b>. This results in the creation of a compiled rule set <b>926</b>. At this point the agent <b>920</b> creates a rule engine <b>922</b> that will be used to execute the rule set. Note that if execution environment <b>916</b> includes a rule engine, then one may not need to be created. After the rule engine <b>922</b> is created or located, the agent <b>920</b> supplies the engine <b>922</b> with the compiled rule set <b>926</b>. Finally, the agent <b>920</b> requests a new working memory <b>924</b> from the rule engine <b>922</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>920</b> is ready to execute the rule engine.

0065Referring now to <figref idref="DRAWINGS">FIGS. 10-11</figref>, diagrams illustrating an example process of moving an agent carrying compiled rules from one execution environment to another are shown. An application <b>1018</b> in execution environment <b>1012</b> request that an agent <b>1022</b> in execution environment <b>1014</b> move to execution environment <b>1016</b>. The location of execution environment <b>1016</b> may be described in the move request by an IP address and port, Uniform Resource Locator (URL), or any other means of addressing. The agent <b>1022</b> discards its rule engine <b>1030</b> along with the associated working memory <b>1032</b>. Subsequently, the agent <b>1022</b> discards its canonical rule set <b>1020</b> if it still has a reference to it. The agent <b>1022</b> then encodes itself along with its compiled rule set <b>1028</b> into a transferable form <b>1024</b>. Though a byte array is shown, the encoded agent could take any form that can be transferred between the two execution environments. Once the agent <b>1022</b> has created an encoded version of itself <b>1024</b> in execution environment <b>1014</b> it transfers the encoded version <b>1024</b> to an agent manager <b>1026</b> residing in execution environment <b>1016</b>.

0066Referring now to <figref idref="DRAWINGS">FIG. 11</figref>, the process continues with an agent manager <b>1122</b> receiving an encoded agent <b>1134</b>. Upon receipt of the encoded agent <b>1134</b>, the agent manager <b>1122</b> decodes the encoded agent <b>1134</b> into a new version of the agent <b>1124</b> and its compiled rule set <b>1128</b> in execution environment <b>1116</b>. Once the agent <b>1124</b> and rule set <b>1128</b> have been decoded, the agent manager <b>1122</b> requests that the agent <b>1124</b> initialize. This request prompts the agent <b>1124</b> to create a new rule engine <b>1130</b> and subsequently pass the compiled rule set <b>1128</b> to it. As during construction, if the execution environment has a rule engine, then one may not need to be created. Once the engine <b>1130</b> has been located/created and the compiled rule set <b>1128</b> has been added to it, the agent <b>1124</b> requests a new working memory <b>1132</b> from the rule engine. As before, the working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>1124</b> is ready to execute the rule engine. Once the move operation completes, the old version of the agent <b>1118</b> in execution environment <b>1114</b> indicates to the requesting application <b>1118</b> in execution environment <b>1112</b> that the move operation has completed. Once the notification has been made, the old agent <b>1118</b> is destroyed.

0067Execution Environment Rule Set Usage

0068Each execution environment may have access to a local rule repository which allow for the rules for a particular domain, domain rules, to be distributed, or partitioned, in any number of rule repositories. An agent may be configured to only use rules provided at construction essentially ignoring rules available from each execution environment's local rule repository. The more general case is for the agent to make use of the rules that it carries with itself along with the rules extracted from the execution environment's local rule repository. Local rule repositories may contain rules for several different domains and are usually specific to execution environment objects that will be asserted to working memory but may also apply to execution environment concerns such as security, resource usage, scheduling, or any other execution environment attribute.

0069Referring now to <figref idref="DRAWINGS">FIG. 12</figref>, a diagram illustrating an example process of constructing an agent remotely with a set of canonical rules carried by the agent and a set of canonical rules resident in a remote environment is shown. An application <b>1218</b>, in execution environment <b>1212</b>, requests a set of rules for an agent from a rule repository <b>1220</b> in execution environment <b>1214</b> based on the goals of the agent that is being created. The result is a collection of canonical rules, known as a rule set <b>1230</b>. The rule set <b>1230</b> is passed to the agent <b>1232</b> during construction in execution environment <b>1216</b>. During construction, the agent <b>1232</b> requests the set of rules from a local rule repository <b>1234</b> given the agent's domain (not shown). The result of which, canonical rule set <b>1236</b>, is then merged with the construction supplied rule set <b>1230</b> to form a merged rule set <b>1222</b>. This rule set contains all the domain and environment specific rules that the agents' rule engine will execute. The agent <b>1232</b> then takes the merged rule set <b>1222</b> and requests that it be compiled by the local rule compiler <b>1226</b>. This results in the creation of a compiled rule set <b>1238</b>. At this point the agent creates a rule engine <b>1224</b> that will be used to execute the rule set <b>1238</b>. Note that if execution environment <b>1216</b> includes a rule engine, then one may not need to be created. After the rule engine <b>1224</b> is created or located, the agent <b>1232</b> supplies the engine <b>1224</b> with the compiled rule set <b>1238</b>. Finally, the agent <b>1232</b> requests a new working memory <b>1228</b> from the rule engine <b>1224</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine.

0070Referring now to <figref idref="DRAWINGS">FIG. 13</figref>, a diagram illustrating an example process of constructing an agent remotely with a set of canonical rules fetched by the agent and a set of canonical local rules resident in a remote environment is shown. An application <b>1318</b>, in execution environment <b>1312</b>, requests the creation of an agent <b>1332</b> in execution environment <b>1316</b>. Agent <b>1332</b> is passed the location of a rule repository <b>1320</b> during construction. During construction, the agent <b>1332</b> requests a set of rules based on its goals from the rule repository <b>1320</b> in execution environment <b>1314</b>. The result is a collection of canonical rules, known as a rule set <b>1330</b>. During construction, the agent <b>1332</b> requests the set of rules from a local rule repository <b>1334</b> that apply to its domain. The result of which, canonical rule set <b>1336</b>, is then merged with the fetched rule set <b>104</b> to form a merged rule set <b>1322</b>. This rule set contains all the domain and environment specific rules that the agents' rule engine will execute. The agent <b>1332</b> then takes the merged rule set <b>1322</b> and requests that it be compiled by the local rule compiler <b>1326</b>. This results in the creation of a compiled rule set <b>1338</b>. At this point the agent creates a rule engine <b>1324</b> that will be used to execute the rule set <b>1338</b>. Note that if execution environment <b>1316</b> includes a rule engine, then one may not need to be created. After the rule engine <b>1324</b> is created or located, the agent <b>1332</b> supplies the engine <b>1324</b> with the compiled rule set <b>1338</b>. Finally, the agent <b>1332</b> requests a new working memory <b>1328</b> from the rule engine <b>1324</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine.

0071Referring now to <figref idref="DRAWINGS">FIGS. 14-15</figref>, diagrams illustrating an example process of moving an agent carrying canonical rules to an execution environment that includes a local repository of canonical rules are shown. Referring now to <figref idref="DRAWINGS">FIG. 14</figref>, an application <b>1418</b> in execution environment <b>1412</b> requests that an agent <b>1422</b> in execution environment <b>1414</b> move to execution environment <b>1416</b>. The location of execution environment <b>1416</b> may be described in the move request by an IP address and port, Uniform Resource Locator (URL), or any other means of addressing. The agent <b>1422</b> discards its rule engine <b>1430</b> along with the associated compiled rule set <b>1428</b> and working memory <b>1432</b>. The agent <b>1422</b> then encodes itself along with its canonical rule set <b>1420</b> into a transferable form <b>1424</b>. Though a byte array is shown, the encoded agent could take any form that can be transferred between the two execution environments. Once the agent <b>1422</b> has created an encoded version of itself <b>1424</b> in execution environment <b>1414</b> it transfers the encoded version <b>1424</b> to an agent manager <b>1426</b> residing in execution environment <b>1416</b>.

0072Referring now to <figref idref="DRAWINGS">FIG. 15</figref>, the process continues with the agent manager <b>1522</b> receiving the encoded agent <b>1534</b>. Upon receipt of the encoded agent <b>1534</b>, the agent manager <b>1522</b> decodes the encoded agent <b>1534</b> into a new agent <b>1526</b> and its canonical rule set <b>1540</b> in execution environment <b>1516</b>. Once the agent <b>1526</b> and rule set <b>1540</b> have been decoded, the agent manager <b>1522</b> requests that the agent <b>1526</b> initialize. This request prompts the agent <b>1526</b> to request the set of rules applicable to the agent's domain from a local rule repository <b>1536</b>. The result of which, canonical rule set <b>1538</b>, is then merged with the carried rule set <b>1540</b> to form a merged rule set <b>1534</b>. This rule set contains all the domain and environment specific rules that the agents rule engine will execute. The agent <b>1526</b> then takes the merged rule set <b>1534</b> and requests that it be compiled by the local rule compiler <b>1524</b>. The result is a compiled rule set <b>1528</b>. The agent then creates a new rule engine <b>1530</b> and subsequently passes the compiled rule set <b>1528</b> to it. As during construction, if the execution environment has a sharable rule engine, then one may not need to be created. Once the engine <b>1530</b> has been located/created and the compiled rule set <b>1528</b> has been added to it, the agent <b>1526</b> requests a new working memory <b>1532</b> from the rule engine. As before, the working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. Once the move operation completes, the old version of the agent <b>1520</b> in execution environment <b>1514</b> indicates to the requesting application <b>1518</b> in execution environment <b>1512</b> that the move operation has completed. Once the notification has been made, the old agent <b>1520</b> is destroyed.

0073As-Needed Rules

0074As there is a cost of carrying around unnecessary rules in terms of both CPU and memory usage, it is desirable in many cases to supply an agent with a subset of its total potential rule set. This can be done in a context-specific manner based on the goals and execution environment of the agent. For example, if each device upon which an agent will be executing only contains a small screen, then there is no need to carry the rules for display on a standard computer monitor. As another example, an agent who moves progressively further in a single direction, perhaps among GPS enabled fixed location devices, need not carry rules that only apply to previous GPS locations.

0075Referring now to <figref idref="DRAWINGS">FIG. 16</figref>, a diagram illustrating an example process of constructing an agent at a remote location with an as-needed set of canonical rules supplied during construction is shown. An application <b>1618</b>, in execution environment <b>1612</b>, requests a set of rules for an agent from a rule repository <b>1620</b> in execution environment <b>1614</b> based on the goals and initial execution environment of the agent that is being created. When supplied with a target execution environment, the rule repository <b>1620</b> can filter out rules that do not apply to that type of environment. The result is a collection of canonical rules, known as a rule set <b>1622</b>. The rule set <b>1622</b> is passed to the agent <b>1624</b> during construction in execution environment <b>1616</b>. The agent <b>1624</b> in execution environment <b>1616</b> takes the rule set <b>1622</b> and requests that it be compiled by the local rule compiler <b>1626</b>. This results in the creation of a compiled rule set <b>1628</b>. At this point the agent creates the rule engine <b>1630</b> that will be used to execute the rule set. Note that if execution environment <b>1616</b> includes a rule engine, then one may not need to be created. After the rule engine <b>1630</b> is created or located, the agent <b>1624</b> supplies the engine <b>1630</b> with the compiled rule set <b>1628</b>. Finally, the agent <b>1624</b> requests a new working memory <b>1632</b> from the rule engine <b>1630</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>1624</b> is ready to be moved to another execution environment or to execute the rule engine.

0076Referring now to <figref idref="DRAWINGS">FIG. 17</figref>, a diagram illustrating an example process of constructing an agent at a remote location with an as-needed set of canonical rules fetched during construction is shown. An application <b>1718</b>, in execution environment <b>1712</b>, requests the creation of an agent <b>1724</b> in execution environment <b>1716</b>. Agent <b>1724</b> is passed the location of a rule repository <b>1720</b> during construction. During construction, the agent <b>1724</b> requests a set of rules based on its goals and execution environment from the rule repository <b>1720</b> in execution environment <b>1714</b>. When supplied with the target execution environment, the rule repository <b>1720</b> can filter out rules that do not apply to that type of environment. The result is a collection of canonical rules, known as a rule set <b>1722</b>. The agent <b>1724</b> in execution environment <b>204</b> takes the rule set <b>1722</b> and requests that it be compiled by the local rule compiler <b>1726</b>. This results in the creation of a compiled rule set <b>1728</b>. At this point the agent creates the rule engine <b>1730</b> that will be used to execute the rule set. Note that if execution environment <b>1714</b> includes a rule engine, then one may not need to be created. After the rule engine <b>1730</b> is created or located, the agent <b>1724</b> supplies the engine <b>1730</b> with the compiled rule set <b>1728</b>. Finally, the agent <b>1724</b> requests a new working memory <b>1732</b> from the rule engine <b>1730</b>. The working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. At this point, the agent <b>1724</b> is ready to be moved to another execution environment or to execute the rule engine.

0077Referring now to <figref idref="DRAWINGS">FIGS. 18-19</figref>, diagrams illustrating an example process of moving an agent from one execution environment to another with a supplied as-needed set of canonical rules are shown. An application <b>1818</b> in execution environment <b>1812</b> requests that an agent <b>1822</b> in execution environment <b>1814</b> move to execution environment <b>1816</b>. The location of execution environment <b>1816</b> may be described in the move request by an IP address and port, Uniform Resource Locator (URL), or any other means of addressing. The move request includes a new as-needed canonical rule set <b>1834</b> based on the agent's goals and target execution environment. The agent <b>1822</b> discards its rule engine <b>1830</b> along with the associated compiled rule set <b>1828</b> and working memory <b>1832</b>. In addition the agent <b>1822</b> discards its old canonical rule set <b>1820</b>. At this point, the agent <b>1822</b> encodes itself along with its new as-needed canonical rule set <b>1834</b> into a transferable form <b>1824</b>. Though a byte array is shown, the encoded agent could take any form that can be transferred between the two execution environments. Once the agent <b>1822</b> has created an encoded version of itself <b>1824</b> in execution environment <b>1814</b> it transfers the encoded version <b>1824</b> to an agent manager <b>1826</b> residing in execution environment <b>1816</b>.

0078Referring now to <figref idref="DRAWINGS">FIG. 19</figref>, the process continues with the agent manager <b>1922</b> receiving an encoded agent <b>1934</b>. Upon receipt of the encoded agent <b>1934</b>, the agent manager <b>118</b> decodes the encoded agent <b>1934</b> into a new version of the agent <b>1924</b> and its new canonical rule set <b>1926</b> in execution environment <b>1916</b>. Once the agent <b>1924</b> and rule set <b>1926</b> have been materialized, the agent manager <b>1922</b> requests that the agent <b>1922</b> initialize. This request prompts the agent <b>1922</b> to go to the execution environments' rule compiler <b>1920</b> and request compilation of its canonical rule set <b>1926</b>. The result is a compiled rule set <b>1928</b>. The agent then creates a new rule engine <b>1930</b> and subsequently passes the compiled rule set <b>1928</b> to it. As during construction, if the execution environment has a rule engine, then one may not need to be created. Once the engine <b>1928</b> has been located/created and the compiled rule set <b>1926</b> has been added to it, the agent <b>1922</b> requests a new working memory from the rule engine. As before, the working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. Once the move operation completes, the old version of the agent <b>1918</b> in execution environment <b>1914</b> indicates to the requesting application <b>1918</b> in execution environment <b>1912</b> that the move operation has completed. Once the notification has been made, the old agent <b>1934</b> is destroyed.

0079Referring now to <figref idref="DRAWINGS">FIGS. 20-21</figref>, diagrams illustrating an example process of moving an agent from one execution environment to another with a fetched as-needed set of canonical rules are shown. An application <b>2018</b> in execution environment <b>2012</b> requests that an agent <b>2022</b> in execution environment <b>2014</b> move to execution environment <b>2016</b>. The location of execution environment <b>2016</b> may be described in the move request by an IP address and port, Uniform Resource Locator (URL), or any other means of addressing. The move request includes a reference to a rule repository <b>2038</b> from which the agent should fetch a new as-needed rule set. Upon receiving the move request, the agent <b>2022</b> requests a new as-needed rule set from the supplied rule repository <b>2038</b> based on its goals and target execution environment <b>2016</b>. After receiving the new canonical rule set <b>2034</b>, the agent <b>2022</b> discards its rule engine <b>2030</b> along with the associated compiled rule set <b>2028</b> and working memory <b>2032</b>. In addition the agent <b>2022</b> discards its old canonical rule set <b>2020</b>. At this point, the agent <b>2022</b> encodes itself along with its new as-needed canonical rule set <b>2034</b> into a transferable form <b>2024</b>. Though a byte array is shown, the encoded agent could take any form that can be transferred between the two execution environments. Once the agent <b>2022</b> has created an encoded version of itself <b>2024</b> in execution environment <b>2014</b> it transfers the encoded version <b>2024</b> to an agent manager <b>2026</b> residing in execution environment <b>2016</b>.

0080Referring now to <figref idref="DRAWINGS">FIG. 21</figref>, the process continues with the agent manager <b>2122</b> receiving an encoded agent <b>2134</b>. Upon receipt of the encoded agent <b>2134</b>, the agent manager <b>2122</b> decodes the encoded agent <b>2134</b> into a new version of the agent <b>2124</b> and its new canonical rule set <b>2126</b> in execution environment <b>204</b>. Once the agent <b>2124</b> and rule set <b>124</b> have been materialized, the agent manager <b>2122</b> requests that the agent <b>2124</b> initialize. This request prompts the agent <b>2124</b> to go to the execution environment's rule compiler <b>2120</b> and request compilation of its canonical rule set <b>2126</b>. The result is a compiled rule set <b>2128</b>. The agent then creates a new rule engine <b>130</b> and subsequently passes the compiled rule set <b>2128</b> to it. As during construction, if the execution environment has a sharable rule engine, then one may not need to be created. Once the engine <b>2130</b> has been located/created and the compiled rule set <b>2126</b> has been added to it, the agent <b>2124</b> requests a new working memory from the rule engine. As before, the working memory will hold all of the data the agent chooses to assert before and during execution of the rule engine. Once the move operation completes, the old version of the agent <b>2138</b> in execution environment <b>2114</b> indicates to the requesting application <b>2118</b> in execution environment <b>2112</b> that the move operation has completed. Once the notification has been made, the old agent <b>2138</b> is destroyed.

0081Dynamic Determination of Needed Rules

0082Large rule sets, even with efficient algorithms such as Rete, are often expensive in computation and bandwidth. The process of dynamically removing rules considered unlikely to be useful has a benefit to performance and also, combined with mobile agents, provides an efficient method for utilizing large rule sets that can be partitioned across many repositories. This method also allows an agent to dynamically change the rules to meet the execution environment processing task.

0083Each constructed agent has a unique identifier for itself and this identifier is also known to the agent's originator. At the point of origination, this identifier will be associated with the agent's outcome. An example outcome is successfully attaining an end goal and sending the results back to the application. Another example outcome is the loss or death of the agent. An agent that is determined to be lost or dead may cause a replacement agent to be launched. The replacement agent will have a unique identifier that differs from the original agent. In addition to a unique agent identifier, an agent also carries with it an indicative subset of the set of previously completed agent outcomes for the given domain. This is a set of unique identifiers and outcomes for agents that have previously executed in the domain of the current agent.

0084In each execution environment, the local rule repository not only stores rules, but is also the location for agents to record statistics about rule engine activity for the rules in the rule set given to the rule engine. These instrumented rules include agent carried rules and rules for the domain that were retrieved from the local rule repository. Alternately, only the locally acquired domain rules may be instrumented.

0085Referring now to <figref idref="DRAWINGS">FIG. 22</figref>, a diagram illustrating an example process of a rule-based agent updating rule statistics when rule processing has completed in an execution environment is shown. As before, an agent <b>2218</b> starts its associated rule engine <b>2222</b> to process its compiled rule set <b>2220</b>. During the course of execution, the rule engine <b>2222</b> may successfully match part of the condition (left hand side) of a rule, may match the condition of a rule and activate it, or may match and activate and fire a rule (perform the consequences of the rule). A rule engine may provide for collection of the statistics for the phases of rule activity mentioned. Alternately, the agent may integrate listener code to monitor these phases of rule execution and collect the statistics as the rule engine executes. A rule being fired may result in the rule asserting new data into the working memory <b>2224</b> and/or the agent <b>2218</b> collecting more data and asserting that into the working memory <b>2224</b>. Once an end goal terminates rule processing, or the agent receives a move event, a termination event, a timeout or some other event, then the rule engine is halted. At this point, the agent <b>2218</b> requests rule statistics from the rule engine <b>2222</b> or collects the statistics from the agent's rule engine listener. These statistics may include, but are not limited to the number of times a rule was fired, the number of times a rule was activated, the number of times a goal in the condition of a rule was matched, the number of times a part of the condition of a rule was matched, or any combination of the above. The statistics <b>2226</b> are then added to aggregate rule history stored in the local rule repository <b>2216</b>. These stored statistics may include statistics for rules that are not available in the local rule repository since an agent can carry rules with it as it moves.

0086When the agent prepares to move to another execution environment it dynamically determines to remove unnecessary rules by consulting the rule history associated with some or all of the rules in its current rule set in conjunction with the indicative subset of previously completed agent outcomes that the agent carries. Referring now to <figref idref="DRAWINGS">FIG. 23</figref>, a diagram illustrating an example process of a rule-based agent dynamically removing unnecessary rules as part of movement to another execution environment is shown. An application <b>2318</b> requests that an agent <b>2326</b> in execution environment <b>2314</b> move to execution environment <b>2316</b>. The agent <b>2326</b> requests a set of rules from the local rule repository <b>2322</b> that are allowed to be carried to other platforms. The result is a canonical rule set <b>2334</b>. This rule set is then merged with the set of rules <b>2320</b> that the agent <b>2326</b> carried with it to execution environment <b>2314</b>. The result is canonical rule set <b>2336</b>.

0087At this point the agent consults the local rule repository <b>2322</b> to get the rule history <b>2330</b> of the rules in set <b>2336</b>. The agent <b>2326</b> then uses the rule history <b>2330</b> with its carried set of previous agent outcomes to remove rules from rule set <b>116</b> that are unlikely to participate in a desired outcome. The statistics are used in aggregate form. As an example consider an agent that carries the results of <b>2318</b> previously executed agents and their outcomes, 50 of which were desirable outcomes. The agent examines the metrics for a particular rule named “A” which shows that it was never activated. The agent then removes rule “A” from its agent carried rule set. As another example consider rule “B” which has been activated and fired in one-third of previous desirable outcomes but also has been active and fired in nearly all negative outcomes. Rule “B” remains in the agent carried rule set. Finally, a rule, “C”, which never activates for any as yet recorded desired outcomes but has been active in almost all negative outcomes can be considered a computational burden and removed from the agent carried rule set. Although activation is a criterion above, finer grained partial left-hand side matching statistics can be used as well. Since rule removal requires an aggregate of previous runs a threshold is provided so that no rule deletion is permitted until a requisite number of outcomes has been obtained.

0088Once the pruned rule set <b>2332</b> has been created, the agent <b>2326</b> encodes itself along with its pruned rule set <b>2332</b> into a transferable form in execution environment <b>2314</b>. The agent <b>2326</b> then transfers the encoded version of itself in execution environment <b>2314</b> to an agent manager <b>2346</b> resident in the target execution environment <b>2316</b>. The remainder of the move process follows that of <figref idref="DRAWINGS">FIG. 5</figref>.

0089Survivability Rules

0090All agents have a lifespan; but that lifespan need not be pre-determined if a set of rules around survivability of an agent is put in place. These rules may be agent specific or execution environment specific. They may be carried with the agent or resident in a rule repository for the execution environment. As these rules are like any other declarative rules, they may be any combination of the above according to the teachings of this invention. In addition, these rules may be used in conjunction with more typical survivability mechanisms such as heartbeats between the application and the agent.

0091Referring now to <figref idref="DRAWINGS">FIG. 24</figref>, a diagram illustrating an example process of an agent using a set of survival rules to determine its lifespan is shown. Agent survivability is controlled by the rules loaded in the local compiled rule set <b>2428</b>. As before, the local rule set may be comprised of rules supplied or fetched from rule repository <b>2420</b> during construction, rules carried from other visited execution environments and/or execution environment specific rules retrieved from rule repository <b>2426</b>. Many sources of data that may be asserted into the working memory and, combined with the local rule set <b>2428</b>, affect the agent's <b>2424</b> lifespan. Examples include lifespan update events from application <b>2418</b>, heartbeat events from application <b>2418</b>, timer events from the execution environment's timer system <b>2434</b>, and even state change events from the agent <b>2424</b> itself. As data is asserted into the working memory, the rules engine guarantees that applicable rules are fired. Any number of rules might result in the agent <b>2424</b> taking actions that affect its survivability. This includes death of the agent <b>2424</b> which is shown. When an agent <b>104</b> dies it halts rule engine processing, records any collected historical statistics for the local rule set and stores these in the rule repository <b>2436</b>.

0092Data Narrowing Rules

0093Agent may visit many execution environments each with differing levels of network connectivity or an execution environment with multiple levels/types of network connectivity. Given this, it is important that an agent take this into consideration when responding to application requests, sending periodic reports, and determining how much data to carry with it when moving. As per the teachings of this invention, execution environment specific rules are an ideal method for insuring the appropriate agent behavior. If the networking capabilities of the execution environment are static, then rules for this may be maintained in the rule repository on the execution environment running the application that launched the agent. In many cases though, the capabilities may be more dynamic in which case the rules regarding network bandwidth are better kept on the remote execution environment.

0094Referring now to <figref idref="DRAWINGS">FIG. 25</figref>, a diagram illustrating an example process of the of an agent using a set of data narrowing rules to determine how much data should be sent over the network is shown. This diagram shows the same agent in three different scenarios. As before, each agent is communicating with an application <b>2532</b> that in this case is hosted on server <b>2530</b> which is connected to a high-speed data network, <b>2534</b>. In the first scenario, the agent <b>2514</b> has been constructed on or moved to server execution environment <b>2512</b>, which is connected to the high speed data network directly via a gigabit ethernet link <b>2544</b>. The agent <b>2514</b> utilized a rule-based system that is driven by the associated rule engine <b>2516</b>. This engine <b>2516</b> has been loaded with execution environment specific rules about the current network bandwidth capabilities of the execution environment <b>2512</b>. In this example the agent <b>106</b> completes a task which will ultimately generate a report back to the application <b>2532</b> on execution environment <b>2530</b>. When that task completes, that event causes a rule to fire in the engine <b>2516</b>, which instructs the agent <b>2514</b> to send a detailed report. In this case, a detailed report is appropriate because a high bandwidth connection is available between the agent <b>2514</b> and the application <b>2532</b>.

0095In the second scenario, that same agent now labeled <b>114</b> has moved to a home computer <b>2518</b> which is connected to the network via a DSL connection <b>2546</b>. As before, the engine <b>2522</b> is loaded with the execution environment specific rules regarding bandwidth available to the execution environment. As the agent <b>2520</b> completes its task, the event causes a rule to fire, which instructs agent <b>2520</b> to send a full report, which contains less data than the detailed report described previously. Note, that the agent <b>2520</b> is not compressing the same data, but sending a different data-set back—a subset of the data to fit the bandwidth available.

0096In the final scenario, the agent, now labeled <b>2526</b> has moved to the mobile device <b>2524</b>. The mobile device is connected to the high speed data network via a relatively low speed cellular data network <b>2536</b>. As before, the agent <b>2526</b> completes its task which results in the rule engine <b>2528</b> firing a rule. This firing causes the agent <b>2526</b> to dispatch a much smaller summary report to the application <b>2532</b> in order to accommodate the low bandwidth connection.

0097Methods, computer readable media and systems have been shown and/or described in the above embodiments for moving an agent that utilizes supplied rules and rules resident in an execution environment. Although the above descriptions set forth embodiments, it will be understood that there is no intent to limit the invention by such disclosure, but rather, it is intended to cover all modifications and alternate implementations falling within the spirit and scope of the invention. For example, the present invention should not be limited to a single agent, or to a particular programming language for the execution environment. Furthermore, the association of agent to execution environments is not limited to the topology depicted. Lastly, the embodiments are intended to cover capabilities and concepts whether they be via a loosely couple set of components or they be converged into one or more integrated components, devices, circuits, and/or software programs.