FIELD OF THE INVENTIONThe field of the invention is matter management computer software, such as may be used by attorneys and law firms to maintain control of their client matters.[0001]
BACKGROUND OF THE INVENTIONThere have been numerous improvements in matter management software over the years, as exemplified by software such as Timeslips™, QuickBooks™ and CTS™ by FlexTrac Systems, Inc., Dimension™ by Computrac, Inc. and Junior Partner™ for Windows™ by Millenium Software Ltd. Among other things, sophisticated timekeeping and billing software packages have been ported from mainframe computers to desktop and laptop computers, and redesigned to make greater use of graphical user interfaces (GUI interfaces). Despite the many advances, however, it turns out that existing matter management software packages still lack several features that would greatly increase their usefulness.[0002]
Overview Sheet[0003]
One particularly pressing need is for a more convenient overview of the status of a matter. Some of the existing packages display basic matter identification information such as matter title, client name and so forth, using an interface that also displays a few milestones and a few calendared events. It is also known to display identification information in an interface that includes individual hourly billing descriptions. But there appears to be no packages that display identification information, the plurality of milestones, the plurality of hourly billing descriptions, and the plurality of calendared items in the same display.[0004]
On-Line Office Procedure Manual[0005]
A related need is for an on-line office procedure manual that can be tied into the milestones. The need is particularly acute in an office worker that would normally handle a task is not available, such as may be caused by employee turnover, or by an employee taking vacation time. A very simple example illustrates the point. In known systems for patent law firms, receipt of an office action from the patent office may trigger the automatic calendaring of the drafting of a response to the office action. But a new employee may not know that in addition to calendaring the response, a copy of the office action should be forwarded to the client, the inventors, and the responsible attorney. Similarly, the filing of a new patent application may trigger automatic calendaring of a reminder to check the file for a filing receipt, but a new employee may not know that along with filing of a new application, one should include related documents such as a Small Entity Statement, A Declaration And Power Of Attorney, an Information Disclosure Statement, a 1449 form, a check to cover the filing fee, and a postcard. Of course, many offices have checklists for such items, and possibly even an employee manual with reminder lists. But such lists are of decidedly reduced usefulness because they are not automatically accessed upon the recording of the triggering event.[0006]
Non-Calendar Reminder Mechanism[0007]
Yet another problem with existing timekeeping and billing systems is that users of such systems, whether secretaries, paralegals, attorneys or others, often have considerable difficulty properly calendaring events into the future. Where matters involve calendaring litigation, for example, calendaring rules differ from court to court, and possibly even case to case, and it is difficult or impossible for any given individual to maintain knowledge of all such rules. The situation is greatly exacerbated in intellectual property law because events are often calendared many years in advance. To some extent this problem has been addressed by auto-calendaring routines that calendar events based upon user modifiable rules sets. But even auto-calendaring routines are only effective in helping to avoid mis-calendaring. They offer no help at all in preventing non-calendaring errors, such as may result from lost or misplaced mail.[0008]
In a patent law office, for example, it often happens that an attorney will submit a paper to the patent office, and not receive any sort of response for a year, or even longer. Because of the lengthy time delay, and because the patent office can be expected to issue an office action at some point in time, many attorneys will not calendar any follow-up until they receive a first office action. That tactic is, of course, problematic since an application or office action may get lost in the mail, or even within the attorney's own office. In such instances the application may well go abandoned. Even if the attorney has an internal policy to calendar follow-ups for lengthy periods of time such as 6 and 12 months, such calendaring still requires an affirmative step, and is therefore still subject to human error. Failure to take a necessary affirmative step will still allow the application to go abandoned. Thus, there is a continuing need to provide a reminder mechanism that operates independently of the calendaring system. If the reminder mechanism were somehow triggered by entries of milestones, the user would have the best of both worlds—a reminder system that is independent of calendaring, but one that could still be reset automatically during the ordinary course of business. Such a mechanism, however, is unknown in the field.[0009]
User-Defined Data Fields[0010]
Several existing systems provide generic data fields that users can adapt for their own custom purposes. Such users may, for example, use the generic fields to store dates, serial numbers, inventor names, and so forth. One continuing problem, however, is that in known systems this flexibility is only available on a global or matter type level, not on the level of individual matters. Designating that[0011]generic field number 4 is to be used for a serial number is a complete waste of space for matters that don't use serial numbers. The same would be true about storing a client's status as a large or small entity. The information is relevant to US patent filings, but is irrelevant for most foreign patent filings, and is certainly irrelevant for copyright filings. Not only does designation of a generic field as a specialty field waste disk space, it also wastes real estate on the interface (computer display), and renders the interface more confusing than it needs to be. Thus, there is a continuing need to store information in a timekeeping/billing system according to user-defined fields that can vary on a matter-by-matter basis.
Another problem with existing user-customizable fields is that the custom fields are hard to keep track of. For example, a user may know that he or she is storing a patentability search date in a particular custom field, but the interface only displays a cryptic filed name such as CFI (perhaps as a designation for customer field number[0012]1). As a result, other users may store corresponding information in some other custom field, and/or may store other types of information in the field being used for search date. In this and other ways the presently available user-customizable fields leave a lot to be desired.
Still another problem with existing user-customizable fields is that such fields are not tied into auto-calendaring or other functions of the system. Yes, it may be possible to print out data stored in custom fields when printing an entire record, but the data is merely stored for retrieval using the display screen, or some sort of report writer. It is not known to the present inventor to interactively search and sort data in user-customizable fields.[0013]
Thus, there remains a considerable need for improved matter management software and related methods.[0014]
SUMMARY OF THE INVENTIONThe present invention provides timekeeping software having at least one of several improvements. One improvement is a single display that shows matter identification information, the plurality of milestones, the plurality of hourly billing descriptions, and the plurality of calendared items. Another improvement is a user-defined on-line procedures mechanism, which is preferably tied into the milestones. Still another improvement is a matter specific timer based reminder mechanism, such as a count-down or count-up timer. Still another improvement is the use of user-defined fields at the matter level, preferably using a plurality of identifier/value pairs (see “Identifier/Value Concept” infra). The software may advantageously display a field description in conjunction with each piece of data displayed, and provide a drop down listing of field descriptions for selection by the user.[0015]
Especially preferred embodiments include several of these improvements. For example, the milestones may advantageously comprise custom fields that can be selected on a matter-by-matter basis. As another example, selection of user-defined milestones may advantageously trigger at least one of autocalendaring, on-line procedure manual, and non-calendar reminder mechanism features.[0016]
In another respect the invention provides a method of managing information in a computer implemented matter management system, comprising: storing a plurality of user-defined data identifiers on a database; providing a user interface with a scrollable listing of the identifiers; selecting a subset of the data identifiers for a particular matter; entering and associating an item of text data with at least one data identifier of the selected subset; and interactively displaying in a single display a plurality of identification information data items for the matter, the at least one data identifier, and its associated text data. The data identifiers may be any one or more of milestones, office procedures, matter details, contact relationships, and contact specific or address specific information.[0017]
The term “user interface” means a display of data that a nonprogrammer or layperson can access, understand, and operate. A user interface does not include a Microsoft™ Access™ or other data table design interface used programmers to set up data tables, field names, and so forth.[0018]
In another respect the invention provides a matter management system that is at least partially stored on a computer readable medium, and comprises a first designation interface that provides for designation of a matter as having a matter type selected from a plurality of matter types; a second designation interface that provides for designation of a plurality of milestones for the matter type; a selection interface that provides for selection of a proper subset of the plurality of milestones as being appropriate for the matter, thereby defining a non-null subset of non-selected members of the plurality of milestones; an interactive display that displays in a single display a plurality of identification information data items for the matter, and at least one of the selected subsets of milestones without listing all of the non-selected members. The system preferably displays all of the selected subsets of milestones and none of the non-selected milestones.[0019]
In another respect the invention provides a matter management system having both an auto-calendaring function and a matter timer.[0020]
Various objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description of preferred embodiments of the invention, along with the accompanying drawings in which like numerals represent like components.[0021]
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1[0022]ais an image of an interface that shows matter identification information, a plurality of milestones, a plurality of hourly billing descriptions, and a plurality of calendared events all on the same display.
FIG. 1[0023]bis another image of the user interface of FIG. 1, further depicting a drop down menu for selecting a milestone.
FIG. 2 is an interface for associating milestones with matter types.[0024]
FIG. 3 is a matter report showing milestones for multiple matters.[0025]
FIG. 4 is an image of an interface that shows a user-defined auto-calendaring mechanism accessed by selection of a milestone.[0026]
FIG. 5 is an image of an interface that shows a user-defined on-line procedures mechanism accessed by selection of a milestone.[0027]
FIG. 6 is a preferred interface for setting matter specific timers.[0028]
FIG. 7 is a sample matter specific timer report.[0029]
FIG. 8 is an image of a preferred matter details interface showing matter specific data and contacts, both using identifier/value pairs.[0030]
FIG. 9 is an image of a preferred contacts interface showing contact-specific data and address-specific data, both using identifier/value pairs.[0031]
FIG. 10 is a matter report depicting a preferred arrangement of milestone, matter detail, and matter contacts stored as identifier/value pairs.[0032]
FIG. 11 is an image of an interface for creating records for new matters in the database, and correlating matter type and other information with the matters.[0033]
FIG. 12 is an image of a document creation interface.[0034]
FIG. 13[0035]ais a representation of a previous system of information storage.
FIG. 13[0036]bis a representation of information storage having identifier/values.
DETAILED DESCRIPTIONThe various Figures in this application are all part of a matter management software system that is at least partially stored on a computer readable medium. The computer readable medium may be a data disk, tape, a CD ROM or other read only memory, a re-writable CD, a chip based or other random access memory (RAM), or any other suitable medium. The system is most likely implemented on a desktop, laptop, handheld, or other personal computer (PC), although it is also contemplated that one or more components can be stored and/or implemented on multiple computers, including local area and wide area computer networks, application service providers (ASPs), and so forth.[0037]
In FIG. 1[0038]aa preferred user interface100 (i.e., a display screen) hasrecord selection areas120A through120D,record identifiers130A-130G,control tabs140A-140G,milestones section150,hours section160,calendar section170, defaultrate code field182,flag field184, andtimer field186.
The user interface depicted in FIG. 1[0039]ais an example of a single display that simultaneously shows matter identification information, at least three of the plurality of milestones, at least three of the plurality of hourly billing descriptions, and at least three of the plurality of calendared items. The matter identification information is displayed in therecord identifiers area130A-130G; milestones are displayed in themilestones section150; hourly billing descriptions are displayed in thehours section160; calendared items are displayed in thecalendar section170.
Record Selectors and Identifiers[0040]
As will be especially appreciated by those familiar with Microsoft™ products, the[0041]record selection areas120A through120D accept user input in the selection of a matter record. The term “user” is employed herein to mean an ordinary employee, one having little or no programming skills. Here,selection area120A provides record selection by docket or matter number,selection area120B provides record selection by matter name,selection area120C provides record selection by client reference number, andselection area120D provides record selection by official serial number. Data can he entered directly into the boxes shown, or by selecting an item from a drop-down list (see FIG. 1b).
Also in this example, selected[0042]matter identifiers130A-130G display information for a selected matter.Identifier130A displays the docket number,identifier130B displays the matter title,identifier130C displays the matter type (patent, trademark, copyright, immigration, state court litigation, contract drafting, opinion letters, etc.),identifier130D displays the official serial number,identifier130E displays the status,identifier130F displays the client's reference number, andidentifier130G displays the client's name. Of course, other record selection and record identifiers could be added to or substituted for those displayed in this example.
Milestones[0043]
The[0044]Milestones section150 of FIG. 1aincludes multiple rows of data, each row corresponding to one milestone, and each row having data in three columns. TheMilestone Date column152 displays a date corresponding to the milestone on the same row. The default date is usually set to the current date, and in any event the date is preferably restricted to past or present dates since milestones are presumably events that have already occurred. Double clicking on any of the date fields inMilestone Date column152 preferably displays a miniature monthly calendar (not shown) that assists the user in selecting a date.
The[0045]Milestone Description column154 displays a predefined milestone that is preferably selected from a drop-down type listing such as that depicted in FIG. 1b. TheMilestone Comment column156 displays textual comments that a user may want to associate with a particular milestone. We have found it particularly useful to include a milestone named “comments”, and then to store the text for the comment in theMilestone Comment column156.
There are several significant advantages to a display such as that of[0046]Milestone Section150. One advantage is thattie interface100 for a given matter need only list those milestones that are actually being used for that particular matter. If only two milestones have occurred, only two milestones are listed. If thirty milestones have occurred, all thirty are listed (using a vertical slider). This scheme makes excellent use of the real estate on a given display screen. Another advantage is that the milestones listed as being available for use in conjunction with a given matter can be restricted according to the matter type. A patent application matter, for example, has very different milestones from a copyright matter, and certainly from a federal district court litigation matter. Users therefore have for selection all the milestones that are appropriate for a given matter, without being confused by having to view milestones that are not even appropriate.
FIG. 1[0047]bis identical to FIG. 1, except that it shows a scrollable drop-downlist153 of milestones appropriate for thematter type130C of the currently selectedmatter120A. As exemplified herein, the drop-downlist153 may comprise a “combo box” in that it shows multiple items of data on each row. In this instance the drop down list showingmilestone choices154A, and associatedmatter type154B.
Although not explicitly shown in the figures, every field having a finite number of choices throughout the system may advantageously have a similar style of drop-down[0048]list153, although lists for other fields would be modified in content according to the particular purpose of each field.
Milestones are preferably stored in identifier/value pair format. This format allows users to define their own milestones to cover the various stages of the types of matters that they use. Intellectual property law offices, for example, may advantageously employ several hundred milestones to describe various aspects of intellectual property prosecution, litigation, and so forth. Since any given matter likely only employs five to ten milestones, this technique avoids the great waste of database capacity and display real estate that would otherwise be utilized in hard coding hundreds of milestone fields for each matter. Identifier/value pairs are also advantageous in that they can readily be displayed in pair format, in scrollable windows.[0049]
In FIG. 2 a[0050]user interface200 generally includes amatter type selector210, and tabs for controlling operation of the system with respect toMatter Detail Parameters220,Milestones230, Task Calendaring/Date Rules240, andMilestone Procedures250.Interface200 is preferably accessed using a right mouse click in theMilestones Section150 of FIG. 1. TheMilestones tab230 has three columns,Milestone Description232, SortOrder234, andTimer236.
The user may associate a plurality of[0051]milestones232 with thematter type210. Once the user has associated themilestones232, entry of a milestone consists of simply choosing a milestone from the drop downlist153 of FIG. 1b. SortOrder234 is the typical order of themilestones232 within thematter type210.Timer236 represents the default for the number of days until the matter should be reviewed. For example, entry of a milestone with a 14 day timer tells the user to refer to this matter in 14 days.
Milestone information is thus stored as identifier/value pairs, where both the identifier and the values are user-defined. In preferred such methods, a plurality of user-defined milestone identifiers are stored on a database, (see FIG. 1[0052]c), and a user is provided with an interface providing a scrollable listing of the identifiers (see FIG. 1b). Sample identifiers include application drafted, application filed, assignment, foreign filing license, issue fee paid, notice of allowance, office action, matter abandoned, patent issued, and response to office action.
A user then associates a matter with a subset of the milestone identifiers (by selecting a milestone identifier from the list of FIG[0053]1b), and enters adate152 into the database corresponding to themilestone identifier154A. The process can be repeated for a subset of identifiers. In most instances the data associated with a milestone identifier will be a date, but the data may also be a comment of some sort, such as “in favor or CIP”, or “patent no. xxxxxxx”. In more preferred embodiments a user may also enter data associating a set of instructions with a selected one of the identifiers, allowing the system to display the instructions upon user selection of the identifier.
One advantage of the present identifier/value method of storing milestone information is that the system is readily adapted to producing a spreadsheet or word processor based report containing milestone information. In FIG. 3 an[0054]exemplary report300 depicts the following information:docket numbers310,client reference numbers320,matter titles330, matter types340,milestones360 with associateddates350, and comments370. The report is an example of a user-generated report that displays milestone and other related information for client matters. The use of thecomments370 field is of note as it is an example of an identifier/value/value method.
In FIG. 4 an[0055]interface400 displays and acceptstask information450 that is typically calendared for amatter type410/milestone420 combination. Thetask information450 shows how a preferred system may calendar atask455 based on adate rule465. The interface also contains the table ofdate rule logic490 that is used by the system when calendaring the tasks. In a preferred embodiment the auto-calendaring information may include thedate source470. For example, adate source470 of “current milestone” with a “1 month rule” may inform the system to calendar thetask 1 month from entry of themilestone420. Thedefault priority475 is used to display a priority such as reminder or warning that is associated with the task.Relationship480 may also be associated to the task.Relationship480 may be the title of the person responsible for the task.
In FIG. 5, is an example of a maintenance and display interface for non-calendar reminders. The[0056]interface500 has aMatter Type area510, and tabs for Matter Detail Parameters520,Milestones530, Task Calendaring/Date Rules540, andMilestone Procedures550. Turing to the Procedure Name/Desc.section560, it is contemplated that users will enter whatever reminder information is appropriate for theparticular Matter Type510 andMilestone555. In this instance the user defined on-line procedures deal with reminders to the person filing a new patent application, and are relatively limited in both detail and extent. In other instances the on-line procedures may be more or less detailed or extensive.
Differences between the presently described system and previous matter management systems can now be more fully appreciated. Previously known matter management software is extremely poor at providing a rapid overview of the status of a matter. The Timeslips™ program, for example, typically shows a single hour entry per interface, requiring a user to prepare a separate report to visualize all recent hours for a given matter. Other programs may show the last several hours entries, but do not show calendar information at the same time. And to the best of our knowledge no previously known matter management software displays milestone information at all, as the term “milestone” is used herein, let alone showing milestone information on the same interface as hours and calendar information. The closest any system comes is the Patsy™ software, which shows calendar information on the same display as important dates for the type of matter at hand—office action dates for patent filings, section 8 & 15 affidavit dates for trademarks, and so forth.[0057]
But simply having fields for various dates is not at all equivalent to the open ended type of milestone information contemplated herein. One clear way of distinguishing the fixed type of date fields in systems such as Patsy™ from the milestone fields contemplated herein is that in preferred embodiments of the present system, users are permitted to set the milestones themselves, not merely enter dates. Another way of distinguishing these different types of systems is that in at least preferred embodiments of presently contemplated software, the milestone fields and related data can be scrolled on a user interface. This allows preferred systems to accommodate more milestones than could realistically be fit onto an interface in a fixed manner. Still another way of distinguishing these different types of systems is that in at least preferred embodiments of presently contemplated software, a user can enter non-date data for each milestone. Thus, for example, in entering a milestone for recordation of an assignment, a user can not only enter a date, but also a reel/frame number. Similarly, in entering a milestone for abandonment of a matter in favor of a continuation, a user can enter the serial number of the continuation. The same can be true for all milestones.[0058]
Hours[0059]
Referring again to FIG. 1[0060]a,section160 includes hours information. In this particular example there are three rows of hours information, each row including adate161, anhours description162, anhours comment163, anhours designation164, anadjustment165, a calculated hours amount166, atimekeeper designation167, and arate code168.
[0061]Date161 may be limited to the current date or a past date, and in any event it may be advantageous to warn the user if the date is not the current date. Double clicking on the date may bring up a calendar interface (not shown) for ease in selecting a date. Thehours description162 is free-form text, and may be single or multi-lined, where multi-lined descriptions include a vertical slider. The hours comment163 is preferably for internal use only, and is therefore generally not printed on invoices, client reports, and so forth. Thehours designation164 may be zero or any real number, positive or negative, although negative numbers and those larger than a given threshold may provoke a warning from the system. Theadjustment165 is usually zero, but can also be any real number. The calculated hours amount166 is merely thehours designation164 plus theadjustment165. Thus, if a discount is intended, the user would enter a negative number for theadjustment165. Thetimekeeper designation167 is usually the timekeeper's initials, or some other sort of code. Double clicking on thetimekeeper designation167 may advantageously provoke the system to display a summary of the timekeeper's billings for the day, week, or month. Therate code168 is some sort of user-defined code, that may be something very simple such as “A”, “B”, “X”, etc., or something more descriptive such as “Normal”, “Discount-1”, “half-price”, etc.
Unlike Time Slips™ and many other popular systems,[0062]section160 is advantageous in that it shows more than one entry for a matter at a time, and additional entries are available through scrolling. The hours shown may also advantageously show entries for all timekeepers, so that a current user can more readily maintain proper consistency in group projects.
Non-Calendar Timer[0063]
Referring yet again to FIG. 1[0064]a, thetimer field186 is used to remind the user that this matter (docket no. 120) may be overlooked if not examined within the timer period. Here, thetimer field186 happens to contain the data, 12 days. In preferred embodiments thetimer field186 displays a countdown of days, months or some other time period for the most current milestone in themilestone area150. In such embodiments, for example, the timer for a milestone of a first matter may be set to 30 days, and the timer for a milestone of a second matter may be set to 90 days. One week after setting such timers, the first matter would display 23 days in thetimer field186 while the second matter would display 83 days in thetimer field186.
FIG. 6 depicts an[0065]exemplary interface600 for changing the timer for a given matter. The user (not shown) may enter a number in the Days Timer Runs610 area. The number entered in the Days Timer Runs610 field is displayed on a matter screen for the purpose of reminding the user to look at the matter. The number decrements by 1 each day reminding the user of the impending date. In a particular embodiment the matter specific timer be set automatically upon the selection of a milestone, but such a timer may be overridden by the user.
In FIG. 7 a[0066]timer summary700 lists matter specific timers sorted by remaining time. While any suitable data may be included, this particular example shows time remaining710, time set720,matter docket number730,title740,primary name750,matter type760, andstatus770. In this manner a user can easily spot matters where the timer has gone down to zero, and which may therefore need attention. Another aspect of count-down timers that has been found to be useful is an upper limit on the number of days to which a timer can be reset. It is contemplated that maximums can be set at any suitable value, such as ≦500 days, 365 days, 180 days, 6 months, 3 months, and so forth. The presently preferred maximum timer setting is 180 days.
Matter specific timers may be reset from time to time, either automatically or manually. In preferred embodiments, the manual[0067]timer reset interface600 is accessed by double clicking on thetimer field186. Automatic timer reset may also be triggered by the user selecting a milestone from a milestone list, where different milestones most likely have different timer resets. Thus, a milestone of opening a new file may have a timer reset of 14 days, while a milestone of receiving a foreign filing license and filing receipt from the patent office may have a timer reset of 180 days. Some milestones may not have any timer reset.
Timer resets can be implemented in any suitable manner. In a preferred embodiment the timer for each matter is stored using two fields, a timer reset date and a timer reset days.[0068]
The system compares these values against the present date, calculates the number of days left, and displays that calculated number in[0069]field186. Also, in the preferred example milestone resets are stored separately, one for each of the milestones. When a user selects a milestone from the milestones list, the system updates the timer reset date to the current date, and replaces the timer reset days with the default number of days that is associated with the milestone.
It will be appreciated that the timers contemplated herein are matter specific timers, not the traditional timekeeping minutes or hours timers found in other systems. A major distinction is that matter specific timers keep track of duration since the occurrence of an event related to the matter as a whole, while timekeeping timers keep track of the time that a timekeeper (attorney, paralegal, etc) is working on a matter. A related consequence is that matter specific timers generally keep track of days, weeks or months, while timekeeping timers generally keep track of minutes or hours.[0070]
Matter timers are preferably count-down timers as described above, although count-up timers are also contemplated in which a field such as[0071]field186 would show the number of days (months or some other time period) since the timer was reset. For example, a count-up timer that was reset to zero on a Monday, may show 4 days on Friday, and 6 days on the following Monday. Similarly, a count-up timer set to 30 on the first of a month may show 60 or 61 a month later. A summary listing (not shown) can also be employed with count-up timers, but would presumably be used in reverse, with a user working down from matters having the highest timer settings, resetting the timers on such matters to zero, or some higher value.
Calendar[0072]
Referring yet again to FIG. 1[0073]a, thecalendar section170 generally includes acalendar date171, acalendar description172, acalendar comment173, anurgency designation174, astatus175, a primaryresponsible timekeeper176, and a secondaryresponsible timekeeper177. As with bothmilestones section150 and thehours section160, thecalendar section170 has three rows in this example, although the available space could readily have been parsed out in some other manner.
The[0074]calendar date171 is similar to that for milestones and hours. It preferably defaults to the current date, and double clicking on the field triggers presentation of a monthly calendar to assist in selecting a date. Thecalendar description172 is free form text, and may be single or multi-lined, where multi-lined descriptions include a vertical slider. Thecalendar comment173 is for internal use, and is not printed on reports intended for clients. Theurgency designation174 is a user-defined code, and may advantageously include “Drop Dead”, “Deadline”, “Warning”, and “Reminder”. Thestatus175 line is also a user-defined code, and may advantageously include “completed”, “missed”, “recalendared”, “entry error”, and the like. In preferred embodiments Entry of data in the field does not delete the record, but merely hides it from view. This keeps the entry for archival purposes, but maintains the calendar section free from displaying old items. The primaryresponsible timekeeper176 and secondaryresponsible timekeeper177 fields contain the same timekeeper codes used in conjunction with thehours section160.
Matter Details[0075]
There is any number of specialized pieces of information that users may want to associate with a matter. The information typically differs substantially forom matter type to matter type, and often differs somewhat even among different matters having the same matter type. For example, a US trademark matter may advantageously be associated with information on the international class, the first use date, the first use in commerce date, a description of goods and services, the legal form of the registrant, and the registration number. In contrast, a US patent matter may advantageously be associated with information regarding small or large entity. abstract current claims, current independent claims, current drawings, and patent number. Such information could be maintained in memo fields, or in generic fields set up to handle data not stored elsewhere. But both of those solutions are unsatisfactory for many reasons, including the difficulty of searching and sorting the information. Both solutions also have the drawback that they tend to result in users'failing to notice that desired data is missing.[0076]
A similar situation exists for contacts. There are often ten or more people or companies related to particular matter, in all sorts of different capacities. In patent matters, for example, a user may want to associate with the matter four or five named inventors, a primary contact, several secondary contacts, a billing contact, one or more assignees, several potential licensees, one or more actual licensees, previous counsel, third party consultants and vendors, responsible partner, responsible attorney, and responsible paralegal. The complexity can be very great indeed because a single person could be associated with the matter in different capacities, and from different addresses. For example, a user may want to store a pointer to a person's home address in the capacity of inventor, and a pointer to the same person's address at work for that person's capacity as a consultant. This can be very important in cases where a single person works for several companies, and different matters are related to the inventor's work at the different companies.[0077]
In FIG. 8 a preferred matter details interface[0078]800 allows users to enter any practical number of matter details860, as well as any practical number ofcontacts870, all of which can vary enormously from matter to matter. This is accomplished through the use of identifier/value pairs, in much the same manner that milestones, address specific information and contact specific information are stored. The interface generally includes amatter detail section860, a matter notesfield864, a client notes filed966, and amatter contacts section870.
The matter details[0079]section860 has a matterdetail identifier column861 and a matterdetail values column862, related as identifier/value pairs in a manner described elsewhere herein. The matterdetail identifier column861 contains user-defined identifiers, which can be listed and scrolled. Preferably, thematter detail identifiers861 that are listed are only a subset of all entered matter detail identifiers entered into the system, as appropriate for the matter type of the current matter. Thematter detail column861 is either free-form text, or a pointer to a word processing, spreadsheet, image, or other document.
The[0080]matter contacts section870 has six columns—acontacts relationship column872, a contact name andaddress column874, ashort name column875, areference column876, a createdocuments column878, and acc column879. Thecontacts relationship column872 contains user-defined reference identifiers that can advantageously be added to, and maintained by users in a manner appropriate for their particular circumstances. Thus, a patent law firm may choose to include relationship identifiers for inventors, assignees, patent and trademark examiners, foreign associates, potential licensees, potential investors, previous counsel, storage services, searching services, etc. Available matter contact relationships are preferably displayed and selected using a drop-down listing. The contact andaddress column874 preferably echoes contacts and address information entered elsewhere, such as using the interface of FIG. 9. Thereference column876 is employed to store whatever information is appropriate for the matter contact relationship. Thus, for foreign associates, prior counsel, inventors, and so forth, the reference information may be the contact's docket number for the current matter. For assignees, appropriate reference information may be the reel/frame number. For a storage service appropriate reference information may be a box number. Preferred systems provide for the use of the literal “Client Reference” as an ersatz reference, which is substituted in documents by reference the corresponding client reference number for this particular matter. The createdocuments column878 contains a button in each row that triggers display of a document creation interface (see FIG. 12). Thecc column879 includes check boxes for selecting whether the indicated contact should receive copies of documents sent out regarding this matter. If the box is checked, the system automatically adds a cc to the indicated contact whenever a document is created for another contact for this matter through the document creation system shown in FIG. 12.
Contact Selection[0081]
FIG. 9 depicts a[0082]contacts interface900 generally including acontacts selection section910, acontacts identifier section920, anaddresses section930, adefault contacts section940, a contacts addressspecific information section950, a contact'sspecific information section960, a reference'sspecific information970, and acontact memo section980. The contacts interface scrollably displays at least one of the identifier/value pairs for both the contact specific data and the address-specific data.
The contacts selection section includes fields for selecting a contact by primary name (i.e., last name for a person or company name for a company)[0083]910A,first name910B (which of course does not exist for a company),client ID number910C (for contacts that are also clients), andcontact type910D (such as individual, company, government agency, court, etc).
[0084]Contacts identifier section920 includes contact identification information, including the contact'sprimary name920A,secondary name920B, middle name or initial920C, title orother suffix920D,contact type920E,contact salutation920F (greeting to be used in letters e.g., “Dear Sir:”), and acheck box910E distinguishing between client and non-client contacts. In the case of individuals, the920A-920D would usually correspond to last name, first name, middle name or initial, and suffix, respectively.
The[0085]address section930 allows users to associate any practical number of addresses with a given contact. This flexibility has long been desired since a given contact may work or have previously worked at several different companies, and may live or have previously lived at several different residences. In this example the software also provides links to addresses of other entities (a referenced company or individual) so that changing the address of a single entity (such as a business) would automatically change the addresses for numerous contacts (such as the work address of related employees of that business). It is preferred that eachline930A-930B displays a different address for the contact, even if the data on the line scrolls off the visible field.
The[0086]default contacts section940 includes columns fordefault relationship942, default contact name andaddress944,default contact reference946, andcc check box948. Thedefault contacts section940 is only active for contacts that are also clients (i.e.,client check box910E). In those cases, thedefault contacts section940 is used to initially populate thematter contacts section870. Thedefault relationship942 is preferably selected from a drop down list of user defined relationships, which is preferably the same drop-down list used in conjunction with thecontacts relationship column872 of FIG. 8. The default contact name andaddress944 is selected from a drop-down list of available contacts and addresses, which is preferably the same drop-down list used in conjunction with the contact andaddress column874 of FIG. 8. Thedefault contact reference946 is a user-defined text field. The use of “Client Reference” as an ersatz reference is permitted.
The address[0087]specific data section950 displays data stored using the identifier/value concept for one or more of the address lines950A-950B. There, appropriate identifiers may be telephone numbers, fax numbers, title (president, etc. where the address is a link to a company), receptionist's name, address specific E-mail address, and so forth. The contactspecific data section960 displays data stored using the same identifier/value concept. Here, however, appropriate identifiers may be the name of a spouse, child, or co-worker, a cell phone number, an E-mail address, a social security number, a birth date, citizenship, and so forth. The set of address specific information displayed in addressspecific section950 depends, of course, on the particular address clicked on in theaddress section930, and if no particular address is clicked on, then the first address is used as a default. Those skilled in the art will be able to extrapolate many additional identifiers, and will appreciate the advantages derived from users being able to define and enter whatever identifiers are appropriate for their particular businesses. Just as a simple example, most companies would not be interested in keeping track of citizenship of contacts, especially employee contacts, but a patent law firm needs that information available in one way or another to file patent applications. Those skilled in the art will also appreciate that as described elsewhere herein, use of the identifier/value concept allows the system to make all of the appropriate identifiers available to a user in a drop down list, but then only display those identifiers and values corresponding to the matter type of the currently selected matter.
FIG. 10 is a matter[0088]status summary report1000 depicting a preferred arrangement ofmilestone1010,matter detail1020,matter contacts1030 with associatedcontact relationships1040, and an area for calendaredevents1050 with an associateddate1160. This report uses identifier/value pairs andhyperlinks1025 to create a useful and interactive summary of a matter.
FIG. 11 is an[0089]interface1100 for creating records for anew matter number1110 and associatedmatter title1120 in the database, and correlatingmatter type1125 and other information with thenew matters1110. Eachmatter1110 and its correlatedtype1125 and other information are linked to aparticular contact1105.Interface1100 generally contains columns formatter number1130,matter title1135,matter type1140,matter status1145,serial number1150,client reference1155,matter rate code1160, and amatter markup1165.Interface1100 may be useful for a user who receives a phone call from acontact1105, and needs to quickly find thematter numbers1130, thematter statuses1145, and other information associated to thecontact1105.
FIG. 12 generally depicts a[0090]document creation interface1200 having a first contact notesfield1210, aspecific contact field1211, a second contact notesfield1212, a cost notesfield1214, a matter notesfield1216, adocument type selector1220, recipient information fields1230,matter reference fields1240,fax number1250,phone number1260,salutation1270 andauthor1280. The document creation interface is displayed in response to a selection of create documents878.
The first contact notes[0091]field1210 displays the contact notes associated with the client. The contact notesfield1212 displays the notes that may have been entered for the chosencontact980. Cost notesfield1214 displays cost notes that are associated with the chosencontact980. Matter notesfield1216 contains the notes that have been entered infield864, and associated to thematter810 of FIG. 8. Displaying all of these various memos is very helpful in providing appropriate reminders to the user when creating documents.
The[0092]document type selector1220 allows a user to select from a drop-down list of predefined document types, including fax, e-mail, letter, and-so forth. The choices correspond to templates created by the user, and which are populated with data from the recipient information fields1230, and the matter reference fields1240. Therecipient information fields1230 are themselves populated from the corresponding contacts fields of FIG. 9.
E-mail addresses, fax, and phone numbers are special cases in that they are taken from the recipient's address[0093]specific data section950. If one or both of the numbers are not found, then the system looks to the contactspecific information section960 for the recipient. If one or both of the numbers are still not found, then the system looks to the addressspecific information section950 for a corresponding referenced company or individual, and finally to the contact specific information for the referenced company or individual.
[0094]Field1240 is defaulted to the information contained in thematter identifiers130A-130G for the current matter. If, however, they are modified by the user, the system asks if the user wants to keep the modifications for the future. If so, the new values are used as defaults in the future, without affecting the data stored asmatter identifiers130A-130G for the current matter. Theauthor field1280 has a drop-down menu, allowing the user to select from names of timekeepers, which are advantageously the same timekeepers designated infields167,176, and177.
Identifier/Value Concept[0095]
FIG. 13[0096]ais a representation of a data table for a previous calendaring system that has pre-defined fields shown in columns1315-1355. In such systems each column represents a field for storing a particular item of information, such as “Disclosure Date” incolumn1315, or Chapter I filing date incolumn1320. The fields of any given data table are, of course, designed to satisfy at least a majority of demands for storing data for a particular type of matter (eg, patents). Since different matters types (eg, copyright, trademark, immigration) would require different data items, each different matter type would typically require a different table with different field names.
The rows in FIG. 13[0097]arepresent data for individual matters. In this particular example, the matter numbers are stored in the first data field,column1310. One can immediately appreciate that this manner of storing data is very wasteful. For matters that don't use “Disclosure Date”, for example, there will beblank data1360 stored in the database. The same would be true for any of the other user-defined fields1320-1355.
It turns out that a user in a patent firm needs hundreds of data fields. Just for storing patent information one may well need to designate 8 or more inventors, 30 or more dates, 50 or more contact people, and 20 or more miscellaneous descriptions for a particular matter. Using the previous type of fixed field data storage, this would require 108 fields for each matter record, and of those perhaps 80% of the cells would be blank because the average matter may use only 22-25 fields.[0098]
Not only does designation of a pre-defined field waste disk space, it also wastes real estate on the interface (computer display) by unnecessarily displaying blank fields to the user. The inefficiency is so great that many known software packages have distinct interfaces for each different type of matter. Otherwise there is no realistic way of displaying hundreds of different fields on the same interface.[0099]
Some previous systems try to accommodate the differing needs of users by providing a dozen or more user-defined fields. But such fields are still pre-determined fields, and waste space in both the table and the interface as discussed above. Moreover, a user must keep track for himself how the various fields are used. For example, is user-defined[0100]field number3 used for the name of an extra inventor, or for some special date. As a result, users often store inconsistent data in the same user-defined field across different matters.
As used herein “identifier/value” refers to storage of data in pairs, where one part of the pair stores all identifier (or pointer to an identifier), and the other part of the pair stores data related to the corresponding identifier. In that manner each value is stored along with an identifier as a new record, rather than using the identifier as a field name, and storing the values for multiple matters in rows of a table relating to that field. There are at least two main advantages. First, each matter can have any number of identifier/value pairs. Thus, a patent matter can have 25 or more inventors associated, rather than being limited to a fixed number (such as 5 or 6) inventors for which there are pre-defined fields. Second, each matter only takes up as much data storage space as it actually utilizes.[0101]
In FIG. 13[0102]b, a sample data table has three fixed fields, designated bycolumns1380,1381, and1382.Field1380 stores matter number,field1381 stores identifiers, andfield1382 stores corresponding values. Thevalue1381 field may store any type of data including text data, which may include ordinary text such as a person's name, numbers, dates, uniform resource locators (URL), hyper-links, and pointers to images. As can be readily appreciated the field names of a previous data table such as that shown in FIG. 13acan be used as identifier data in theidentifier field1381 of the data table of FIG. 13b.
An exemplary use of identifier/values is shown in FIG. 1[0103]a,section150, where the identifiers include “Office action, response”, “Notice of allowance”, “Family filing, divisional”, and the corresponding data include “10-Apr-98”, “09-Jun-98”, and “24-Jul-98”. Another exemplary use is shown in FIG. 8,section860, where the identifiers are “Current Abstract”, “Current Claims”, “Current Indep Claims”, etc, and the corresponding values are pointers to various files. Still another exemplary use is shown in FIG. 8,section870, where the identifiers are “Client Contac, Primary”, “Responsible Paralegal”, “Responsible Partner”, etc, and the corresponding values are pointers to various contact records. The same use is made of contact relationship type identifiers in FIG. 9,section940. Still other exemplary uses are shown in FIG. 9,sections950 and960, where the identifiers are such items as “Business Fax” “Business Phone”, “Cell Phone”, “Citizenship”. “President”, etc. Still another exemplary use is shown in FIG. 9,section930, in which identifiers are “Old Addr 1”, “Work 1”, etc, and the values are the actual data of the addresses. Even office procedures can be stores as identifier/value pairs, as can be seen in FIG. 5. In each of these instances there are dozens or even hundreds of identifier choices, but only those choices selected for each matter are shown on the user interface, and only those choices actually utilized for each matter take up space in the database.
As briefly discussed above, one limitation that may be avoided through the use of identifier/value pairs is an otherwise rather strict limit on the number of fields that can be included in a system. In previous systems, for example, a patent user may be limited to storing names for only 5 or 6 inventors. Yes, most matters have less than 5 or 6 inventors, but there are also matters with 15 inventors. To allocate space for 15 inventors is very wasteful for almost all of the matters. And even then, what happens when a matter has 16 inventors? The previous systems have no good way to resolve that issue.[0104]
Similarly, with respect to contact information, many systems store phone and fax numbers, title, and so forth. But it is sometimes advantageous to store data on other types of information, such as inclusion on a Christmas list, social security number, reference number, account code, password, help line code or number, and so forth. There may indeed be hundreds of such identifiers to choose from, and still each contact will only utilize display space and storage space for the identifiers actually used. Additionally, because identifier/values can be displayed using drop-down or scrollable lists, display real estate is not a limiting factor even if a particular contact uses dozens of identifiers.[0105]
A related advantage is that by displaying the identifier with respect to each value, a higher degree of clarity is achieved in the display. A user looking at a crowded display showing dozens of pre-defined fields may not be completely certain what the values in the display fields relate to. However, the use of identifier/value pairs improves the display efficiency to such a degree that each identifier can be displayed in a clear manner. It is even contemplated that different users may alter the display order of the various identifiers, such that those of greater importance tend to be near the top of any list.[0106]
Still another contemplated benefit of using identifier/values is that a relatively high degree of storage and display efficiency is achieved because there are generally no blank fields on the storage device or on the display. Thus, the user in the patent firm described in the previous paragraph would not have 80% blank data in his records. Blank fields on a storage device are inefficient because they take up space without actually storing a value, and blank fields on the interface are inefficient because there is a limited amount of space on an interface with which to display fields.[0107]
Thus, specific embodiments and applications of matter management systems have been disclosed. It should be apparent, however, to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims.[0108]