Events, Deadlines and Tasks

Tasks or deadlines

In phpIP, a deadline is represented by the due date of a task. So the UI shows "tasks" rather than "deadlines".

A task is composed of:

• A generic name, such as "File", "Respond", "Pay"... These names are standardized and taken from the event_name table (that can be edited by an administrator).

• Details (optional), that complement the generic name. This is a free-text field, where the user can designate what the generic task applies to, e.g. "Respond - Exam Report", "Pay - Grant Fee".

• Due date, ditto.

• Done date, ditto.

• Done flag, shown as a checkbox in the UI. When the box is checked in the UI, the done date is set to the current date or the due date, whichever is earlier. The flag is automatically set when a done date is entered manually.

• An optional "By" (or assigned_to) field. Filled with a user who wishes to follow the task specifically in his dashboard (when clicking the filter button bearing his user name).

A task is necessarily triggered by an event, thus, each task is attached to its triggering event. Several tasks can be attached to a single event. If an event is deleted, the attached tasks are also deleted.

Tasks may be generated automatically from events by rules defined in the task_rules table, which is accessible to an administrator from the menu Tables->Rules. The task_rules table comes populated with many useful rules that can be adapted or complemented.

For further details check the task table description and check how tasks are handled in the UI in the corresponding section of the Overview.

Events

These track the various steps forming the file history of a matter, such as "Filed", "Published", "Granted", but also "Search Report", "Examiner Action", etc. These are also standard and defined in the event_name table.

Some events are "status events" (such as "Filed", "Published", "Granted").

Some events are "killer" events (such as "Abandoned", "Expiry", "Transferred"), meaning that the matter becomes inactive when such an event is inserted, and that tasks are no longer generated nor followed in the Dashboard for the matter.

Check how events are handled in the UI in the corresponding section of the Overview.

Special events

The following events are an integral part of the database engine and they should not be altered (especially their codes in the event_name table).

• Filed, Granted.

Trigger many tasks and are the basis of many date calculations, such as expiry and renewals.

• Priority Claim.

Is the basis of date calculations in some tasks that are not triggered by this event itself, but by the "Filed" event.

A special note here on the "Refers to" field (alt_matter_id column) of the event: this field designates the matter on which the priority claim is based. The effect is that the "Priority Claim" event date is synchronized with the filing date of the designated matter.

• Parent Filed

Created automatically in EP and PCT national phases. Tracks the filing number of the parent EP or PCT.

Here, the "Refers to" field will designate the parent matter, so that the event date is synchronized with the filing date of the parent matter.

(In fact, the "Refers to" field can be used in any event to synchronize the event date with the filing date of the referenced matter.)

• Entered

Tracks the actual filing date of child matters, especially divisionals and continuations. Is created with the current date that needs to be changed to the correct date.

• Expiry

This event is actually used as a task for calculating the expiry date, but it is not inserted as a task in the matter. The calculated expiry date is inserted in the matter's "Expiry" field. When the expiry date is effectively reached, the "Expiry" event is inserted in the matter.