Design

FIELD OF INVENTION

The present invention relates to a system and method for work flow process management and design.

BACKGROUND

Recently, business process management systems have emerged to enable business owners to better manage their business solutions and functions. Most businesses are bound by a set of business process rules which define the core imperatives that govern business process activities. Based on these business process rules, business process management systems integrate relevant data and rules into a single unified system and are capable of designing, executing, monitoring, and analyzing business processes in a predetermined organization. In this regard, existing computer systems are integrated with the business processes.

For example, an organisation may seek to automate its business transaction process which may involve a computer e.g. receiving a sales order, sending a notification to the client of its receipt, triggering an employee to fulfil the order, and generating an invoice together with the order.

To automate such processes, difficulties may arise during the implementation phase. For example, the relevant data and/or inputs may require analysis by the management system based on complicated rules. While there are various Business Process Modelling (BPM) methodology and tools available, the issues may be compounded by increasingly complex business processes involving larger data sets and more complex rules.

Further, the ability of existing business process modelling systems to be changed or improved upon may be restricted as existing business processes are typically based on data and rules stored in a specific structure. As the structure of data and rules are decided upon during the initial design phase, the scope for future changes and enhancements are reduced. In general, a complete re-design of the system may be necessary. For example, should an e.g. RDBMS (relational database management system) be utilised, data is broken up and stored in a plurality of relational tables. In this regard, the complexity of coding any improvements using existing business process management systems may require the complete re-design of the system should changes or improvements need to be implemented. Therefore, there exists a need to provide a system and method for business process management.

SUMMARY In accordance with a first aspect of the present invention, there is provided a method of work flow process management implemented on a computer device, the method comprising the steps of receiving a first electronic document; automatically identifying a work flow associated with the electronic document; retrieving stored work flow definition data associated with said work flow; parsing said received electronic document based on the retrieved work flow definition data; and invoking a next stage of the work flow based on the parsing of the received electronic document.

Invoking the next stage may comprise generating a second electronic document associated with the next stage; presenting the second electronic document for user input; receiving the second electronic document including user input data; parsing said received second electronic document based on the work flow definition data; and invoking a subsequent stage of the work flow based on the parsing of the received second electronic document.

The next or subsequent stages may each be selected from a plurality of stages depending on a content of the first or second electronic documents, the work flow definition data, or both.

The parsing may comprise identifying a current stage associated with the work flow; retrieving data associated with said current stage in a stage Rowtype data structure comprising one or more data columns, wherein each column is capable of comprising at least two different elements of the data associated with said current stage; and executing said parsing based on said retrieved data.

The stage Rowtype data structure may be retrieved from a first repository; and wherein retrieving the data associated with said current stage comprises accessing the stage Rowtype data structure in the first repository using a unique stage row code.

The work flow may be stored as a work flow document in a second repository, and the method further comprises accessing the work flow document in the second repository using a unique work flow document code.

The unique row code may be comprised in the work flow document. In accordance with a second aspect of the present invention, there is provided a method of work flow design implemented on a computer device, the method comprising the steps of: associating a work flow with a first electronic document such that the first electronic document triggers the work flow; generating work flow definition data associated with said work flow for parsing the first electronic document based on the work flow definition data such that a next stage of the work flow is invoked based on the parsing of the first electronic document.

The work flow definition data may be generated such that invoking the next stage comprises generating a second electronic document associated with the next stage; presenting the second electronic document for user input; receiving the second electronic document including user input data; parsing said received second electronic document based on the work flow definition data; and invoking a subsequent stage of the work flow based on the parsing of the received second electronic document.

The work flow definition data may be generated such that the next or subsequent stages are each selected from a plurality of stages depending on a content of the first or second electronic documents, the work flow definition data, or both.

Generating the work flow definition data may comprise: identifying one or more stages associated with a work flow; creating a stage Rowtype data structure for storing data associated with each stage in one or more data columns, such that each column is capable of comprising at least two different elements of the data associated with each stage; and assigning the created stage Rowtype data structures to said work flow.

The method may further comprise storing each of the created stage Rowtype data structures in a first repository; and providing access to each of the stage

Rowtype data structures in the first repository by respective unique stage row codes.

The step of assigning the one or more created stage Rowtype data structures to the work flow may comprise: storing the work flow as a work flow document in a second repository; and providing access to the work flow document in the second repository by a respective unique work flow document code.

The one or more respective unique row codes may be comprised in the work flow document.

The method may further comprise designing the first or second electronic documents comprising the steps of: identifying one or more categories of information incorporated in the first or second electronic documents; creating a form Rowtype data structure for storing data representing each category of information in one or more data columns such that each column is capable of comprising at least two different elements of the data representing each category of information; and assigning the one or more created form Rowtype data structures to the first or second electronic documents.

The method may further comprise storing each of the created form Rowtype data structures in a third repository; and providing access to each of the form Rowtype data structures in the third repository by respective unique form row codes. The step of assigning the one or more created form Rowtype data structures to the first or second electronic documents may comprise: storing the first or second electronic documents as respective form documents in a fourth repository; and providing access to the form documents in the fourth repository by a respective unique form code.

The one or more respective unique form codes may be comprised in the first or second electronic documents.

Each stage Rowtype data structure may further comprise rules for progressing to the next or subsequent stage of the work flow.

The method may further comprise the step of executing the stages of the work flow according to the stage Rowtype data structures assigned to the work flow. In accordance with a third aspect of the present invention, there is provided a computer readable data storage medium having stored thereon computer code means for instructing a computer to execute a method of work flow process management, the method comprising the steps of receiving a first electronic document; automatically identifying a work flow associated with the electronic document; retrieving stored work flow definition data associated with said work flow; parsing said received electronic document based on the retrieved work flow definition data; and invoking a next stage of the work flow based on the parsing of the received electronic document. In accordance with a fourth aspect of the present invention, there is provided a computer readable data storage medium having stored thereon computer code means for instructing a computer to execute a method of work flow design, the method comprising the steps of: associating a work flow with a first electronic document such that the first electronic document triggers the work flow; generating work flow definition data associated with said work flow for parsing the first electronic document based on the work flow definition data such that a next stage of the work flow is invoked based on the parsing of the first electronic document. In accordance with a fifth aspect of the present invention, there is provided a system for work flow process management the system comprising: means for receiving a first electronic document; means for automatically identifying a work flow associated with the electronic document; means for retrieving stored work flow definition data associated with said work flow; means for parsing said received electronic document based on the retrieved work flow definition data; and means for invoking a next stage of the work flow based on the parsing of the received electronic document.

In accordance with a sixth aspect of the present invention, there is provided a system for work flow design, the system comprising: means for associating a work flow with a first electronic document such that the first electronic document triggers the work flow; means for generating work flow definition data associated with said work flow for parsing the first electronic document based on the work flow definition data such that a next stage of the work flow is invoked based on the parsing of the first electronic document.

In accordance with a seventh aspect of the present inventions, there is provided a method of workflow process management, the method comprising the steps of identifying one or more stages associated with a workflow process; creating a stage Rowtype data structure for storing data associated with each stage in one or more data columns, such that each column is capable of comprising at least two different elements of the data associated with each stage; and assigning the created stage Rowtype data structures to said workflow process. The method may further comprise storing each of the created stage Rowtype data structures in a first repository; and providing access to each of the stage Rowtype data structures in the first repository by respective unique stage row codes. The step of assigning the one or more created stage Rowtype data structures to said workflow process may comprise: storing the workflow process as a workflow process document in a second repository; and providing access to the workflow process document in the second repository by a respective unique workflow process document code.

The one or more respective unique row codes may be comprised in the workflow process document.

The method may further comprise designing a form associated with one stage of the workflow comprising the steps of: identifying one or more categories of information incorporated in the form; creating a form Rowtype data structure for storing data representing each category of information in one or more data columns such that each column is capable of comprising at least two different elements of the data representing each category of information; and assigning the one or more created form Rowtype data structures to said form.

The method may further comprise: storing each of the created form Rowtype data structures in a third repository; and providing access to each of the form Rowtype data structures in the third repository by respective unique form row codes.

The step of assigning the one or more created form Rowtype data structures to said form may comprises storing the form as a form document in a fourth repository; and providing access to the form document in the fourth repository by a respective unique form code.

The one or more respective unique form codes may be comprised in the form. Each stage Rowtype data structure may further comprise rules for progressing to another stage of the process

The method may further comprise the step of executing the stages of the process according to the stage Rowtype data structures assigned to said workflow process.

In accordance with a eighth aspect of the present inventions, there is provided a method of workflow process management, the method comprising the steps of identifying a current stage associated with a workflow process; retrieving data associated with said current stage in a stage Rowtype data structure comprising one or more data columns, wherein each column is capable of comprising at least two different elements of the data associated with said current stage; and executing said current stage based on said retrieved data.

The stage Rowtype data structure may be retrieved from a first repository; and wherein retrieving the data associated with said current stage comprises accessing the stage Rowtype data structure in the first repository using a unique stage row code.

The workflow process may be stored as a workflow process document in a second repository, and the method further comprises accessing the workflow process document in the second repository using a unique workflow process document code.

The unique row code may be comprised in the workflow process document.

In accordance with a ninth aspect of the present inventions, there is provided a computer readable data storage medium having stored thereon computer code means for instructing a computer to execute a method of workflow process management, the method comprising the steps of: identifying one or more stages associated with a workflow process; creating a stage Rowtype data structure for storing data associated with each stage in one or more data columns, such that each column is capable of comprising at least two different elements of the data associated with each stage; and assigning the created stage Rowtype data structures to said workflow process.

In accordance with a tenth aspect of the present inventions, there is provided a computer readable data storage medium having stored thereon computer code means for instructing a computer to execute a method of workflow process management, the method comprising the steps of: identifying a current stage associated with a workflow process; retrieving data associated with said current stage in a stage

Rowtype data structure comprising one or more data columns, wherein each column is capable of comprising at least two different elements of the data associated with said current stage; and executing said current stage based on said retrieved data.

In accordance with an eleventh aspect of the present inventions, there is provided a system for workflow process management, the system comprising: means for identifying one or more stages associated with a workflow process; means for creating a stage Rowtype data structure for storing data associated with each stage in one or more data columns, such that each column is capable of comprising at least two different elements of the data associated with each stage; and means for assigning the created stage Rowtype data structures to said workflow process.

In accordance with a twelfth aspect of the present inventions, there is provided a system for workflow process management, the system comprising: means for identifying a current stage associated with a workflow process; means for retrieving data associated with said current stage in a stage Rowtype data structure comprising one or more data columns, wherein each column is capable of comprising at least two different elements of the data associated with said current stage; and means for executing said current stage based on said retrieved data.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which:

Figure 1 is a schematic diagram illustrating the various modules of the eMS in an example embodiment. Figure 2 shows a flowchart illustrating an overview of the processes within the eMS in an example embodiment.

Figure 3 illustrates the interactions between the eBPM, the eFS (Electronic Filing System), and the eForm modules in an example embodiment..

Figure 4 shows the components of an account centric document based BPM module in an example embodiment.

Figure 5 shows a flowchart illustrating a method of business process modelling for data storage, management and organisation performed in an example embodiment.

Figures 6a, 6b, 6c, 6d and 6e illustrates the process of defining business process rules and associating respective tasks for the complaint workflow in an example embodiment.

Figure 7 illustrates the process flow of encoding a BPM workflow into eDoc structure in an example embodiment.

Figure δ illustrates the business process management Master Listing display for the complaint workflow in an example embodiment.

Figure 9 illustrates the business process management Operation Listing display for the complaint workflow in an example embodiment. Figure 10 shows a flowchart illustrating an example workflow for processing a complaint form according to a method performed by an example embodiment of the present invention. Figure 11 illustrates an example of a workflow flowchart defining the business process rules for the complaint workflow outlined in Figure 10 in an example embodiment.

Figure 12 illustrates a more detailed example of the workflow for business process modelling of the complaint workflow outlined in Figure 10 in an example embodiment.

Figure 13 illustrates two tasks stored in an eDocument structure in an example embodiment.

Figure 14 is a flowchart illustrating a method of work flow process management implemented on a computer device in an example embodiment.

Figure 15 is a flow chart illustrating method of work flow design implemented on a computer device in an example embodiment.

Figure 16 is a flowchart illustrating a method of work flow process management in an example embodiment. Figure 17 is a flow chart illustrating method of work flow process management in an example embodiment.

Figure 18 is a schematic diagram of the method and system of the example embodiment implemented on a computer system.

Figure 19 is a schematic diagram of the method and system of the example embodiment implemented on a wireless device. DETAILED DESCRIPTION

The described example embodiments seek to provide a document-based business process modelling system utilising a variable length data storage and management filing system. The embodiments of the present invention can include a flowchart-based graphical interface for business process task definition. Coupled with account-centric and document based framework of the filing system of, the BPM rules and tasks definition may be simplified and accelerated. Some portions of the description which follows are explicitly or implicitly presented in terms of algorithms and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as ""storing", "obtaining", "scanning", "processing", "generating", "loading", "formatting", "assigning", "filing", or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission or display devices.

The present specification also discloses apparatus for performing the operations of the methods. Such apparatus may be specially constructed for the required purposes, or may comprise a general purpose computer or other device selectively activated or reconfigured by a computer program stored in the computer. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various genera! purpose machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialized apparatus to perform the required method steps may be appropriate. The structure of a conventional general purpose computer will appear from the description below.

In addition, the present specification also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the spirit or scope of the invention.

Furthermore, one or more of the steps of the computer program may be performed in parallel rather than sequentially. Such a computer program may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer. The computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM mobile telephone system. The computer program when loaded and executed on such a general-purpose computer effectively results in an apparatus that implements the steps of the preferred method.

PCT/MY08/00017 discloses an account centric, document based filing system which organises related data into one location. This is achieved by storing related documents in an account-centric manner where documents of a particular account, e.g. all invoices, payments, notices and personal details and other documents and transactions of a particular client, are stored in the same account-centric folder with the relevant account being the client, thereby providing more efficient file storage, retrieval and management. The inventors have recognised that the filing system disclosed in PCT/MY08/00017 may be utilised in the storage of rules and processes of business process modelling systems. In this regard, the example embodiments seek to provide a document-based business process modelling system utilising the variable length data storage and management filing system disclosed in PCT/MY08/00017.

The embodiments of the present invention seek to provide a flowchart-based graphical interface for business process task definition. Coupled with the account-centric and document based framework of the filing system of PCT/MY08/00017, the BPM rules and tasks definition can be simplified and accelerated.

The Electronic Rapid System Generator (eRSG) in the example embodiment is a collection of web-based tools and generators that can generate and operate business web-based application systems in a more cost effective manner by reducing the time to market and being more robusj in meeting change requirements.

The eRSG is designed to be used by 2 types of users - consultants and end users. Consultants develop business applications with the tools and generators, while the end users are operators of the business applications developed by consultants.

Figure 1 is a schematic diagram illustrating the various modules of the eMS (Electronic Manual System) 100 in an example embodiment. The eRSG 120 comprises the eForm 102, eBFS (Electronic Browser Filing System) 116, eReport 106, System control 108 and the eBPM module 104b at the design phase.

The eBPM (eBusiness Process Management) module comprises of a design component 104b and an operation component 104a. The eBPM may be used as a web- based tool to specify, create, and operate document and business process flows. The System control 108 serves as the backbone of any application. For example should a user initiate operations of a created workflow, the System control 108 can communicate with an intermediate module Exchange 110 which serves as an eDoc (eDocument) router for e.g. invoking the respective BPM workflow definitions (tasks) at the eBPM module 104a.

The System control 108 may also receive a newly created workflow definition from e.g. the charting tool of the eBPM 104b during its design phase. In this case, the system control 108 will send the created document to the Exchange 110 and instruct the Exchange 110 to process and store the document in the eFS 112 via the eBPM 104a.

The eForm module 102 at the design phase is a web-based tool to specify document-centric data structure and to facilitate the design of a GUI (Graphical User Interface). The eForm module 102 at the usage phase (post design) provides a GUI to facilitate user inputs at the various stages of the defined business processes.

The eReport module 106 is a parameter driven business intelligence tool to create and view reports. The system control module 108 is a set of tools to govern user roles, access control, security and consistencies for generated applications. The Exchange module 110 is responsible for interchanging data formats of the various business process workflows documents or tasks as they are stored or retrieved through the eBPM 104a module or even a third party data format or storage system 114. eBPM 104a will route the respective document in the form of eDoc structure to eFS 112 for processing in the Transaction Processor 122 and filing in the Core 124. It will be appreciated by a person skilled in the art that the Core 124 may be in the form of a database. Alternatively, the Core 124 may be a management system which manages data stored in existing databases such as e.g. Oracle, DB2, MS-SQL, MySQL, etc. In this alternative embodiment, the Core 124 uses the existing databases as data storage. The Core 124 serves as the file manager or interface to e.g. convert the data into the appropriate table structure for storage into an existing database and vice versa during file retrievals from the existing database. For example, in the example embodiment, the eFS comprises an eLedger filing system which can handle the storing, managing and retrieving of data into other databases systems, relational or otherwise.

Figure 2 shows a flowchart 200 illustrating an overview of the processes of application development e.g. designing a workflow by a consultant in an example embodiment. Firstly, at step 202, document-centric data structures for the electronic forms are defined based on actual physical forms. Next, at step 204, the electronic versions of the forms are created by uploading images of scanned physical forms/documents and assigning screen elements. At step 206, the system control module 108 (figure 1) generates a system for data entry, validation and retrieval 208. Additional processes such as to design reports 210 and work flow design and management 212 by the eBPM 104 (figure 1) can also be carried out to add business reporting and multiuser collaboration functionalities in business process workflows. Figure 3 illustrates the interactions between the eBPM, the eFS (Electronic Filing

System), and the eForm modules in an example embodiment. A description of the eFS is included by cross reference to PCT/MY08/00017.

Accordingly, each workflow document (in the form of an eDocument structure) is stored in a workflow eLedger. The workflow eLedger is a storage means representing a virtual cabinet of the filing system. Each workflow eLedger comprises at least one virtual folder representative of e.g. all workflow eDocuments associated with e.g. a business process category. Each workflow eLedger will further comprise a Line Zero, a Document

Zero and Electronic Pages. Each Electronic Page may then comprise one or more documents (workflow eDocuments). The collection of Line Zero, Document Zero and

Electronic Pages comprising a number of workflow eDocuments are organized within the folder in a document based manner as the data on each physical document is not broken up and stored across different relational tables but is stored as a collated electronic document. Further, as the documents of a particular account are grouped together in a folder, the storage is account centric which can optimise data storage, management and retrieval.

The Line Zero in the example embodiment functions like a summary note of the folder, and comprises a fixed length area with a plurality of columns for data storage, with each of the plurality of columns containing "retrieval keywords' which may be useful during the retrieval process. It will be appreciated by a person skilled in the art that most of the data reporting, searching and sorting can be achieved by using SQL language directly on the Line Zero. Whenever a query keyword is entered into a query system during a query, the queried keyword is cross-matched with the retrieval keywords in the Line Zero data retrieval purposes.

The Document Zero functions like an index page of the folder and is updated whenever a new document is added into the folder. The Line Zero may also be updated with new document additions.

A workflow eDocument is a hierarchical document structure with a coding system. It contains the data obtained from the workflow that has been converted into a pre-determined structure to enable reconstruction of the form for display. It is formed by fields which are arranged in rows forming a string of characters termed Rowtype. A Rowtype is a collection of columns used to describe fields appearing on forms that belong to a logical grouping. Each column has a unit code (column code) within its Rowtype and each Rowtype has a unit code (row code) within the workflow application.

A Dictionary ledger is also available containing, inter alia, the row code(s) of the rowtype(s) representing the form and its display attributes. Description of the Dictionary ledger of the eFS is included by cross reference to PCT/MY2008/000017. The dictionary contains folders of dictionary eDocuments, each eDocument containing the field defintions of each of the workflow eDocuments. In this regard, for each type of workflow electronic document, a separate dictionary eDocument containing the workflow eDocument' s field definitions are stored into the Dictionary ledger.

It will be appreciated by a person skilled in the art that by managing data based on a row with a set of fields rather than an individual field, programming can be much simplified. There is no need to track the intricate relationships between a series of individual data, regardless of how they might interact, as compared to other existing approaches. New data can be readily integrated by appending it to the row without having to change the data structure. This can be achieved since a row is defined solely by the dictionary, thus any changes would advantageously only affect the dictionary. During run-time, where business process flows have been pre-defined earlier, a desired business process flow (or workflow) is initiated by the user submitting a desired eForm provided by the eForm module (102 of Figure 1). Based on the submitted eForm, a BPM workflow electronic document associated with the submitted eForm is retrieved from the data store 314 via the EFS 312. For example, suppose the user wishes to file a complaint and hence selects the complaint submission eForm (Doc1) on the system. The system would then retrieve the appropriate complaint form for display on the computer monitor for further user inputs. -" It will be appreciated by a person skilled in the art that the task eDocuments may be stored in the same way as previously described under the Workflow eDocument. i.e. task eDocument may be stored in task ePages of a task eFolder within a task eLedger. The task eDocument may be formed by Rowtype data structures comprising fields arranged in variable characters string format.

Once the task document (complaint form, Dod) is completed and submitted for data storage by the user, it will trigger retrieval and invoking of the associated BPM workflow electronic document where predefined rules and conditions will be parsed (306, 310). Based on the parsed eForm, a subsequent task document 308 is invoked and the data from the parsed eForm will be sent to EFS for eventual data storage (312, 314). The invocation and parsing according to the BPM workflow electronic document will continue until the N^ associated task document 316 representing the final workflow task to be performed is retrieved and completed before the business process flow is ended 318. For example, suppose the complaint form has been entered and submitted by the first user. The submitted form is parsed by the system on the retrieved BPM work flow electronic document associated with the submitted form, and upon successful verification, signifies the completion of the first task and moves the workflow into the second stage where the task of obtaining the approval of a manager for investigation of the complaint is triggered. This second task may e.g. involve generating an approval form where the manager may simply click on an "Approved" button, after having reviewed the submitted complaint form, to complete the second task. Upon approval by the manager, the complaint form may then be forwarded to a complaint investigator. The final task may then be for an investigation report by the complaint investigator results in the end of the workflow.

Figure 4 shows the components of an account centric document based BPM system (eBPM) 400 in an example embodiment. The system 400 comprises a graphical based charting tool 402 which comprises of two modules namely, rule definition module

402a and task document association module 402b. The rule definition module 402a allows the definition of rules by graphical means through the creation of the flow chart as described in step 102 of Figure 1. The task document association module 402b allows the user to attach documents or forms defining each of the tasks associated with each of the pre-defined rules, as described in step 104 of Figure 1.

In the example embodiments, the Business Process Charting Tool can enable a user to define business process rules and associate tasks with the respective rules with minimal technical programming. The Charting Tool as shown in Figure 6a to 6e provides a graphical user interface to the user and can allow a user to select desired rules definitions through point-and-select process. The only technical coding required may be in the defining of the conditions of the rules as shown in Figure 6d. Any subsequent changes to a business process flow can be made directly to the business process workflow through the Charting Tool and the amended workflow will automatically be reflected in all associated tasks documents. Thus, with the Charting Tool BPM rules definition and tasks definition process can be simplified and accelerated.

The system 400 further comprises: a BPM virtual storage (eBPM eLedger) 408 which stores all BPM workflow definitions; a BPM controller 410 which handles all BPM document submission from the Exchange 110 (Figure 1) to the eFS 112. Also, BPM documents in the eDoc structure received from the Exchange 110 (Figure 1) are routed to the BPM controller 110 which may, in turn, invokes the BPM engine 412; a

BPM engine 412 which processes the predefined BPM rules and manages the activities of the BPM operations. The BPM engine handles the evaluation of each BPM document. Each executed or activated workflow requires different evaluation and parsing. The BPM engine decides which subsequent task to be invoked after passing the rules evaluation process. The system 400 may further comprise an Operation eLedger 414 which stores the operation details of each task associated with a particular activated BPM workflow. For example the Operation eLedger 414 may store, for each task, pre-tasks, post-tasks, conditions, time taken to complete the task, etc. Additionally, a Master eLedger 416 that store the results of the operation activities of each activated BPM workflow; an operation listing module 404 which outlines the details of atl the tasks bound to a BPM workflow which outlines the list of associated document; and a master listing module 406 which outlines the details of the predefined BPM workflow are further comprised in the system 400.

Figure 5 shows a flowchart 500 illustrating a method of business process modelling for data storage, management and organisation performed in an example embodiment. The process may be divided into a definition phase 500a and a run-time phase 500b.

The definition phase 500a involves the steps 502 to 504. At step 502, a business process workflow is created by a user, using a charting tool. The charting tool may be graphical based wherein a user creates a flowchart depicting the various stages of the process workflow being created. At each stage of the flow chart created by the user, the charting tool can derive the rules for the process to proceed from one task onto a following task. For example, the user may identify the need for e.g. employee A to approve a payment invoice before another employee B proceeds with the payment of the invoice. At step 504, once the rules have been defined with the creation of the workflow chart, tasks corresponding to each of the rules are defined by the user. For example, suppose employee A has now approved the invoice (and a rule is satisfied). Based on this, the corresponding task may be to e.g. send the invoice via electronic means to employee B, with a confirmation of employee A's approval. In this regard, a list of rules and tasks associated with each stage are created to a particular business process workflow. The following description describes a workflow where a complaint is lodged. Here, the three main tasks in such a workflow would be:

1. The receiving and forwarding of the complaint to a Manager by a Clerk;

2. The approval and forwarding of the complaint to an Investigator by the Manager, 3. The submission of an Investigation Report by the Investigator to the Manager.

Figure 6a to Figure 6e illustrates the process of rule definitions and tasks association in the BPM Charting Tool in the example embodiment of the present invention. The steps are as follow: i. Figure 6a illustrates how to create a task in the BPM Charting tool. In the example embodiment, this is achieved by performing a right-click on the empty area of the Charting tool window. This would provide a dropdown list of selection choices 602 including other conditions or stage types. In this example, a task is inserted. ii. Figure 6b illustrates the properties window 604 initiated after task is selected for insertion into the workflow. Here, the user may enter the properties details to associate a task with an electronic document. These properties may include identifiers to the task electronic document e.g. the Ledger Code 606, Document

Code 608, and the individual associated with the task (role) 610. iii. After all the properties details are entered by the user, a rectangular box 612 with the name of the task will be displayed on the window as shown in Figure 6c. The step in Figure 6c is to define the rule needed to fulfil the criteria of the task created. A property window 616 is prompted by selecting an edge 614 of the rectangular box 612, "exiting" from the task created, e.g. a complaint form. iv. Figure 6d illustrates the condition editor 616 invoked from step 6c. It is in this step that any rules and conditions to be associated to the selected task will be defined, e.g. "IF" statements, "AND" statements, "n of m", greater than, less than etc. v. Steps i to step iv is repeated until all tasks that are to be associated to the workflow are defined. Figure 6e illustrates a completed workflow definition 600 with all the associated tasks and their respective rules. Figure 7 shows the storage of the created workflow 602 in eDocument structure using the BPM Charting tool 402 (Figure 4) in an example embodiment. In the example embodiment, the workflow created with the BPM charting tool 702 is generated originally in XML format 704. Subsequently, it is appended into a dedicated BPM document and stored in an eDoc (eDocument) structure 706. It is indicated that this eDoc is a BPM document through the workflow definition in the dedicated BPM field 708 and 710. The name of the BPM workflow - "Complaint" is also stated in column (field) 712. The final workflow in eDoc structure 706 will then be stored in the BPM eLedger 408 (Figure 4). This workflow eDocument will be referenced whenever there is a task submitted bearing the same document code submitted to the BPM controller 410 and routed to the BPM engine 412 (Figure 4) for subsequent processing.

It will be appreciated by a person skilled in the art that while the figures 6a-6e and 7 illustrate a simple linear workflow, a more complex workflow may similarly be created. For each stage of the workflow, a subsequent task may be dependent on conditional inputs. For example, in the case of the complaint workflow, the form submitted by the clerk may include an input field which may determine the nature of the complaint. Service staff complaints may be forwarded to a Human Resource manager while Food Hygiene complaints may be forwarded to an Operations manager. It will further be appreciated that multiple subsequent stages may arise with the completion of each stage of the workflow. As such, workflows can comprise complex tree structures branching from each stage of the workflow.

With the created business process workflow, the business processing system is now ready for use and the method moves onto the run-time phase 500b comprising steps 506 to 516. At step 506, a BPM master listing of all activated business process workflows is created.

Upon activation of a particular workflow, i.e. when a workflow is initiated, all activity details of each task as defined in the workflow eDocument, such as pre-tasks, post-tasks, conditions, task start and end time, and etc will be stored in the Operations eLedger 414 (Figure 4). An overview of the operation activities of the workflow is stored in the Master eLedger 416 (Figure 4). The main difference between the Operations eLedger and Master eLedger is that the Operations eLedger stores the tasks of a particular workflow, broken-down into activities, as well as the subsequent links between the tasks of the particular activated workflow. On the other hand, the Master eLedger stores the current status of all activated or completed workflows.

Returning to the flow chart in Figure 5, the BPM master listing step (executed by Master Listing Module 406 of Figure 4) extracts information in the associated eDocument from the Master eLedger to provide an overview of all the created business process workflows. The master list can allow all initiated business processes to be retrieved and displayed quickly. In other words, rather than having to retrieve each business process from the eBPM eLedger, a summary of each process workflow is stored in this master list to facilitate quicker retrieval of pertinent information by the BPM master listing module 406 (Figure 4) in the example embodiment. Figure 8 shows a Master Listing as displayed on a user interface of the program in an example embodiment. In the embodiment, based on the complaint submission scenario, an instance of the complaint BPM workflow 802 is listed in the BPM Master Listing 800 as illustrated in Figure 8 together with other activated workflows. Selecting the complaint BPM workflow 802 on the displayed master list prompts the BPM controller (410 of Figure 4) to display the list of tasks associated with the selected complaint BPM workflow (802 of Figure 8). The BPM Operation Listing extracts information in eDocument format from the Operation eLedger before displaying the associated task activity details as illustrated in Figure 9.

It will be appreciated by a person skilled in the art that the Master and Operation eLedgers are created individually to facilitate respective extraction for reporting and display purposes. In alternative embodiments, they may be combined into a single eLedger. In such an embodiment, the combined Master Operation eLedger may contain all pertinent information of each initiated workflow, including e.g. the status of each workflow and the status and details of each task within each workflow. Figure 9 illustrates the business process management Operation Listing display 900 for the complaint workflow in an example embodiment. Operation Listing display window shows details of the tasks of the selected workflow. As shown, the tasks include "Complaint form" submission 902, "Approvement" (by the Manager) 904, and "Investigation Report" submission 906. Each of these tasks is assigned to different parties e.g. individuals, as indicated in the "Role" Column 908 of the Operation Listing window 900. Other information such as the start and end time of the task, duration, status, etc. are also outlined in the Operation Listing window 900 These information may be used for monitoring or reporting purposes.

Various forms (or documents) associated with each task which may be used at each stage may also be created at this stage. For example, an electronic form (or document) with a checklist may be created for employee A to ensure that the items on the checklist have been adhered to before his/her approval. The completion of the checklist indicates to the business processing system that the task has been completed.

At step 508, the user first elects the type of workflow that is desired and the system receives data from a user. The pre-designed workflow can be loaded to facilitate business processes. A workflow can be retrieved through a unique workflow document code assigned during the design phase. When a workflow is being retrieved for usage, the business process system first extracts the associated workflow eDocument stored in the workflow Dictionary under a specified document code. The extracted workflow eDocument will then obtain the list of rules and tasks associated with the workflow. For example, the user may elect to submit an invoice for payment with an associated business process workflow eDocument code of DW01. Based on this document code, the unique workflow document is retrieved wherein the first task may be to generate a previously designed electronic form for e.g. an employee or customer to input. In this case, the form could require inputs such as invoice no., date, amount etc. It will be appreciated that the workflow may be identified from the submitted form without having the user elect any workflow directly.

At step 510, the completed form, known herein as a form eDocument, is submitted and stored to the data storage and management system as described in PCT/MY08/00017. In PCT/MY08/00017, each form document is stored in a form eLedger. The form eLedger is a storage means representing a virtual cabinet of the filing system. Each form eLedger comprises at least one virtual folder representative of e.g. ail form eDocuments associated with a business process workflow. Each form eLedger will further comprise a Line Zero, a Document Zero and Electronic Pages. Each Electronic

Page may then comprise one or more documents (form eDocuments). The collection of

Line Zero, Document Zero and Electronic Pages comprising a number of form

- eDocuments are organized within the folder in a document based manner as the data on each physical document is not broken up and stored across different relational tables but is stored as a collated electronic document. Further, as the documents of a particular account are grouped together in a folder, the storage is account centric which can optimise data storage, management and retrieval.

The Line Zero in the example embodiment functions like a summary note of the folder, and comprises a fixed length area with a plurality of columns for data storage, with each of the plurality of columns containing "retrieval keywords" which may be useful during the retrieval process. It will be appreciated by a person skilled in the art that most of the data reporting, searching and sorting can be achieved by using SQL language directly on the Line Zero. Whenever a query keyword is entered into a query system during a query, the queried keyword is cross-matched with the retrieval keywords in the Line Zero data retrieval purposes.

The Document Zero functions like an index page of the folder and is updated whenever a new document is added into the folder. The Line Zero may also be updated with new document additions.

An eDocument is a hierarchical document structure with a coding system. It contains the data obtained from the form that has been converted into a pre-determined structure to enable reconstruction of the form for display. It is formed by fields which are arranged in rows forming a string of characters termed Rowtype. A Rowtype is a collection of columns used to describe fields appearing on forms that belong to a logical grouping. Each column has a unit code (column code) within its Rowtype and each Rowtype has a unit code (row code) within the workflow application.

A Dictionary ledger is also available containing, inter alia, the row code(s) of the rowtype(s) representing the form and its display attributes. Description of the Dictionary ledger of the eLedger filing system is included by cross reference to

PCT/MY2008/000017. The dictionary contains folders of dictionary eDocuments, each eDocument containing the field design defintions of each of the forms. In this regard, for each type of electronic form, a separate dictionary eDocument containing the form's field definitions are stored into the Dictionary ledger.

It will be appreciated by a person skilled in the art that by managing data based on a row with a set of fields rather than an individual field, programming can be much simplified. There is no need to track the intricate relationships between a series of individual data, regardless of how they might interact, as compared to other existing approaches. New data can be readily integrated by appending it to the row without having to change the data structure. This can be achieved since a row is defined solely by the dictionary, thus any changes would advantageously only affect the dictionary. At step 512, the current task to be performed by the business processing system retrieved from the BPM master list is monitored and performed where necessary. With the completion of each task, the workflow retrieved in step 508 will be checked for completion at step 514 before the business process is considered complete (step 516). Otherwise, the business process system returns to step 510, and ensures that no task is left out.

For example, upon receipt of the submitted form from step 510, the monitor unit determines that the first task is complete (step 512) and moves on to step 514. At step 514, the system determines that there are further tasks based on the extracted workflow document and generates a new task of forwarding the invoice document to employee A for approval (task 2), effectively returning to step 510. The system then monitors for the approval of employee A (step 512). Subsequently, further checks at step 507 determine that a further task of forwarding the form document on to employee B (task 3) is performed. Once the form document is forwarded successfully (steps 510 and 512 are successfully completed), the work flow is deemed complete at step 514 and the process ends at step 516. It will be appreciated by a person skilled in the art that there may be situations or rules which define the termination of the workflow process such that not all the tasks need to be completed. For example, the submitted invoice document may have been keyed in incorrectly and is rejected by the employee. Figure 10 shows a flowchart 1000 illustrating an example workflow for processing a complaint form according to method performed by another embodiment of the present invention. In this flowchart , the scenario of a complaint on the services provided by the company is lodged by a customer. The workflow and task lists associated with steps 502 to 506 of Figure 5 have already been determined and defined. The following steps disclose the execution of the workflow by the system during run time.

At step 1002, a complaint form (Document 1) is received by the automated system over e.g. the internet. It will be appreciated by a person skilled in the art that the complaint form need not be a form created with the eForm module. The user may e.g. attach a complaint document of any file type, e.g. Word document, Excel spreadsheet, PDF, jpeg images, etc, to the form for submission to the clerk. Alternatively, the user may submit a document of any file type into the system. The complaint document of any file type may first be encoded and converted into a set of variable characters string and structured into an eDoc structure prior to storage and transmission. Based on the defined rules and task lists, the received form comprising the document (or simply the complaint document) is routed to a clerk (user 1) and is checked for completeness and verified. Upon verification by the clerk, the system forwards the complaint form (or the complaint document) to a Manager (User 10) to decide whether to dispatch an Investigator (User 3) to investigate the complaint (Step 1004). Upon approval by the manager to initiate investigations, the complaint form (or complaint document) is forwarded by the system, to the investigator for reading (Step 1006). At step 1008, the investigator carries out the investigation and creates an Investigation Report (Document 10) for submission to the Manager. The document is uploaded to the system which transmits the Investigation Report to the Manager. At step 1010, the Manager receives the Investigation Report and makes a decision to either close the incident or continue investigation. It will be appreciated by a person skilled in the art that all forms, reports and documents may be stored in the same way as previously described under the Workflow eDocument. i.e. A complaint eDocument may be stored in complaint ePages of a complaint eFolder within a complaint eLedger. The complaint eDocument may be formed by Rowtype data structures comprising fields arranged in variable characters string format.

It will be appreciated by a person skilled in the art that the system may perform tasks in addition to the forwarding of messages and documents. For example, the system may be tasked to remind the manager every few days should the manager not make timely decisions. Figure 11 illustrates an example of a workflow flowchart 1100 created with the charting tool in step 502 of Figure 5, defining the business process rules and tasks for the complaint workflow outlined in Figure 10.

At step 1102, the business process workflow is initiated. The first task of generating a complaint form DBC1 stored in ledger LD10 is displayed for the user for input (step 1104). Upon receipt of the completed form, the form is forwarded to a clerk for verification. If the clerk determines that the form is improperly entered, verification is deemed to have failed and the workflow is deemed to have been terminated implicitly (step 1106).

If the form is successfully verified by the clerk, the next task is retrieved from the workflow document. The system determines that the next task is to generate an approval form with a document code of DBC2 stored in ledger LD10. The complaint form is forwarded to a Manager (User 2) to decide whether to dispatch an Investigator (User 11) to investigate the complaint (Step 1108). Here, if the manager determines that the investigation is rejected, the workflow will also be terminated implicitly (step 1110). Upon approval by the manager to initiate investigations, the next task of receiving investigation report with document code of DBC3 is invoked (step 1112). The task involves the receipt of an investigation report DBC3 generated by the Investigator. The generated investigation report DBC3 will then be evaluated by the manager which makes a decision to either close the incident or continue investigation.

Once all tasks of the workflow have been completed successfully, the workflow is ended (step 1114).

Figure 12 illustrates a more detailed example of the workflow 1200 for business process modelling of the complaint work flow illustrated in Figure 2. The run time workflow of the above said BPM of a complaint form is described as follows: At step 1202a, a complaint form is received by the clerk (user 1). The clerk then verifies the completeness of the complaint form. Successfully verified complaint forms are forwarded to the manger (1202b), while failed verification forms lead to the workflow termination and are not forwarded to the manager for further actions (1202c). Steps 1202a, 1202b and 1202c are all part of the actions in step 1002 (figure 10);

Subsequently, the manager (user 2), at step 1204, analyses the complaint form and decides further action. The manager may approve the complaint form to carry out further investigations (1204a); or he may reject complaint form for further investigation

(1204b), leading to workflow termination. Both 1204a and 1204b are part of the actions in step 1004 (figure 10);

At step 1206, upon receipt of the approval to carry out investigation, the investigator (user 3) carries out investigation on the submitted complaint (step 1006 of figure 10) and creates an investigation report (step 1004 of figure 10). The investigator then submits the investigation report to the manager for further action (step 1208). The manager analyses the investigation report and decides if further investigation is needed and initiates continued investigation on the complaint (step 1210), returning the process to step 1206. If the manager is satisfied with the investigation report, he may decide for the case to be closed and the workflow similarly ended (step 1212).

It will be appreciated by a person skilled in the art that while the example embodiments describe the tasks to be forwarded to a particular "user", the "user" may be a group of individuals. For example, upon the investigation approval by the manager, the approval may be sent to a group of investigators, each of whom may perform the investigation and submit the investigation report. In such an embodiment, the system could have fields for investigators to be aware when a particular investigator has taken up the task; hence avoiding duplicated investigations by different investigators.

Figure 13 illustrates two tasks stored in an eDocument structure in an example embodiment. The illustrated tasks are tasks 1108 and 1112 (Figure 11) of the complaint workflow 1100. The system document code of the both tasks 1302, 1304 is DB10 1306. A set of document in the form of an eDoc structure similar to 1302 and 1304 will be generated whenever a BPM workflow is created in the Charting Tool 402 (Figure 4). These task eDocs will be used to populate the Operation Listing Module as shown in Figure 9. The rowtype in the example embodiment that holds the information concerning the respective task is RB20 1308. Each of the rowtype comprises of terminators 1310 which separate the respective data fields, as described in PCT/MY08/00017. The information contained in the rowtype of RB20 1308 includes the Role (person) who will carry out the task 1302 which in this case indicates a Manager 1310, the name of the task: Approvement 1312, the document that is to be handled during the course of this task DBAO 1314, the subsequent document or task to be invokedupon completion of the current task is DBEO 1316 and a condition (Approve="True") 1318 which defines the criteria for which the current task is considered to be completed. The current status column 1320 stores the present status of the task. As may be observed, since the condition "Approve=True" 1318 is satisfied by the present status, the next task is invoked. In this example, upon approval by the manager, the workflow proceeds to the next task. The following task example 1304 is the subsequent task after completion of task 1302. Based on the example in Figure 11, the subsequent task after approval by the manager is the Investigation report 1324 task. The Role column 1326 stores the identity of the party responsible for carrying out the task e.g. the "Site investigator. The document that is to be handled during the course of this task, i.e. the investigator report document DBEO, is stored in column 1326. Upon submission of the document DBEO by the investigator, the subsequent document DBFO, which contains definitions of the next task is stored in column 1328. As the workflow is complete upon receipt of the report, the document DBFO may contain instructions to bring the complaint workflow to an end. The status of the Site Investigator as the assignee 1322 of the task 1304 are also included contained in the RB20 rowtype 1308.

Embodiments of the present invention seek to provide a new system and method of business process workflow definition. A provided graphical user interface can allow a user to specify the business process workflow through a drag and drop concept which may offer increased simplicity and user-friendliness.

In existing BPM systems, various BPM frameworks were designed for different purposes and require extra customisation effort if it is to be implemented in a new environment. The embodiments of the present invention can provide the flexibility and simplicity of BPM definitions through its account centric and document based framework. The document-based embodiments of the present invention allow business process modelling and workflow definition in association with documents.

Further, the documents moved between parties in the the embodiments can be stored as an eDocument comprising e.g. an independent document, a collection of documents, or a section of a document, converted into a Rowtype data format . The embodiments of the present invention provide the management of the passing of documents to relevant parties in the form of an eDoc structure. In contrast, conventional business process modelling and workflow definition require certain amount of programming in the form of coding and scripting, operating in a traditional legacy system where data are normalized and stored in a distributed tables environment. The process of business process modelling and workflow definition can be simplified and accelerated.

The embodiments of the present invention also allow data to be obtained or input using external legacy systems. A data structure conversion will be performed transparently on the external data format into the eDoc structure in order to take advantage of the simplicity and flexibility of the present invention and vice versa through the conversion of eDoc into XML format which is a widely accepted universal data format.

It will be appreciated by a person skilled in the art that traditional RDBMS storage means involve the breaking up the data for storage in various table locations. However, the workflow data is organised in a coupled manner in the account centric document based framework in example embodiments.

Figure 14 is a flowchart 1400 illustrating a method of work flow process management implemented on a computer device in an example embodiment. At step 1402, a first electronic document is received. At step 1404, a work flow associated with the electronic document is automatically identified. At step 1406, stored work flow definition data associated with said work flow is retrieved. At step 1408, said received electronic document is parsed based on the retrieved work flow definition data. At step 1410, a next stage of the work flow is invoked based on the parsing of the received electronic document. Figure 15 is a flow chart 1500 illustrating method of work flow design implemented on a computer device in an example embodiment. At step 1502, a work flow is associated with a first electronic document such that the first electronic document triggers the work flow. At step 1504, work flow definition data associated with said work flow is generated for parsing the first electronic document based on the work flow definition data such that a next stage of the work flow is invoked based on the parsing of the first electronic document. Figure 16 is a flowchart 1600 illustrating a method of work flow process management in an example embodiment. At step 1602, one or more stages associated with a workflow process is identified. At step 1604, a stage Rowtype data structure is created for storing data associated with each stage in one or more data columns, such that each column is capable of comprising at least two different elements of the data associated with each stage. At step 1606, the created stage Rowtype data structures are assigned to said workflow process.

Figure 17 is a flowchart 1700 illustrating a method of work flow process management in an example embodiment. At step 1702, a current stage associated with a workflow process is identified. At step 1704, data associated with said current stage is retrieved in a stage Rowtype data structure comprising one or more data columns, wherein each column is capable of comprising at least two different elements of the data associated with said current stage. At step 1706, said current stage is executed based on said retrieved data.

The method and system of the example embodiment can be implemented on a computer system 1800, schematically shown in Figure 18. It may be implemented as software, such as a computer program being executed within the computer system 1800, and instructing the computer system 1800 to conduct the method of the example embodiment

The computer system 1800 comprises a computer module 1802, input modules such as a keyboard 1804 and mouse 1806 and a plurality of output devices such as a display 1808, and printer 1810.

The computer module 1802 is connected to a computer network 1812 via a suitable transceiver device 1814, to enable access to e.g. the Internet or other network systems such as Local Area Network (LAN) or Wide Area Network (WAN).

The computer module 1802 in the example includes a processor 1818, a Random Access Memory (RAM) 1820 and a Read Only Memory (ROM) 1822. The computer module 1802 also includes a number of Input/Output (I/O) interfaces, for example I/O interface 1824 to the display 1808, and I/O interface 1826 to the keyboard 1804.

The components of the computer module 1802 typically communicate via an interconnected bus 1828 and in a manner known to the person skilled in the relevant art.

The application program is typically supplied to the user of the computer system

1800 encoded on a data storage medium such as a CD-ROM or flash memory carrier and read utilising a corresponding data storage medium drive of a data storage device 1830. The application program is read and controlled in its execution by the processor 1818. Intermediate storage of program data maybe accomplished using RAM 1820. The method of the current arrangement can be implemented on a wireless device 1900, schematically shown in Figure 19. It may be implemented as software, such as a computer program being executed within the wireless device 1900, and instructing the wireless device 1900 to conduct the method. The wireless device 1900 comprises a processor module 1902, an input module such as a keypad 1904 and an output module such as a display 1906.

The processor module 1902 is connected to a wireless network 19013 via a suitable transceiver device 1910, to enable wireless communication and/or access to e.g. the Internet or other network systems such as Local Area Network (LAN), Wireless Personal Area Network (WPAN) or Wide Area Network (WAN).

The processor module 1902 in the example includes a processor 1912, a

Random Access Memory (RAM) 1914 and a Read Only Memory (ROM) 1916. The processor module 1902 also includes a number of Input/Output (I/O) interfaces, for example I/O interface 19112 to the display 1906, and I/O interface 1920 to the keypad 1904. The components of the processor module 1902 typically communicate via an interconnected bus 1922 and in a manner known to the person skilled in the relevant art. The application program is typically supplied to the user of the wireless device 1900 encoded on a data storage medium such as a flash memory module or memory card/stick and read utilising a corresponding memory reader-writer of a data storage device 1924. The application program is read and controlled in its execution by the processor 1912. Intermediate storage of program data may be accomplished using RAM 1914.

It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.