Posts made by ChristianS9906

You should be able to do this--we do something similar, but generically for foreign annuities (as opposed to CN-specific ones):

1. Set up the <CN Annuity Due> task to have a RespondBy date that uses the later of 12 months from issue date OR 12 months from triggering task RespondBy date.

2. Set up the triggering for it to have two alternative triggers:

a) When a CN application gets an issue date (or the issue date changes, if you want to be more conservative) OR

b) When a <CN Annuity Due> task completes while the status field in the matter does not include "Expired." If you want, you can tweak this to be "when a <CN Annuity Due> task completes with a "Completed" or "Missed" state--that way you can close the task out with "Abandoned" if you are letting it go and it won't generate the next deadline. <CN Annuity Due> would be whatever you decide to call this task (you're actually recursively triggering it based on itself). NOTE: You may get an extra <CN Annuity Due> task at the end of the patent term that dockets before expiration but for date after it is expired. There's probably a way to deal with this, but I haven't devoted brain power to figuring it out at this time.

I also recommend setting up a <CN Annuity Due - Grace Period> task that triggers whenever the <CN Annuity Due> task completes with a "Missed" status. It would be set to have a RespondBy of 18 months from the TriggeringTask Reference Date. If you set up the <CN Annuity Due> task to auto-close with "Missed," then AppColl should, if you miss an annuity payment, auto-docket both the next annuity deadline AND the final deadline for the current annuity deadline.

Disclaimer: While I think that the above will work as desired, you should, if you attempt the above, test it thoroughly to make sure that it behaves as expected. I make no warranties about whether the above information is correct and assume no responsibility for any damages or liabilities that you may incur if you act on the above information/advice.

Depending on the situation, you could modify the TaskType definition to change the task in question to a "Transient Event"--this causes the task to be auto-generated, thereby allowing it to trigger follow-on tasks and/or send out notifications. But the Transient task will then self-destruct immediately after that and will not appear on your docket. For example, we have our AppColl setup such that all "USPTO e-Office Action: ...." tasks are transient events--they trigger any deadlines they need to trigger and then they vanish.

You can also just turn off or modify auto-docketing for tasks that you find are not useful at all. For example, we turned off the "Review USPTO Communication" triggering completely (actually, we deleted whatever triggers it had). We manually docket it when there is something peculiar needing review, but it otherwise doesn't bother anyone.

It would be nice if the reports feature allowed for more flexible display options for contact-related data. For example, it would be useful to be able to list contacts for a matter in a number of ways, e.g., by full name (as is, I believe, currently the only way you can do so), by initials, by first name last initial, by first name only, by last name only, by first initial last name, by nickname, etc.

It is often the case that contact names take up a significant amount of column space in reports since contacts are typically listed by first/middle/last name. If you have a report that includes attorney, paralegal, contributor, and partner columns, you're likely looking at about a page-width of report space that is occupied by detailed name data. Most of the time, however, providing abbreviated name information would be sufficient--for example, displaying the same information using initials would convey the same information using only 12 characters, thereby consuming much less report real estate.

There could be several ways of implementing this--one would be to simply include the alternate forms of contact name display as separate columns that could be added to a report, e.g., AttorneyFullName, AttorneyInitials, AttorneyNickname, AttorneyFirstInitLastName, etc.

Another option would be to provide a format option for contact columns that are to be included in a report. Each contact column, e.g., Attorney, ClientContact, etc., would, when selected in the column chooser, cause a listbox to be shown that would allow the user to choose between a variety of formats for how that data will be shown. This could also be extended to non-Contact data, e.g., date formats, text data (e.g., All Caps, Sentence Caps, As-entered, etc.).

A third option would be to allow the user to specify a global format setting for the report in question (which could also affect how data is displayed in the Matters/Tasks/etc. modules). For example, the user could specify that Contacts are to be shown using their middle initials as opposed to their full names. This would be applied to all such data in the module in question, so you wouldn't be able to mix-and-match, e.g., have one column with Contacts listed by initials and another column with Contacts listed by full name.

A somewhat related enhancement would be to allow the user to change how the Inventors are listed for a matter. Right now, I think the Inventors field lists inventors by their non-alias ("true") names, even if an alias was used in filing an application. It would be nice to allow users to choose to list inventors for an application using their "true" names and their "as-filed" names. It would also be nice to be able to list such data in a way that indicates when there is a discrepancy between the true inventor name and the as-filed inventor name. For example, in the Matter Details interface, when a listed inventor was listed using an alias when an application was filed, the Inventors list shows both the true name for the inventor and, in parentheses, the alias for that inventor that was used in the filing. It would be great if that could also be an option in the Reports module.

It would be great if users could be given the ability to specify "aliases" to use for column names in a report. These could be displayed in addition to the "normal" column names (or not at all) when viewing the report in AppColl, but if the report is emailed to someone, exported to CSV/PDF, etc., the aliases would be used for the column names instead of the AppColl field names.

Thus, for example, if one sets up a Task report that is intended to be sent to client DeltaCorp on a recurring basis, the "Matter.ClientRef" column could be set up to be labeled "Delta Ref." instead, and the "RefDate" column labeled as "Mail Date," and the Matter.CountryCode column labeled as "Ctry.," and so forth. In that last example, it would allow the report to be much more compact since the column header of "Matter.CountryCode" is much wider than the 2-letter country codes that would be listed under it.

Such a feature would significantly improve the Reports function and eliminate repetitive reformatting/relabeling of the report columns prior to sending such reports to clients.

These aliases, of course, would be cosmetic and would not be usable as filter conditions--it might be nice to display them in AppColl's on-screen displays of reports that use them, but I could also see implementing the feature so that the aliases only appear in the report once it "leaves" AppColl.