Ensuring the entry of certain data in a matter management system by leveraging another process

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

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'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's financial statements. Because of this potential impact to financial statements, some companies' 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's matters, for specific categories of matter, and/or on a matter-by-matter basis. In some embodiments, the company'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'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 518a, 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'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'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'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 & 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.

Claims

1. A method in a computing system for collecting information relating to an engagement between a first organization and a second organization, comprising: recurringly, at intervals of a fixed length, for each of a plurality of information fields relating to the engagement; with the computing system, accessing an indication comprising a time-based condition under which receiving contents for the information field becomes required to perform a first process, wherein the computing system is configured to perform the first process for users other than at least one user responsible for entering the contents in the required information field independently of whether the contents for the information field are received,wherein when the condition is presently satisfied, the computing system requires receiving contents for the information field prior to performing the first process for at least one user of a plurality of users who is responsible for the contents for the information field, and wherein when the condition is presently not satisfied, the computing system does not require receiving contents for the information field to perform the first process for the plurality of users, so that the first process can be performed irrespective of whether contents for the information field have been provided;with the computing system, determining whether the time-based condition under which the information field becomes required is presently satisfied;when it is determined that the condition under which the information field becomes required is presently satisfied, with the computing system, identifying receiving contents for the information field as presently required;when it is determined that the condition under which the information field becomes required is presently not satisfied, with the computing system, identifying receiving contents for the information field as presently not required; andwhen receiving contents for the information field is presently required to perform the first process and contents for the information field have not been received, preventing performance of the first process by the at least one user responsible for the contents for the information field.

2. The method of claim 1, further comprising, for each information field identified as presently required: determining whether contents have been provided for the information field; andif contents have not been provided for the information field, recording data in the computing system identifying the information field as delinquent.

3. The method of claim 2, further comprising, for each information field identified as delinquent, identifying a user of the first organization to whom to identify the information field as delinquent.

4. The method of claim 2, further comprising: for each information identified as delinquent, identifying a second process relating to the engagement that is precluded in response to the delinquency of the information field identified as presently required; andwhen the at least one user attempts the second process relating to the engagement that is identified as precluded, preventing the completion of the attempted second process.

5. The method of claim 2 wherein an information field is identified as delinquent by providing for display to a first user affiliated with the first organization an indication that the information field is delinquent.

6. The method of claim 5 wherein the first user has primary responsibility for the provision of contents of the delinquent information field.

7. The method of claim 5 wherein a second user affiliated with the first organization has primary responsibility for the provision of contents of the delinquent information field.

8. The method of claim 5 wherein a second user affiliated with the second organization has primary responsibility for the provision of contents of the delinquent information field.

9. The method of claim 2 wherein a first user affiliated with the first organization has primary responsibility for the provision of contents of a delinquent information field, and wherein an information field is identified as delinquent by, in response to an attempt by a second user affiliated with the first organization to complete a distinguished process relating to the engagement: preventing the second user from completing the distinguished process; andproviding for display to the second user a message identifying the delinquent information field and indicating that the distinguished process can only be completed once the first user has provided contents for the delinquent information field.

10. The method of claim 1 wherein the first organization is a provider of services to the second organization.

11. The method of claim 1 wherein the second organization is a provider of services to the first organization.

12. A computer-readable memory whose contents cause a computing system to perform a method for collecting information relating to an engagement between a first organization and a second organization, the computer-readable memory not being a transitory, propagating signal per se, the method comprising: periodically, at fixed intervals, for at least one of a plurality of information fields relating to the engagement: accessing an indication comprising a time-based condition under which receiving contents for the information field becomes required in order to perform a first process, wherein the computing system is configured to perform the first process for users other than at least one user responsible for entering the contents in the required information field independently of whether the contents for the information field are received;determining whether the condition is presently satisfied; andwhen it is determined that the condition is presently satisfied, identifying the information field as presently required and requiring the contents for the information field to be received prior to performing the first process for at least one user of a plurality of users who is responsible for the contents for the information field;for each information field of the plurality identified as presently required: determining whether contents have been provided for the at least one information field; andif contents have not been provided for the at least one information field, identifying the information field as delinquent;for each information field identified as delinquent: in response to the delinquency of the information item, identifying at least one process relating to the engagement as precluded, wherein the computing system is configured to perform the process independently of whether the contents for the information field are received; andwhen the at least one user responsible for the contents for the information field attempts the at least one process relating to the engagement that is identified as precluded, preventing the performance of the at least one process.

13. The computer-readable memory of claim 12, the method further comprising, for each information identified as delinquent, identifying a user of the first organization to whom to identify the information field as delinquent.

14. The computer-readable memory of claim 12 wherein an information field is identified as delinquent by providing for display to a first user affiliated with the first organization an indication that the information field is delinquent.

15. The computer-readable memory of claim 14 wherein the first user has primary responsibility for the provision of contents of the delinquent information field.

16. The computer-readable memory of claim 14 wherein a second user affiliated with the first organization has primary responsibility for the provision of contents of the delinquent information field.

17. The computer-readable memory of claim 14 wherein a second user affiliated with the second organization has primary responsibility for the provision of contents of the delinquent information field.

18. The computer-readable memory of claim 12 wherein a first user affiliated with the first organization has primary responsibility for the provision of contents of a delinquent information field, and wherein an information field is identified as delinquent by, in response to an attempt by a second user affiliated with the first organization to complete a distinguished process relating to the engagement: preventing the second user from completing the distinguished process; andproviding for display to the second user a message identifying the delinquent information field and indicating that the distinguished process can only be completed once the first user has provided contents for the delinquent information field.

19. The computer-readable memory of claim 12 wherein the first organization is a provider of services to the second organization.

20. The computer-readable memory of claim 12 wherein the second organization is a provider of services to the first organization.

21. The computer-readable memory of claim 12 wherein a first condition under which a first information field becomes required is different from a second condition under which a second information field becomes required.