-
Notifications
You must be signed in to change notification settings - Fork 17
Home
The database is articulated around a central table called “matter” (such as patents, trademarks or designs), that contains minimal information for each matter (essentially a category, a case reference, a country, and an expire date). Information that will be the substance of a matter is freely linked to each matter, in any number, from additional tables: actors, events, tasks, and classifiers. We found that anything useful in a matter fits in one of these four tables.
Actors are any person or company involved in a matter (applicants, inventors, client, agents...). Each actor can be linked to a matter with any of several roles, and a same actor can be linked to a matter with multiple roles, for instance an inventor can also be an applicant. A client (company) can also be an applicant. All variations are possible.
The roles are contained in the actor_role table.
Actors are linked to matters through a link table called matter_actor_lnk. This link table contains additional information about the specific link, such as the actor's role, his reference (for clients and agents), his company, a date, his order of display among other actors with the same role...
Events are related to the history of the matter and show how the matter is progressing. They basically have a name and a date. They can be a link to another matter if that other matter is involved in the progress of the current matter (see more details below).
Tasks are triggered by specific events. They have a name, a deadline, a “done” flag, and an optional “done date”. For instance, in a patent, an event tracking an “examiner action” issued by a patent office will trigger a “Response” task having a deadline three months after the examiner action date.
Tasks can be added manually to events. Some tasks are created automatically based on information in a task_rules table, when corresponding trigger events are entered for the matter.
Classifiers are other pieces of useful information that do not correspond to the above, such as keywords, business units, patent classification... and also links to related matters, for instance patents around a same invention. They have a type and a value, or a link to another matter. The value can be free-text stored in the classifier table itself (a value that is specific to the matter and not reused in other matters), or an index in a classifier_value table containing values that can be used multiple times (such as a list of products or business units).
One key feature of phpIP is that any piece of information, even if it is used in multiple matters, say patents, is stored in one place only. We use two mechanisms for that:
Linked events
For instance, the priority date of a second patent is the filing date of a first patent. In traditional systems, this date is copied into a record related to the second patent. What if the filing date of the first patent is changed? Well, the system or user needs to make sure the date is updated in the second patent. In phpIP, the priority date of the second patent is an event linked to the filing event of the first patent. If the filing date of the first patent is changed, that change is automatically reflected in the priority event of the second patent, and tasks that rely on this date are updated.
Containers for shared information
In phpIP, the first matter in a series of related matters, for instance the first filed patent in a family, is a container for information common to all patents in the family, for instance client, inventors and applicants. Classifiers are also shared. Each subsequent created matter in the family shares this information from the container without duplication. If the information needs to be changed, it is changed in one place for all family members. The user may configure what type of information is shared by default and he has the option to change that as he adds the information.
These features make queries for displaying all data related to a matter more complex, but this is all handled by the user interface, so it is transparent to the end user. You will need to be more careful if you intend to write advanced queries but we have provided some view tables that list all the data related to each matter (and hence make the linked event and container techniques transparent).