Patent Publication Number: US-2013246106-A1

Title: Hierarchical budget process orchestration

Description:
The present application is based on and claims the benefit of U.S. provisional patent application Ser. No. 61/611,388, filed Mar. 15, 2012, the content of which is hereby incorporated by reference in its entirety. 
    
    
     BACKGROUND 
     The process of planning a budget or generating a budget is often a very complicated process. Normally, this is a highly manual process and can require a great deal of time and effort, and it can also be inefficient and error prone. 
     The budget planning process often requires many different iterations, and the particular process used in formulating and iterating through budget revisions is often defined by a budget hierarchy of an organization. However, the budget hierarchy does not always match the organization hierarchy of the organization. For instance, a budget hierarchy may require input from different individuals or groups within an organization, that are not separately defined within the structure of the organizational hierarchy. Nonetheless, those individuals or groups may be required to provide input to, or to review, budgets during the planning process. Because of the very complicated and iterative budgeting process, many organizations fall back to a manual process for generating a budget. 
     The problems associated with the budget planning process can be exacerbated as the complexity of the organization generating the budget grows. The more complex the organization, the more complex the budget planning process. Similarly, many organizations go through regular restructuring. This can require modifications and retraining of individuals involved in the budget planning process. 
     Some organizations regularly revise their budget planning process. This requires constant updates to the process, and this exacerbates the cumbersome nature of the process as well. 
     Further, budget data is often extremely sensitive data. This can require additional security to control access to the data, even for those individuals who are involved in the budget planning process. 
     It should also be noted that the process of developing or creating a budget is not only important to private sector entities, but to public sector organizations as well. In the public sector, the budget often represents the entity&#39;s legal authority to spend based on planned revenues. Even the highest level government officials cannot spend government resources, without properly established budget authority. 
     It is common for public sector organizations to prepare two types of budgets. An operating budget often spans one or two years and the capital budget spans multiple years and is commonly a rolling multi-year plan (such as a rolling 5-year plan). An operating budget includes a spending plan for continuing services and strategic initiatives of short term duration. A capital budget includes a spending plan for asset acquisitions or construction projects. 
     With all of these budgets, budget planning is a cyclical process that is often repeated annually or bi-annually with many phases and stages. Budget planning is also an iterative process wherein data is analyzed in many scenarios within a stage to develop an optimum budget proposal. 
     The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter. 
     SUMMARY 
     A hierarchical budgeting structure is generated and used for generating and reviewing budgets during the budget planning process. Automated workflows for generating the budget and iteratively reviewing the budget are determined based upon the hierarchical budgeting structure. The hierarchical budgeting structure is first defined and that hierarchical budgeting structure is used to control flow of the information during the budget planning process. Nodes in the hierarchal structure each have an associated workflow and a set of rules that control activities that can be performed at a given node and that control security features corresponding to that node. 
     This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of one illustrative embodiment of a budget planning system. 
         FIG. 2  is a flow diagram illustrating the overall operation of the system shown in  FIG. 1 . 
         FIGS. 2A-2B  show illustrative organizational budget hierarchies used for budget planning 
         FIG. 2C  shows an exemplary user interface display of a hierarchy of budget plans for the organizational budget hierarchy shown in  FIG. 2B . 
         FIGS. 3A and 3B  are a flow chart illustrating the operation of the system shown in  FIG. 1  in more detail. 
         FIGS. 3C-3O  are illustrative user interface displays. 
         FIG. 4  is a flow diagram illustrating the creation of an organization structure with a budget planning purpose in greater detail. 
         FIG. 5  is a flow diagram illustrating one embodiment of the operation of the system shown in  FIG. 1  in aggregating information from child (or descendent) budget plans to a parent (or ancestor) budget plan. 
         FIG. 5A  is an illustrative user interface display. 
         FIG. 6  is a flow diagram illustrating one embodiment of the operation of the system shown in  FIG. 1  in distributing information from a parent plan to child plans. 
         FIG. 6A  is an illustrative user interface display. 
         FIGS. 7A and 7B  are illustrative user interface displays showing allocations from one scenario to another and from one stage to another, respectively. 
         FIG. 8  is a flow diagram illustrating the creation of a parent plan for a set of child plans. 
         FIG. 9  is a flow diagram illustrating the operation of the system shown in  FIG. 1  in navigating though a hierarchical budget plan structure. 
         FIG. 10  is one illustrative architecture. 
         FIG. 11-15  are illustrative mobile devices. 
         FIG. 16  is one illustrative computing environment. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a block diagram of one illustrative business system  100  that includes budget planning system  102 , business data store  104  and other business systems  106 . Business data store  104  holds a variety of different business data including historical expenditure and revenue data  108 , employee data  110 , salary/benefit data  112 , and a variety of other business data  114 . Business data store  104  can, of course, be a single data store or multiple data stores that are located in the same place, or remotely from one another. Business data store  104  also illustratively stores business data records for customers, accounts, and a variety of other business data records that correspond to business applications that may be run by a business. 
     Other business systems  106  illustratively include human resource (HR) and payroll system  116 , financial/accounting system  118 , fleet management system  120  and other systems  122 . Other systems  122  may, for instance, include customer resource management (CRM) systems, enterprise resource planning (ERP) systems, line of business (LOB) applications, or other business systems or applications that are used by a business. 
     In the embodiment shown in  FIG. 1 , budget planning system  102  illustratively includes processor  124 , hierarchy generation component  126 , budget planning component  128  (which itself includes configuration component  130  and process generator  132 ), budget planning data store  134  and user interface component  136 . Budget planning data store  134  illustratively includes budget hierarchies  138 , budget plans (including things such as stages and workflows)  140  and budgets (which can be completed, in process, etc.)  142 . 
     In one embodiment, user  144  accesses budget planning system  102  to generate a budget plan for generating one or more budgets. Of course, user  144  can access system  102  either through a user device  146 , or directly, as indicated by arrow  148 . In any case, either user device  146  or user interface component  136  generates user interface displays  150  which illustratively include user input mechanisms which user  144  can interact with in order to provide inputs to interact with budget planning system  102 . A number of illustrative user interface displays are described below. 
       FIG. 2  is a flow diagram illustrating one embodiment of the operation of budget planning system  102  in generating a budget plan for use by individuals in generating a budget. In one embodiment, budget planning data store  134  holds budget hierarchies (and/or budget organizational hierarchies)  138  which have already been generated by hierarchy generation component  126 . As discussed in the background section above, it may be that the budget hierarchy is different than the organizational hierarchy of the company (or other organization) for which the budget is to be generated. In any case, in one embodiment, user  144  either accesses an existing budget hierarchy  138 , or generates a new budget hierarchy  138 . This is indicated by block  160  in  FIG. 2 .  FIG. 2A  is a simplified hierarchical diagram showing one exemplary budget hierarchy  162  for budget planning In hierarchy  162 , the organization for which budget planning is to be done includes a budget office represented by node  164 . Budget office  164  has at least two departments  166  and  168 . Each department has one or more divisions  170  and  172  (while only divisions for department  166  are illustrated, there may also be divisions for department  168  as well). 
     In the embodiment shown in  FIG. 2A , division  1  is responsible for three programs represented by nodes  174 ,  176  and  178 . In the hierarchy  162  shown in  FIG. 2A , department node  166  is a child (or descendent) of budget office node  164  which is its parent (or ancestor). Division nodes  170  and  172  are children (or descendants) of department node  166  and program nodes  174 ,  176  and  178  are children (or descendants) of their parent (or ancestor) division node  170 . 
     In one embodiment, each of the nodes in hierarchy  162  may have an associated budget. Therefore, each node may illustratively have a budget plan that is used in generating its corresponding budget. For instance, if an administrator of the program represented by node  174  needs to create a budget to fund that program, then a budget plan can be generated for node  174 . Similarly, if the division represented by node  170  needs to create a budget, then a budget plan can be generated for division node  170 , that receives inputs from, or distributes information to, the budgets generated for nodes  174 ,  176  and  178 . The same is true of each node in hierarchy  162 . For each node, a budget plan is illustratively generated and used in creating a budget. The budgets corresponding to each node can then be rolled up to budget office  164  where they can be aggregated and presented in an overall budget for review and approval. Of course, certain things can be distributed downward from the budget office plan for node  164  to the plans for its descendent nodes, This can be used, for example, when the budget office sets targets for the divisions. 
       FIG. 2B  shows one illustrative user interface display  180  that is generated to show a more complex budget hierarchy  182 . As will be described below in more detail with respect to  FIG. 9 , user  150  can navigate through the various budget plans corresponding to the nodes in hierarchy  182 , and corresponding informational displays  184  are changed or updated, as the user selects different nodes in hierarchy  182 . This is described in greater detail below with respect to  FIGS. 9 and 9A . It is briefly mentioned here for the sake of better understanding the present description. 
     In any case, once user  144  has either accessed an existing budget hierarchy or generated a new budget hierarchy, then user  144  illustratively generates a budget plan for each desired node in the budget hierarchy. This is indicated by block  186  in  FIG. 2 . Assuming that each node in the budget hierarchy is to have an associated budget, then a budget plan is generated for each node in the hierarchy. 
     Once the budget plans are generated for each node in the hierarchy, they can then be associated with one another in child/parent associations to follow the budget hierarchy for which they were generated.  FIG. 2C  shows one illustrative user interface display  192  that shows a budget plan hierarchy  194 . Budget plan hierarchy  194  includes a budget plan that has been generated for each node in the user interface display shown in  FIG. 2B . Also, the budget plans in hierarchy  194  are connected to one another in parent/child relationships which correspond to the nodes in user interface  180  in  FIG. 2B  as well. Associating budget plans with one another in parent/child relationships is indicated by block  196  in  FIG. 2 . It will be noted that block  196  is shown in dashed lines indicting that it is optional. That is, where only a single budget is to be generated, then only a single budget plan needs to be generated and it does not need to be associated with any other plans. However, the present description will proceed with respect to a plurality of different budget plans being arranged in parent/child relationship. 
     Once all of the budget plans have been generated, they are saved and output for use by those responsible for generating the budgets corresponding to those budget plans. This is indicated by block  198  in  FIG. 2 . 
       FIGS. 3A and 3B  (collectively referred to as  FIG. 3 ) show a flow diagram that illustrates one embodiment of the operation of the system shown in  FIG. 1 , in generating a budget plan, in more detail. Before beginning this description, it may be helpful to understand a number of terms. A budget planning process is a practice to develop the financial estimates of income and expenses, and inputs and outputs for the budget planning process. A budget plan is a document used to develop estimates of inflows and outflows for a responsibility center. 
       FIG. 3A-I  shows a user interface display that allows the user  144  to enter the budget plan configuration mode to configure items to be used by a budget plan. This is done by selecting the configuration button. 
     User  144  first uses hierarchy generation component  126  to define a budget organization structure (or budget hierarchy) such as that shown in either  FIG. 2A  or  2 B. This is indicated by block  200  in  FIG. 3 . In doing so, user  144  interacts with suitable user interface displays  150  to define responsibility centers  200  that are responsible for various budgets. These correspond to the nodes in the budget hierarchy. 
     User  144  then defines how the budget plans roll up or down within the hierarchy and how they are eventually approved. This is indicated by block  202  in  FIG. 3 . User  144  then illustratively defines the sequence for the budget plans. That is, some budget plans in the hierarchy will be dependent on others before their corresponding budget can be completed. This dependency (or sequence) is indicated by block  204  in  FIG. 3 . Of course, user  144  can provide other inputs to define other features in a budget hierarchy as well, and this is indicated by block  206 . 
     Before continuing with the description of  FIG. 3 , creating a budget planning hierarchy will be described in more detail.  FIG. 4  is a flow diagram illustrating one embodiment of the operation of system  102  (and specifically configuration component  130 ), in operating to create an organization structure (or budget planning hierarchy)  138  with a budget planning purpose. Hierarchy generation component  126  first displays an organization hierarchy form and receives its name or displays an existing organizational hierarchy. This is indicated by block  420  in  FIG. 4 .  FIG. 4A  shows one illustrative user interface display  422  that allows the user to choose an organization type from list  424  and assign a purpose to the organization type, such as “budget planning” by selecting item  426  from a purposes list  428 . 
     In one embodiment, the hierarchy generation component  126  generates a user interface display with a canvas and allows a user to drag and drop various hierarchical organizational components onto the canvas and inter-relate them in a dependency structure (or hierarchy) to form the organization hierarchy. The user interface display also allows the user to name the structure and assign it a budget planning purpose.  FIG. 4B  shows a user interface display  430  that has a canvas  432  that shows an organizational hierarchy  434  that is to be used for budget planning Assigning the budget planning purpose to the organizational hierarchy is indicated by block  436  in  FIG. 4 . 
     It can be seen in  FIG. 4B  that the user has chosen a parent node labeled “executive”  438  and has associated a child node labeled “finance”  440  as a child of the executive parent node  438 . The user has also chosen a plurality of grandchild and great grandchild nodes  442  and  444 , respectively, and arranged them hierarchically in structure  434 . Receiving these types of edit inputs selecting a parent node and dependent nodes and generating a display of those nodes to display hierarchical structure  434  is indicated by blocks  446  and  448  in  FIG. 4 , respectively. 
     Hierarchy generation component  126  then allows the user to identify budget plans related to the hierarchical structure  434 , in order to generate a budget plan hierarchy (of budget plans) corresponding to structure  434 .  FIG. 4C  shows a user interface display  450  that shows a budget plan hierarchy  452  that shows a parent budget plan node  454  corresponding to a parent budget plan, a child budget plan node  456  corresponding to a child budget plan and a plurality of children and grandchildren nodes  458  and  460  which correspond to the child and grandchildren nodes  442  and  444  in structure  434 , respectively. The budget plan hierarchy and the organization hierarchy, once complete, can have an effective date set for the budget plans corresponding to those hierarchies. This is indicated by blocks  462  and  464  in  FIG. 4 . The budget hierarchy and organizational structure can then be saved for later use, in budget planning data store  134 , or in other data stores. This is indicated by block  466  in  FIG. 4 . 
     Referring again to  FIG. 3 , once the budget hierarchy is defined at block  200 , user  144  uses hierarchy generation component  126  to also define the review workflow for review of a budget in the corresponding budget plan. This is indicated by block  208  in  FIG. 3 . This illustratively includes a definition of who can approve the budget as indicated by block  210 , and it also allows user  144  to define and manage transitions in the budget planning process. For instance, the budget, as it is being drafted, may be in a “draft” status, and then it may be transferred to a “review” status where it is being reviewed. Of course, once it is finally approved or rejected, it can be transferred to an approved or rejected state as well. Managing these transitions is indicated by block  212  in  FIG. 3 . Of course, the user can also define other review workflow items, and this is indicated by block  214 . 
     Once the user  144  has generated the budget hierarchy, the user can then define types of information needed during the budget planning process. In one embodiment, user  144  accesses budget planning component  128  (and specifically configuration component  130 ) to set up the types of information needed during the budget planning process. In order to do this, user interface component  136  illustratively generates suitable user interface displays  150  that allow the user to set up this type of information. In one embodiment, user  144  first defines budget plan scenarios. A budget plan scenario, for the purposes of the present description, is a classification of budget plan line item estimates for budget planning A budget plan scenario allows an organization to track budget amounts or quantities. Some examples of budget plan scenarios include “requested”, “actuals”, and “approved”. Defining the types of information needed in terms of budget plan scenarios is indicated by block  216  in  FIG. 3 . 
       FIG. 3C  shows one exemplary user interface display  218  that can be generated by configuration component  130  (using user interface component  136 ) through which user  144  can define budget plan scenarios. It can be seen that user interface display  218  illustratively includes a list section  220 , a code section  224 , and a unit of measure section  226 . When user  144  selects the scenarios entry  228  in the list in section  220 , code section  224  displays a list of scenarios and unit of measure section  226  displays dropdown menu  230  which can be actuated by the user to select one of a variety of different units of measure corresponding to a selected scenario in list  224 . In  FIG. 3C , it can be seen that the user has selected the “actual amount” scenario and has selected the unit of measure as “monetary” in dropdown menu  230 . Again, the user is simply setting up the different types of inputs that will be needed in a budget using the budget plan that the user  144  is currently generating. In this example, one type of information that will be needed is an “actual amount” and it will be given in monetary terms. 
     It can be seen that list  224  includes a variety of other scenarios including an “approved budget” scenario which will be given in monetary terms, a “current estimate” scenario which is given in monetary terms, a “requested amount” scenario which is given in monetary terms, a “FTE” amount (which refers to a full time equivalent count meaning the number of full time equivalent employees) which is measured as a simple count, and an “approved” scenario which is given in monetary terms as well. 
     Once the user has defined all the types of information (such as all the scenarios), then the user illustratively generates the various budget planning stages that will be used in the budget plan. This is indicated by block  232  in  FIG. 2 . A budget planning stage, for purposes of the present description, describes the transitions of a budget plan in a budget planning process and responsibility center. For example, a budget planning process may go through a variety of budget planning stages before it is approved. A budget baseline stage, for instance, is a stage where all of the baseline information is entered into the budget document. The budget document then may go through an “existing programs” stage where all of the existing programs provide their budgetary information. It then may go through a “new programs” stage where new programs of the organization provide budgetary information as well. Of course, it may go through a “request” stage where the budget that has been developed is submitted as a request for approval. After that, there may be an “adjustment” stage where the budgetary information is adjusted during the review process. Similarly, where the budget is a child of a parent budget, there may be an “aggregation” stage where information from all of the children of a parent is aggregated to the parent budget. This would occur in a bottom-up model. In a top-down model, information from a parent budget (such as budgetary targets) may be distributed downward to child budgets. All of these can be stages in the budget planning process. 
       FIG. 3D  shows one exemplary user interface display  234  that can be generated by configuration component  130  (using user interface component  136 ) that allows user  144  to define the budget planning stages. It can be seen that some of the items in user interface display  234  are similar to those shown in user interface display  218  and they are similarly numbered. However, it can be seen that in  FIG. 3D , the user has selected the “stages” items  236  in list section  20 . This causes budget planning component  128  to generate a list of stages  238  that can be selected by the user. If the user highlights a stage in the list, and actuates the “add” button  240 , that stage will be added to the current budget plan. Of course, the stage can be removed by actuating button  242  as well. 
     Once the budget planning stages have been defined, user  144  illustratively interacts with process generator  132  in budget planning component  128  to generate budget planning workflows. For the purposes of the present discussion, a budget planning workflow is a sequence of budget planning stages through which the budget plans are passed during the budget planning process. That is, the workflows define the order of the budget planning stages and associate the workflow that will be used to transition the budget plan status between those stages. This is indicated by block  244  in  FIG. 3 . 
       FIG. 3E  show one exemplary user interface display  250  which is similar, in some ways, to user interface display  234  shown in  FIG. 3D . However,  FIG. 3E  shows that, in list section  220 , the user has selected workflows button  252 . Budget planning workflow pane  254  is then opened for the user to order the stages according to a desired workflow. In one embodiment, the user can add a name for a given workflow by clicking add button  256  and entering a new name and workflow in box  258 . The user can then select one of the workflows in name box  260  and can select a specific workflow, by number, in dropdown menu  262 . When this is done, budget planning component  128 , and specifically process generator  132 , displays a list of stages in stage list  264 , that have already been defined by the user. The user can then click the add, and remove buttons  266  and  268 , respectively, to add stages from list  264  to selected stages list  270 . In this way, the user is selecting particular stages that are to be included in the present workflow. 
     The user can rearrange the stages in a variety of different ways. In one embodiment, the user simply selects one of the stages in list  270 , and clicks the move up button  272  to move the stage upward in the list of selected stages. Similarly, by clicking the move down button  274 , the user can move the selected stage downward in the list of selected stages. 
     In another embodiment, the user can use a workflow editor to arrange stages according to a given workflow.  FIG. 3E-1  shows a first workflow  275  that corresponds to a parent budget plan and a second workflow  277  that corresponds to one or more child budget plans. It can be seen that workflow  275  has stages and state transitions. The same is true of workflow  277 . Workflow  275  first has a stage for creating a baseline budget and then for activating child budget plans. Once these stages have been processed, there is a stage transition from a state of “Creating Budget Office Target” to a state of “Allocate to Departments”. Workflow  275  then waits for the departments&#39; budget plans to be completed and then undergoes another state transition from “Allocate to Departments” to “Budget Office Department Review”. This means that all of the departments have submitted their budgets and they are awaiting budget office review. Once the budget office review stage is complete, workflow  275  undergoes another state transition from “Budget Office Department Review” to “Executive Review”. When the executive review stage is complete, the workflow  275  goes through another state transition from “Executive Review” to “Plan Completed”. 
     Workflow  277  shows one illustrative work flow for a child budget plan that starts with a request for the budget document from the department which initiates workflow  277 . The first stage is “Department Update Requests” which ask for budgetary updates from the departments. When this stage is completed, workflow  277  goes through a state transition from “Department Request” to “Department Submitted”. When all of the departments have completed their budget plans, another state transition occurs from “Department Submitted ” to “Plan Completed”. Workflow  277  then returns to the “Departments Complete” stage in workflow  275 . 
     The workflows shown in  FIG. 3E-1  can be created from an editor that displays a workflow pane and a set of workflow elements (such as stages, transitions, etc.) that can be dragged from an elements pane to the workflow pane and configured as shown in  FIG. 3E-1 . Of course, other embodiments for generating a workflow can be used as well. 
     In any case, once the user has finished arranging the stages according to a workflow, the user has successfully generated the budget planning workflow by defining the order of the budget planning stages and associating the workflow that will be used to transition the budget plan status between those stages. 
     The user can then assign the present budget plan a priority. Budget plan priorities are categories of precedence or areas of importance by which plans are classified for evaluation and ranking. A user can define priorities, and then assign them to a given budget plan. Defining priorities so that they can be assigned to budget plans is indicated by block  276  in  FIG. 3 .  FIG. 3F  shows a user interface display  278  that is similar to user interface display  250  shown in  FIG. 3E . However,  FIG. 3F  shows that the user has chosen the priorities button  280  in section  220 . This causes budget planning component  128  to open pane  282  which allows the user to add or remove budget plan priorities. In one embodiment, the priorities can be sorted alphabetically, or otherwise. In addition, by clicking the add and remove buttons  284  and  286 , the user can illustratively define and add new budget priorities or remove other budget priorities. 
     Having defined all these things (the organization structure or budget hierarchy, the new workflow, the types of information needed, the budget planning stages, the workflows that arrange the budget planning stages in order, and the priorities), the user can now generate a new budget planning process for a given budget (such as the present year&#39;s budget plan). In doing so, the user may wish to identify a location where the budget attachments are to be stored. This is indicated by block  288  in  FIG. 3 .  FIG. 3G  shows a user interface display  290 , which is similar to user interface display  278  shown in  FIG. 3F , except that the user has chosen folders button  292  in display portion  220 . This causes budget planning component  128  to open a budget plan folders pane  294 . Pane  294  displays a list of folder locations  296  that can be selected by the user. Of course, the user can add or remove other folder locations by using the add and remove buttons  298  and  300 . 
     The user can then define the templates that are used at each budget planning stage, to receive information. This is indicated by block  302  in  FIG. 3 .  FIG. 3H  shows another user interface display  304 , that is similar to the one shown in  FIG. 3G , except that the user has now selected the template files button  306  in portion  220 . It can also be seen that the “folders” button  292  has been relabled to “attachment locations” button  293 . In any case, this causes budget planning component  128  to open template files pane  308 . Pane  308  allows the user to identify the particular file name (by path name or otherwise) in file name list  310 , and then to specify the type of template or attachment that is located there in attachment type list  312 . In the embodiment shown, list  312  is a set of dropdown menus that allows the user to select from a list of different attachment types for the specific template files listed in list  310 . 
     Having now configured the various items necessary for a budget planning process, the user can then return to the user interface display shown in  FIG. 3A-1 . Instead of selecting budget planning configuration button under the setup menu, the user can select budget planning processes button. In response, process generator  132  can then generate a user interface display such as that shown at  316  in  FIG. 3I . User interface display  316  includes a budget list  318  that lists various budgets that have already been named. By selecting one of those budgets, a user can further define the budget using the budget cycle and dropdown menus in section  320 . The user can then select a number of different tabs and further define the process. In the embodiment shown in  FIG. 3I , the user has selected the template and folder tab  322 . This display allows the user to select a template file and a folder for storing budget plan attachments for the budget planning process. This can be done through suitable user input mechanisms, such as text boxes or dropdown menus, one example of which is shown at block  324 . 
       FIG. 3J  shows one example where the user wishes to further configure the budget by selecting the dropdown menu for the budget cycle in portion  320 . It can be seen that this allows the user to select the budget cycle span, the fiscal calendar, the name and the starting period for the present budget process. This is indicated in menu portion  321 . 
     The user can then assign a budget planning workflow to each responsibility center. This is indicated by block  326  in  FIG. 3 .  FIG. 3K  shows one example of a user interface display  328 , which allows the user to do this. In  FIG. 3K , the user has selected the process administration tab  330 . This allows the user to select the budgeting hierarchy in dropdown menu  332 . This results in the display for assigning budget planning workflow to a responsibility center. This can be done in menu  334 . It can be seen that menu  334  allows the user to select one of the responsibility centers in section  336  and either define or view the organization type in section  338 . The user can then use a suitable user input mechanism, such as dropdown menu  340 , to assign a budget planning workflow to the selected responsibility center. Menu  334  also shows that the workflow number is displayed in portion  342 . 
       FIG. 3L  shows another user interface display  344 . In one embodiment, the user has selected one of the responsibility centers. This causes menu  346  to be displayed. Menu  346  includes dropdown menu  348  and dropdown menu  350  that allow the user to select an organization type and budget planning workflow, respectively. The user can then actuate the “assign” button  352  to assign the workflow and organization type to that responsibility center. 
     Having assigned a budget planning workflow to each responsibility center, the user can now set process stage rules at each budget planning stage in a given workflow. This is indicated by block  354  in  FIG. 3 .  FIG. 3M  shows one illustrative user interface display  356  that can be generated for doing this. It can be seen that user interface display  356  is similar to user interface display  344  shown in  FIG. 3L , except that the user has now selected the stage rules and templates button  358 . This causes budget planning component  128  to generate a list  360  of budget planning workflows, and another user interface  362  that identifies various stages in the selected workflow, and a set of rules  364 ,  366  and  368  that can be configured for a selected stage in list  362 . In one embodiment, rule  364  allows the user to associate a child budget plan with the current budget plan that is being configured. Rule  366  allows a user to add lines to the current budget plan, while rule  368  allows the user to modify lines in the current budget. In one embodiment, the user sets rules for each of the stages in stage list  362  by placing a check in the check box associated with each of the rules. Therefore, as shown in  FIG. 3M , the stage “department request” has been configured so that a user can add lines to the budget in that stage of the budget plan and modify lines as well. 
     Of course, other user interface displays can be used as well.  FIG. 3N , for instance, shows another user interface display  370  that can be used to define the rules and templates used for the budget planning stages in a selected budget planning process. The user selects a workflow from workflow list  372 , and then selects a stage from stage list  374 . As workflow list  372  is selected, stage list  374  is updated. As a stage from list  374  is selected, the displayed rules are updated as well Finally, the user selects rules that are enabled at a selected stage by using the rules generally shown at  376 . In the embodiment shown in  FIG. 3N , the user can associate a child, add lines, modify lines, edit a budget plan, delete a budget plan, or reset a budget plan, as configured by the user. 
     Both  FIGS. 3M and 3N  allow the user to also assign templates to be used for generating or viewing budget plans at a selected stage. In  FIG. 3M , this is done by the user selecting a dropdown menu  378  and selecting a template for use in entering information at that budget planning stage. The same is true in  FIG. 3N , where the user selects a dropdown menu  380  and selects a template for receiving budget information at the selected stage. Of course, this can be done in other ways as well. 
     In any case,  FIG. 3  shows that setting the process stage rules can include attaching child plans, as indicated by block  382 , adding line items as indicated by block  384 , modifying line items as indicated by block  386  and assigning templates as indicated by block  388 . Of course, the user can configure other rules at each stage as well, and this is indicated by block  390 . 
     The user can then assign priorities to the budget plan, before activating it. This is indicated by block  392  in  FIG. 3 .  FIG. 30  shows one exemplary user interface display  394  that can be used by the user to assign priorities to a budget plan. User interface display  394  is similar to user interface display  356  shown in  FIG. 3M , except that the user has now selected the “budget plan priority constraints” button  396 . This causes user interface display of user input mechanisms that show a list of priorities in field  398  and a list of selected priorities in field  400 . By actuating add button  402  or remove button  404 , priorities are assigned from list  398  to the budget plan in list  400  or they are removed from the budget plan in list  400  to the priorities list  398 , respectively. 
     Once the priorities are assigned to a budget plan, the budget plan can be activated by the user. This can be done by actuating the “activate” button  406  on user interface display  394 . This changes the status of the budget from “draft” to “in process”. Budget plans can now be created using this budget planning process, once it has been activated. Activating the budget planning process is indicated by block  406  in  FIG. 3 . Budget planning component  128  then determines whether there are any more budget planning processes that need to be created. If so, processing reverts back to block  288  and additional budget planning processes can be created for the budget hierarchy that was previously configured. Determining whether more budget planning processes are to be created is indicated by block  408  in  FIG. 3 . 
     Once all of the budget planning processes have been created, then budget planning system  102  allows the various users involved to conduct budget planning using the activated budget planning process. In doing so, the system guides the budget planning process through the various stages in the various workflows until the entire budget planning process is complete. Budget planning system  102  can do this for a plurality of different budgets at a given time. For instance, system  102  can perform these steps for an operating budget and for a capital budget, as discussed above. Conducting the budget planning process and completing the various budgets is indicted by blocks  410 ,  412  and  414  in  FIG. 3 . Once the budget has been completed, the status of the given budget is changed to “complete” in order to prevent new budget plans from being created using this process. Changing the status is indicated by block  416  in  FIG. 3 . 
       FIG. 5  is a flow diagram illustrating one embodiment of the operation of budget planning component  128  generating a budget plan that aggregates child plans into a parent plan. In one embodiment, the user first opens a parent plan that is to receive aggregations from child plans. This is indicated by block  470  in  FIG. 5 . 
     Configuration component  130  then generates a user interface display to allow a user to select a parent scenario in the parent plan that will receive the aggregation from one or more child plans. This is indicated by block  472  in  FIG. 5 .  FIG. 5A  shows one embodiment of a user interface display  474  that allows the user to define the parent scenario in the parent plan that is to receive the aggregation. User interface display  474  further allows the user to identify child scenarios to be aggregated from child plans to the identified parent scenario. This is indicated by block  476  in  FIG. 5 . For instance, the user using dropdown menu  478  can define that the user wishes to have an allocation from a source budget plan scenario (that can be chosen in dropdown menu  480 ) to a destination budget plan scenario (that can be chosen from dropdown menu  482 ). 
     In fact, multiple source scenarios can be used and aggregated to a single destination scenario in the parent plan. Table  1  illustrates an example where multiple source lines are to create a single destination budget plan line. The upper portion of Table  1  shows the dimensions, effective date, budget class and amount that are used as the source lines to generate the aggregated line in the parent plan. Collecting the budget plan lines from the child plans that have the identified child scenario is indicated by block  484  in  FIG. 5 . Using that information to populate the line in the parent plan, that has the selected parent scenario, and displaying that information is indicated by block  486  in  FIG. 5 . 
     
       
         
           
               
               
               
               
             
               
                 TABLE 1 
               
               
                   
               
               
                 Dimension 
                 Effective Date 
                 Budget class 
                 Amount 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 For example: 
               
            
           
           
               
               
               
               
            
               
                 100.10.01 
                 Dec. 22, 2010 
                 Expense 
                 100.00 
               
               
                 100.10.01 
                 Dec. 22, 2010 
                 Expense 
                 200.00 
               
            
           
           
               
            
               
                 Would be aggregated 
               
            
           
           
               
               
               
               
            
               
                 100.10.01 
                 Dec. 22, 2010 
                 Expense 
                 300.00 
               
            
           
           
               
            
               
                 But the following would not as the budget classes are different. 
               
            
           
           
               
               
               
               
            
               
                 100.10.01 
                 Dec. 22, 2010 
                 Revenue 
                 100.00 
               
               
                 100.10.01 
                 Dec. 22, 2010 
                 Expense 
                 200.00 
               
               
                   
               
            
           
         
       
     
       FIG. 6  is a flow diagram illustrating one embodiment of the operation of budget planning system  102  in distributing information from a parent plan down into child plans. This may happen, for instance, when a parent node in the organizational structure wishes to generate a target amount for certain budget items for child nodes in the organizational structure. For instance, an executive node may generate budgetary targets for divisions, each of which have a child plan of the executive plan corresponding to the executive node. In this case, the executives may wish to enter the target amounts in the executive budget plan and have those amounts distributed downward to the various child plans associated with the division budgets.  FIG. 6  is a flow diagram illustrating one exemplary way in which this can be done. 
     A user first illustratively opens a parent plan that has scenarios that are to be distributed down to child plans. This is indicated by block  500  in  FIG. 6 . Budget planning component  128  then generates a user interface to identify a parent scenario in the parent plan that is to be distributed to the child plans. This is indicated by block  502  in  FIG. 6 . Budget planning component  128  also generates a user interface display that can be used to identify the child scenarios that are to receive the distribution from the identified parent scenario in the parent plan. This is indicated by block  503  in  FIG. 6 . 
       FIG. 6A  shows one embodiment of a user interface display  504  that can be generated for this purpose. In user interface  504 , the user has selected a parent budget plan (BR — 2012 — 019: operations baseline  2012 ). The user has then selected the “budget plan lines” button  506  and selected a scenario that is to be allocated (or distributed downward) to child plans in dropdown menu  508 . It can be seen that the user has selected the “2012 DEPT approved” scenario. This causes budget planning component  128  to generate user interface box  510  which shows that the “2012 DEPT approved” scenario is the destination in the child plans for the parent plan “target” scenario. The user can choose the particular type of allocation method, in this case, “distribute” using dropdown menu  512 . When distribution is properly configured, the user simply actuates the “allocate” button  514  and this causes the “target” budget plan scenario in the parent plan to be distributed downward to the “2012 DEPT approved” budget plan scenario in the associated child plans. 
     Budget planning component  128  then collects the budget plan lines from the parent plan (in this case the “target” budget plan scenarios) and distributes the collected budget plan lines to the destination scenarios identified in the child plans. This is indicated by blocks  516  and  518  in  FIG. 6 . 
     The user can then close the parent plan and open one of the associated child plans. When this is done, the associated child plan is displayed with the distributed lines already populated into the child plan. This is indicated by blocks  520 ,  522  and  524  in  FIG. 6 . 
     It should be noted that the same sort of process discussed with respect to  FIG. 6  can be used to populate one budget plan scenario from one or more other budget plan scenarios through associated plans (not necessarily a parent or child but a sibling) or from within a single plan. In order to do that, budget planning component  128  illustratively generates a suitable user interface display that allows a user to specify not only the source scenario where the information is to be obtained, but the destination scenario, where the information is to be aggregated or distributed.  FIG. 7A  shows one embodiment of a user interface display  526  that can be used for this purpose. 
     User interface display  526  shows that the user has selected the allocations schedule button  528 . This causes budget planning component  128  to generate a list of allocation schedules  530 . The user can define an allocation method at  532  (such as aggregate, distribute, allocate, etc.). Among other things, the user can then define the source scenario  534  which is the source of the allocation and the destination scenario  536  which is the destination of the allocation. In the embodiment shown in  FIG. 7A , it can be seen that the user has selected the “monthly periods” allocations schedule and indicated that the allocation method is to be an “allocation by period”. The user has defined the source scenario as the “target” budget plan scenario and the destination scenario as the “requested” budget plan scenario. Therefore, budget planning component  128  will allocate the amounts in the source scenario to the destination scenario during the budget planning process. 
     The allocation schedule defined in  FIG. 7A  can be applied in various stages. That is, the user can create stage allocations to execute budget planning allocations during a stage of a given workflow process.  FIG. 7B  shows a user interface display  538  that can be used for this process. The user has selected the “stage allocations” button  540  which allows the user to identify a budget planning workflow  542  and a specific stage in that workflow  544 . The user can then identify an allocation schedule  546  to be executed during that stage of the identified workflow. 
     In one embodiment, budget planning component  128  also allows a user to create a parent budget plan for a set of children budget plans.  FIG. 8  is a flow diagram showing one illustrative way in which this can be done. First, budget planning component  128  generates a display that lists various budget plans. This is indicated by block  541  in  FIG. 8 . The user then selects one or more of the plans from the list of budget plans that are displayed. Filtering the list to only selected budget plans is indicated by block  543  in  FIG. 8 . Budget planning component  128  then receives a parent plan selection input from the user, on the user interface display, that selects a parent plan that is to be assigned as the parent to the selected budget plans. This is indicated by block  545  in  FIG. 8 . In one embodiment, this can be done where the user is a member of a role that has permission to form this operation. In addition, none of the selected budget plans can have a different parent budget plan already. All of the selected budget plans are illustratively associated with the same budget planning process, and the budget planning process is to have a status of “in process”. If these requirements are met, the user can illustratively select an already existing budget plan as the parent for the selected budget plans, or the user can specify a new budget plan that is to serve as the parent of the selected budget plans. In response, budget planning component  128  illustratively accesses the budget organization structure (or budget hierarchy) in data store  134  to verify that all of the selected budget plans can have the same parent plan. This is indicated by block  547  in  FIG. 8 . If so, then budget planning component  128  creates the parent plan for the selected plans, or assigns the selected plans to an existing plan, as its children. This is indicated by block  549  in  FIG. 8 . 
       FIG. 9  is a flow diagram illustrating one embodiment of the operation of budget planning component  128  in allowing a user to view and navigate various budget plans  140  in data store  134 . In one embodiment, budget planning component  128  generates a list view of existing budget plans for the user. This is indicated by block  550  in  FIG. 9 . The user may then provide a user input requesting a hierarchical view of the listed budget plans. This is indicated by block  552 . In response, budget planning component  128  generates a display of the budget organization hierarchy (or budget hierarchy)  138  corresponding to the list of budget plans. This is indicated by block  554  in  FIG. 9 .  FIG. 4B  (discussed above) shows one embodiment of a hierarchy. The user then selects a level in the hierarchy, such as by selecting one of the nodes in the hierarchy. This is indicated by block  556  in  FIG. 9 . In response, budget planning component  128  generates a display showing not only a node corresponding to the selected level in the budget hierarchy, but also showing parent budget plans and child budget plans and the relationships of those plans to the selected node on the selected level of the hierarchy. This is indicated by block  558  in  FIG. 9 .  FIG. 2C  (again discussed above) shows one embodiment of such a user interface display. 
     Component  128  then receives user actuation of a budget plan from the hierarchy shown in  FIG. 2C . That is, the user can simply click on one of the nodes in the hierarchy of  FIG. 2C , or otherwise select or actuate one of the nodes. This is indicated by block  560  in  FIG. 9 . In response, component  128  displays the details of the actuated budget plan. This is indicated by block  562  in  FIG. 9 . In one embodiment, component  128  also applies security so that the user may only be allowed to see sections of the actuated budget plan, or may blocked from viewing the budget plan, entirely. 
       FIG. 2B  shows a display of the various details of the selected budget plan, as indicated by  184  in  FIG. 2B . The details include, by way of example only, the status of the individual workflows in the budget plan.  FIG. 2B  shows that four workflows have not been submitted, five are in review, ten are approved, and none are rejected or canceled. Of course, these are exemplary status indicators only. Details can also include an enumeration of the stages, a summary of the amounts for various scenarios that have an amount value, the summary of units of various scenarios that have a unit value, and a list of various budget plans in the hierarchy being displayed. Of course, these details are exemplary only and different or additional details could be used as well. 
     It can thus be seen that the system supports aggregation of an organization hierarchy for budgeting into the budgeting process, and also easily supports organizational changes. By simply redefining or modifying the budget hierarchy, the user can accommodate such changes quickly. The system also introduces multiple levels of parallel workflows to orchestrate the budget planning process. Workflow-specific budget planning stage management controls data visibility, security, and presentation. That is, at each stage in a budget plan, the user can set rules that control whether various other users or roles can see certain types of data, and whether they can make any changes to that data in the budget plan. The system can be used to easily manage bottom-up types of budget planning and top-down types of budget planning, or any combination of those, as defined by the process. 
     At each node in the budget organizational hierarchy a budget planning workflow is used to define the stages of review that an individual budget plan transitions through. Nodes at a specific level in the hierarchy may reuse the same workflow, but have different reviewers and requestors. Workflow providers can be used to automatically enforce that the budget plans are reviewed by the appropriate individuals with responsibility for the organization unit and budget. By tying the budget planning process to the organizational structure, the system provides a tighter level of data control and security. With each stage in the budget planning workflow, there are a set of rules that dictate what can be used to control what values for the budget planning and what areas are visible and able to be modified. 
     Also, within each level in the hierarchy, it is possible to have multiple budget plans so they can be ranked. The plans can be associated in parent/child relationship or in other desired ways. This allows the budgeting information to be summarized at a higher level for review and adjustment. Within a specific step in the workflow, and based on the budget planning stage, automated tasks can be used to aggregate the data upward or allocate it downward. This automatic transition controls the significant problem with budgeting systems—keeping the data controlled and synchronized at each review level. Rules are defined for how this aggregation is done. Such rules, as described above, can include splitting annual amounts to monthly amounts or creating best-case and worse-case estimates, and this can all be managed through the allocation rules. 
     In addition, while some specific examples were discussed above, it will be noted that a wide variety of changes can be made, and those changes are contemplated by the present discussion. The budget planning orchestration can automatically be performed by processor  124  or another processor or workflow orchestration engine that has access to the stored budget plans. 
       FIG. 10  is a block diagram of system  100 , shown in  FIG. 1 , except that it is disposed in a cloud computing architecture  580 . Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location or configuration of the system that delivers the services. In various embodiments, cloud computing delivers the services over a wide area network, such as the internet, using appropriate protocols. For instance, cloud computing providers deliver applications over a wide area network and they can be accessed through a web browser or any other computing component. Software or components of system  100  as well as the corresponding data, can be stored on servers at a remote location. The computing resources in a cloud computing environment can be consolidated at a remote data center location or they can be dispersed. Cloud computing infrastructures can deliver services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from a conventional server, or they can be installed on client devices directly, or in other ways. 
     The description is intended to include both public cloud computing and private cloud computing. Cloud computing (both public and private) provides substantially seamless pooling of resources, as well as a reduced need to manage and configure underlying hardware infrastructure. 
     A public cloud is managed by a vendor and typically supports multiple consumers using the same infrastructure. Also, a public cloud, as opposed to a private cloud, can free up the end users from managing the hardware. A private cloud may be managed by the organization itself and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installations and repairs, etc. 
     In the embodiment shown in  FIG. 10 , some items are similar to those shown in  FIG. 1  and they are similarly numbered.  FIG. 10  specifically shows that business system  100  is located in cloud  582  (which can be public, private, or a combination where portions are public while others are private). Therefore, user  144  uses a user device  584  to access those systems through cloud  582 . 
       FIG. 10  also depicts another embodiment of a cloud architecture.  FIG. 10  shows that it is also contemplated that some elements of business system  100  are disposed in cloud  582  while others are not. By way of example, data store  134  can be disposed outside of cloud  582 , and accessed through cloud  502 . In another embodiment, budget planning component  128  is also outside of cloud  582 . Regardless of where they are located, they can be accessed directly by device  584 , through a network (either a wide area network or a local area network), they can be hosted at a remote site by a service, or they can be provided as a service through a cloud or accessed by a connection service that resides in the cloud. System  100 , or portions of it, can also be disposed on device  584 . All of these architectures are contemplated herein. 
     It will also be noted that system  100 , or portions of it, can be disposed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices, such as palm top computers, cell phones, smart phones, multimedia players, personal digital assistants, etc. 
       FIG. 11  is a simplified block diagram of one illustrative embodiment of a handheld or mobile computing device that can be used as a user&#39;s or client&#39;s hand held device  16 , in which the present system (or parts of it) can be deployed.  FIGS. 12-15  are examples of handheld or mobile devices. 
       FIG. 11  provides a general block diagram of the components of a client device  16  that can run components of system  100  or that interacts with system  100 , or both. In the device  16 , a communications link  13  is provided that allows the handheld device to communicate with other computing devices and under some embodiments provides a channel for receiving information automatically, such as by scanning. Examples of communications link  13  include an infrared port, a serial/USB port, a cable network port such as an Ethernet port, and a wireless network port allowing communication though one or more communication protocols including General Packet Radio Service (GPRS), LTE, HSPA, HSPA+ and other 3G and 4G radio protocols,  1 Xrtt, and Short Message Service, which are wireless services used to provide cellular access to a network, as well as 802.11 and 802.11b (Wi-Fi) protocols, and Bluetooth protocol, which provide local wireless connections to networks. 
     Under other embodiments, applications or systems (like system  100 ) are received on a removable Secure Digital (SD) card that is connected to a SD card interface  15 . SD card interface  15  and communication links  13  communicate with a processor  17  (which can also embody processors  124  from  FIG. 1 ) along a bus  19  that is also connected to memory  21  and input/output (I/O) components  23 , as well as clock  25  and location system  27 . 
     I/O components  23 , in one embodiment, are provided to facilitate input and output operations. I/O components  23  for various embodiments of the device  16  can include input components such as buttons, touch sensors, multi-touch sensors, optical or video sensors, voice sensors, touch screens, proximity sensors, microphones, tilt sensors, and gravity switches and output components such as a display device, a speaker, and or a printer port. Other I/O components  23  can be used as well. 
     Clock  25  illustratively comprises a real time clock component that outputs a time and date. It can also, illustratively, provide timing functions for processor  17 . 
     Location system  27  illustratively includes a component that outputs a current geographical location of device  16 . This can include, for instance, a global positioning system (GPS) receiver, a LORAN system, a dead reckoning system, a cellular triangulation system, or other positioning system. It can also include, for example, mapping software or navigation software that generates desired maps, navigation routes and other geographic functions. 
     Memory  21  stores operating system  29 , network settings  31 , applications  33 , application configuration settings  35 , data store  37 , communication drivers  39 , and communication configuration settings  41 . Memory  21  can include all types of tangible volatile and non-volatile computer-readable memory devices. It can also include computer storage media (described below). Memory  21  stores computer readable instructions that, when executed by processor  17 , cause the processor to perform computer-implemented steps or functions according to the instructions. System  100  or the items in data store  110 , for example, can reside in memory  21 . Similarly, device  16  can have a client business system  24  which can run various business applications or embody parts or all of business system  100 . Processor  17  can be activated by other components to facilitate their functionality as well. 
     Examples of the network settings  31  include things such as proxy information, Internet connection information, and mappings. Application configuration settings  35  include settings that tailor the application for a specific enterprise or user. Communication configuration settings  41  provide parameters for communicating with other computers and include items such as GPRS parameters, SMS parameters, connection user names and passwords. 
     Applications  33  can be applications that have previously been stored on the device  16  or applications that are installed during use, although these can be part of operating system  29 , or hosted external to device  16 , as well. 
       FIGS. 12 and 13  show one embodiment in which device  16  is a table computer  600 . In  FIG. 12 , computer  600  is shown with user interface display  218  from  FIG. 3C  displayed on the display screen  602 .  FIG. 13  shows computer  600  with user interface display  504  from  FIG. 6A  displayed on display screen  602 . Screen  602  can be a touch screen (so touch gestures from a user&#39;s finger  604  can be used to interact with the application) or a pen-enabled interface that receives inputs from a pen or stylus. It can also use an on-screen virtual keyboard. Of course, it might also be attached to a keyboard or other user input device through a suitable attachment mechanism, such as a wireless link or USB port, for instance. Computer  600  can also illustratively receive voice inputs as well. 
       FIGS. 14 and 15  provide additional examples of devices  16  that can be used, although others can be used as well. In  FIG. 14 , a smart phone or mobile phone  45  is provided as the device  16 . Phone  45  includes a set of keypads  47  for dialing phone numbers, a display  49  capable of displaying images including application images, icons, web pages, photographs, and video, and control buttons  51  for selecting items shown on the display. The phone includes an antenna  53  for receiving cellular phone signals such as General Packet Radio Service (GPRS) and  1 Xrtt, and Short Message Service (SMS) signals. In some embodiments, phone  45  also includes a Secure Digital (SD) card slot  55  that accepts a SD card  57 . 
     The mobile device of  FIG. 15  is a personal digital assistant (PDA)  59  or a multimedia player or a tablet computing device, etc. (hereinafter referred to as PDA  59 ). PDA  59  includes an inductive screen  61  that senses the position of a stylus  63  (or other pointers, such as a user&#39;s finger) when the stylus is positioned over the screen. This allows the user to select, highlight, and move items on the screen as well as draw and write. PDA  59  also includes a number of user input keys or buttons (such as button  65 ) which allow the user to scroll through menu options or other display options which are displayed on display  61 , and allow the user to change applications or select user input functions, without contacting display  61 . Although not shown, PDA  59  can include an internal antenna and an infrared transmitter/receiver that allow for wireless communication with other computers as well as connection ports that allow for hardware connections to other computing devices. Such hardware connections are typically made through a cradle that connects to the other computer through a serial or USB port. As such, these connections are non-network connections. In one embodiment, mobile device  59  also includes a SD card slot  67  that accepts a SD card  69 . 
     Note that other forms of the devices  16  are possible. 
       FIG. 16  is one embodiment of a computing environment in which system  100  (for example) can be deployed. With reference to  FIG. 16 , an exemplary system for implementing some embodiments includes a general-purpose computing device in the form of a computer  810 . Components of computer  810  may include, but are not limited to, a processing unit  820  (which can comprise processor  124 ), a system memory  830 , and a system bus  821  that couples various system components including the system memory to the processing unit  820 . The system bus  821  may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. Memory and programs described with respect to  FIG. 1  can be deployed in corresponding portions of  FIG. 16 . 
     Computer  810  typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer  810  and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media is different from, and does not include, a modulated data signal or carrier wave. It includes hardware storage media including both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer  810 . Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media. 
     The system memory  830  includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM)  831  and random access memory (RAM)  832 . A basic input/output system  833  (BIOS), containing the basic routines that help to transfer information between elements within computer  810 , such as during start-up, is typically stored in ROM  831 . RAM  832  typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit  820 . By way of example, and not limitation,  FIG. 16  illustrates operating system  834 , application programs  835 , other program modules  836 , and program data  837 . 
     The computer  810  may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only,  FIG. 16  illustrates a hard disk drive  841  that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive  851  that reads from or writes to a removable, nonvolatile magnetic disk  852 , and an optical disk drive  855  that reads from or writes to a removable, nonvolatile optical disk  856  such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive  841  is typically connected to the system bus  821  through a non-removable memory interface such as interface  840 , and magnetic disk drive  851  and optical disk drive  855  are typically connected to the system bus  821  by a removable memory interface, such as interface  850 . 
     The drives and their associated computer storage media discussed above and illustrated in  FIG. 16 , provide storage of computer readable instructions, data structures, program modules and other data for the computer  810 . In  FIG. 16 , for example, hard disk drive  841  is illustrated as storing operating system  844 , application programs  845 , other program modules  846 , and program data  847 . Note that these components can either be the same as or different from operating system  834 , application programs  835 , other program modules  836 , and program data  837 . Operating system  844 , application programs  845 , other program modules  846 , and program data  847  are given different numbers here to illustrate that, at a minimum, they are different copies. 
     A user may enter commands and information into the computer  810  through input devices such as a keyboard  862 , a microphone  863 , and a pointing device  861 , such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit  820  through a user input interface  860  that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A visual display  891  or other type of display device is also connected to the system bus  821  via an interface, such as a video interface  890 . In addition to the monitor, computers may also include other peripheral output devices such as speakers  897  and printer  896 , which may be connected through an output peripheral interface  895 . 
     The computer  810  is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer  880 . The remote computer  880  may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer  810 . The logical connections depicted in  FIG. 16  include a local area network (LAN)  871  and a wide area network (WAN)  873 , but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. 
     When used in a LAN networking environment, the computer  810  is connected to the LAN  871  through a network interface or adapter  870 . When used in a WAN networking environment, the computer  810  typically includes a modem  872  or other means for establishing communications over the WAN  873 , such as the Internet. The modem  872 , which may be internal or external, may be connected to the system bus  821  via the user input interface  860 , or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer  810 , or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,  FIG. 16  illustrates remote application programs  885  as residing on remote computer  880 . It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.