System and method for creating a performance tool and a performance tool yield6931622
Abstract
A system and method for generating a performance tool includes a builder, a seeker, and a catalyst. The builder is used to generate the seeker. The seeker is selected for operation, thereby launching the catalyst. The catalyst runs the seeker and receives assertions, such as selected answers, in response to interrogatives, such as questions. When all assertions are provided to all interrogatives, the seeker generates a yield. However, the yield also can be generated dynamically as the seeker operates.
Claims
1. A system for determining requirements for a yield comprising:
a seeker comprising at least one interrogative, at least one potential assertion, and logic associated with a combination of the interrogative and an assertion provided in response to the interrogative and the at least one potential assertion and configured to generate the yield as a solution based on the interrogative, the assertion, and the logic;
a builder configured to build the seeker; and
a catalyst configured to operate the seeker and, based on the interrogative and the assertion, to execute the logic to select at least one component for the yield.
2. The system of claim 1 further comprising a controller configured to operate at least one member of a group comprising the builder and the catalyst.
3. The system of claim 2 wherein the builder further comprises builder programming language code and the controller comprises:
a processor configured to process the builder programming language code and input data to effect generating the seeker;
memory configured to store the input data for the processing of the builder programming language code; and
a user interface configured to receive and transmit to the processor the input data for the builder to effect generating the builder programming language code.
4. The system of claim 3 wherein the user interface further is configured to generate other data for manifestation.
5. The system of claim 3 wherein the user interface comprises at least one member of a group comprising a graphical user interface, a voice recognition interface, a voice activated interface, a voice generation interface, a video interface, and an audio interface.
6. The system of claim 3 wherein the controller further comprises an input/output interface configured to receive other data from an external device to effect generating the seeker.
7. The system of claim 2 wherein the controller comprises:
a processor configured to process the seeker, including the logic, and the input data to effect generating the yield for the seeker;
memory configured to store seeker data for the seeker and to transmit to the processor the seeker data; and
a user interface configured to receive and transmit to the processor the seeker data to effect processing the logic of the seeker.
8. The system of claim 7 wherein the user interface further is configured to generate other data for manifestation.
9. The system of claim 7 wherein the user interface comprises at least one member of a group comprising a graphical user interface, a voice recognition interface, a voice activated interface, a voice generation interface, a video interface, and an audio interface.
10. The system of claim 7 wherein the controller further comprises an input/output interface configured to receive other data from an external device to effect processing the seeker.
11. The system of claim 1 further comprising a repository configured to store data used by at least one member of a group comprising the builder and the catalyst.
12. The system of claim 11 wherein the repository is configured to store objects used by the builder to build the seeker.
13. The system of claim 12 wherein the objects comprise at least one member of a group comprising a decision node, an action node, an input node, an output node, a pipe node, a process node, a smart component node, a define object an order object, a network element object, an email object, a database update object, a notification object, a run test object, a launch chat object, an open media object, an open link object, a get data object, and a help link object.
14. The system of claim 11 wherein the repository is configured to store objects used by the catalyst to process the seeker.
15. The system of claim 14 wherein the objects comprise at least one member of a group comprising a decision node instance, an action node instance, an input node instance, an output node instance, a pipe node instance, a process node instance, a smart component node instance, a define object, an order object, a network element object, an email object, a database update object, a notification object, a run test object, a launch chat object, an open media object, an open link object, a get data object, and a help link object.
16. The system of claim 1 further comprising a security system configured to govern access to at least one member of a group comprising the builder and the seeker.
17. The system of claim 1 further comprising a super-user system configured to access the builder and to generate the seeker.
18. The system of claim 1 further comprising a user system configured to access the seeker and to launch the catalyst to operate the seeker.
19. A system for determining requirements for a yield comprising:
a seeker configured with a plurality of interrogatives, a plurality of potential assertions, and a plurality of command strings, at least one potential assertion corresponding to each interrogative, and at least one command string corresponding to each combination of each interrogative and the corresponding at least one potential assertion; and
a builder configured to generate the interrogatives, the potential assertions, and the command strings, to associate the potential assertions to the interrogatives, and to associate the command strings to the combinations of each interrogatives and the corresponding at least one potential assertions to build the seeker.
20. A system for determining a yield comprising:
a seeker configured to generate a plurality of interrogatives and a plurality of potential assertions, at least one potential assertion associated for each interrogative, and configured with a plurality of command strings, each command string corresponding to a combination of one of the interrogatives and the associated at least one potential assertion; and
a catalyst configured to operate the seeker, to process command strings associated with the combinations of one of the interrogatives and the associated at least one potential assertions, and, in response thereto, to select at least one component for a the yield.
21. A system for determining a seeker comprising:
an input manager configured to receive an input and to generate a command string corresponding to the input;
a builder interpreter configured to receive the command string, to execute a command method corresponding to the command string, and, in response, to identify a data component for the seeker;
a builder collector configured to store the data component; and
a process manager configured to receive the command string from the input manager, to pass the command string to the builder interpreter, to receive the data component from the builder interpreter, and to store the data component in the builder collector.
22. The system of claim 21 wherein the builder interpreter is configured to crate an instance of a command object having the command method prior to executing the command.
23. The system of claim 21 wherein.
the builder interpreter further is configured to create a command factory and to pass the command string to the command factory; and
the command factory is configured to create an instance of a command object having the command method and to pass the command method to the builder interpreter for execution.
24. The system of claim 23 wherein the command method comprises an execute method and the builder interpreter is configured to execute the execute method.
25. The system of claim 21 wherein the input manager further is configured to receive a command as the input and, in response, to generate a command request for additional input, to receive the additional input, and to create the command string using the command and the additional input.
26. The system of claim 25 further comprising a display manager wherein:
the input manager further is configured to pass the command request to the display manager; and
the display manager is configured to receive the command request and to render the request for the additional input.
27. The system of claim 26 wherein the display manager is configured to render the request by generating for display a dialogue box identifying the request for additional input.
28. The system of claim 26 wherein the display manager is configured to render the request by generating an audio simulated voice identify the request for additional input.
29. The system of claim 21 further comprising a display manager configured to render an interface identifying an option for the input.
30. The system of claim 29 wherein the option comprises at least one member of a group comprising a text entry box, a drop down box, and a command selection and the display manager is configured to generate a display interface for display, the display interface identifying the at least one member of the group comprising the text entry box, the drop down box, and the command selection.
31. The system of claim 29 wherein the option comprises at least one member of a group comprising a verbal entry, a verbal selection list, and a verbal command selection and the display manager is configured to generate an audio interface having an audio simulated voice identifying the at least one member of the group comprising the verbal entry, the verbal selection list, and the verbal command selection.
32. The system of claim 21 further comprising a display manager configured to render the data component.
33. The system of claim 32 wherein the display manager is configured to render the data component using at least one member of a group comprising a display interface and an audio interface.
34. The system of claim 32 wherein:
the input manager further is configured to pass a command request for additional information to the process manager; and
the process manager further is configured to retrieve the additional information from a repository and to transit the additional information to the input manager.
35. The system of claim 21 further comprising a command factory configured to create an instance of a command object having the command method and to pass the command object to the builder interpreter.
36. The system of claim 21 further comprising a builder collector configured to store the data component.
37. The system of claim 36 wherein the data component comprises a data object.
38. The system of claim 21 further comprising a deployment manager configured to distribute a plurality of data components for the seeker to a deployment location.
39. The system of claim 21 further comprising a debug manager configured to generate an execution of the command method to an output device.
40. The system of claim 39 wherein the debug manager has an on mode in which a data stream identifying the command method execution is transmitted to the output device and an off mode in which the data stream identifying the command method execution is not transmitted to the output device.
41. The system of claim 21 further comprising at least one base node having a type and at least one method and data for the type and configured to execute according to the type.
42. The system of claim 41 wherein the type comprises at least one member of a group comprising a decision node, a process node, a pipe node, an output node, and a smart component node.
43. The system of claim 42 wherein the type consists of the decision node and the method and data, when executed, are configured to generate an interrogative for which at least one assertion may be provided.
44. The system of claim 42 wherein the type consists of the process node and the method and data, when executed, are configured to generate text.
45. The system of claim 42 wherein the type consists of the process node and the method and data, when executed, are configured to generate a process.
46. The system of claim 42 wherein the type consists of the pipe node and the method and data, when executed, are configured to connect at least two objects.
47. The system of claim 42 wherein the type consists of the output node and the method and data, when executed, are configured to identify an output type and an output location for a yield of the seeker.
48. The system of claim 42 wherein the type consists of the smart component node and the method and data, when executed, are configured to execute an automated process.
49. The system of claim 41 wherein the base node comprises:
a node property comprising at least one property and an argument for a node type; and
a node position comprising positioning information for the base node identifying a position for an output at which the base node is located.
50. The system of claim 41 wherein the base node comprises a smart component comprising at least one method that, when executed, results in at least one member of a group comprising automating a process and rendering a data component.
51. A system for determining a seeker comprising:
an input manager configured to receive an input and to generate a command string corresponding to the input;
a command factory configured to create an instance of a command object having a command in an execute method and to pass the command object for execution;
an interpreter configured to receive the command string, to create the command factory and to pass the command string to the command factory, to receive the command object from the command factory, to execute the execute method, and thereafter, to identify a data component for the seeker;
a collector configured to store the data component; and
a process manager configured to receive the command string from the input manager, to create the interpreter, to pass the command string to the interpreter, to receive the data component from the interpreter, and to store the data component in the collector.
52. A system for processing a seeker comprising:
a flow manager configured to process at least one interrogative to generate the interrogative and at least one potential assertion, to receive at least one assertion in response hereto, and, thereafter, to process logic for the interrogative and the assertion to select at least one component having at least one variable to generate a yield; and
a yield manager configured to store the component having the variable for the yield.
53. The system of claim 52 wherein the logic comprises at least one command string set.
54. The system of claim 52 further comprising a user interface configured to render the interrogative and the potential assertion.
55. The system of claim 54 wherein the user interface comprises at least one member of a group comprising a graphical user interface, a voice simulated interface, a voice response interface, and a voice activated interface.
56. The system of claim 52 further comprising a user interface configured to receive the assertion as an input.
57. The system of claim 56 wherein the user interface comprises at least one member of a group comprising a graphical user interface, a voice simulated interface, a voice response interface, and a voice activated interface.
58. The system of claim 52 wherein:
the flow manager further is configured to process a plurality of interrogatives to generate the interrogatives and a plurality of potential assertions, to receive and process a plurality of assertions in response thereto, at least one assertion corresponding to each interrogative, and, thereafter, to select a plurality of components, each component having at least one variable, to generate the yield; and
the yield manager further is configured to store the components having the variables for the yield.
59. The system of claim 58 further comprising a user interface configured to render the interrogatives and the potential assertions.
60. The system of claim 59 wherein the user interface comprises at least one member of a group comprising a graphical user interface, a voice simulated interface, a voice response interface, and a voice activated interface.
61. The system of claim 58 further comprising a user interface configured to receive the assertions as inputs.
62. The system of claim 61 wherein the user interface, comprises at least one member of a group comprising a graphical user interface, a voice simulated interface, a voice response interface, and a voice activated interface.
63. The system of claim 52 wherein the flow manager comprises:
a component store configured with a component list having a component identification and a type corresponding to the component identification for a plurality of components;
an interrogative configured to generate an interrogative object having interrogative data and at least one potential assertion and to pass the interrogative object;
a flow manager assertion configured to receive an assertion object provided in response to the interrogative and to pass the assertion object;
interpretive logic configured to receive the interrogative object and the assertion object and to select a command string set in response thereto; and
an interpreter configured to receive the command string set from the interpretive logic, to execute at least one command method corresponding to the command string set, and, in response, to select at least one component from the component list for the yield.
64. The system of claim 63 wherein the interrogative comprises at least one member of a group comprising a question interrogative, a listener interrogative, and a component execution interrogative.
65. The system of claim 63 wherein the assertion object is selected in response to the interrogative and further is configured with a reference to a next interrogative.
66. The system of claim 63 wherein the interpreter further is configured to set a variable for the selected component for the yield.
67. The system of claim 63 further comprising a command factory configured to receive the command string set from the interpreter, to create at least one command object having the command method, the command object corresponding to the command string set, and to pass the command object to the interpreter.
68. The system of claim 63 wherein:
the system further comprises a command factory configured to receive the command string set from the interpreter, to create a plurality of command objects corresponding to the command string set, each command object having a corresponding command method, and to pass the command objects to the interpreter; and
the interpreter further is configured to create the command factory, to pass the command string set to the command factory, to receive the command objects from the command factory, to execute the corresponding command method of the command objects, and to perform at least one member of a group comprising select a plurality of components from the component store for the yield, selecting the at least one component and setting the at least one variable for the component, and setting a plurality of other variables for a plurality of other components.
69. The system of claim 63 wherein:
the system further comprises a command factory configured to receive the command string set from the interpreter, to create at least one command object having the command method, the command object corresponding to the command string set, and to pass the command object to the interpreter; and
the interpreter further is configured to create the command factory and to pass the command string set to the command factory.
70. The system of claim 63 further comprising native code configured to modify the component when the component is added to the yield.
71. The system of claim 52 wherein the yield manager further comprises:
a reversal block configured to store anti-logic corresponding to the processed logic;
a response history configured to store the assertion selected in response to the interrogative;
a yield variables configured to store the variable for the component; and
a yield collector configured to store the component.
72. The system of claim 52 wherein:
the yield manager further comprises:
a reversal block configured to store anti-logic corresponding to the processed logic;
a response history configured to store the assertion selected in response to the interrogative;
a yield variables configured to store the variable for the component; and
a yield collector configured to store the component; and
the flow manager further comprises:
a component store configured with a component list having a component identification and a type corresponding to the component identification for the component and a plurality of other components;
an interrogative configured to generate an interrogative object having interrogative data and at least one potential assertion, and to pass the interrogative object to the response history;
a flow manager assertion configured to receive an assertion object provided in response to the interrogative, and to pass the assertion object to the response history;
interpretive logic configured to receive the interrogative object and the assertion object and to select a command string set in response thereto; and
an interpreter configured to receive the command string set from the interpretive logic, to execute at least one command method corresponding to the command string set, and, in response, to select from the component store the at least one component having the at least one variable for the yield, to store the component in the yield collector, to set the variable in the yield variables, and to create the anti-logic opposing the executed command method, and to store the anti-logic in the reversal blocks.
73. A system for determining requirements for a seeker comprising:
a repository comprising a builder;
a server configured to access the repository to create an instance of the builder and to transmit the builder instance from the server; and
a super-user system configured to connect to the server via a connection, to download the builder instance to the super-user system, and to operate the builder instance to generate the seeker configured with a plurality of interrogatives a plurality of potential assertions, and a plurality of command strings, at least one potential assertion corresponding to each interrogative, and at least one command string associated to each combination of the at least one potential assertion and the corresponding interrogative.
74. The system of claim 73 further comprising a network wherein the super-user and the server are a part of the network and wherein the connection comprises an internet protocol connection.
75. A system for determining requirements for a seeker comprising:
a repository comprising a builder;
a server configured to access the repository to create an instance of the builder and to make the builder instance operational from the server; and
a super-user system configured to connect to the server via a connection and to operate the builder instance from the server to generate the seeker configured with a plurality of interrogatives, a plurality of potential assertions, and a plurality of command strings, at leas one potential assertion corresponding to each interrogative, and at least one command string associated to each combination of the at least one potential assertion and the corresponding interrogative.
76. A system for determining requirements for a yield comprising:
a repository comprising a seeker and a catalyst;
a server configured to access the repository to create an instance of the catalyst and an instance of the seeker and to transmit the seeker instance and the catalyst instance from the server; and
a user system configured to connect to the server via a connection, to download the catalyst instance and the seeker instance to the user system, to launch the catalyst instance with the seeker instance from the user system, and to operate the seeker instance to generate the yield.
77. The system of claim 76 further comprising a network wherein the user and the server are a part of the network and wherein the connection comprises an internet protocol connection.
78. A system for determining requirements for a yield comprising:
a repository comprising a seeker and a catalyst;
a server coffin to access the repository to create an instance of the catalyst and an instance of the seeker and to make the seeker instance operational with the catalyst distance from the server; and
a user system configured to connect to the server via a connection, to launch the catalyst instance with the seeker instance from the server, and to operate the seeker to instance generate the yield.
79. A system for generating a performance tool comprising:
a process object panel configured with a plurality of process objects;
a repository object panel configured with a plurality of repository objects; and
a graphic seeker representation panel configured to receive a plurality of seeker objects three dimensionally, each connected to at least one other, identifying a three dimensional seeker process, the plurality of seeker objects comprising at least one member of a group comprising at least one process object and at least one repository object.
80. The system of claim 79 further comprising at least one command button configured to generate a command for at least one object added to the graphic seeker representation panel.
81. The system of claim 80 wherein the command button further is configured to enable entry of an argument after the command is generated.
82. The system of claim 80 wherein the at least one command button comprises a command from at least one member of a group comprising create decision, create pipe, create process, create output, create smart component, enable, disable, if, endif, then, launch, link, unlink, load, new, remove, save, and, set, set response, and equals.
83. The system of claim 79 wherein the process object panel comprises at least one member of a group comprising:
a decision element configured to generate at least one interrogative with at least one corresponding potential assertion from which at least one assertion may be selected as a decision;
an action element configured to identify an action to be taken in response to a selected assertion or in response to a selected output;
an input configured to identify input data needed for the decision or the action; and
an output element configured to identify an outcome of the action or the decision.
84. The system of clam 79 wherein the repository object panel comprises at least one member of a group comprising a define object, an order object, a network element object an email object, a database update object, a notification object, a run test object, a launch chat object, an open media object, an open link object, a get data object and a help link object.
85. A system for generating a performance tool comprising:
a plurality of components each having a component identification and a type;
an interrogative configured with interrogative data;
a potential assertion configured with assertion data selectable in response to the interrogative; and
a command string set corresponding to a combination of the interrogative and the selected potential assertion that when processed for execution and executed, is configured to cause selection of at least one of the components for a yield.
86. A system for determining requirements for a yield comprising:
a seeker comprising a plurality of interrogatives and a plurality of potential assertions, a selected one of the plurality of assertions corresponding to each interrogative, and configured to generate the yield as a solution based on the interrogatives and the selected assertions;
a builder configured to build the seeker; and
a catalyst configured to operate the seeker to generate the interrogatives and the potential assertions and to receive the selected assertions to generate the yield.
Description
FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
Not Applicable
MICROFICHE APPENDIX
Not Applicable
FIELD OF THE INVENTION
The present invention relates to the field of generating performance tools known as seekers with a computer implemented seeker builder and operated by a seeker catalyst.
BACKGROUND OF THE INVENTION
Computer programs and processes are created for performance analysis and for creating solutions for building systems and performing processes. Many of these systems and processes are complex, and creating the programs to perform the analysis and to create the solution takes a significant amount of time. In addition, when the process or system is complex, it is difficult to program all of the steps that require performance due to the amount of detail required for the solution. Moreover, because of the significant time required, sometimes months, the process or system required for the solutions may change before the programming is complete. Therefore, an improved builder/seeker system is needed to perform analysis of requirements for a solution and to do so in a more responsive period of time. Additionally, a more advanced form of a builder application is needed to facilitate the capture and modification of instructions and data associated with a seeker and the process to which a seeker is intended to address.
SUMMARY OF THE INVENTION
The present invention is directed to a system for a system for determining requirements for a yield. The system comprising at least one interrogative, at least one potential assertion, and logic associated with a combination of the interrogative and an assertion provided in response to the interrogative and the potential assertion and configured to generate the yield as an absolute solution based on the interrogative, the assertion, and the logic. A builder is configured to build the seeker. A catalyst is configured to operate the seeker and, based on the interrogative and the assertion, to execute the logic to select at least one component for the yield.
The present invention further is directed to a system for determining requirements for a yield. The system comprises a seeker configured with a plurality of interrogatives, a plurality of potential assertions, and a plurality of command strings. At least one potential assertion corresponds to each interrogative. At least one command string corresponds to each combination of an interrogative and a potential assertion. A builder is configured to generate the interrogatives, the potential assertions, and the command strings. The builder further is configured to associate the potential assertions to the interrogatives and to associate the command strings to combinations of the interrogatives and the potential assertions to build the seeker.
Further still, the present invention is directed to a system for determining a yield. The system comprises a seeker configured to generate a plurality of interrogatives and a plurality of potential assertions. At least one potential assertion corresponds to each interrogative. The seeker further is configured with a plurality of command strings, and each command string corresponds to a combination of an interrogative and a selected potential assertion. A catalyst is configured to operate the seeker, to process command strings associated with combinations of the interrogatives and the selected potential assertions, and, in response thereto, to select at least one component for a yield.
Still further, the present invention is directed to a system for determining a seeker. The system comprises an input manager configured to receive an input and to generate a command string corresponding to the input. A builder interpreter is configured to receive the command string, to execute a command method corresponding to the command string, and, in response, to identify a data component for the seeker. A builder collector is configured to store the data component. A process manager is configured to receive the command string from the input manager, to pass the command string to the builder interpreter, to receive the data component from the builder interpreter, and to store the data component in the builder collector.
Also, the present invention is directed to a system for determining a seeker. The system comprises an input manager configured to receive input and to generate a command string corresponding to the input. A command factory is configured to create an instance of a command object having a command in an execute method and to pass the command object for execution. An interpreter is configured to receive the command string, to create the command factory and to pass the command string to the command factory, to receive the command object from the command factory, to execute the execute method, and, thereafter, to identify a data component for the seeker. A collector is configured to store the data component. A process manager is configured to receive the command string from the input manager, to create the interpreter, to pass the command string to the interpreter, to receive the data component from the interpreter, and to store the data component in the collector.
Additionally, the present invention is directed to a system for processing a seeker. The system comprises a flow manager configured to process at least one interrogative to generate the interrogative and to process at least one potential assertion, to receive at least one assertion in response thereto, and, thereafter, to process logic for the interrogative and the assertion to select at least one component having at least one variable to generate a yield. A yield manager is configured to store the component and the variable for the yield.
Further, the present invention is directed to a system for determining requirements for a yield. The system comprises a repository comprising a builder. A server is configured to access the repository to create an instance of the builder and to transmit the builder instance from the server. A super-user system is configured to connect to the server via a connection, to download the builder instance to the super-user system, and to operate the builder instance to generate the seeker.
Further yet, the present invention is directed to a system for determining requirements for a seeker. The system comprises a repository comprising a builder. A server is configured to access the repository to create an instance of the builder and to make the builder instance operational from the server. A super-user system is configured to connect to the server via a connection and to operate the builder instance from the server to generate the seeker.
Still further, the present invention is directed to a system for determining requirements for a yield. The system comprises a repository comprising a seeker and a catalyst and a server configured to access the repository to create an instance of the catalyst and an instance of the seeker and to transmit the seeker instance and the catalyst instance from the server. A user system is configured to connect to the server via a connection, to download the catalyst instance and the seeker instance to the user system, to launch the catalyst instance with the seeker instance from the user system, and to operate the seeker instance to generate the yield.
Additionally, the present invention is directed to a system for determining requirements for a yield. The system comprises a repository comprising a seeker and a catalyst and a server configured to access the repository to create an instance of the catalyst and an instance of the seeker and to make the seeker instance operational with the catalyst instance from the server. A user system is configured to connect to the server via a connection, to launch the catalyst instance with the seeker instance from the server, and to operate the seeker to generate the yield.
Moreover, the present invention is directed to a system for generating a performance tool. The system comprises a process object panel is configured with a plurality of process objects. A repository object panel is configured with a plurality of repository objects. A graphic seeker representation panel is configured to receive a plurality of seeker objects three dimensionally identifying a three dimensional seeker process. Each object is connected to at least one other object. The plurality of seeker objects comprise at least one member of a group comprising at least one process object and at least one repository object.
The present invention also is directed to a system for generating a performance tool. The system comprises a plurality of components each having a component identification and a type. An interrogative is configured with interrogative data. A potential assertion is configured with assertion data selectable in response to the interrogative. A command string set corresponds to a combination of the interrogative and the selected potential assertion that, when processed for execution and executed, is configured to cause selection of at least one of the components for a yield.
Further yet, the present invention is directed to a system for determining requirements for a yield. The system comprises a seeker comprising a plurality of interrogatives and a plurality of potential assertions, a selected one of the plurality of assertions corresponding to each interrogative, and configured to generate the yield as an absolute solution based on the interrogatives and the selected assertions. A builder is configured to build the seeker. A catalyst is configured to operate the seeker to generate the interrogatives and the potential assertions and to receive the selected assertions to generate the yield.
Further still, the present invention is directed to a system for determining requirements for a yield. The system comprises a seeker comprising a plurality of interrogatives and a plurality of potential assertions, a selected one of the plurality of assertions corresponding to each interrogative, and configured to generate the yield as an absolute solution based on the interrogatives and the selected assertions. A catalyst is configured to operate the seeker to generate the interrogatives and the potential assertions and to receive the selected assertions to generate the yield.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a seeker system in accordance with an embodiment of the present invention.
FIG. 2 is a block diagram of an exemplary controller in accordance with an embodiment of the present invention.
FIG. 3 is a block diagram of a seeker system operating in accordance with an embodiment of the present invention.
FIG. 4 is a block diagram of a builder system in accordance with an embodiment of the present invention.
FIG. 5A is a message diagram of builder operations system in accordance with an embodiment of the present invention.
FIG. 5B is a continuation of the diagram of FIG. 5A.
FIG. 5C is a continuation of the diagram of FIG. 5B.
FIG. 5D is a continuation of the diagram of FIG. 5C.
FIG. 5E is a continuation of the diagram of FIG. 5D.
FIG. 5F is a continuation of the diagram of FIG. 5B.
FIG. 6 is a block diagram of a catalyst system in accordance with an embodiment of the present invention.
FIG. 7 is a block diagram of a flow manager in accordance with an embodiment of the present invention.
FIG. 8 is a block diagram of a yield manager in accordance with an embodiment of the present invention.
FIG. 9 is a block diagram of a super-user system connected to a server in accordance with an embodiment of the present invention.
FIG. 10 is a block diagram of a user system connected to a server in accordance with an embodiment of the present invention.
FIG. 11 is a block diagram of a super-user system with downloaded component instances in accordance with an embodiment of the present invention.
FIG. 12 is a block diagram of a user system with downloaded component instances in accordance with an embodiment of the present invention.
FIG. 13 is a block diagram of a three dimensional interface in accordance with an embodiment of the present invention.
FIG. 14 is a block diagram of a three dimensional interface generating a seeker in accordance with an embodiment of the present invention.
FIG. 15 is a block diagram of a seeker operating in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION
Builder applications may be written using standard technology, such as JAVA Swing, JAVA, C++, and others. However, an advanced builder application is needed that is intended to facilitate the capture and modification of not only instructions and data associated with a seeker, but also the process that the seeker is intended to address. Such processes range from simple to extremely complex. Highly complex processes may involve intensely complicated branching. Such branching often cannot adequately be expressed using conventional two dimensional diagramming techniques. Thus, a three dimensional builder environment would better facilitate 1) apprehension, organization, and display of complex processes; 2) some automated translation from process information to programming code and appropriate data; 3) debugging support; and 4) deployment support, such as the capacity to distribute seeker data to a variety of platforms, including extensible mark-up language (XML), Oracle platforms, DB2, and Microsoft Access.
The builder application can then be used to build seekers. Seekers are tools that enable a user to perform highly complex processes and to build highly complex systems and devices, without requiring the user to first perform costly and lengthy training in one or more areas of technology.
The systems and methods of the present invention enables a user to rapidly build complex performance tools and solutions that support complex decision processes. They dynamically build unique performance tools and solutions based upon user input or automated responses. The user need not be an experienced programmer or experienced in the technical field in which the tool is to be generated. The invention dynamically writes code for a tool based upon user input or automated responses.
When a system of the present invention is operated, a user or automation system can provide responses to interrogatives. The system uses the responses to provide a solution in varied forms and formats, including a report, medium, graphical based data, links to on-line training, generation of additional tools, activation of automated objects, automated population of databases, and/or other forms.
The systems and methods of the present invention may be enabled in multiple interface forms. For example, systems configured according to the present invention may interface with personal computer systems, including desktop computers and laptop computers, server computer systems, handheld devices, voice response systems, voice generation systems, voice activated systems, graphical systems, and automated systems that do not require user operation.
Additionally, the present invention may generate information through multiple interfaces. For example, the present invention may generate information to a GUI interface, via voice response, as a data stream, for browser enabled systems, and/or other systems.
The present invention is able to collect information through whatever means is required. For example, in one embodiment, the present invention may collect information through voice activation or a graphical user interface (GUI). In another embodiment, the present invention may collect information through data stream automation or a data stream listener.
A data stream listener, for example, monitors a voice or data stream and applies logic to one or more pieces of data from that stream. In one embodiment, a data stream listener monitors a data stream to identify and match portions of the data stream to a specified pattern. If the data stream listener identifies that pattern in the data stream, the data stream listener initiates an action, automates a process, generates a message, and/or takes another action.
The present invention further may be configured to communicate with varied databases. For example, in one embodiment, the present invention may be configured to open a portal to a structured query language (SQL) database, a DB2 database, an Oracle database, and/or another database. In another embodiment, the present invention may be configured to communicate with one of the aforementioned databases or more than one of the aforementioned databases. In other embodiments, the present invention may be configured to communicate with other databases in addition to, or exclusive of, the aforementioned databases.
In some embodiments, the present invention may be configured to automate tasks. A task may be controlled by, and launched through, a smart object or a smart seeker. For example, an e-mail may be automatically launched to a user as part of the implementation of a particular system. In another example, a database may be updated at the end of an implementation of the system.
In some embodiments, the present invention is configured to make decisions or initiate actions based upon pattern matching. With the pattern matching, features are enabled and/or disabled when a pattern is identified. For example, if the pattern in a layer of selected data is determined, a system of the present invention may select options to present for a seeker or to activate a smart object. This pattern matching is advanced over prior systems in which options were enabled or disabled based only on selections made for an immediately prior option.
In some embodiments, the present invention uses object oriented system objects that have unique capabilities. Objects may include text, graphics, data, automation, and/or other attributes. The objects, for example, may be used to build a parts list or to automate a process.
Objects also may include logic and/or processes from other objects. Objects may include modifiers used to further define the object. For example, an object may be defined as a ball. A modifier for large may be added followed by a modifier for red. Thus, the object becomes a large red ball.
Similarly, an object can be defined for a tracking system for a package. An object for a package may be defined with a starting location. A modifier for a first location may be added, followed by a modifier for a second location, followed by a modifier for a third location. A modifier for the destination ultimately may be added. Thus, the object may be defined as a package having a starting point, a first, second, and third location at which the package traveled, and a final destination.
Objects also may be identified as smart objects. A smart object may include a set of properties or smart components that enable the smart object to initiate an action, such as obtaining further information or initiating an automated process. For example, a listener smart object may monitor a data stream, identify a series of bits and/or bytes, and send data with the identified byte stream to another object and/or initiate an automation object, such as automating obtaining data from a selected database and transmitting that data via e-mail to a selected user.
FIG. 1 depicts an exemplary embodiment of a seeker system of the present invention. The seeker system 102 comprises a controller 104. Optionally the seeker system 102 may comprise one or more of a builder 106, a seeker 108, a catalyst 110, a repository 112, a security system 114 and/or a yield 116. A super-user system 118 or a user system 120 may communicate with the seeker system 102. Preferable, the seeker system 102 is developed as an object oriented system. Although, other implementations exist.
The controller 104 operates the components of the seeker system 102. When the seeker system 102 has only a builder 106, the controller 104 operates the builder. The controller 104 may operate the builder 106 to generate one or more seekers, such as the seeker 108. In other instances where the seeker system 102 includes a seeker 108 and a catalyst 110, the controller 104 operates the catalyst so as to run the seeker. Additionally, the controller 104 may control transferring data to and from the repository 112, when included. Further, the controller 104 may operate the security system 114, when included, to control the ability of users to interact with the system.
The controller 104 may be logically or physically divided in some embodiments. For example, the controller 104 may include multiple processors or a single processor.
Further, the controller 104 may be a controller on a server-type system. This may include an intranet server, an internet server, a local area network (LAN), including an ethernet network, a wide area network (WAN), and other networking systems and server enabled systems.
Further, the controller 104 may operate on a standalone basis, such as in a personal computer. Thus, a builder 106, a seeker 108, and/or a catalyst 110 may be downloaded to a computer, such as a personal computer, and operated from the controller 104 on that computer. In this example, the repository 112 may be downloaded to the computer on which the controller 104 resides. Alternately, a link may be established to the repository 112, if required.
The seeker system 102 may be embodied in multiple forms. For example, the seeker system 102 may partially or wholly be included in a networked system, such as an internet system, an intranet system, a LAN, including an ethernet system, a WAN, and other network systems. Additionally, the seeker system 102 may reside wholly or partially on a single computer. For example, one or more components of the seeker system 102 may be loaded or downloaded to a computer, such as a personal computer, and operated from that computer.
The builder 106 is used to create one or more seekers, such as the seeker 108. The builder 106 also may include collectors or containers to hold data and/or objects.
The builder 106 further may be configured to include an interface to enable a user using a user system 120 to input data and to enable a user to identify a seeker that is being constructed and/or builder operations. For example, a builder 106 may include an input manager and an output manager to manage input and output, such as for a GUI or a voice response/voice generation system. In one embodiment, the builder 106 includes a three dimensional (3D) graphical user interface. The 3D interface enables a user to build a seeker by clicking, dropping, and dragging an object to a 3D representation panel and connecting the objects with connectors to depict potential options and/or process flow. The 3D representation enables a user to efficiently depict a process example on a monitor or other output device by providing a system and method used to see and manipulate objects and any supporting objects simultaneously. In other embodiments, the builder 106 may include a voice-based interface, a form-based interface, or other interfaces.
The builder 106 further may be configured with logic to generate command strings. The logic may be used to bind objects and to generate the interrogatives and receive and process assertions and modifiers. The logic may enable a user to create interrogatives and assertions, including modifier objects, to generate a seeker. The logic may be generated for individual objects, including interrogative objects, assertion objects, and modifier objects.
The builder 106 further may be configured with an interpreter to execute the command strings. The executed commands may be used to build interrogatives, assertions, and/or logic for a seeker.
An interrogative provides a decision point. For example, an interrogative may include a question, such as a true or false question, a question with one or more possible assertions, a selection to which a graphic may be a response, or another type of interrogative. An interrogative is a selection directive to which a response is required. An interrogative may be implemented as an interrogative object.
An assertion is a response or potential response or potential response to an interrogative. An assertion may be a selected assertion, such as a selection from a list of four items or a true or false, or entered assertion, such as a text entry from a dialogue box or another entry, a selected or entered graphic, and/or other assertions to interrogatives. Similarly, corresponding potential assertions may include selectable assertions, enterable assertions, selected or enterable graphic assertions, and/or other potential assertions. For example, an interrogative may be generated with a list of four selectable potential assertions (i.e. potential responses). One of the four items may be selected, and the selected item is the selected assertion for that interrogative. An assertion may be implemented as an assertion object that may be selected and defined for a particular interrogative object.
Objects may include interrogative objects, assertion objects, component objects, modifier objects, and other objects. Objects may include data, methods, and/or logic. Objects may be stored in a collector.
Collectors hold objects, including data objects, code bearing objects, and/or a combination of the two. Collectors also hold modifiers and other objects. The collectors facilitate a secondary or external process to produce output.
The seeker 108 receives data and, in response to the data, provides a yield. The yield is an instance of a solution for which the seeker was generated. For example, in a first instance, the yield may identify a parts list that a switch may require so that it may be installed in a network. In another instance, a different parts list may be generated for a yield for a switch that is to be implemented in a different network.
A seeker 108 may contain interrogatives. The interrogatives are generated to a user, and assertions will be collected in response to the interrogatives. Additionally, a seeker 108 may generate automation. For example, a seeker 108 may send itself to a first user, collect information from a first user, send itself to a second user, collect information from the second user, and then provide a yield for which the information was collected. In this example, the seeker 108 may transmit itself to the first and second user via e-mail.
The seeker 108 also may initiate other automated seekers or automated objects. For example, a seeker may activate an automated object that will initiate a connection to a database, collect information from the database, and return the information to the seeker. This connection may be an internet protocol (IP) connection to an internet or intranet location or another connection.
A seeker 108 may be a smart seeker. Smart seekers have artificial intelligence attributes. For example, the smart seeker may be configured to identify trending and to activate an action in response to identifying a trend. For example, the smart seeker may identify three particular assertions to interrogatives and activate another smart seeker that is generated to a user via e-mail for collection of data. In another example, a smart seeker may monitor other seekers used by users and, at a particular level of use, notify a super-user of the use level and increase a system resource, such as processing speed, memory, or bandwidth, allocated to a system on which the seekers operate for those users.
A seeker 108 is a data file containing information required to create an active data object that collects data, including pull down selections and menus, text and graphic objects that are configured to receive and collect text, changeable versions of both data objects and text objects that identify which objects, if any, are to be reactivated to re-collect information, and other objects. An object may re-collect information if an assertion to an interrogative is changed, thereby potentially requiring different selections or assertions for subsequent objects. For example, if a user provided assertions for five interrogatives and subsequently changed an assertion for the third interrogative, then it may be necessary to obtain new assertions for the fourth and/or fifth interrogatives. A changeable version of an object is configured to identify which other interrogatives will re-activated based upon the changed assertion a prior interrogative.
The seeker 108 may be implemented in a variety of formats. For example, the seeker 108 may be a listener seeker, a voice response seeker, a voice activated seeker, a voice generation seeker, a GUI implemented seeker, an automation seeker, and other types of seekers. Listener seekers, for example, may be configured to monitor data, such as a data stream, and take some action or transaction when a specified match is identified. For example, a data listener seeker may monitor a byte stream and e-mail a user when a pattern of bytes is identified. In another example, a listener seeker may monitor voice data, such as in a voice response activated system or a security system, and take some action upon identifying particular words and/or syllables in the voice data stream.
A voice response seeker may activate an action or transaction based upon receiving and identifying a voice, such as receiving voice commands and initiating another seeker in response to the voice commands. Further, a seeker may be a voice simulation seeker. In this example, a seeker would provide voice commands or responses in response to some action or transaction, such as an assertion to an interrogative.
The seeker 108 may include an interface. For example, the seeker 108 may include a GUI configured to provide data to a user graphically or as text. A voice response seeker may have an interface configured to provide data to a user using voice simulation, a GUI, or a combination of the two. An automation seeker may or may not include an interface, depending on the seeker. For example, an e-mail automation seeker may include a GUI interface presented to a user upon opening the e-mail. However, in another example, a data automation seeker activated to query and collect data from a database may not have a user interface, but may have a database interface. Other examples exist.
A seeker 108 may be configured as an evaluator. An evaluator evaluates a level of prior use or a level of prior response to determine a current proposed level of use or current proposed level to which interrogatives may be posed. Thus, an evaluator identifies past performance to dynamically determine a current level to which a user may be set. An evaluator seeker may be used, for example, in a training exercise to determine a level of expertise for a user and then identify a level at which the user may be placed when providing assertions to interrogatives for a network configuration process. If the user demonstrates expertise in a certain area, interrogatives may not be required for a more basic area, such as a basic network setup. Other examples exist.
The seeker 108 may be generated for a series of layers. A seeker for a basic level may not be required to provide graphics and/or reports. A basic level seeker may be selected to provide only text. A process level seeker may enable or disable solution trees, such as with troubleshooting. A complex process level seeker may be configured to enable graphics and/or reports and provide complex logic. For example, a complex process level seeker may place graphics at identified coordinates and provide links to training or help menus. An automation seeker may provide artificial intelligence attributes, such as by initiating an automation process. A trending level seeker may monitor assertions, identify trends, and take an action or a transaction in response to identifying the trend. It will be appreciated that the higher level seekers include functionality of the lower level seekers. For example, the automation seeker also includes attributes of the complex process level seeker. Similarly, the complex process level seeker includes the attributes of the basic level seeker.
The seeker 108 may contain data relational to one or more object components. Object components include process-related objects, such as decisions, actions, yields, interrogatives, assertions, and data; automation objects, such as e-mail automation objects, database update objects, notification objects, test run objects, chat launch objects, and medium open objects; and logic and/or algorithmic objects.
The catalyst 110 operates a seeker, such as the seeker 108. The catalyst 110 is initialized upon activation of a seeker, whether the seeker is activated automatically or through a user selection.
The catalyst 110 processes the builder programming logic, together with data and objects that support processes for the seeker 108, to generate interrogatives or to initiate and/or complete some automation process. When the catalyst 110 generates interrogatives, the catalyst also may be configured to receive assertions. The catalyst 110 processes the assertions with data and/or objects, including objects having supporting processes, to generate a yield for the seeker. As discussed, the yield is a total solution for the seeker. In the instances in which a seeker is an automation seeker, the catalyst 110 may process the automation seeker without generating interrogatives or other data to a user interface and may provide the yield as an input to another process or seeker, as data to a database or some other location, or as some other output.
The catalyst 110 may collect information through multiple collection methods. The catalyst 110 may collect information via a user interface presented to a user through which a user may enter data. The catalyst 110 further may collect information by generating a connection or a link to a database, an internet or intranet site, a network location, or some other location and by retrieving the data from that location. The catalyst 110 may generate queries via the link or connection and receive data in response to the query. The catalyst 110 may use the response data to further operate the seeker 108, such as using the data to determine a next sequence of interrogatives or a next process. The catalyst 110 also may store the data or use the data for some other process or purpose.
The catalyst 110 may use other collection methods. For example, the catalyst 110 may operate a seeker that is listening to streaming data or voice. In this example, the catalyst 110 and the seeker may collect bytes of data, voice samples, or some other data.
The seeker 108 may be operated through an interface that provides interrogatives to a user. For example, the seeker 108 data file, when activated in catalyst 110, may generate a user interface that queries a user for necessary scenario-based information. Moreover, a seeker 108 may operate in different formats, languages, and methods of collection simultaneously using the same source objects that were associated in the builder 106 to create the seeker 108. The seeker 108 may be configured to generate one or more user interfaces having one or more different formats, including different language formats and/or different types of user interfaces, such as a GUI or a voice simulated or voice response interface.
The repository 112 stores data and objects for temporary, semi-permanent, and/or permanent use. The repository 112 may be virtual or a physical device, and it may be logically parsed into one or more configurations. The repository 112 may be accessed as necessary, including a server based configuration, such as a web enabled configuration, and a downloadable configuration. For example, the controller 104 may open a portal to the repository 112 and move an instance of one or more objects to the controller for processing. Alternately, the controller 104 may open a portal to the repository 112, and an instance of one or more objects may be processed from the repository. In another example, objects may be downloaded from the repository 112 to a standalone computer, such as a personal computer. In such a configuration, the controller 104 may initiate a portal to the repository 112 and control the download to the computer. Alternately, the computer may initiate a portal directly to the repository 112 or via the controller 104 to the repository.
The security system 114 governs access for a user or a super-user to the seeker system 102. The security system 114 may provide access to a builder 106 or a seeker 108 based upon access rights identified for a user or a super-user. For example, a password for a user or a super-user may identify the level of access or use for that user or super-user. Preferably, the security system 114 will process an identification and/or a password to identify and to provide the level of access and/or use to a user or super-user.
The yield 116 is the absolute solution generated by the seeker 108 when operated by the catalyst 110. Because the yield 116 is based on the dynamic collection of assertions and/or data from the seeker 108, the yield is a dynamic and accurate solution for an instance of a seeker. Thus, the yield 116 is generated dynamically as assertions are selected for interrogatives. Moreover, a user or super-user using a super-user system 118 may view or otherwise identify, such as through a voice system, the dynamic yield 116, assertions, and components selected in response to assertions dynamically as they are created. Therefore, a user or super-user can view or otherwise identify the yield as it is being constructed or processed.
Each instance of a seeker may result in a different instance of a yield 116. The yield 116 may identify a component, a system, and/or a process. Alternately, the yield may be data, an object, a system, a process, and/or another function. In addition, the yield 116 may be an automation, such as an automatically generated e-mail, a smart seeker or a smart object, an automated system, an automated process, or another automated yield. Other examples of other yields exist.
The super-user system 118 is a processor-based system that enables a super-user to communicate with the seeker system 102. The super-user system 118 may be a personal computer, a networked computer, or some other processor-based system. The super-user system 118 enables a user to send and receive data, including commands, logic, objects, user interfaces, and other data, to and from the seeker system 102.
The user system 120 is a processor-based system that enables a user to communicate with the seeker system 102. The user system 120 may be a personal computer, a networked computer, or some other processor-based system. The user system 120 enables a user to send and receive data, including commands, logic, objects, user interfaces, and other data, to and from the seeker system 102.
The seeker system 102 of FIG. 1 operates as follows. In a first example, a super-user connects to the seeker system 102. In this example, the seeker system 102 includes a controller 104, a builder 106, and a repository 112. The builder 106 is operated by the controller 104 and may store data and/or objects at the repository 112 as needed and/or retrieve data and/or objects from the repository as needed.
The super-user uses the builder 106 to create the seeker 108. In this example, the super-user produces a list of interrogatives with possible assertions for each so that the interrogatives, when generated to a user, each are associated with a pull down menu that can be generated to a user interface. The builder 106 uses the builder programming language code (BPLC) to create the interrogatives, to create and associate assertions with interrogatives, to designate how the interrogatives will be presented, and, to designate how one or more next interrogatives and assertions will be presented to the user, based on selected assertions. In this example, the builder 106 has an interface through which the super-user can generate the BPLC. The builder 106 further uses the BPLC to generate the logic with which each interrogative and assertion will be processed for generation to a user and, based upon the assertions provided by a user, what the yield will be.
While operating, the builder 106 uses objects and data stored in the repository 112. For example, an automated object or other repository object may be needed for a process or a data stream listener object may be needed by the builder and obtained from the repository. Other objects and/or data may be needed by the builder 106 while operating and may be obtained via the repository 112. Additionally, the builder 106 may store data in the controller 104 or the repository 112 for temporary, semipermanent, and/or permanent use.
In another example, the seeker system 102 includes a controller 104, a seeker 108, a catalyst 110, and a repository 112. A user connects to the seeker system 102 via an IP connection. In this example, the IP connection is an intranet connection. The user selects the seeker 108, which launches the catalyst 110. The catalyst 110 operates the seeker 108 and is controlled by the controller 104.
In this example, the seeker 108 generates a user interface for the user. Through the user interface, the seeker 108 presents a series of interrogatives. The user responds to the interrogatives with assertions. The seeker 108 is configured to select from among a series of interrogatives based upon assertions presented in response to a prior interrogative. Thus, for example, if a user responds to an interrogative by presenting a first assertion, the seeker 108 will then generate interrogative D to the user. Whereas, if the user presents a second assertion in response to an interrogative, the seeker 108 will generate interrogative G to the user via the user interface. Each assertion to each interrogative initiates a similar response by the seeker 108 to provide additional and/or final interrogatives so that a yield may be determined. In other examples, the seeker 108 may be configured to step through a sequence of interrogatives, regardless of the assertions presented in response to the interrogatives.
After the seeker 108 has presented the final interrogative to the user, and the user has responded with the final assertion, the seeker generates the yield. In some instances, the seeker 108 presents the yield to the user via the user interface. Although, the yield may be used for other purposes. For example, if the yield of the seeker 108 is a parts list, the seeker may be configured to generate the parts list via the user interface, email the parts list to an e-mail address, generate the parts list to another seeker, store the parts list in a database or other device, and/or take some other action.
While operating, the seeker 108 uses objects and data stored in the repository 112. For example, a graphic may be needed for a user interface or a data stream listener object may be needed by the seeker and obtained from the repository. Other objects and/or data may be needed by the seeker 108 while operating and may be obtained via the repository 112. Additionally, the seeker 108 may store data in the controller 104 or the repository 112 for temporary, semi-permanent, and/or permanent use.
FIG. 2 depicts an exemplary embodiment of a controller that may be used with the present invention. The controller 104A of FIG. 2 comprises a processor 204, a memory 206, a user interface 208, and an input/output interface 210. The controller 104A may communicate with a database 212 and/or a device 214. Other examples of controllers exist.
The processor 204 processes software and/or firmware to carry out operations for the controller 104A, including processing builder programming language code and catalyst programming language code. The processor 204 may be configured to process data and command strings or execute methods of objects to effect processes for a builder 106 or a catalyst 110. Execute methods of objects, including command objects, sometimes may be referred to as command methods.
The processor 204 may be configured to control transmitting data, including messages, to and from the controller 104A via the input/output (I/O) interface 210. The processor 204 also may be configured to control generating information to the user interface 208 and receiving information from the user interface. The processor 204 further may control transmitting data to the memory 206 for temporary, semi-permanent, and/or permanent storage and retrieving data from memory.
The memory 206 is configured to store data used by the processor 204 during operation and to provide access for that data to the processor. The memory 206 is configured to store data for temporary, semi-permanent, and/or permanent storage. Thus, the memory 206 may include volatile memory and/or non-volatile memory. Examples of such memory are random access memory (RAM), non-volatile RAM (NVRAM), read only memory (ROM), including programmable read only memory (PROM), erasable programmable read only memory (EPROM), and/or electrically erasable programmable read only memory (EEPROM). The memory 206 also may include flash memory or scratch memory.
The user interface 208 is configured to generate data for manifestation to a user system and/or receive data from a user system. For example, the user interface 208 may include a GUI, a web enabled interface, a voice activated interface, a voice recognition interface, a voice simulated generation interface, a keyboard, a mouse, and other input and output devices. A GUI or web enabled interface may include interfaces generated to monitors for personal computers and other computers and interfaces generated for hand held devices, such as a palm pilot, a wireless phone, or another hand held unit. It will be appreciated that an interface may include one or more of the interfaces identified above or other interfaces. For example, an interface may include a voice activated/voice recognition interface and a voice generation interface.
Generating data for manifestation of a GUI interface may include generating data for display on a monitor, a hand held device, or another GUI interface. The user interface 208 also may include a video interface or an audio interface, such as an MP3 interface. Generating data for manifestation of an audio interface, such as a voice generation interface, may include generating data for voice simulation or other voice generation. Generating data for manifestation of a video interface may include generating data for video display. Other examples exist.
The I/O interface 210 communicates with the database 212 and other devices for which communication is required, such as the device 214, to effect generating a seeker 108 by a builder 106 or to effect processing a seeker by a catalyst 110. When communicating with the database 212, the I/O interface 210 opens a connection to the database. The I/O interface 210 may push or pull data to or from the database 212 or transmit or receive other data, including messages, to the device 214. The I/O interface 210 may be configured to communicate with any database, including an SQL database, a DB2 database, via XML, an Oracle database, and others.
The I/O interface 210 may be configured to communicate using wireless and wireline communications. For example, the I/O interface 210 may be configured to communicate with the database 212 or the device 214 via a LAN, a WAN, a radio frequency (RF), a digital wireless network, a fiber link, a digital service level link, via an IP connection, and other modes.
The database 212 is configured to store data. The database 212 may be, for example, an SQL database, an Oracle database, a DB2 database, and other database types.
The device 214 is a device configured to communicate with the controller 104A. The device 214 may be, for example, a personal computer, a server, a wireless based communication device, an IP device, a router, or another type of device configured to communicate with the controller 104A.
FIG. 3 depicts an exemplary embodiment of an instance of the seeker system 102A. In the instance of FIG. 3, an instance of a builder 106A is used to build a seeker 108A. The seeker 108A is selected for operation, thereby launching the catalyst 110A. In other embodiments, the catalyst 110A may be launched and may be used to select a seeker for operation. The catalyst 110A processes the seeker 108A to collect data and/or assertions. The catalyst 110A processes the final data and/or assertions with logic from the seeker 108A to generate the yield 116A.
FIG. 4 depicts an exemplary embodiment of a builder. The builder 106B of FIG. 4 comprises an input manager 402, a deployment manager 404, a debug manager 406, a rendering manager, such as a display manager 408, a process manager 410, a builder interpreter 412, a builder command factory 414, and a builder collector 416. Preferably the components of the builder 106B are implemented as objects in an object-oriented system.
The input manager 402 captures information entered by a user and creates command strings based on the information entered by the user, including voice entry, text entry, selection of a position of an input device, such as a pointer, selection of a corresponding location of a cursor based on an input from a keyboard, a voice command, or other information. The command strings may be referred to alternately as builder programming language code 418.
In one embodiment, command strings are generated based on a selected command button on a user interface, voice commands, subsequent entries provided by a user in response to a dialogue box, a voice prompt, or another prompt, location selections made by locating a pointer on a monitor or other location selection medium and clicking or otherwise selecting a specific location. Alternately, a location may be selected by generating a set of coordinates using a keypad, a keyboard, a voice command, or another location selection medium. Thus, a location selection medium may be a device or combination of devices that enable selection of a location at which a graphic, text, an object, or another input/output appliance is placed. Examples of command buttons include create decision, create pipe, create process, create output, set, if, endif, and, then. Other examples exist.
Preferably, each of the command strings generated in response to selection of a command and other entries are used to create an object or set a property for an object. For example, a Create Decision command button may be used to create a decision object. The Create Pipe command is used to create an object that connects two or more other objects. The create process command is used to create an object that identifies a process. The Create Output command is used to create an output object that generates some output to a screen, paper, a disk, a seeker, or another output. The Create Smart Component command is used to create a smart component object used to generate objects to a screen or to another output device. The Set command is used to set a property for a created object. The if, and, endif, and, then, and, equal (=), and similar commands or text entries are used in the creation of specific command strings for the creation or setting of the above referenced command strings or objects. Once created, the decision object, pipe object, process object, output object, smart component object, and other similar objects may be referred to as nodes.
A command string typically has a command, a name and/or a property, an operator, and an argument. For example, a user may select a create decision command. The user then may be prompted to enter the name of the decision node and a position at which a graphic for the decision node may be placed. The user may enter the word "Color" for the name of the decision node, place a pointer on a monitor, and then select a location on the monitor by clicking a selection button, such as a mouse click. The input manager 402 will associate the name Color for the particular decision node to be created, calculates the virtual position of the location on the monitor at which the pointer selected, and create a command string, such as the following: Create Decision Color @ 104:404:0. In this example, the decision node that was created is named Color, and the preliminary position of the object Color when generated for display on a monitor will be 104 on the X axis, 404 on the Y axis, and 0 on the Z axis. In this example, the command is Create Decision, the name is Color, the operator is @, and the argument is 104:404:0.
The input manager 402 transmits the command strings to the process manager 410. In some instances, the input manager 402 may receive a command string from the process manager 410 for execution. Typically, a command string received by the input manager 402 from the process manager 410 will include an instruction to obtain information from a user.
The input manager 402 is configured to obtain data associated with each command to be generated when a command is selected. Thus, when a command is selected, such as with a command button, the input manager 402 obtains a name, a property, an operator, an argument, or other command string data required to complete a command string. For each selectable command, the input manager 402 is configured with the required command string data and the mode in which the command string data may be obtained. For example, the input manager 402 may be configured to generate a dialogue box or another prompt or read data provided by another input/output device, such as to read a virtual location of a pointer when a location on a monitor is selected. Alternately, the input manager 402 may be configured to obtain command string data from another location, such as a repository.
Each command string has command string fields that can be populated with command string data. In one example, the command string fields include a command, a name, a property, an operator, and an argument. In this example, the command is generated upon selection of a command button that is selected from a display. The other command string data used to populate the command string fields may be collected by the input manager 402 using varied methods, depending on the command fields and the selected command. For example, the input manager 402 may generate a dialogue box, a voice prompt, or another prompt from which a user may input data. Additionally, the input manager 402 may collect command string data by reading a virtual position on a display at which a pointer was placed and a selection was made, such as by placing a pointer or cursor at the position on a monitor and clicking a mouse button or another pointer selection device. Further, the input manager 402 may collect command string data from a repository, an external database, or another seeker.
The deployment manager 404 distributes data and objects to a location for use by a user. Preferably, the deployment manager 404 has one or more tables that identify the location at which the data and/or objects for a seeker are to be deployed. The tables in the deployment manager 404 may be configurable, loaded from another location, and/or dynamically populated from an object or a smart seeker. Preferably, the deployment manager 404 copies files or data and/or objects to the deployment location, such as to directories on a server or to directories on a local computer.
The debug manager 406 causes command strings and executed commands to be generated to an output device, such as a system console, a monitor, a printer, a disk, or another output device. The debug manager 406 also generates representative output for display. While in debug mode, commands are executed in the builder interpreter 412 using the "debug" method instead of using the "execute" method. The debug method causes data streams to be generated to a selected output device as the commands are executed. The data stream identifies the executed commands and their output.
The debug manager 406 has a "debug on" mode and a "debug off" mode. The debug manager 406 is configured to send the "debug on" command or the "debug off" command to the process manager 410 depending on which command is selected by a user.
A rendering manager is configured to render data and/or objects (i.e. data components) for an output. Rendering may include rendering using a display interface, rendering using an audio interface, or rendering using another type of interface. Thus, a rendering manager may generate a data component, a dialogue box, or other data for display or generate a simulated voice for an audio interface to identify a data component, an audio entry, or other data to be generated using a voice system. It will be appreciated that other output rendering managers may be present in other embodiments, such as a voice manager managing rendering voice output. In the embodiment of FIG. 4, the rendering manager is a display manager 408.
The display manager 408 is configured to generate for display data and/or objects. The display manger 408 may be configured to generate for display data and/or objects for a browser or another display interface, such as a browser window operating from a personal computer or a server.
The process manager 410 is the controlling agent of the builder 106A. The process manager 410 receives command strings from the input manager 402, the deployment manager 404, the debug manager 406, and the display manager 408 (collectively, the manager components 402-408). In response to receiving a command string, the process manager 410 reads a base interpreter object from memory and creates one or more instances of the builder interpreter 412. The process manager 410 then transmits on or more command strings to each of the one or more instances of the builder interpreter 412. The process manager 410 can create one builder interpreter instance and pass all command strings to the builder interpreter instance, create multiple builder interpreter instances and pass one command string to each instance, or create multiple builder interpreter instances and pass one or more command strings to each builder interpreter instance. Additionally, the process manager 410 receives command strings from the builder interpreter 412, determines which of the manager components 402-408 that each command string is to be sent, and transmits that command string to the determined manager component.
The builder interpreter 412 receives command strings, reads the command strings, and executes associated commands, such as command objects or execute methods of objects. The builder interpreter 412 creates a builder command factory 414, when needed, to create command objects and other objects based on command strings received from the process manager 410. The builder interpreter 412 determines when and whether one or more command factories are to be created and which command strings are to be passed to one or more command factories. However, the function and operation of the command factory 414 may be included with the builder interpreter 412 without having the separate command factory. The builder interpreter 414 also may be configured to store components in the builder collector 416 (via the process manager) or to retrieve components from the builder collector, to set variables of the components, and to perform other processes when executing commands.
In some embodiments, the builder interpreter 412 is created to process a command string and execute associated command objects. The builder interpreter 412 thereafter collapses itself. In other embodiments, more than one builder interpreter 412 is created, each for one or more command strings. Other embodiments may include a persistent interpreter or more than one persistent interpreters, whether object oriented or in some other form.
The builder command factory 414 receives one or more command strings and creates executable commands. Preferably, the builder command factory 414 creates command objects having execute methods. In one example, the builder command factory 414 is configured to read a command string, retrieve from memory a base command object corresponding to the command, create an instance of that base command object for the command in the command string with one or more execute methods, and pass the one or more command objects to the builder interpreter 412.
The execute methods may be based on the name, type, operator, and argument in the command string. Alternately, the execute methods may include base methods and/or commands from the base command object. Depending on the specific base command object, the execute method may perform a different process. For example, the builder command factory 414 may have a command create object and a command set object. In this example, the execute method of the command create object, when run, will create a specific instance of an object, and the execute method of the command set object will set a property of a specific instance of an object.
The builder command factory 414 may be configured to identify the command object and the parameters associated with the command object instance to be created by the command string received from the builder interpreter 412. The builder command factory 414 may be configured to read the first word of the command string to identify the command. The balance of the command string preferably identifies the instance command object to be created. In one embodiment, the second word in the command string identifies the node object for which the immediate command object instance will be created. For example, a node object may include a decision node, a process node, a pipe node, an output node, or a smart object node. Preferably, the name of the node follows the node identification, and the argument follows an operator.
For example, a command string may be Create Decision Color @ 104:404:0. In this example, Create identifies the base command object of command create. Decision identifies the CommandCreate object having a type of decision node. Color identifies the name of the decision node to be created. 104:404:0 identifies the argument of a property of the Color decision node, which in this case is the location property. Other examples exist.
The builder command factory 414 then creates an instance of the command object for population or execution. An instance of the command object will contain the methods and/or data of the base command object. When the instance of that base command object is run, the instance of the command object will execute behavior that is associated with that command.
In some embodiments, the builder command factory 414 is created to create an instance of an object for a command string, and the command factory thereafter collapses itself. In other embodiments, more than one builder command factory is created, each for one or more command strings. Still other embodiments may include a persistent command factory or more than one persistent command factories, whether object oriented or some other form.
The builder collector 416 holds data and/or objects, such as graphic objects, that are created by commands and/or objects executed by the builder interpreter 412. Once an object or data is created, the process manager 410 may store the object or data in the builder collector 416. The object may be retrieved, modified, and again stored in the builder collector 416. Thus, the builder collector 416 is configured to store objects on a temporary, semi-permanent, and/or permanent basis. Further, the builder collector 416 stores the objects from the point at which they are created by the builder interpreter 412 to the point at which they are generated for display by the display manager 408. The objects stored by the builder collector 416 include instances of the base node objects, including instances of a decision node, a process node, a pipe node, an output node, and a smart component node. The data and/or objects may be referred to alternately as data components or data objects.
The builder programming language code 418 includes the command strings described above that are sent between the manager components 402-408 and the process manager 410. The command strings are processed by the process manager 410, the interpreter 412, and/or the builder command factory 414.
A base node 420 is a base object having a type, one or more properties, and one or more methods that can be used to create a seeker. For example, a base node 420 may include a type, e.g. instance, of a decision node, a process node, a pipe node, an output node, and a smart component node. Each type of base node 420 may have a different set of methods and/or data to accomplish different results. For example, a decision node may be used to generate interrogatives for which one or more assertions ultimately may be provided or selected. A process node may be used to generate text or hold a process that may be executed. A pipe node may be used to connect two or more other objects and to identify a connection, such as a communication link identifying line speed and cost. An output node may be used to identify an output type and a destination type, such as an output report having a destination of a printer, an e-mail address, or a seeker. One or more instances of a base node 420 may be generated by the builder interpreter 412 and stored in the builder collector 416.
Preferably, each base node 420 includes a node property 422, a node position 424, and/or a smart component 426, including any combination thereof. An instance of a base node 420 may include one or more instances of the node property 422, a node position 424, and/or a smart component 426.
The node property 422 includes one or more properties for the instance of the base node. Each property may have an argument. For example, an instance of a decision node may include a node property for a question and another node property for an option. The argument of the question property may be the actual question to be presented to a user. The argument of the options property may be selectable options or enterable options to be presented or selected in response to the question.
The node property 422 includes information that differentiates the instance of the base node 420 from other nodes and information that is uniquely appropriate to that particular node. For example, the base node 420 may contain an instance of a node property object 422, containing assigned attributes, including name, color, and shape. In this example, the name attribute will have an argument identifying the name of the node. The color attribute will have an argument identifying the color of the object to be rendered. The shape attribute will have an argument identifying the shape of the object to be rendered.
The node position 424 contains data identifying the position of the instance of the base node 420. The positioning information specifies where an object or an element of an object is located on an output device and/or in relation to other objects. The position information may be provided to the instance of the base node 420 by direct entry, by populating the position information from a repository, by filling the position information from another source, such as when defining that instance of that base node 420, and by other entry or populating means.
A smart component 426 contains instance data and instance behavior. The smart component 426 behavior also may contain methods for the instance of the base node 420. For example, a smart component 426 may contain behavior identifying how to render an object, including how to generate for display a specified shape, how to generate a connection for the shape, and how to share information with other objects. The smart component 426 further may include specific execute method tables and fields that facilitate behavior, methods, and data sharing with other objects.
The system of FIG. 4 operates as follows. With reference to FIG. 4 and FIGS. 5A-5F, in a first example the builder 106B is used to create and set a base object called Color having a decision node type. Referring to FIGS. 5A-5B, a user 502 selects a "create decision" button. The user 502 then may select a location on a screen or other output display at selected coordinates, such as by placing the cursor at a location on the screen and clicking a mouse button.
The input manager 402 recognizes that the "create decision" button and a set of coordinates have been selected. In response, the input manager 402 generates a dialogue box for display on a monitor requesting the name of the decision object to be created. In one embodiment, the input manager 402 calls the display manager 408 directly to generate the dialogue box, such as with a command request. This is done through a method, such as "showDialog( )," and the method is executed through the display manager 408 reference. An example of an entire command may be "outputManager.showDialog( )." Other methods exist for the input manager 402 to generate a dialogue box.
The user then enters the word "Color" to identify the name of the decision object. The input manager 402 receives the input and generates a command string having the command, the type, the name "Color," the operator, and the argument. In this example, the input manager 402 generates a command string for Create Decision Color @ Coordinates. The coordinates may be any selected coordinates, but are represented in FIG. 5A as COORD.
It will be appreciated that in other examples another dialogue box may be generated to obtain coordinates from the user 502 rather than reading the selected coordinates before or after a command button is selected. Additionally, a dialogue box may be generated instructing the user 502 to select a location on the monitor, thereby entering the coordinates. Other examples exist.
The input manager 402 transmits the command string to the process manager 410. In this example, the command string is an argument within a "process manager command." For example, the process manager command may be "ProcessManager.ProcessInput(Argument)" where the argument is the command string. Upon receiving the process manager command with the command string, the process manager 410 creates an instance of the interpreter 412A by executing a standard command code. The command code may be, for example, "Binterpreter bInterpreter=NewBInterpreter( )". Executing this command code causes the process manager 410 to read a class interpreter object from memory, and to create the specific instance of the interpreter 412A for interpreting the current command string.
The process manager 410 passes the command string to the interpreter 412A, which causes the interpreter to create an instance of a builder command factory 414A by executing a command. For example, the interpreter command may be "CommandFactory commandfactory=NewCommandFactory( )". This causes the interpreter 412A to read a base command factory object from memory and to create the instance of the builder command factory 414A for executing the command string at issue.
The interpreter 412A passes the command string to the builder command factory 414A. Generally, the builder command factory 414A then will read the base command object from memory, create an instance of that object for the particular command string, and pass the created object back to the interpreter 412A.
It will be appreciated that the memory may be a volatile memory and/or a non-volatile memory, such as a non-volatile random access memory (NVRAM), a read only memory (ROM) and permutations thereof, a random access memory (RAM), a disk drive, and/or other types of memory.
The builder command factory 414A receives the command string Create Decision Color @ COORD. The builder command factory 414A reads memory and retrieves a base command object, in this instance a CommandCreate. The builder command factory 414A creates an instance of the CommandCreate object with an execute method to create a decision node object named Color, including all the inheritance methods and properties of a decision node object. The builder command factory 414A passes the CommandCreate object to the interpreter 412A. Thereafter, the builder command factory 414A destroys itself.
The interpreter 412A receives the CommandCreate object and runs the execute method causing the creation of the object named Color having a type decision node, including the sub-class objects of a decision node object. The interpreter 412A transmits the object Color to the process manager 410, and the process manager transmits the object Color to the builder collector 416. The interpreter 412A returns control of the builder 106A to the process manager 410 and destroys itself.
Referring now to FIGS. 5C-5D after the input manager 402 generates the dialogue box requesting the name of the decision type object, the input manager generates a dialogue box asking what the question will be for the newly created object called Color. In this example, the input manager 402 is configured to obtain arguments for one or more properties of the newly created object called Color. In this example, a decision node object has a property for questions and a property for options. Thus, the object Color also has properties for questions and options.
In response to the dialogue box requesting entry of a question, the user 502 enters "what color car do you want?" The input manager 402 receives the entry and generates a command string to set the first property for the object Color. In this example, the input manager 402 generates a command string for Set Color Question="what color car do you want?" to the process manager 410.
As before, the process manager 410 creates an instance of the builder interpreter 412B and passes the command string to the builder interpreter. Upon receiving the command string, the builder interpreter 412B creates an instance of the builder command factory 414B and passes the command string to the builder command factory.
The builder command factory 414B receives the command string identifying the "set" command. The builder command factory 414B then creates an instance of an object called CommandSet by reading the base object CommandSet from memory and creating the object CommandSet with an execute method to set a question property for the object Color to "what color do you want?" The builder command factory 414B then passes the object CommandSet to the builder interpreter 412B and destroys itself.
The builder interpreter 412B receives the object CommandSet and runs the execute method. This causes the builder interpreter 412B to send a command to the process manager 410 to retrieve the object Color from the builder collector 416. The builder interpreter 412B then sets the question property of the property object to "what color car do you want?" In this example, the object Color has a sub-class property object called question, and the execute method causes the builder interpreter 412B to set the argument of the sub-class property object called question to "what color car do you want?" The builder interpreter 412B then transfers the object Color back to the process manager 410, and the process manager transmits the object Color back to the builder collector 416. The builder interpreter 412B returns control of the builder 106B to the process manager 410, and destroys itself.
Referring now to FIGS. 5E-5F, the input manager 402 generates for display to the user 502 a dialogue box for the options. In this example, the input manager 402 generates the "options" dialogue box as part of obtaining information to complete a set of command strings initiated by selecting the "create decision" button. Thus, the input manager 402 may be configured to obtain further information to generate additional command strings to the process manager 410 upon the selection of an initial command by a user 502 or reception of a command from some other source. In this example, the input manager 402 is configured to obtain information for determining the options property for the object Color having type decision node.
The input manager 402 generates a dialogue box for display to the user 502 to obtain information for the options. In response, the user 502 enters "red, blue, and green." The input manager 402 receives the entry and generates the command string "Set Color Options=red, blue, and green" to the process manager 410. The process manager 410 creates another instance of the builder interpreter 412C as described above and passes the command string to the builder interpreter.
Upon receiving the command string, the builder interpreter 412C creates an instance of the builder command factory 414C as described above. The builder interpreter 412C passes the command string to the builder command factory 414C. In response, the builder command factory 414C identifies the command string as having a "set" command, reads memory to find the object CommandSet, and creates an instance of the object CommandSet having an execute method to set the options property for the object Color to "red, blue, and green." The builder command factory 414C passes the object CommandSet to the builder interpreter 412C and destroys itself.
The builder interpreter 412C runs the execute method of the object CommandSet. This causes the builder interpreter 412C to send a command to the process manager 410 to retrieve the object Color from the builder collector 416. The builder interpreter 412C then sets the sets the argument for the property object called options to "red, blue, and green." The builder interpreter 412C transmits the object Color back to the process manager 410, and the process manager transmits the object Color back to the builder collector. The builder interpreter 412C then returns control of the builder 106A to the process manager 410, and destroys itself.
In the above example, each time a command string was passed to the process manager 410, the process manager created the builder interpreter and passed the command string to the builder interpreter. Thereafter, the builder interpreter created an instance of a builder command factory and passed the command string to the builder command factory. The builder command factory created an instance of the specific command object with an appropriate execute method. The builder command factory then passed the instance of the command object to the builder interpreter and destroyed itself. Likewise, the instance of the builder interpreter executed the execute method of the command object and then destroyed itself.
By creating and then destroying an instance of the builder interpreter and/or the builder command factory each time a command string is to be processed, the builder 106 uses a more minimal amount of memory than otherwise would be used if multiple instances of builder interpreters and multiple instances of command factories were to be saved permanently or semi-permanently in memory. Thus, the builder 106B uses less memory when operating. Although, in other embodiments, the builder 106B may include a permanent or semi-permanent builder interpreter and/or builder command factory. In these instances, preferably only one instance of the builder interpreter and/or builder command factory will be resident in memory and will execute all command strings and create the required objects. However, in other cases, more than one instance of the builder interpreter and/or builder command factory may be included. In addition, one or more instances of the builder interpreter and/or builder command factory may be saved, loaded, or otherwise resident in one or more memory locations, including volatile and/or non-volatile memory locations.
Referring still to FIG. 4, in another example, the display manager 408 reads the contents of the builder collector 416 to render one or more objects for generation to a display. Initially, the input manager 402 transmits a display command to the process manager 410. The display command may include a reference to a zoom or to another view of one or more objects. The process manager 410 creates an instance of the builder interpreter 412 and passes the display command to the builder interpreter. The builder interpreter 412 executes the display command (via use of the builder command factory) and then destroys itself. This causes the process manager 410 to generate a display command with the reference vector of the builder collector 416 to the display manager 408.
The display manager 408 receives the command message from the process manager 410 to display one or more objects. The command message includes a reference, i.e. a pointer, to the builder collector 416. The display manager 408 executes the methods associated with the command message to acquire a reference to the vector in the builder collector 416 for each node object.
The display manager 408 references each node object in the builder collector 416 in turn to read each node object and its sub-class objects. The display manager 408 reads the node position object, the node property object, and the smart component object.
The node position object contains the absolute position information and the relative position information. The absolute position information identifies where and how the object is to be generated for display on the screen. The relative position information identifies the positioning relationship to other objects. The absolute position can be calculated from the initial absolute position in the node position object and from relative positioning, zoom, and attitude, based on the desired view. Thus, an associated graphic for the graphic node can be rotated or otherwise moved because the initial and relative position and the size of the graphic are known.
The property object contains variable properties and associated arguments that may be unique for each different type of node object. The node property object may override positioning information identified in the node position object. Additionally, the node property object may override other default arguments, including default color.
The smart component object contains specialized data, such as the actual graphic object to be generated for display. The smart component object also contains other information necessary to generate the graphic object for display. For example, the smart component object may include a graphic object for a sphere or pyramid, including a default color, such as red or blue.
Once the display manager 408 reads the node property object, the node position object, and the smart component object for each node object, the display manager 408 renders that object. As used herein, rendering means to generate one or more objects for display on a monitor or other output device.
The display manager 408 may receive command messages from the input manager 402 via the process manager 410 to modify one or more objects that are rendered. For example, if a user selects a zoom for one or more rendered objects, the input manager 402 transmits a command message to the process manager 410, and the process manager transmits the command message to the display manager 408. In response, the display manager 408 calculates the new position, size, and view of the selected one or more objects and again renders the objects for the selected view. A command message may be a command string.
In another example, a user may select a "debug on" command from the debug manager 406. In response, the debug manager 406 generates a "debug on" command to the process manager 410. The process manager 410 transmits the "debug on" command to the builder interpreter 412. The builder interpreter 412 creates a command debug object (via the builder command factory) and runs the associated execute method for the command debug object. Running the execute method causes the builder interpreter 412 to transmit a message to the debug manager 406 via the process manager 410 instructing the debug manager to turn the debug mode to "on," which causes a data stream to be generated to an output device upon execution of commands in a builder interpreter 412. Additionally, output from those executed commands also is transmitted to the selected output device. The data stream for the executed commands and the output of the executed commands is transmitted from the builder interpreter 412, to the process manager 410, and finally through the debug manager 406 to the output device. The debug mode may be turned off by transmitting a "debug off" command from the debug manager 406 to the builder interpreter 412 via the process manager 410. A process similar to the above stated debug on process will be completed.
In another example, the builder interpreter 412 creates an instance of a decision node. The resulting decision node instance is transferred to the process manager 410, and the process manager transfers the decision node object instance to the builder collector 416. When the display manager 408 is instructed to render a three dimensional image of a process being created for a seeker, the display manager reads the contents of the builder collector via a read command generated to the process manager 410. The display manager 408 reads the contents of the builder collector 416, including the properties and associated arguments of each property of each object. The display manager 408 converts the information identifying the properties and arguments of the objects into a visible representation of each object and generates that visible representation to a display or another output device.
FIG. 6 depicts an exemplary embodiment of a catalyst. The catalyst 110B of FIG. 6 comprises a flow manager 602 and a yield manager 604. Preferably the components of the catalyst 110B are implemented as objects in an object-oriented system.
The flow manager 602 manages the operation and flow of the catalyst 110B when operating a seeker. The flow manager 602 retrieves objects and/or other data required for operation of a seeker, such as from a repository. The flow manager 602 also controls storage of objects and/or other data, such as to a repository. The flow manager 602 controls operation of the seeker and generation of objects and/or data to interfaces.
The flow manager 602 controls and manages the operations of the catalyst 110B, including storage and retrieval of data, presentation of interrogatives, collection of assertions and other data, and the flow of future interrogatives based upon assertions. Additionally, the flow manager 602 determines if other seekers or objects are to be activated and activates those seekers or objects as needed. For example, the flow manager 602 may activate an automation seeker to retrieve data from an external database for use in a present seeker. Alternately, the flow manager 602 may determine that a present seeker is completed and activate another seeker or an automation object, such as an email object, upon its completion to provide data to an email account. Other examples exist.
User interfaces, such as the user interface 208 of FIG. 2, are added on top of the catalyst 110B (and the seeker system 102) to fit a selected seeker system environment and to facilitate a very light custom interface that can connect easily to the seeker system or components thereof. The flow manager 602 generates data to one or more of these user interfaces for different embodiments of a seeker.
For example, if a user interface is configured to present information to a user via a GUI, the GUI interface will be added on top of the catalyst 110B, and the flow manager 602 will generate data to the GUI interface. The GUI interface thereafter will process the data from the flow manager 602 and generate, for example, browser-enabled pages that are presented to the user to effect the collection of data or assertions. The user interface formats the browser-enabled pages according to the specified interface, including browser-enabled pages for a handheld device or a personal computer. In another example, the user interface may include a voice-enabled user interface or a voice response system interface, each configured to process data from the flow manager 602 for generation to a user via its interface.
Another interface may use JAVA in the form of tag libraries, forms, servlets, JAVA server pages (JSP), and other standard coding options. Another interface may include multiple sub-interfaces, including a graphic interface to pass graphics through pages or other browser-based strings, a flow interface to display text, a solution interface to set or retrieve components, a logic interface to set, retrieve, or other wise control variables, and an error interface to display error messages.
On startup, the flow manager 602 determines how a seeker will operate. In the instances in which interrogatives are presented to a user in a question format, the flow manager 602 determines the first question to be presented by effecting a query to the seeker. The flow manager 602 will receive in response to its query a pointer identifying the initial interrogative. The flow manager 602 creates a question object and populates the question object with the appropriate interrogative options and/or a selected list of potential assertions. The flow manager 602 processes a user response by identifying the assertion presented by the user, creating a logic object comprised of catalyst programming logic, and passes the logic object to an interpreter. The interpreter operates the logic to add component objects for a yield or to otherwise determine the yield or one or more portions of the yield.
The yield manager 604 manages output containers for a yield. The yield manager 604 monitors and temporarily stores results of an operation of a seeker while the seeker is operating and after the seeker has completed. For example, if a seeker is providing interrogatives to a user and collecting assertions in response to those interrogatives, the yield manager 604 temporarily stores the assertions and dynamically builds the yield while the assertions are being collected by the seeker. Additionally, in this example, the yield manager 604 monitors the paths of which interrogatives are presented and the assertions that are collected in response to interrogatives so that, if a user steps back to change an assertion, the yield manager 604 is able to identify assertions to be removed and/or components or processes to be removed from the yield that correlate to the removed assertions.
The catalyst 110B may be configured to operate in multiple modes, including a linear mode and an object mode. Linear mode operations typically represent data as a list. Object mode operations typically represents data as one or more sets. A set may include interrogatives, assertions, and/or logic, or any combination thereof. The linear mode is easy to understand and to program. However, the object mode may provide greater power and flexibility in some instances given the complexity of programming for the object mode.
FIG. 7 depicts an exemplary embodiment of a flow manager for the object mode. In the embodiment of FIG. 7, the flow manager 602A comprises an interrogative 702, an assertion 704, a component store 706, interpretive logic 708, a catalyst interpreter 710, a catalyst command factory 712, and native code 714. The native code 714 is optional. While only one interrogative 702, assertion 704, component store 706, interpretive logic 708, interpreter 710, and command factory 712 are depicted in FIG. 7 for simplicity, one or more may be included in an instance of the flow manager 602A. Thus, for example, multiple interrogatives 702, multiple assertions 704, multiple component stores 706, multiple interpretive logic 708, multiple interpreters 710, and multiple command factories may be included in an instance of the flow manager 602A.
The interrogative 702 generates information to a user to initiate a response or activates some system level process to provide input to the seeker. The interrogative 702 initiates an action for which a response provides one or more selection directives from a source, such as a user input, a data stream, or a program. The interrogative 702 also transmits to the interpretive logic 708 the specific interrogative for which an assertion is accepted. Examples of an interrogative 702 include a question interrogative, a listener interrogative, and a component execution interrogative.
Question interrogatives have associated assertion interrogatives that can be associated to generate responses to the question interrogatives. Thus, a question interrogative is constructed with at least one assertion and a logic object as a set so that a question may be generated with one or more assertions, such as options in a dropdown menu. The logic is used to identify whether the assertion is a dropdown selection or a text or other entry. The logic also is used to receive the assertion in response to the interrogative.
A listener interrogative is a system level program that intercepts one or more streams of data and monitors the stream or s |
