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?

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.

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."

The USPTO is instituting new fees on continuations/divisionals/CIPs January 19, 2025, that are based on how long ago the "EBD" (earliest benefit date) for the application is. The EBD is the earliest US non-provisional date that the continuing application claims priority benefit to (a PCT application is viewed as a US non-provisional). If the EBD is more than 6 years ago and no more than 9 years ago, a $2700 fee is due (undiscounted). If more than 9 years ago, then the fee is $4000. Federal register notice is here.

It would be very helpful if AppColl could have fields that indicate the EBD and the number of years since the EBD for each US non-provisional application (or at least, each continuing application). Such fields would ideally be available via the Matters Reports interface so that we can generate reports with the data.

The EBD would be calculated by looking at each US non-provisional application listed as a priority connection for such an application and then using the earliest filing date for those connections as the EBD.

NOTE: The Federal Register does note that if priority to a US provisional is claimed using 35 USC 120 instead of 35 USC 119, then such a provisional would be considered for the EBD. Since AppColl doesn't track what kind of benefit claim is made, it technically does not know if a provisional should or should not be included in the EBD calculation. However, I am unaware of any scenario in which anyone would actually want to claim priority benefit to a provisional using 35 USC 120, and AppColl's working assumption when filling out ADSs is to use 35 USC 119, so I think it is safe to assume that any provisionals that are in the priority chain were claimed via 35 USC 119 and thus should not be considered in the EBD calculation.

Can this be done?

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.

@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

The new chat-style Discussion feature is great! We are looking forward to using it. A few suggestions for improving it:

a) Make the chat-style Discussions be accessible via fields in Reports and Email/Form Letters. When this is done, please make it so that there are not double or triple carriage returns between each line, as that will make the data take up much more space. (This is done; thanks!)

b) Make the chat-style Comments for Tasks be visible in the table Task View of Matter Details as a column. (This is also done; thanks again!)

c) Create a feature that allows for bulk and/or automated deletion of Comments. For example, it would be nice to give Admins the ability to run a Matter report and then have a button that allows the Admin to delete all Comments for all of the Matters (and, optionally, Tasks in those Matters) listed in the report without needing to go into each matter/task and individually delete every comment, which seems to be the only way to get rid of them now.... (NOTE: The ability to exclude the chat-style Comments from the transaction log is noted and welcome).

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 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

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

The CSV or XLS bulk update feature is nice, but it would be great if it could be set up to truly work in the background, i.e., so that you can continue to use AppColl while it is processing the spreadsheet import. Right now, when you start a bulk import, you're pretty much prevented from doing anything in AppColl in that browser until it finishes. You get that progress pop-up which can only be dismissed by stopping the import. And if you try and use another AppColl browser tab, that same pop-up comes up there too. The only solution is to use a different browser and log in via that.

Importing data can be quite time-consuming. For example, we often have to update thousands of records at a time to reflect potential changes in ClientContact info, and those imports often take 15 minutes to validate and another 45 minutes 1.5+ hours 1.8+ hours to actually be imported (assuming there's no issue with the validation that requires re-validation!). During that time, the user is locked out of being able to do anything else in AppColl in that browser.

It would be nice if AppColl would confine the import process to a single tab so that AppColl could continue to be used in other tabs of the same browser while the import process churns away on its dedicated browser tab....

Would that be possible?

Thanks,
Christian

The browser-based email editor included in AppColl automatically inserts the matter AppCollEmailIntake email address into the recipient list for any email created in it. It does this even if the AppCollEmailIntake email address is not included in the email template that is used to generate the email.

Can this please be fixed? We do not use the EmailIntakeAddress for our own account but do use it for clients that have AppColl and wish us to use their version of it, and it can cause confusion when both are present.

The whole point of having an email template is so that there can be a consistent format for emails, and having the editor decide to override the template and include recipients that aren't supposed to be there seems contrary to that purpose. If a template is intended to reference the EmailIntakeAddress, it is easy enough to include that field in the template--AppColl should not be inserting it on its own.

It would be helpful if Matter records had a yes/no field for POA that could be used to indicate if a power of attorney had been accepted for a matter. For example, this can be very helpful when transferring matters in and in identifying cases where a power of attorney has been filed but not yet accepted....

Even better would be if it could automatically determine yes/no status of this field. Not sure if that's possible though.

@BruceY9495 Where are you seeing that, Bruce? I don't see it anywhere (Matters columns, matter details, or task response date). I would assume that's maybe where data is stored if you manually edit the EBD. Although would assume that for users, it would only show/use the calculated EBD unless there was a user-edited EBD, in which case it would just use that.

Christian

@ChristianS9906 Thank you, Gregg--much appreciated! When will the EBD data finish being populated for existing records? In our case, it appears that only about 10% of our pending/published/unfiled/allowed US non-provisionals have this data.

@BruceY9495 My thinking is to have two tasks, one for 6 years offset and one for 9 years offset, that simultaneously auto-docket for all apps at the time of filing. They would both be set up to auto-close themselves as Closed after their respective deadlines pass, and I'd likely have them send out email notifications a month or two ahead of time to give a heads-up. I don't see a reason (at least, not yet) to close them out with any other status--if the client wants to pursue a pre-six or pre-nine year CON filing, then we would ensure that the new matter for that CON filing would set the file-by date to beat the EBD being 6+ or 9+ years in the past. I'm not seeing much need to track what's happening in the CON in the parent case, which is why I'm planning on just having those 6/9 year offset tasks auto-close themselves once no longer relevant--once the relevant deadline is past, it's not like you can do anything about it anyhow....

The reason I intend to set up both 6 and 9 year tasks at the same time instead of daisy-chaining them is that for some cases, you might never have a 6-year task that gets closed in order to trigger the 9 year task. Haven't thought about this much yet, but it seems like a potential scenario. There might be a way to handle this with query-based triggering, but it would require some experimentation.

One thing I will be doing, however, is making these new tasks able to be turned on/off based on Tags in the Client contact record. I anticipate more sophisticated clients asking us not to send them reminders about such potential CONs, so want to be able to easily turn it off for those clients and avoid the docket clutter.

Thank you for adding the EBD as a field--much appreciated.

We'd like to be able to docket reminders based on it in cases, but I think we need to be able to select it for the "Response Date" in the Task Type definition interface in order to do so.

Can this please be added ASAP?

Thank you,
Christian

@BruceY9495 UPDATE: Our account has EBD data for about 40 matters, but that's it. I guess it is still updating/being calculated.

Our account had the EBD data in it as of this morning, so I think they have added it.

Thanks, Gregg!

@gregg_appcoll Hi Gregg, do you know when the EBD field will be populated with data for all our existing US matters? The field is there, but not very useful to us without that info...would rather not have to add it all manually.

@ChristianS9906 Looks like the EBD field is now available for those of you looking to use it. Thanks!

UPDATE: The field is now available, but there is no data in it for any of our pending matters.... Can it be populated?