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

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 Email button in the Matter Details screen is great. However, the way in which emails are created could use a little improvement. This would all be fairly straightforward to implement and would be a timesaver for users:

a) There are often situations where the email being generated lists the email address of the person who is generating the email. While having that email address in the email address fields is harmless, it is also completely unnecessary and needlessly consumes space in the mailto link that could be used for other purposes. This would be very simple to strip out.

b) There are also often situations where an email address may get double-included. For example, a client may have standing instructions to always CC a particular attorney in addition to the ClientContact on correspondence for all their matters (thus leading to that particular attorney's email address being hard-coded into a client-specific email template for that client), but that particular attorney is also the ClientContact for some matters. In the matters where that particular attorney is the ClientContact, their email address will appear twice. At the very least, it would be nice if AppColl could cleanse each of the TO and CC fields for dupes and remove them. If an email address appears in both the TO and CC fields, they could be either a) left in both fields or b) removed from one field, e.g., the CC field.

Christian

It would be helpful if AppColl could provide statistics on report usage, e.g., a way to see how many times a given report was run by users within a given timeframe (or several time frames, e.g., within last month, within last 3 months, within last 6 months, within last 12 months, lifetime).

Ideally, these statistics would reflect only incidents where reports were generated manually by a user (as opposed to auto-scheduled emailed reports). However, it might be nice to have both types of report usage tracked and available for review by users/admins.

This would allow admins/users to periodically review their reports and make more informed decisions as to whether to retire reports that are infrequently used. As the system currently stands, we're finding there are lots and lots of reports that have been generated over the years and we have little idea which actually get used on a regular basis. Having that info on hand would make it easier to figure out which ones spark joy and which can be tidied up.

@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

It would be really great if task notification emails could be set up to be triggerable based on task metadata. For example, it would be great if a notification for a task could be set up to only be sent out if the Matter.Client was a particular client or if Matter.CountryCode = "CN"--you get the idea. This would allow a single task to have multiple potential notifications that could be sent out in the alternative based on matter-specific data.

The only way to do this now is to either:

a) Have multiple separate tasks, each with its own set of notifications that are tailored to a particular metadata condition. However, this results in having different tasks for different clients/countries/etc., which is confusing on the docket and makes it very cumbersome to manage how tasks trigger (for example, if you have 10 different flavors of what is the same task (except for the notifications), you'd have to revise 10 separate tasks if there was any revision needed, e.g., to task triggering.

b) Have (b), but make them each a transient task that triggers off a common task type. Each transient task would only trigger off that common task type if certain other conditions were met, e.g., if the common task was in a particular client's docket or in a matter in a particular jurisdiction. The transient tasks would have the customized notifications. However, this still results in potentially a large number of different task types--we already have 600+ task types, and we'd like to avoid having hundreds more that are just there to provide different notifications....

Cheers,
Christian

@GreggH8509 I think Tar's original idea would provide usefulness beyond what the transient task approach would. For example, it might be that a particular matter has certain sensitivities, e.g., requires special handling (perhaps due to a licensee's requirements, litigation considerations, etc.), and having it so that there was a pop-up that came up if you ever brought that matter's matter details up could put it front-and-center to the user that there is something important about the case....

To that end, it might also be useful to have a "private notes" field for both tasks and matters (like exists for Contact records) that could be used to store such info. "Notes" could be used to store more verbose info, e.g., text from client emails, etc., whereas "Private Notes" could be used to store more concise info, e.g., "MATTER SUBJECT TO LITIGATION HOLD" or "CLIENT MUST PREPAY" that could be popped up in the pop-up that Tar mentions.

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

@support_appcoll Has there been any movement on implementing this idea? It would be hugely useful to have the ability to define some custom fields for tasks.

For example, a field for "In IDS Database" to record whether an Office Action and its cited references have been added to the IDS database. Or "recommendation sent" to indicate that the client has been provided with a recommendation.

Christian

The Email button in the Matter Details screen is great. However, the way in which emails are created could use a little improvement. This would all be fairly straightforward to implement and would be a timesaver for users:

a) There are often situations where the email being generated lists the email address of the person who is generating the email. While having that email address in the email address fields is harmless, it is also completely unnecessary and needlessly consumes space in the mailto link that could be used for other purposes. This would be very simple to strip out.

b) There are also often situations where an email address may get double-included. For example, a client may have standing instructions to always CC a particular attorney in addition to the ClientContact on correspondence for all their matters (thus leading to that particular attorney's email address being hard-coded into a client-specific email template for that client), but that particular attorney is also the ClientContact for some matters. In the matters where that particular attorney is the ClientContact, their email address will appear twice. At the very least, it would be nice if AppColl could cleanse each of the TO and CC fields for dupes and remove them. If an email address appears in both the TO and CC fields, they could be either a) left in both fields or b) removed from one field, e.g., the CC field.

Christian

AppColl offers the ability for users who have Report creation permissions to make a report "Private", which is great. It would be really nice, however, if the Permissions manager in AppColl could have a setting that could give add/delete/modify Report privileges to a user but only for private reports. In other words, that user could add/delete/modify reports that they make, but not modify/delete reports that others have made. Moreover, any report made by such a user would automatically be a "private" report so that others cannot see it. Ideally, those permissions would extend through to the Manage Report Schedules as well, e.g., those users could manage schedules for their private reports, but NOT add/delete/modify schedules for other reports.

For example, we want our practitioners and secretaries to be able to make their own reports and schedule them to be sent to themselves (if desired), but we do not want them to be able to modify other reports, e.g., ones that sys admins have set up for general use by anyone in the firm. Right now, there isn't a happy middle ground that will let us do that. We have to give full report permissions to our users and just trust that they will not accidentally modify a report that they have no ownership of.

It would also be great if the "Reports" combo box in each module could have a toggle that lets the user flip between listing all reports, only private reports, and (possibly) public reports.

Cheers,
Christian

It would be nice if there was a way to easily pull or display more detailed info on all matter inventors from the Matter Details interface. For example, right now, it just shows you the name of each inventor. However, it would be really great if the interface could be updated to show (or optionally show) further info for each inventor, e.g., City/State/Country of residence, citizenship, assignee, and possibly other data (for example, a field that might show if they are ex-employees or active employees).

Most/all of the above info is actually very useful info to have on-hand when looking at a matter. For example, if any inventor is a resident of India, you would want to be able to easily figure that out so you can make sure to docket requesting an Indian foreign filing license. Similarly, if any inventor is a Greek citizen, you'd want to be able to easily detect that as well so you can make sure you file the first application in Greece. And if there are inventors that work for different entities/would assign to different entities, you'd want to know that up-front as well so that the proper assignments get generated.

Right now, the only ways to get all this info for the inventors in a matter are to:

a) Drill down inventor-by-inventor from the Matter Details screen. You have to click on each inventor's "View Contact" button, review the pop-up, and then close it. This technique does not let you see all of this info at once for all of the inventors. It also does not show all info for each inventor (although, to be fair, it does show most/all of the info I flagged above).

b) Create a form letter or email that has fields to show all this data, and then generate it. This is clunky/cumbersome.

c) Create a database query in Contacts module? I'm not even sure if you can do this. But even if you can, it would require leaving the Matter Details module for the Contacts module and then crafting a query. It should not require such steps to get easy access to this info.

I would propose that the Matter Details interface be updated to include a button below the "Add" button called "Summary" that, when clicked, would bring up a pop-up window that listed, in table form, all of the inventors, their as-filed names (if applicable), their citizenship, assignee/employer, city of residence, etc. Ideally, the listed data can be copied in table form and pasted in table form into other documents, e.g., Excel, Word, or Outlook. It would, in effect, act somewhat like the "View Contact" link, but for all inventors at once and showing the data in a table format.

And if you really wanted to gold-plate it, you could add the ability for any individual user to add/remove any column from the Contacts module to the table view and to change the column order as they see fit, similar to how users can modify the columns in the Contacts module itself. That would let users potentially add other fields to the display that might be relevant to them, e.g., a field like "Tags" that they maybe use to store indications of whether or not the inventor is an ex-employee or not, or perhaps "Private Notes" or "Nicknames" to provide more info on how to communicate with that inventor.

@ChristianS9906 After posting this, I noticed that task types now include a "deleted" task status that can be selected for the auto-close behavior. I initially thought that maybe AppColl would cause tasks with such status to automatically delete themselves when they auto-close (which would pretty much reach a similar end result to the above). But then I tested it, and it seems like all it does is close the task out as "deleted." The task sticks around, however.

AppColl includes a "Transient Event" DeadlineType that was created responsive to input I provided several years ago. A transient event is just like a normal event except that it comes into existence and then immediately deletes itself--however, it triggers any follow-on tasks that might be needed and sends out notifications associated with it prior to disappearing.

It would be very nice if the Tasks framework were to be updated so that any TaskType could be made to be "transient," i.e., made to self-delete once no longer "Open." For example, every TaskType definition could have a "Transient" (or "Delete Once Closed" if a more descriptive name is desired) setting, e.g., a checkbox, that can be checked for a TaskType if that TaskType is to self-destruct once closed out.

This would be a little different than how the existing Transient Event DeadlineType works in that non-Event TaskTypes with this setting enabled would not immediately self-delete, but would stay visible on the docket until closed out. However, the existing Transient Event DeadlineType should be implementable under this new framework as well, e.g., as a normal Event DeadlineType that has the "Transient" setting enabled--since Events are tasks that instantly complete themselves, the "transient"-enabled Event should work like the current Transient Event DeadlineType.

The benefit to having this setting is that it would allow for intermediate deadlines, e.g., reminder deadlines, to be auto-closed and then disappear from the docket, as opposed to cluttering it up in a "completed" state. We like to have our docket be relatively streamlined, e.g., free of low-value entries. An advance reminder of an upcoming foreign deadline, for example, is useful to have on the docket, but once that reminder is in the past, it really isn't something we need to keep seeing.... Being able to have it automatically clean itself off the docket would be a nice capability to have (and would save our docketing department time and effort).

@SadiqA2304 Sort of...but this requires a) two browser windows running at the same time (more windows!) and b) still requires the user to have to navigate to each matter in each interface.

AppColl allows you to have logins to multiple AppColl accounts, allowing a law firm user to access the law firm's AppColl account and also client AppColl accounts (if given login rights). It's a neat feature.

Right now, to switch accounts you have to go to the account icon in the upper right corner, hover over it, hover over the Switch Accounts menu flyout, and then select the account you want to switch to. You then need to navigate to the matter you want to view in the switched-to account.

In many cases, a user will actually be wanting to switch between accounts to look at the same matter. For example, there may be tasks that need to be completed in two separate accounts for the same matter. It would be a really neat feature if AppColl could, for users having login rights to multiple accounts, identify those matters that exist in two different accounts and then, in the Matter Details view, provide a button that, when clicked, switches between the record for that matter in one AppColl account to the record for that same matter in the other AppColl account. This would let the user flip back and forth between two accounts while still viewing the same matter. This saves the user the hassle of navigating back to that matter in either account after an account switch (and avoids the need to use the Account Switch flyout menu.

Just curious if this feature/fix is in the works. The inability for users to edit/delete their own discussion posts hobbles the Discussion feature significantly. For example, we would like our staff to be able to just put all their comments into a single discussion entry (to avoid lengthy chains of entries), but they can only do that for Task Discussions (not Matter or, presumably, Contacts Discussions). They also cannot delete a Discussion comment they made, which would be desirable from a docket cleanup perspective.

Can you please let me know if this is something that will be addressed soon?

Thank you.

The ability to see how frequently a given report has been viewed is a nice feature add; thanks for including it. However, I have some suggestions for making it more useful:

a) The look-back window is only 90 days; it would be nice if it also looked back 180 days and 365 days. Some reports might get accessed only on a quarterly basis, and the 90-day lookback might miss that.

b) The usage stats only seem to include "views"--it would be nice if it also included other types of report access. For example, a report that is synced every night or emailed/FTP'd every night might never be "viewed" after it is created, but it is nonetheless in heavy use.

c) It would be great if a report could be made that listed all reports and the various usage stats that are currently only viewable report-by-report by hovering over each report. If we want to do a report "cull," step one would be to try and get a sense for which reports are rarely used. Right now, we'd have to hover over every report to get that info, which is not at all efficient.

Please do keep the improvements coming!

Thanks,
Christian