The Review USPTO Differences task/yellow triangular warning is very useful, but it is also very cumbersome--I would like to ask if it can be made "smarter." In particular, I would like to suggest that it be modified so that if a flagged difference is reviewed and the user selects "Ignore" (or maybe make a new button that is "Ignore Forever"), then any future instance for that matter in which that same discrepancy is found will also be ignored.

We are faced with the situation where almost every time we PAIR scrape a matter, we get USPTO differences--and we spend an inordinate amount of time revisiting the same issues over and over and over.

For example, our docket numbers almost never actually align with what the USPTO has because we use our docket number + our client's docket number in PAIR (clients want us to do this, particularly on shared customer numbers--I'm sure we are not alone in this).

Another example is with PCT priority connections--we store the full PCT serial number in AppColl, e.g., PCT/US2015/012345, while the USPTO (for reasons I cannot fathom) stores the same serial number in the abbreviated form as PCT/US15/12345. These are identical serial numbers, but get repeatedly flagged as being "discrepancies"--every time AppColl flags these, we have to go through the process of reviewing and re-ignoring this discrepancy.

A third example is with Examiner names--the USPTO uses first name, middle initial with no period, LAST IN ALL CAPS. We use first, middle initial with period, last in normal caps. These seem to get flagged every time as well.

If the USPTO discrepancies feature/task weren't so useful, we'd likely turn off the task since it generates a massive amount of tedious work that we have to repeatedly do every time there's a PAIR scrape for a matter. If AppColl could be modified to make some sort of "whitelist" table (akin to the Contact "aliases" field) for each matter that stored each "ignored" value and then did not flag that value again if it showed up in a subsequent scrape for that matter, it would make this feature SOOOOOOO much better/more useful.

Can this be done?

@joe-appcoll-com
Yes--add:

a) the ability to allow the admin for account receiving the sync to review what fields are in the sync report and, for each such field, designate which field in the receiving account's database the sync report field will be imported into (including giving the admin the ability to direct that the synced field NOT be imported into any field in the database of the receiving account). This will vastly improve the Sync feature since it will allow users to map imports between different fields, e.g., law firm uses "AttorneyRef" to store their docket number and ClientRef to store client's docket number, while client uses "ClientRef" to store law firm's docket number and "AttorneyRef" to store their own docket number. It should be possible for either party to set up a Sync of either field and have the receiving party direct that Sync to the field that stores that same data--even if they are different field names in each account.

b) disable any new or modified sync into an account until (a) has been done--this avoids potential catastrophe that may occur if a sync is set up and the underlying report for it is then modified and ends up overwriting data in the recipient's account that was not supposed to be synced.

I suggested this to AppColl directly earlier and know this is being worked on, but figured I'd float here to get feedback from others.

Cheers,
Christian

It would be nice if there was a single form letter field that could be used to add all inventors to an email's TO line. Right now, if you want to add all inventors to an email generated within AppColl, you have to use this:

{Matter.Inventor1.Email};{Matter.Inventor2.Email};{Matter.Inventor3.Email};{Matter.Inventor4.Email};{Matter.Inventor5.Email};{Matter.Inventor6.Email};{Matter.Inventor7.Email};{Matter.Inventor8.Email};{Matter.Inventor9.Email};{Matter.Inventor10.Email};{Matter.Inventor11.Email};{Matter.Inventor12.Email};{Matter.Inventor13.Email};{Matter.Inventor14.Email};{Matter.Inventor15.Email};{Matter.Inventor16.Email};{Matter.Inventor17.Email};{Matter.Inventor18.Email};{Matter.Inventor19.Email};{Matter.Inventor20.Email}

And if you have more than 20 inventors (god forbid!), you're out of luck.

It would be really nice if AppColl just had a field like:

{Matter.Inventors.Email}

...that would add emails for all the inventors to the form letter/email template (separated by semicolons).

This somewhat aligns with another suggestion made on May 13, 2022, for a field like {InventorFirstNames}, which would concatenate a string of inventor first names together (and add commas and "and" where appropriate).

Cheers,
Christian

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.

AppColl allows admins to define custom fields (would be nice to have a few more of those!). Those fields are shown above the Notes field and below the Connections and Inventors field. Custom date fields are shown in a column to the right, and all other custom fields in a column to the left. There is the ability to re-order the fields within each column.

What would be really nice (and admittedly pretty challenging to pull off, I bet) is to give admins the ability to change where custom fields are located in the Matter details interface. For example, let's say that I create a "TD_Date" field that is intended to record the expiration date of a patent subject to terminal disclaimer--I'd probably want that info to be up near the "expiration date" field. Similarly, if I have a custom field of "ClientAdmin" to that is intended to record which client paralegal/secretary is assigned to a given matter, I'd probably want that to be just below "ClientContact" in the GUI.

It would be really neat if AppColl offered this flexibility.....

Cheers,
Christian

AppColl allows you to create form-filled USPTO forms for a matter; you can also create form-filled copies of such forms for multiple matters relatively easily from the Matters module. It would, however, be great if one could (for at least certain forms), give the user the option to specify how fields in that form that are NOT fillable from AppColl data are to be filled in.

For example, the AIA/122, AIA/123, AIA/83, and SB/123 forms (and there may be others) all relate to changing the address for a patent or application. Take the AIA/123 form, which is used to switch the correspondence/maintenance fee notice address--you need to provide either (a) a customer number that has the new address or (b) separately specify the name/address/telephone/email of the new addressee. It would be really great if AppColl gave you the chance to enter data for the fields in (b) prior to generating the PDFs, and then populated those fields in the generated PDF with that data.

For example, we recently had to transfer files back to a client (with no successor counsel arranged) and file change of correspondence address forms for 30 different patents. All of them had the information in (b) specified to be the same, and we had to copy-paste that info (which involved copying the data for 8 fields into all 30 forms--240 copy-pastes!) to finish the forms. It would have been a huge time-saver if we could have supplied that info up-front and had AppColl populate it when it populated the matter-specific data.

The PatentTermAdjustment field is (I think) only shown for applications that have the United States as Country. However, China is implementing a PTA-like system and PTA will thus be a datapoint that needs to be entered for Chinese patent applications.

It appears that other countries offer PTA as well, including, for example:

South Korea
Singapore
Nicaragua
Honduras
Guatemala
El Salvador
Dominican Republic
Costa Rica
Colombia
Chile

The PTA field should, I think, just be made available globally.

Cheers,
Christian

It would be a very nice feature if there were an "AdjustedExpirationDate" field that was simply the ExpirationDate field + PTA. This would not be user editable; it would be calculated based on whatever was entered into the ExpirationDate and PTA fields.

Right now, AppColl automatically changes the "Status" of "Issued" patents to "Expired" when the expiration date is reached. However, patents with PTA do not expire on their expiration date, they expire later. This can be very problematic, as if a report having the application status is generated from AppColl and provided to, for example, CPI or some other annuity service, it will incorrectly tell the annuity service that an application is expired when it is actually not. This may cause the annuity service to assume that maintenance fees no longer need to be paid, and the service will no longer request payment instructions for it.

This is problematic when trying to generate a report, for example, of all patents that may have maintenance fees that need to be paid. You'd want to include all patents with "Issued" status, but also all patents with "Expired" status that still had PTA left. Unfortunately, there is no easy way to do this right now. If the AdjustedExpirationDate field existed, we could simply filter on all patents with Issued status OR Expired status with AdjustedExpirationDate > today.

The only other option is to manually edit the ExpirationDate field to include the PTA, but that would be non-preferred since it introduces a constant risk of user error and is difficult to easily verify as being correct.

In a perfect world, the AdjustedExpirationDate would also reflect the effects of any terminal disclaimers that might have been filed--although this would be much more complicated to determine. It might be best to have another calculated field for "TDExpirationDate" that reflects this modified expiration date.

It would also be nice if the auto-change from "Issued" to "Expired" were to be based on the AdjustedExpirationDate instead of the ExpirationDate. That would be much more accurate and much less likely to lead a user to inadvertently miss a patent that was still active due to PTA. This should be the default behavior, or at least a setting that admins can select.

Can this be done?

AppColl currently allows for a decent number of "custom fields" to be specified for Matters. It would be nice if AppColl also allowed users to specify some custom fields for tasks as well.

For example, users might want to have fields for:

Deadline for recommendation
Number of extensions available
Countries in which to validate in
Etc.

I think it could be a relatively small number of such fields--hard to imagine needing as many as for Matters.

Christian

@JasonP2345 I also agree, but with a caveat--once a task is closed out, then the owner should not change dynamically. Or there should be a way to choose whether or not the owner should be updated dynamically for closed-out tasks.

Closed-out tasks are historical records, indicating how a task was closed out, who was responsible for it when it was closed out, etc. Having that data change when a matter is reassigned to a new attorney or other contact could lead to misunderstandings as to who did what later.

Open tasks, however, are the responsibility of whoever they are assigned to, and it makes sense to update those to reflect whoever is assigned to a particular role for a matter when matter contacts are updated.

Otherwise, I agree that this would be a very useful feature. Right now, we have to manually bulk update all tasks to have new owners when we reassign matters. It is a drag.

Christian

Each Task Type definition has a "Description" field that can be used to store internal notes regarding that Task Type. As far as I can tell, this field is only visible in the Task Types module and in the Task Type editor. It would be very useful if that field could also be accessible as a field in emails/form letters/reports (just like DeadlineType is available).

For example, it would be helpful to be able to store instructions for how to handle a particular task type/deadline in the task type definition and then display that information to users in association with each instance of that task type. This would be particularly helpful for more esoteric deadlines that people may not be as familiar with.

Ideally, there would actually be a separate "Instructions" field for each Task Type that could be used for this purpose (allowing "Description" to be used to describe what the task is, what purpose it serves, etc., while "Instructions" is used to store instructions to the task owner of what they need to do), but this would be icing on the cake. You might even consider having two separate Instructions fields, one for short instructions and one for more detailed ones.

Thus, two suggestions:

a) Make the Task Type "Description" field accessible via emails/form letters/reports, and

b) Add an "Instructions" text field (similar to "Description") to Task Types (or "Instructions1" and "Instructions2" fields) and have them be similarly ssible via emails/form letters/reports.

Hopefully at least (a) can be done relatively quickly.

It would be nice to be able to filter records by the Discussion field; can this feature be added?

@mike_appcoll Just curious--any ETA on item (c) above?

The Contact merge interface does not show first/middle/last names as separate columns. When you have multiple contacts that only differ in that one of their names is actually a double name, e.g., John David as first name instead of John as first name and David as middle name, the two contacts appear identical in the Merge interface, so you don't know which one you are picking as the primary contact....

Can this be fixed?

AppColl allows you to create form-filled USPTO forms for a matter; you can also create form-filled copies of such forms for multiple matters relatively easily from the Matters module. It would, however, be great if one could (for at least certain forms), give the user the option to specify how fields in that form that are NOT fillable from AppColl data are to be filled in.

For example, the AIA/122, AIA/123, AIA/83, and SB/123 forms (and there may be others) all relate to changing the address for a patent or application. Take the AIA/123 form, which is used to switch the correspondence/maintenance fee notice address--you need to provide either (a) a customer number that has the new address or (b) separately specify the name/address/telephone/email of the new addressee. It would be really great if AppColl gave you the chance to enter data for the fields in (b) prior to generating the PDFs, and then populated those fields in the generated PDF with that data.

For example, we recently had to transfer files back to a client (with no successor counsel arranged) and file change of correspondence address forms for 30 different patents. All of them had the information in (b) specified to be the same, and we had to copy-paste that info (which involved copying the data for 8 fields into all 30 forms--240 copy-pastes!) to finish the forms. It would have been a huge time-saver if we could have supplied that info up-front and had AppColl populate it when it populated the matter-specific data.

It would be a pretty nice feature to be able to assign permissions to groups and assign users to those groups; the idea would be that each user would be a member of one or more groups and would have the permissions associated with each group.

Moreover, it would be nice to have the ability to specify, for each group, what data they are allowed to edit, especially with respect to TaskTypes. For example, we have a fairly strict policy as to who has "add/modify/delete" permissions in our system--we do this to limit the potential for errors. However, there are some tasks that are of lower importance--we'd like to be able to delegate the ability to modify those tasks to people that do not otherwise have global "add/modify/delete" permission.

This would let us docket/dedocket those tasks without taking up the resources of our docketing department while still protecting the integrity of our overall docketing system.

Probably not an easy thing to implement, but it would be very useful.

Cheers,
Christian

@SadiqA2304 I thought of that but was concerned that it might muck with triggering conditions if the task name was later changed to remove the "under development" text.

It would also mean that normal users would still see it and the under development tasks would still clutter up the interface.

It would be helpful if Task Types had a setting allowing them to be specified as being "under development." Under-development tasks would only be visible to Admins in the GUI and reports and invisible to all other users. This would prevent such task types from inadvertently being used by users before they are finalized, potentially resulting in mis-docketed tasks.

Once under-development task types are finalized and tested, the "under development" setting could be removed and the task types made available for general use.

AppColl has a "Trash" that deleted items get sent to; items in the Trash can be selectively undeleted if desired. The trash can also be emptied to permanently delete items. We would like to delete most of the trash, but

However, there are some aspects of trash that could be vastly improved:

a) For the love of God, make deleting trash items a background task. Right now, if you delete items, you can expect to wait ~3+ minutes/1000 items, and the poor schmuck doing it can't really do anything else in AppColl while the deleting is occurring.

b) The trash should be able to be filtered. For example, I'd like to be able to delete all items in the trash that are more than a month old, but the only way to do that is to go through every page of trash items more than a month old, select all items, and then delete them. At 120 pages of trash items, I'm looking at a minimum of six hours spent doing this, with me having to interact with the system every 3 minutes.

c) Add a setting that lets admins specify a default "permanently delete" age where AppColl automatically permanently deletes items in the trash that are over X days old.

And a minor quibble:

d) There are two buttons: "Permanently Delete" and "Empty Trash." They do the same thing, except that the former only deletes the items that are selected and the latter deletes ALL items in the trash. Maybe they should be relabeled "Permanently Delete Selected Items" and "Permanently Delete ALL Items."

Just upvoted your original idea, Sadiq.