Abstract:
A facility for collecting distinguished information relating to an engagement of a first organization by a second organization is described. The facility provides an interface usable by at least one user affiliated with the second organization to provide the distinguished information. Only after the interface is used by a user affiliated with the second organization to provide the distinguished information, the facility permits at least one user affiliated with the second organization to perform a distinguished process.

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
     This application is a continuation-in-part of both U.S. patent application Ser. No. 10/864,290 filed on Jun. 9, 2004 now U.S. Pat. No. 7,617,154, which claims the benefit of U.S. Provisional Patent Application No. 60/477,425, filed on Jun. 9, 2003, U.S. Provisional Patent Application No. 60/497,247, filed on Aug. 22, 2003, and U.S. Provisional Patent Application No. 60/497,246, filed on Aug. 22, 2003; and U.S. patent application Ser. No. 10/923,606, filed on Aug. 20, 2004, which is a continuation-in-part of U.S. patent application Ser. No. 10/864,290, filed on Jun. 9, 2004 now U.S. Pat. No. 7,617,154, which claims the benefit of U.S. Provisional Patent Application No. 60/477,425, filed on Jun. 9, 2003, U.S. Provisional Patent Application No. 60/497,247, filed on Aug. 22, 2003, and U.S. Provisional Patent Application No. 60/497,246, filed on Aug. 22, 2003. 
     Each of the above-listed patent applications is hereby incorporated by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The present invention is directed to the field of automated tools for managing the collection of data about a project, legal matter, or legal case. 
     BACKGROUND 
     Corporate law departments and claims departments of insurance companies (collectively, “companies” or “clients”) have used matter management systems to track information about legal matters and projects (collectively, “matters”). For example, such systems may be used to store a list of people involved in a matter, a schedule for a matter, a budget for a matter, a list of actions taken with respect to the matter, a set of documents relating to the matter, etc. One of the major weaknesses of these systems is that information about these matters can be inaccurately entered by its providers. Because the type of information contained in these matter management systems can be critical (e.g., estimates of potential liability which must be disclosed in certain situations), inaccurate information will result in unreliable reports about the matters and can also lead to other problems such as a failure to comply with Sarbanes-Oxley rules and other regulatory requirements. 
     One of the reasons that matter information may not be accurate is that many matter management systems have a set of fields that must be completed to create a matter on the system or that a third party such as a law firm is required to complete before beginning work on a project (“required fields”), but some or all of the information necessary to complete the required fields is not immediately available and may not be known or reasonably provided until weeks or even months after the matter has commenced. An example of this type of information includes potential liability probabilities and estimates for a litigated matter. (E.g., Financial Accounting Standard 5 establishes rules about when companies are required to recognize the potential loss contingency in the financial statements and disclose the existence of the potential suit to shareholders.) If there has not been a reasonable opportunity to investigate the facts or the law affecting the litigation, this potential liability information is not available or determinable. Consequently, if a user does not have all of the information necessary to complete the required fields when creating or setting up a matter, that user will have a “Catch-22” decision to either enter inaccurate or “dummy” information, or not create or setup the matter. If the user decides to enter inaccurate or “dummy” information, the user may forget or be too busy to go back into the system and correct the inaccurate or “dummy” information. If, on the other hand, the user decides not to create or set up the matter, then the matter management system cannot be immediately used for the matter. 
     An alternative to the required field approach is to make the entry of data in the matter fields not mandatory (an “optional field”); in other words, the user can save the matter form without having entered any value in the field. If the field is optional, it can eliminate the problem of a user entering inaccurate or “dummy” data when creating a matter. However, this solution is also often not satisfactory, because in many situations a blank field is as inaccurate as “dummy” information. Just like with required fields, if the user forgets or is to busy to go back into the system and enter the correct information in the optional field, information will never be entered and the system will have inaccurate data. 
     Another approach would be to make the field optional, but change the field to a required field at a later point in time; in other words, the user can initially create or setup the matter without having filled in any information in the optional field, but then later after the field becomes required, if the user tries to edit or provide any information in the matter fields, the system will not allow the user to save the matter field form without the recently-required field to be completed. This approach, although preferable to the prior two approaches described above, is also not satisfactory because if there is no need to re-edit the matter information in the future, the form never needs to be resaved. Thus, this delay in making the field required does not ensure that the data will ultimately be provided into the field. 
     Finally, a system could use an alerting system to remind a responsible person to enter information in required fields that are incomplete, but the alerting system may not be a sufficient incentive to cause the person to enter the desired information in the fields. For example, if the system sends an email reminder, the user can simply ignore or delete the email message without entering information in the required fields that are incomplete. 
     The problems described above can also exist in situations where a user who is not responsible for managing the matter initially creates the matter in the system for the person who is responsible for the matter. For example, a secretary of an attorney may be responsible for initially creating the matter for a company, or entering data for a law firm to setup the matter, but the secretary may not know or have access to all of the information necessary to complete the required fields of matter information. What the secretary would like to do is fill in the information available to the secretary at the time of saving the form, and then have the attorney fill in the remaining matter information later. This situation involving a secretary and an attorney, however, raises all of the same problems described above. If all of the fields are required fields, the secretary must enter “dummy” information or not provide any information. Alternatively, if the secretary has the option of leaving the fields blank, then the in-house attorney may fail to later enter the important matter information, so the fields are always blank. 
     Accordingly, a software facility that overcame some or all of the aforementioned shortcomings relating to the accurateness of information in a matter management or project management system would have significant utility to corporate law departments, claims departments of insurance companies, and other entities managing projects such as law firms. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a high-level block diagram showing a typical environment in which the facility operates. 
         FIG. 2  is a display diagram showing a typical user interface presented by the facility for configuring whether a field is required of users, and if it is required, which user is it required of and when does the field become required. 
         FIG. 3  is a display diagram showing a typical new matter form presented by the facility in which there may be one or more required fields. 
         FIG. 4  is a display diagram showing a sample pop-up warning message presented by the facility to the person attempting to save a matter form in which one or more soft-required fields do not have a value entered. 
         FIG. 5A  is a table diagram showing sample contents of a matter fields setup table used by the facility to determine what matter fields are required to be completed, and which processes to leverage to ensure information is entered in the required matter fields. 
         FIG. 5B  is a table diagram showing sample contents of a matter fields table used by the facility to track whether a value has been saved in a field that is in use, and if a value has not been saved, whether that field is currently required and therefore the field is identified as incomplete. 
         FIG. 6  is a flow diagram showing steps typically performed by the facility to determine whether a matter has any fields that are currently required for which no information has been entered into the field. 
         FIG. 7  is a display diagram showing a sample alert displayed to a user on the matter page notifying the user that there are one or more required matter fields that are incomplete. 
         FIG. 8  is a display diagram showing a sample dashboard or system-wide alert page presented by the facility to a user to identify one or more matters that required matter fields that are blank. 
         FIG. 9  is a display diagram showing how the posting of other matter data, such as documents, can be leveraged to ensure that the required matter fields are completed. 
         FIG. 10  is a flow diagram relating to  FIG. 9 , and shows steps typically performed by the facility to determine if the user should be allowed to submit other data to a matter such as a document. 
         FIG. 11  is a display diagram showing how the closing matter process can be leveraged to ensure that the required matter fields are completed. 
         FIG. 12  is a flow diagram relating to  FIG. 11 , and shows steps typically performed by the facility to determine if the user should be allowed to close a matter. 
         FIG. 13  is a display diagram showing how the invoice approval process can be leveraged to ensure that the required matter fields are completed. 
         FIG. 14  is a flow diagram relating to  FIG. 13 , and shows steps typically performed by the facility to determine if the user should be allowed to approve an invoice. 
         FIG. 15  is a display diagram showing a setup of a new matter in which a user specifies outside vendor responsible for the matter, and if allowed by the system level setup, which budget information, status report information, and/or spending accrual information is required of the outside vendor and/or the company. 
         FIG. 16  is a table diagram showing how the facility determines if and when a status report is due and what fields are required to be completed by the outside vendor and/or the company in the status report. 
         FIG. 17  is a flow diagram showing steps typically performed by the facility to determine when a status report form is due and what data is required to be completed by the outside vendor and/or the company in the status report form. 
         FIGS. 18A and 18B  are display diagrams showing the web page form that might be presented to the responsible user (and his or her delegates) of the outside vendor and/or the responsible user (and his or her delegates) of the company so that such user can provide the required status report data. 
     
    
    
     DETAILED DESCRIPTION 
     A software facility for ensuring the entry of certain data in a matter management system at a specified time in the future by leveraging another process (the “facility”) is described. The facility tends to ensure that certain fields of information about the matter (the “required matter fields”) are provided at the appropriate time. In some embodiments, the facility requires both company users (such as corporate law department users or insurance claims department users) and outside vendors (such as law firms, consulting firms, or other submitters of invoices) to provide matter information. Accordingly, the functionality relating to the required matter fields could apply to either company users or outside vendor users. 
     The following example demonstrates the usefulness of the above-described functionality. Financial Accounting Standard 5 sets forth requirements for recognizing a potential loss contingency in the company&#39;s financial statements, or disclosing the existence of a potential liability to shareholders. If a company fails to make a timely analysis of the potential loss contingency of a dispute or lawsuit, it may cause a material misstatement in the company&#39;s financial statements. Because of this potential impact to financial statements, some companies&#39; analysis of potential loss contingency is governed by Sarbanes-Oxley regulations, which require that companies establish and maintain adequate internal controls over financial reporting. Thus, if a company enters and tracks information about potential loss contingencies using a process that forces the immediate entry of information about the potential liability analysis, such analysis may not be reliable because the company has not had sufficient time to complete an analysis of the law and facts. Similarly, any process that does not ensure that such analysis has been completed and information about such analysis has been recorded is not reliable. In either situation, the company may not be able to certify that it has adequate internal controls with respect to this financial information, and therefore will not be able to comply with Sarbanes-Oxley rules and regulations. On the other hand, the facility enables users to complete the analysis within a designated time period after the matter has been created and there has been sufficient time to complete an analysis of the law and facts, yet ensures that this information is ultimately and timely entered into the facility. 
     In some embodiments, the facility specifies the required matter fields, and when the matter fields become required. For example, a field could be required when the matter is first created, or it could be required a specified number of days after the matter is created, or within so many days of another event in the matter or facility. For example, the event could be the trial date in a litigation matter, or it could be the beginning of a new fiscal quarter. Those skilled in the art will appreciate that there may be other trigger events linked to the requirement that matter information be completed, such as the spending the in the matter exceeds the matter budget. 
     In some embodiments, the facility is configurable so that the company can specify the required matter fields, and when the required matter fields become required. This configurability could be at the facility-level, across all of a company&#39;s matters, for specific categories of matter, and/or on a matter-by-matter basis. In some embodiments, the company&#39;s setup of required fields will also specify which user is required to complete the field. For example, the facility could specify that the estimate of exposure field in a litigated matter will become required 90 days after the matter is created, and the lead company person and his or her supervisor must provide a value in the field. Alternatively, the facility could be configured so that the company creates the matter by completing a minimum set of fields (such as the matter name, matter description, and law firm managing the matter), and then a third party vendor such as a law firm is responsible for completing the required fields at a specified time in the future (again either on a specific date or related to a matter or facility event). 
     As described above, one aspect of the facility is defining which are the required fields, and when they become required. Another aspect of the facility is specifying what process or processes the facility will leverage to ensure that information is ultimately provided into the required fields. In some embodiments, the facility prevents other data related to the matter from being entered or edited until all required matter fields have been completed. For example, in some embodiments, the facility prevents users from saving and storing files or documents, entering budget amounts for a matter, posting invoices, or providing information that characterizes the present status of the matter, referred to herein as a “status report.” In some embodiments, the restriction placed on certain processes may apply to all users involved in the matter, or it may apply only to the user or users who are responsible for entering information in the required matter fields. While various examples of processes that can be leveraged to enforce a delayed-required field have been described above, those skilled in the art will appreciate that there may be additional types of data relating to the matter that can be leveraged to ensure that required matter information is ultimately and timely provided. 
     In some embodiments, the facility prevents completion of a matter-related process until all required matter fields have been completed. For example, if a user decides to change the status of a matter from “open” to “closed,” as part of the process of closing the matter the facility requires the person closing the matter to complete any required matter information that was left blank. In some embodiments, the facility prevents a company user responsible for a required matter field from (i) reviewing and/or approving, modifying, or rejecting an invoice posted by an outside vendor, (ii) reviewing and/or approving, modifying, or rejecting a budget submitted by an outside vendor to the matter, and/or (iii) reviewing and/or approving, modifying, or rejecting a document submitted by an outside vendor to the matter. In some embodiments, the restriction that information in all required matter fields must be entered before a matter-related process can be completed is applied to all users involved in the matter, or some embodiments apply the restriction only to the user or users who are responsible for entering information in the required matter fields. While various examples of processes have been described above, those skilled in the art will appreciate that there may be additional types of processes relating to the matter that can be leveraged to ensure that required matter information is ultimately and timely provided. 
     In addition, the facility can use the capabilities described above to give users more flexibility in the entry of information in required matter fields, but still ensure that the information is ultimately provided. For example, in some situations, the user creating a matter may not know or have access to the information necessary to complete a required matter field. The user is in a “Catch-22”—either the person has to enter “dummy” information into the required matter field or the person cannot create the matter. In some embodiments the facility will differentiate between a “hard-required” matter field and a “soft-required” matter field. A hard-required matter field is a field in which information must be entered for the form to be saved. A soft-required matter field is one in which the facility allows the user to save the form with the soft-required field blank, but the facility then blocks the entry of some or all other data in the matter and/or prevents the completion of some or all processes in the matter as described above to ensure that information is ultimately entered in the soft-required field. In some embodiments, the facility specifies which fields are hard-required and which fields are soft-required. In some embodiments, the facility enables companies to determine which fields are hard-required and which fields are soft-required. 
     Details of how the facility may be implemented are described below in conjunction with  FIGS. 1-18B . 
       FIG. 1  is a high-level block diagram showing a typical environment in which the facility operates. The block diagram shows several client computer systems used by company users or outside vendor users, such as client computer systems  110 ,  120 ,  130 , and  140 . Each of the client computer systems has a web client computer program for browsing the World Wide Web, such as web clients  111 ,  121 ,  131 , and  141 . The client computer systems are connected via the Internet  150  to a server computer system  160  hosting the facility. Those skilled in the art will recognize that client computer systems could be connected to the server computer system by networks other than the Internet, however. Typically, to be able to connect to the server computer system, the client computer systems must properly authenticate itself to the server computer system, such as by providing user ID and password, or using other authentication technology. 
     The server computer system  160  contains a memory  170 . The memory  170  contains the facility  171 , incorporating both matter management functionality  172  and electronic invoicing functionality  173  typically used by the facility. The memory typically contains a web server computer program for delivering web pages in response to requests from web clients. While items  171 - 174  may be stored in memory while being used, those skilled in the art will appreciate that these items, or portions of them, may be transferred between memory and a persistent storage device  183  for purposes of performing memory management and maintaining data integrity. The server computer system further contains one or more central processing units (CPU)  181  for executing programs, such as programs  171 - 174 , and a computer-readable media drive  182  for reading information or installing programs such as the facility from computer-readable media, such as a floppy disk, a CD-ROM, or a DVD. 
     While various embodiments are described in terms of the environment described above, those skilled in the art will appreciate that the facility may be implemented in a variety of other environments including a single, monolithic computer system, as well as various other combinations of computer systems or similar devices connected in various ways. Additionally, those skilled in the art will appreciate that the facility may be implemented using various software configurations, such as configurations in which the matter management and electronic invoicing software are merged, or other configurations in which their functionality is divided across a larger number of modules, and/or distributed over multiple computer systems. 
       FIG. 2  a display diagram showing a typical user interface presented by the facility for configuring whether a field is required of users, and if it is required, which user is it required of and when does the field become required. This “setup” shown on web page  200 , is therein titled “Edit Matter Category.” Web page  200  shows setup being performed on a per matter category basis, but it could also be for all matters, or on a matter-by-matter basis. The matter category shown is titled “Litigation”  210 , and it is active  211 . 
     The user interface provides several setup options for the fields of matter information. For example, the first selection is whether the field is used. In some embodiments, there may be some fields that must be used in the setup of the system  220  (e.g., when a user creates a new matter, this field must be shown in the matter form). With respect to other fields, the company may have the option to use them  221 , or not use them  222 . 
     In some embodiments, the facility gives companies the ability to pick which fields are “required” (the field must have a value for the form containing the matter information to be saved) or “optional” (the field does not have to have a value for the form containing the matter information to be saved). As shown in web site  200 , the company may have the option of making the field required of the company user responsible for the matter  230  or the lead law firm user responsible for the matter  231 . The field titled Description of Asset Exposure is an example of an optional field  232 . In some embodiments, the company may not have the ability to choose which fields are required, and the facility has been pre-configured with one or more required fields  233 . 
     In some embodiments, the facility gives companies the ability to specify when the field will become required. Some fields the facility may be pre-configured to require the field upon matter creation  240 . Alternatively, the company could specify that the field is required immediately when the matter is created  241 . Or the company could specify a number of days in relationship to an event, such as the number of days after matter creation  242 , the number of days after the company was served with a lawsuit  243 , the number of days after notice of loss  244 , or the number of days before an event such as a trial date  245 . 
     In some embodiments, the facility gives companies the ability to specify what actions will be restricted once a field becomes required and the required information has not been provided (in other words, what actions will be restricted to create leverage to ensure that the required field is completed). For example, if a matter field has become required and if the company has received an invoice to the matter, the facility prevents the invoice from being approved until the matter field has been completed  250 . The restricted action could also be paying an invoice  251 , submitting other data to the matter  252 , or a any of the foregoing  252 . 
     While various embodiments are described in terms of the setup described above, those skilled in the art will appreciate that the facility may be implemented in a variety of other setup criteria and options. The facility may be completely pre-configured with no setup options, or all of the possible setup options could be modifiable by the company. Also, the setup can be varied for each subject matter type within each matter classification (e.g., environmental, employment/labor, securities, business contracts, etc. are examples of different subject matter types). In addition, many events can trigger a field to become required. For example, the facility may enable an administrator to make all company estimates of exposure due within a specified number of days of the company&#39;s quarterly reports, regardless how many days the matter has been open. Also, there could be many types of actions that could be prohibited to create leverage to ensure that the information is entered into the matter field that has become required. In addition, the facility could make fields required of a specific users (e.g., the lead company person, or lead law firm attorney). Also, in the embodiment shown in  FIG. 2 , the company is not allowed to configure the facility to specify which fields are “hard-required” fields, and which fields are “soft-required” fields. In other embodiments, the facility enables the company to specify which fields are “hard-required” fields, and which fields are “soft-required” fields in the facility setup. 
       FIG. 3  is a display diagram showing a typical new matter form in which there may be one or more required fields. This form, shown on web page  300 , is therein titled “New Matter—Create Profile.” In some embodiments, the facility displays in a legend  310  showing which fields must be completed for the form and any information therein to be saved (“hard-required” fields)  320 ; and which fields, although required for future work or processing, can be left blank when the matter form is saved (“soft-required” fields)  330 . In addition, the form may display to the user that the field is not currently required, but will become required at a specified date in the future  340 . 
       FIG. 4  is a display diagram showing a sample pop-up warning message  400  that is shown to the person attempting to save a matter form  300  in which one or more soft-required fields do not have a value entered  410 . Notice that the warning message gives the user the option of saving the form even though there are soft-required fields that have not been completed  420 . If the user had tried to save the matter form with one or more hard-required fields for which no value had been entered, the user would not be presented with the option of saving the form. A similar warning message may be provided for fields that are not currently required, but will become required in the future. Those skilled in the art will appreciate that the facility may provide other methods for notifying the person trying to save the matter form that soft-required fields have not been completed, and preventing the user from saving the matter form if hard-required fields have not been provided. 
       FIG. 5A  is a table diagram showing sample contents of a matter fields setup table used by the facility to determine what matter fields are required to be completed, and which processes to leverage to ensure information is entered in the required matter fields. The matter fields setup table  500  is comprised of rows, such as rows  501 - 511 , each of which corresponds to a unique matter field. Column  512  determines whether the field will be used in the matter. In the particular embodiment shown in  FIG. 5A , the facility requires certain fields to always be used in every matter  513 ; other fields the company may have decided to use  514  or not use  515 . Column  516  determines whether the field is required or optional. In the particular embodiment shown in  FIG. 5A , the facility requires certain fields to always be required in every matter  517 ; other fields the company may have decided to make required of company users  518 , or of law firm users  518   a , or not required  519 . Column  520  determines when the field (if used) is required. In the particular embodiment shown in  FIG. 5A , the facility requires certain fields to be required immediately  521 ; other fields the value specified  522  is the number of days in relationship to the event specified in the Trigger Event column  523 . In this particular embodiment, if the field is not used (such as in row  507 ) or if the field is not required (as in row  506 ), then the designation in column  520  is ignored. Column  523  specifies the date used to determine when a required field becomes due. For example, in row  505 , the Case Summary for Audit letter field becomes required 60 days after the Service Date that has been entered in the matter (which in this particular embodiment is the “Start Date”). Column  524  specifies the method used to ensure that information in the required field is ultimately entered (e.g., users are not allowed to submit other data as shown in row  505 , or invoices cannot be paid as shown in row  510 , or no data or other process is allowed as is shown in row  508 ). If a field is “hard-required,” the method is not applicable (as shown in rows  501 - 504 ) because information is required to be entered in the field for the matter form to be saved. Column  525  specifies whether the field is a “hard-required” field (i.e. a value must be entered for the user to be able to save the matter form such as the one shown in  FIG. 3 ), or a “soft-required” field (i.e. a value is not required to be entered for the user to be able to save the matter form, but if a value is not entered in some embodiments the facility will provide a warning as shown in  FIG. 4 ). In this particular embodiment, if the field is not used (such as shown in row  507 ) or if the field is not required (as in row  506 ), then the designation in column  525  is ignored. 
       FIG. 5B  is a table diagram showing sample contents of a matter fields table used by the facility to track whether a value has been saved in a field that is in use (e.g., in  FIG. 5A  rows  501 - 506  and  508 - 511  are designated as in use), and if a value has not been saved for the field in a matter, whether that field is currently required and therefore the matter form is identified as incomplete. The matter fields table  550  is comprised of rows, such as rows  551 - 553 , each of which corresponds to a unique matter. Columns  554 - 565  are the fields used by the facility for each matter. In this particular embodiment, table  550  shows only a partial list of the fields, and the facility may have many more fields, each of which is contained in a column. The value that has been saved in each field is shown in table  550 . If no value has been saved, the table cell is blank  567 . One of the columns  566  is not a matter field, but is instead a field to track whether all fields that are currently required have a value that has been entered. The steps that the facility uses to determine if a currently required matter field is incomplete is shown in  FIG. 6 . 
     While each of the table diagrams in  FIG. 5A  and  FIG. 5B  show a table whose contents and organization are designed to make them more comprehensible by a human reader, those skilled in the art will appreciate that actual data structures used by the facility to store this information may differ from the table shown, in that they, for example, may be organized in a different manner; may contain more or less information than shown; may be compressed and/or encrypted; etc. 
       FIG. 6  is a flow diagram showing steps typically performed by the facility to determine whether a matter has any fields that are currently required for which no information has been entered into the field, and when alerts should be displayed or sent to users about matters that have one or more currently-required fields that are incomplete. The facility may make this determination in several different situations. In one situation, the facility runs a periodic subsystem  610  (e.g., every night), to determine if any field in matter has become required  611 . The facility determines if the field is currently required by using the matter field setup table  500  and the matter fields table  550  shown in  FIGS. 5A and 5B  respectively. For example, if the field is in use (e.g.,  514 ); if the field is designated as a required field (e.g.,  518 ); if the time for the requirement has been triggered (which is determined by using the date that the subsystem is running compared to the number of days (e.g.,  522 ) before or after the applicable Trigger Event (e.g.,  523  and  557 )), then the field is identified by the facility as currently required. If any currently-required field in a matter has no value, then the facility marks the matter as having a currently-required field that is incomplete  612  (in the matter field table the matter is marked in column  566 , e.g.,  578  and  579 ). 
     Several examples demonstrate this calculation by the facility. In table  550 , none of the matters have values entered for the Claims field, Key Issues field, and Trial Strategy field ( 567 - 575 ). Because the Claims field is not required  519 , the facility does not identify this field as currently required. Similarly, the facility does not identify the field of Key issues field as currently required because the field is not in use  515 . Although the Trial Strategy Memo field (row  508 ) is in use, and is a designated a required field, the field is not currently required for matters  551  or  552  because the date that the subsystem is being run (assume for purposes of this example it is May 1, 2006) is not within 90 days of the Trial date (column  563 ). On the other hand, the field is currently required for matter  553  because at the time the subsystem is being run the matter is within 90 days of the Trial date and the Trial Strategy Memo field is blank, and consequently, the facility has marked matter  553  as having a currently-required field that is blank  579 . Similarly, although the Trial Strategy Memo is not a currently-required field for matter  552 , the Company Liability Estimate field is a currently-required field at the time when the facility subsystem was run (the field becomes required 90 days after matter creation as specified in row  510 , and the matter was created on Dec. 12, 2005, and the subsystem in this example was run on May 1, 2006), and therefore the facility has marked matter  552  as having a currently-required field that is blank  578 . 
     When running subsystem  610 , if the facility marks the matter as having one or more currently-required fields that are incomplete  612 , then in some embodiments the facility provide alerts within the facility (e.g.,  FIG. 7  and  FIG. 8 ) and/or will send an email alert to the responsible users notifying them that one or more fields in the specified matter have become due and a value must be entered before other data can be saved to the matter and/or process can be completed  640 . If the matter has no incomplete fields that are currently required, the matter is marked as such in the matter table  650  (for example,  577  in  FIG. 5B ). 
       FIG. 6  shows other situations in which the facility determines if a matter has any fields that are currently required for which no information has been entered into the field. Whenever a system administrator changes the setup of the fields in the facility (as shown in display  FIG. 2 , which affects the values in table  500 ) the facility runs a subsystem  620  to check every matter in the facility to determine if there is a currently-required field for which no value has been entered  621 . If any currently-required field in a matter has no value, then the facility marks the matter as having a currently-required field that is incomplete  622  (in the matter field table the matter is marked in column  566 , e.g.,  578  and  579 ). When running the subsystem identified by  620 , if a matter is marked as having one or more currently-required fields that are incomplete, then in some embodiments the facility provide alerts within the facility (e.g.,  FIG. 7  and  FIG. 8 ) and/or will send an email alert to the responsible users notifying them that one or more fields in the specified matter have become due and a value must be entered before other data can be saved to the matter and/or process can be completed  640 . If the matter has no incomplete fields that are currently required, the matter is marked as such in the matter table  650 , as is shown in field  577  in  FIG. 5B  for the “Georgie Porgie v. Acme” matter. 
     In addition, whenever a user attempts to save a matter form  630  (whether creating a new matter as shown in  FIG. 3  or saving the matter form for an existing matter), the facility determines whether there are any hard-required fields or soft-required fields that are blank. If there are any hard-required fields that are blank (as determined from column  525  in the matter field setup table  500 ), the facility displays an error message to the user stating that the user must provide values for the identified hard-required fields to be able to save the matter  631 . If there are any soft-required fields that are currently required that are blank, (1) the facility displays an warning message to the user stating that one or more currently-required fields are blank, but the warning message allows the user to save the matter form  631  (example of message shown in  FIG. 4 ); and (2) the facility marks the matter as having one or more currently-required fields that are incomplete  632 . 
     While various embodiments are described above with respect to the steps a facility uses to identify whether a matter has any currently-required fields that are incomplete, those skilled in the art will appreciate that the facility may have a variety of other means of determining whether a matter has any currently-required fields that are incomplete. 
       FIG. 7  is a display diagram showing a sample alert presented by the facility to users who are viewing a matter that has one or more currently-required fields that are incomplete. If a matter has been created with one or more soft-required fields that do not have a value entered, or if a field that was not previously required becomes required, in various embodiments, the facility provides a variety of alerts to company users that the matter data is incomplete with respect to required fields. The matter data is displayed on a web page  700 , and in this particular embodiment the alert  710  is contained within a summary section at the top of the web page  720 . The alert may also identify the specific fields that are required but for which no value has been provided  730 . 
     In some embodiments, the facility may display the alert on each user&#39;s home page or master dashboard page.  FIG. 8  is a display diagram showing such a web page  800 , in which an alert is displayed to the user identifying one or more required fields in the matter profile that are incomplete  810 . In this particular embodiment the user can click on the “Due” hyperlink to jump directly into the web page that displays the matter data. 
     In some embodiments, if a matter field becomes required and there is no value in the field, the facility will notify the person responsible for the matter by sending an email to such person notifying him or her that a field that currently has no value has become required. 
     While various embodiments are described above with respect to alerts to users if fields that are required or have become required do not have a value in the field, those skilled in the art will appreciate that the facility may have a variety of other means of notifying the user that the required field or fields are incomplete. 
       FIG. 9  is a display diagram showing how the posting of other matter data (and in this diagram specifically the posting of documents to a matter) can be leveraged to ensure that the required matter fields are completed. In this particular embodiment a user accesses the web page where the user can post documents  900 . In some embodiments, when the user clicks the action to post a document  910 , if there are any required matter fields that are blank, the facility displays a pop-up message explaining that documents cannot be posted until the incomplete required matter fields have the proper information entered  920 . In some embodiments, when the user clicks the button to proceed  930 , the facility then displays the matter profile form displayed in  FIG. 3 , which the user can complete to enable the matter to be closed. 
       FIG. 10  is a flow diagram relating to  FIG. 9 , and shows steps typically performed by the facility to determine if the user should be allowed to submit other data to a matter such as a document. The user accesses web page in the matter where the user can post a document  1010 . The user clicks the action to post a document  1020 . The facility checks the matter fields table described in  FIG. 5B  to determine if the matter has any required matter fields that are incomplete  1030 . If there are required matter fields that are incomplete, the facility will not allow the document to be posted, and will display a message to the user that certain required matter fields must be completed before the document can be posted  1040 . Those skilled in the art will appreciate that the steps shown in  FIG. 10  may be altered in a variety of ways. For example, in some embodiments the facility may not allow the user to access the location for posting documents if there are any required matter fields that are blank. 
       FIG. 11  is a display diagram showing how the closing matter process can be leveraged to ensure that the required matter fields are completed. In this particular embodiment a user accesses the matter and triggers an action in the facility to close a matter. In some embodiments the facility displays a web page  1100  that is a form of information required to be entered to be able to close the matter  1110 . When a user fills out the close matter form and clicks the action to close the matter  1120 , the facility displays a pop-up message explaining that the matter cannot be closed until the incomplete required matter fields have the proper information entered  1130 . In some embodiments, when the user clicks the button to proceed  1140 , the facility then displays the matter profile form displayed in  FIG. 3 , which the user can complete to enable the matter to be closed. 
       FIG. 12  is a flow diagram relating to  FIG. 11 , and shows steps typically performed by the facility to determine if the user should be allowed to close a matter. The user accesses the matter and clicks an action to close the matter  1210 . The facility displays a closing matter form  1220  shown in  FIG. 11 , and the user completes the fields in the close matter form, and clicks an action to save and close the matter  1230 . The facility checks the matter fields table described in  FIG. 5B  to determine if the matter has any required matter fields that are incomplete  1240 . If there are required matter fields that are incomplete, the facility will not allow the matter to be closed, and will display a message to the user that certain required matter fields must be completed before the matter can be completed  1250 . Those skilled in the art will appreciate that the steps shown in  FIG. 12  may be altered in a variety of ways. For example, in some embodiments the facility may not allow the user to access the close matter form if there are any required matter fields that are blank. 
       FIG. 13  is a display diagram showing how the invoice approval process can be leveraged to ensure that the required matter fields are completed. In this particular embodiment the user accesses a web page (called the “invoice pending page”)  1300 , which displays a list of invoices  1310  that are pending the user&#39;s review and approval. In this embodiment, each invoice is posted to a matter  1315 . If all of the required matter fields in a matter have been completed, the user is presented with a dropdown selection of options for approval of the invoice (e.g., “Recommend Pay in Full”)  1320 . If, however, one or more required matter fields are incomplete, then the user is not presented with a dropdown selection of invoice approval options, and instead is notified that there is an incomplete task  1330 . In this embodiment the user can click on a link  1340  to access the matter profile form displayed in  FIG. 3 . Once the user enters information in the required matter fields for the matter, the incomplete task alert will be removed from the invoice pending page, and the user will be allowed to approve an invoice. While various embodiments are described above with respect to preventing a user from approving an invoice if one or more required matter fields are blank, those skilled in the art will appreciate that the facility may have a variety of other means ensuring that the required matter fields have been completed before a user can process an invoice that has been posted to a matter. For example, the user may be prohibited from even accessing or viewing the invoice if any of the required matter fields are incomplete, or the facility may allow the invoice to be approved, but not sent to accounts payable for payment until all of the required matter fields are completed. Alternatively, the approval options may not be displayed on the invoice pending page, but on a different web page displaying the invoice. 
       FIG. 14  is a flow diagram relating to  FIG. 13 , and shows steps typically performed by the facility to determine if the user should be allowed to approve an invoice. The law firm posts an invoice to a matter  1410 . The facility routes the invoice for approval, and the invoice becomes pending the review of a company user who has responsibility for entering information in the required matter fields  1420 . When the company user accesses the invoice pending page  1430 , the facility identifies the invoices that should be displayed on the pending page for the user. Prior to rendering the invoice pending page, with respect to the matter corresponding to each invoice on the invoice pending page the facility will also check the matter fields table described in  FIG. 5B  to determine if there are any matters with required matter fields are incomplete. If there are required matter fields that are incomplete, the facility will not display the invoice approval selections ( 1320  in  FIG. 13 ) for the invoice, and will instead display an incomplete task alert ( 1330  in  FIG. 13 )  1440 . If all the required matter fields of the matter to which the invoice was posted have been completed, then the invoice approval selections ( 1320  in  FIG. 13 ) will be displayed to the user with respect to the invoice. Those skilled in the art will appreciate that the steps shown in  FIG. 14  may be altered in a variety of ways. For example, some embodiments of the facility may always display the invoice approval selections, and check the matter fields table in  FIG. 5B  once the user has selected the invoice approval option, in which case the incomplete task alert would be shown to the user when the user attempts to submit the invoice for approval ( 1350  in  FIG. 13 ). 
     In some embodiments, the facility permits a company to set up matters in a manner that requires company users to provide or approve information contained in the status report instead of, or in addition to, vendor users. This functionality is discussed below in connection with  FIGS. 15-18B . 
       FIG. 15  is a display diagram showing a typical new matter setup in which a user specifies an outside vendor responsible for the matter, and if permitted by the system-level setup, which budget information, status report information, and/or spending accrual information is required of the outside vendor and/or the company. In various embodiments, the facility permits a company user to perform the setup for a single matter; all of its matters; all of its matters with a particular outside vendor; or a proper subset of all of its matters selected in any other way. 
     The matter setup page may have other selections about the matter which do not involved required fields  1501 . However, in the budget setup section  1510 , the facility enables the company user to specify whether a budget is required of the outside vendor  1513  and when the budget is required  1514 , what type of budget is required  1512 , and/or whether an accrual entry for outside vendor spending during the fiscal year that has not yet been billed (used by companies that use the “accrual” method of accounting)  1515  and when the accrual entry is required  1516 . 
     In the status report setup section  1530 , the facility enables the company user to specify whether a monthly or quarterly status report is required of the outside vendor and/or the company  1532  and when the first status report is required  1533 ; whether a detailed case assessment is required to be attached to a status report  1534  and in which status report the detailed case assessment should be provided  1535 ; whether a detailed trial analysis is required to be attached to a status report  1536  and in which status report the detailed trial analysis should be provided  1537 ; and/or whether the matter budget  1538 , estimates of exposure/recovery  1539 , estimates of resolution  1540 , and/or a case summary  1541  are required, and if already provided displayed and confirmed, and when such data (i.e.,  1538 - 1541 ) is first required to be provided/confirmed  1542 / 1543 . This section also contains a set of radio buttons  1544  that the company user may use to indicate whether the selected status report options are required of the outside vendor, the company, or both. 
     In the Outside Vendor Responsible setup section  1550 , the facility enables the company user to specify the outside vendor user responsible for the matter  1551  and the system automatically fills in the name of the outside vendor associated with such user  1552 . Those skilled in the art will appreciate that the user interface for selecting the outside vendor user responsible and the outside vendor may be implemented in a variety of other selection options. In addition, those skilled in the art will recognize that while the selections identified in  FIG. 15  is on one web page, such selections may be made in a sequence of web pages. 
       FIG. 16  is a table diagram showing how the facility determines if and when a status report is due and what fields are required to be completed by the outside vendor in the status report. The status report table  1600  is comprised of rows, such as rows  1601 - 1605 , each corresponding to a matter. Each row is divided into a matter ID column (which is the object ID in the facility)  1606 ; the matter name  1607 ; the status report option  1608 ; whether the status report is to be augmented or confirmed by the outside vendor, the company, or both  1609 ; if a budget is to be confirmed or updated in the status report, the budget type  1610 ; requirement that the status report include a case assessment and when it is due in terms of the number of days after the matter was created  1611 ; requirement that the status report include a trial assessment and when it is due in terms of the number of days before the trial data  1612 ; requirements for other data  1612  and when such data is due  1614 ; the date of the last status report  1615 ; and the date the matter was created  1616 . The facility can determine from the data in each row whether a status report is due at any given time and what fields should be displayed in the status report. For example, the status report options column  1608  is one check to determine if a status report is due that month. If the selection is “Quarterly,” and the current day is Apr. 2, 2004, and if a status report was not submitted Apr. 1, 2004, or Apr. 2, 2004 (as shown in the date of the last status report  1615 ), then the status report is due (in this particular embodiment the “Quarterly” selection uses the quarters of a calendar year, but those skilled in the art will appreciate that the frequency of the reporting option or the cycle dates can vary). 
     Even if a status report is not required because of the status report option field, there are other reasons that a status report may be due. For example, if as shown the “Big E. Rentals” matter was created on Jan. 15, 2004, and if a case assessment is due 60 days thereafter, a status report due alert would be generated and displayed to the outside vendor user responsible for the data (or his or her delegate) on Mar. 15, 2004, and the outside vendor would not be able to submit invoices until such status report data is provided. If an outside vendor opened up the status report form between March 15th and March 31, the form might include a field for the current status of the matter and a field in which the user is required to attach a document containing the case assessment prior to saving the form. If the user does not submit a status report during such time period, and opens up the status form report after March 31, the form may also require additional data (e.g., if the status report table specifies that a budget must be confirmed Quarterly). 
     Similarly, the facility can use the trial assessment due column  1612  to determine if a status report is due, and if the status report form should include an attachment containing the trial assessment (the facility must reference the trial date contained in a separate table in the facility, which can be cross referenced using the Matter Object ID  1606 ). 
     Similarly, the facility can use the “Display Options” column  1613  to determine (i) if the status report form displays the current budget and requires the outside vendor user to confirm or update the budget (if the first number in the three-digit sequence is a 1 the budget must be displayed and confirmed, if the digit is a 0, the budget is not displayed); (ii) if the status report form displays the current estimates of exposure/recovery and requires the outside vendor user to confirm or update the estimates of exposure/recovery (if the second number in the three-digit sequence is a 1 the estimates of exposure/recovery must be displayed and confirmed, if the digit is a 0, the estimates of exposure/recovery are not displayed); and/or (iii) if the status report form displays the resolution estimates and requires the outside vendor user to confirm or update the resolution estimates (if the first number in the three-digit sequence is a 1 the resolution estimates must be displayed and confirmed, if the digit is a 0, the resolution estimates are not displayed). In connection with the Display Option column, the facility uses the “Display Options Due” column  1614  to determine in what status report such data is shown and required to be updated (after which it will be included in all future monthly or quarterly status reports). 
     Those skilled in the art will recognize that the facility could be designed so that any type of data could be required to be input or updated in the status report form. Essentially, the status reporting tool can be used to ensure that any type of data in the facility is provided at a specific point in time, or periodically confirmed and/or updated throughout the life of the matter. 
       FIG. 17  is a flow diagram showing steps typically performed by the facility to determine when a status report form is due and what data is required to be completed by the outside vendor and/or the company in the status report form. The company first creates system-level requirements for data  1701 , or sets requirements for data when a matter is created  1702 . Then, after an outside vendor user responsible for data in one or more matters (or his or her delegates) or a company user responsible for data in one or more matters (or his or her delegates) logs into the facility  1703 , the facility checks to determine if the user is responsible for any matters in which data is required and due  1704 . This includes but is not limited to determining if there is a monthly or quarterly status report due for the month, or if other data is required to be provided for that month such as a case assessment. If data is required and due for any of the user&#39;s matters, the facility provides an alert for each matter in which a status report is due (as shown in  FIG. 4 )  1705 . The user can access the matter and call up the status report form for the matter  1706 , and the facility will generate the status report form with the fields for the required data  1707 . The user can then enter the data in the status report form, and save the form  1708 . The facility will save and display the status report, and may save data to other portions of the facility (e.g., if the status report form included a case assessment document that was attached, the attached document will be saved in the documents folder for the matter; or if the data includes an estimated resolution date, the data will be saved in the matter profile for the matter)  1709 . Once the status report has been submitted that satisfies the requirement for the data that is required and due, the outside vendor user (or another outside vendor user for the same vendor) can submit an invoice to the matter so long as no other data is required and due for the matter  1710 . Similarly, once a company user submits a status report that satisfied the requirement of the data that is required and due, the company user (or another company user) can approve an invoice submitted to the matter so long as no other data is required and due for the matter  1210 . 
       FIGS. 18A &amp; 18B  are display diagrams showing examples of web page forms that may be presented to the responsible user (and his or her delegates) of the outside vendor or of the company so that such user can provide the required status report data.  FIG. 18A  shows an example of the first status report input form  1800  for the matter that might be presented to the responsible user or delegate. The form has a field to specify the current status  1810 , a field to specify the total budget for the matter  1820 , and fields to enter the monthly fees  1830  and expenses  1831  for each month of the current fiscal year, together with a field to enter a description of the activities for the applicable month  1832 .  FIG. 18B  shows an example of the 3rd month status report input form  1850  for the same matter that might be presented to the responsible user of the outside counsel. In this example, the form has a field to specify the current status  1851 , fields to specify the estimates of exposure and recovery for the matter  1860 - 1863 , fields to specify the estimated resolution of the matter  1870 ,  1871 , a field to attach a file (such as a Microsoft Word document) that contains a case analysis for the matter  1880 , and the budget displayed with a selection to confirm the budget  1890  or a link to update and correct the budget  1891 . In other words, the data object which is in the form of a status report can change for each status report to display the required information that must be completed or updated at the time the status report is submitted. In some embodiments, the facility displays chevrons—such as those displayed near the identifiers for fields  1860 - 1863  and  1870 - 1871 —that identify these fields as required. In some embodiments (not shown), the facility requires all of the fields in the status report. In some embodiments, where the status report is required for a company user, the company user must complete all required fields in the status report. In some embodiments (not shown) in which the status report is required for a company user, the company user must operate a confirmation control to confirm the accuracy and currentness of the information in all of the fields, or in all of the required fields. While various embodiments of a status report form are described above, those skilled in the art will appreciate that the facility may provide other fields for data in the status report form. 
     It will be understood by those skilled in the art that the above-described facility could be adopted or extended in various ways. For example, the facility may be used by a variety of different clients and outside or inside vendors. Additionally, the facility can require fields in response to a wide variety of events, observed by the facility in a wide variety of ways. While the foregoing description makes reference to preferred embodiments, the scope of the invention is defined solely by the claims that follow and the elements recited therein.