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

This relates to some recent suggestions regarding an InventorEmails field (https://forum.appcoll.com/topic/134/new-field-request-inventoremails?_=1663947413348); it might be a more flexible way to get to the same result that could be extended to other fields.

Some contact fields for a matter are actually lists. These include the inventors, applicant(s), and licensee(s). In each case, the contact record(s) that are listed have their own fields. It is sometimes the case that users want to be able to make a list of the contact(s) for those fields, but break out the data for specific fields for each contact within the list. For example, we have a document that we provide to our foreign associates that lists, for each inventor:

<LAST NAME>, <First name> <Middle name>, Citizenship: <Citizenship>
<StreetAddress>,
<City>, <State> <ZIP>
<Country>
<ForeignNickname>

All of this info is provided (if available) for a given inventor before the next inventor is listed. Right now, our template for this is 7800 characters long since we have to essentially create 20 separate field blocks, one for each InventorX (where X is a number from 1 to 20). The format of these blocks is identical, except that "Matter.Inventor1" in every field within the first block gets changed to "Matter.Inventor2" in the second block, and so forth.

What would be great is if there were a Form letter/email syntax that would let a user define a block of text with fields and then bracket it within some sort of syntax block that causes AppColl to replicate the field data in that block that derives from an item in a list for each item in that list.

For example:

{Matter.Inventors.List({MATTER.INVENTORX.LAST}{+032MATTER.INVENTORX.SUFFIX}{+044+032Matter.InventorX.First}{+032Matter.InventorX.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.InventorX.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.InventorX.ForeignNickname}{+013+010Matter.InventorX.Address})}

This would cause AppColl to, for each inventor listed for a matter, generate a text block per the above string.

This syntax could be really useful, I think. You could use it to insert emails for all inventors into an email, e.g.:

{Matter.Inventors.List({Matter.InventorX.EmailAddress}+059**)}**

There could even be a variant of this that adds an additional feature of making a punctuated list, e.g., with commas inserted between blocks (if more than two items in the list) and an " and " inserted before the last item (if more than one item in the list). The syntax for this could be like:

Dear {Matter.Inventors.PunctuatedList({Matter.InventorX.Prefix+032}{Matter.InventorX.Last})}

Which might generate a list like:

Dear Mr. Smith, Mrs. Doe, and Dr. Strange,

This would really enhance form letters/emails.

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

This relates to earlier posts I made: (https://forum.appcoll.com/topic/137/new-field-syntax-list?_=1773350339170) and https://forum.appcoll.com/topic/169/more-streamlined-form-letter-field-syntax?_=1773350545712

Having just had to update our Inventor/Applicant sheet, which is 9600 characters long and, in essence, just lists the first, last, and middle name, citizenship, address, and foreign nickname for the first 20 inventors, I thought it worth re-elevating this request. I wanted to add, for each inventor, their TaxID number (if they have one listed). It is a painful document to edit. Here's what it looks like in raw form for the first 3 inventors:

{MATTER.INVENTOR1.LAST}{+032MATTER.INVENTOR1.SUFFIX}{+044+032Matter.Inventor1.First}{+032Matter.Inventor1.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.Inventor1.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.Inventor1.ForeignNickname}{+013+010Matter.Inventor1.Address}{+013+010MATTER.INVENTOR2.LAST}{+032MATTER.INVENTOR2.SUFFIX}{+044+032Matter.Inventor2.First}{+032Matter.Inventor2.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.Inventor2.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.Inventor2.ForeignNickname}{+013+010Matter.Inventor2.Address}{+013+010MATTER.INVENTOR3.LAST}{+032MATTER.INVENTOR3.SUFFIX}{+044+032Matter.Inventor3.First}{+032Matter.Inventor3.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.Inventor3.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.Inventor3.ForeignNickname}{+013+010Matter.Inventor3.Address}

The syntax for working with form fields leaves a lot to be desired. Things that would make it so much better/user-friendly include:

a) Ability to specify, in plain English, what the preamble/postamble for a given field will be. This business of spelling out, character-by-character, what the preamble/postamble should be using a + symbol and the 3-digit ASCII code for each character makes it impossible look at a form letter template document and understand how the document will look once populated with data. It also dramatically shortens the "usable" MailTo link content that can be passed to an email from an email template. Allowing use of plain English, e.g., with delimiters, would address both issues.

b) Ability to use "lists" in templates, e.g., if you have the same set of fields that you want to output for each member of a list, there should be a way to do that via a list field and one instance of the set of fields that you want to output, as opposed to having to specify the same set of fields 20 times with only an index number changing for each instance.

Separately from the above, it appears that the Address form field inserts a double carriage return at the end of it, thereby forcing a blank new line after it. This causes issues when Address is used in a block of other field data, like in the above example--each field in the block of field data has a +013+010 preamble that causes that field to start on a new line if data is present. If the field has no data, however, the new line doesn't get inserted, thereby avoiding a blank line. The Address field, however, doesn't seem to play well with this convention--I had to list it last for each block since it seemed it was always introducing an unwanted gap line in between itself and an immediately following field line. If users want a gap line after the Address field, they do always have the option of specifying one in the field postamble, of course.

Any chance that the above could be implemented?

Cheers,
Christian

@SadiqA2304 1000% agree. One thing that would also be a huge value add would be some way to select a limited set of matters to use as "test" cases (this would be in the TaskType definition UI) and then provide a "test" button for each WHEN clause that would let you, in effect, simulate what the outcome would be, i.e., WHEN clause executes or fails, for that WHEN clause for each of the specified matters. It would be a much quicker way of testing whether you've got your WHILE clauses for a given WHEN clause set up right. Right now, you often have to have a test matter open in Matter Details, manually add a triggering task for a WHEN clause, and then see what happens, then delete those triggered tasks for next round of testing, etc. It's rather time-consuming.

Trigger condition editing for Tasks in AppColl is in dramatic need of improvement--there is no ability to insert new triggers in between existing triggers, or to change which "when" clause a given "while" condition is "anded" with.

This makes defining new tasks or modifying existing ones extremely tedious. For example, if you have a task with multiple different trigger scenarios, each with its own WHEN clause that each have their own WHILE clauses, you might easily have 10-12 separate trigger conditions, e.g., 3 WHEN clauses, each with its own set of 3 WHILE clauses. If you realize that you need to tweak the triggering by adding another WHILE clause to the last WHEN clause, no big deal--just tack it on and you're done. But if you need to do it to the first-listed WHEN clause, you're out of luck--you have to delete the second and third WHEN clauses and all their WHILE clauses, add the new WHILE clause to the first WHEN clause, and then re-construct the second and third WHEN clauses and all their WHILE clauses. In the example above, you'd have to delete 8 of your 12 trigger clauses, add the additional trigger clause, and then re-build the deleted clauses.

Suggestion: The trigger conditions for a TaskType are currently listed in a table format, with the WHILE conditions indented in rows below their parent WHEN condition. Just add a button to each WHEN condition row in the table that would, when the user clicks it, allow the user to insert a new WHILE condition for that WHEN condition. The newly added WHILE clause would be added after the existing WHILE clauses for the relevant WHEN clause. This would entirely solve the significant usability issue noted above.

Icing on the Cake Suggestions: Maybe also add up/down buttons to allow the order of trigger conditions to be changed. This would be more of a cosmetic change, as changing the order of WHILE clauses within a WHEN clause would have no functional impact--but it would allow users to re-organize the WHILE conditions within a WHEN condition so that they are more consistent between WHEN conditions for a given TaskType. And it would allow a WHILE condition to be moved up or down into an adjacent WHEN condition, which would affect function but also potentially be useful if you put a WHILE condition in the wrong WHEN condition and want to relocate it.

Finally, the UI already has the ability to individually delete any condition--except the first WHEN condition. It really should allow the user to delete that one as well. There are times when you define a set of task triggers to have multiple WHEN conditions, and then later you realize that the first one isn't needed any more. But you can't delete it without deleting all trigger events and then rebuilding the ones you want to keep. Or by changing the first WHEN condition to be the last WHEN condition and updating its WHILE conditions to match (only works if first WHEN has same or greater number of WHILE conditions as last WHEN condition or if you only have two WHEN conditions).

Screenshot below showing suggested revisions to TastType definition UI.

We've been using this for several years, and I figured I'd share. If you file a non-pub request in a US matter, there isn't a very easy way of auto-docketing a Task to rescind that non-pub request in response to later filing a foreign application. However, it's not impossible to do so....

DISCLAIMER: This seems to work, but I make no warranties and, of course, do not accept liability if it turns out to not work as intended—you should test it yourself to satisfy yourself that it works before relying on it.

You'll need to create the task types below.
................................................................................................................................................................................................................................................
TaskType: Rescind Non-Pub Transient Trigger

Deadline Type: Transient Event

Response Date: Use the triggering task closed-on date with 0 months/0 days offset.

Make sure that “Enable automatic task generation based on above trigger events” and “When automatically generated, only create the task for each related pending US matter (if any)” are both checked.

Triggers
a) When any task completes
b) AND while the 'CountryCode' field in the matter doesn't contain 'US'
c) AND while the 'TaskType' field in the task contains 'Statutory Bar Date'

NOTE: (c) can be replaced with whatever task is appropriate for your docketing setup—the key is to choose a task that will always be present in a non-US or PCT filing and that will always be closed out as “Complete” when that non-US or PCT filing is actually filed and that will have a closed-on date that is the actual filing date of that non-US or PCT filing (this is important!). We used “statutory bar date” since we have both Paris and PCT statutory bar date tasks, and this approach allowed us to get both with one rule set. But you could also just use “when a specific task completes with a given state” to combine (a) and (c) if you just use one such task type for all foreign filings.
................................................................................................................................................................................................................................................

TaskType: Rescind Non-Pub Request

Deadline Type: Hard External Deadline with +45 days (or maybe less, if you want to have some cushion) from triggering task reference date as response date.

Make sure that “Enable automatic task generation based on above trigger events” is checked.

Triggers
a) When a 'Rescind Non-Pub Transient Trigger' task is created
b) AND while the 'NonPublication' field in the matter contains 'True'
c) AND while the 'CountryCode' field in the matter contains 'US'
d) AND while the 'Type' field in the matter contains 'Utility'
e) AND while the 'Type' field in the matter doesn't contain 'Utility: Provisional'
f) AND while a task database query 'Matter = "{Task.Matter}" and TaskType = "Rescind Non-Pub Request"' doesn't return any records

Every time a foreign case gets filed, the transient trigger will be created (and then disappear) in all related US matters—the Rescind Non-Pub Request listens for that trigger event. If it hears it in a US matter, it then auto-dockets in that matter if the additional conditions are met.

(a) is the trigger event. (b) limits the Rescind Non-Pub Request task to only docket in matters that have Non-Pub set to True. (c) limits this auto-docketing to US matters only (this is probably unnecessary—the trigger task should only be created in US matters in the first place). (d) limits the Rescind Non-Pub Request task to only docket in Utility apps (not design apps) and (e) excludes docketing it in provisionals (also probably unnecessary since they don’t publish/non-publish). Lastly, (f) prevents duplicate Rescind Non-Pub Request tasks from being created, e.g., one for each foreign app filed off of a US matter—you just get the first one to be docketed.

NOTE: (f) is handy for reducing clutter, but using it runs the risk of having the date for the Rescind Non-Pub Request task be wrong. For example, if you file multiple foreign apps, and the first one that triggers the transient trigger happens to have a filing date (closed-on date) that is after the filing date (closed-on date) of a later-docketed foreign filing, the Rescind Non-Pub Request will have a due date based on the first-docketed but not first-filed foreign matter, and that will be off. If you prefer, leave (f) off to ensure that Rescind Non-Pub Requests are docketed for every foreign filing according to each such foreign filing’s actual filing date.

Cheers,
Christian

There are situations where there it would be desirable to control triggering of a task based on events that happened in an earlier-filed case in the same family. For example, maybe you have a checklist that you want to have done when the first application in a family is filed, but you don't want to have it done for each subsequent application in the family.

Right now, I don't believe there is a mechanism that lets you autodocket tasks to account for such a scenario.

One way to add such capability would be to have a CarryForward field where the contents of the field are carried forward into the same field in subsequent matters that are based on that matter (using the "Save and Duplicate" function); this is already done for several fields when you use "Save and Duplicate," so this new field could simply be treated in the same way.

However, Tasks Type definitions would be updated to have several new parameters that allow a Task to modify the data in the CarryForward field. At a minimum, that ability would be to allow the task, when "Completed," to append specified text to the contents of the CarryForward field for the matter. In the checklist scenario, when the checklist task is "Completed," the checklist task could be set up to append "Checklist" to the CarryForward field for the matter (I included asterisks to serve as delimiters). When the next matter in the family is opened, it would get the "Checklist" data in the CarryForward field, and that could then be used as a trigger to prevent creation of a checklist task in the new matter.

If you wanted to give even more flexibility to this approach, the parameters that could be set in a Task could include:

Append specified text (as described above)
Remove specified text (delete specified text from field--this is where delimiters would be very prudent)
Replace specified text with other specified text
Clear entire field

You could also have these options able to be specified for different task states, e.g., when task is created/opened, closed, or changed to a particular TaskStatus.

Finally, it would be useful to have the ability for the specified text include form fields, e.g., "FiledOn( {Matter.FilingDate})" and for tasks to have the ability to have their RefDate or RespondBy dates set based on the date stored in such text in the CarryForward field. For example, in New Zealand, you have to request examination by 5 years from the filing date of the first NZ application (regardless of whether it is in that first NZ app or a DIV of it). You can't rely on priority date for the 5-year deadline since your first app might be a US provisional, and you can't rely on the NZ filing date since that wouldn't be the right one for DIV applications. Being able to pass on the relevant date to later applications would be a real help....

AppColl allows users to define up to 16 custom text fields and 4 custom date fields that are accessible via the Matters module. These fields have internal names in AppColl of UserString1, UserString2, UserDate1, UserDate2, etc.

There are five things that would greatly improve these custom fields:

a) Significantly expand the number of custom text and date fields available to users (or make it not capped at all). It is often the case that we use the custom fields to store client-specific data where there is no appropriate field available in the default field set. Ideally, we'd store the data in a custom field with the same name used by the client for that data so that there's no uncertainty as to which custom field has that data. However, with only 16 text fields to work with, we often have to use the same custom field to store different types of data for different clients. Expanding the number of custom fields would allow us to avoid having to make a custom field serve multiple different purposes for different clients.

b) Related to (a), it would be nice if one could optionally specify one or more clients for each custom field; AppColl would then only show a custom field in the MatterDetails interface if it either a) had no client specified (i.e., generic to all clients) or b) had a client specified that matched the client of the matter being displayed.

c) Also related to (a), in the column picker for Matters/Tasks, it would probably be a good idea to either put custom fields as a separate tab or allow the user to include/exclude them from the list of fields/columns. Or maybe include them at the bottom of the list, separated from the other list members (so you'd have an alphabetical list of default AppColl columns, followed by an alphabetical list of custom fields/columns. I'm just thinking that if the cap on # of custom fields is increased or removed, there might be a lot of them in some accounts to wade through.

d) Allow for a group name to be assigned to custom fields; this would only be used in laying out the MatterDetails interface--essentially, any fields that have the same group name would be clustered together within a common region, possibly enclosed within a frame or other visible boundary. This would allow the presentation of such fields to be more organized (and allow the admins to adjust such presentation).

e) Allow for users to control the order in which custom fields are displayed on the MatterDetails interface. Right now, the custom fields are displayed in the same order as they are listed in the Settings page. In many cases, there may be related custom fields that are defined at different points in time and are thus separated from one another in the sequence of custom fields in the settings interface, with other, unrelated custom fields in between them. This fractured presentation is then replicated in the MatterDetails interface. Note that if (d) is implemented, then (i) the user should also be able to specify the order that groups are displayed in and (ii) the order specified for fields should be followed within each group with respect to the fields within that group, but should not override the groupings.

These would all be really helpful features to add and would make AppColl much more flexible for users.

@gregg_appcoll Hi Gregg, thanks for the quick response.

If you are going to expose the ClientContactContactID as a column, please also do so for other Contacts-based fields in Matters. That would be great!

For the Inventors, you're correct that the Inventors CSV export does include the ContactID for the inventors. This would work for our purposes. However, I don't think we have any way to automate getting that information out of AppColl, and that's critical.

Our current practice is to do a nightly FTP dump of our Matters, Tasks, and Contacts tables from AppColl via the Manage Report Schedules interface to take a daily snapshot of our AppColl data. We then import that data into a parallel database that we maintain internally and use for various internal systems.

I may be mistaken, but I don't think we have the option of selecting the Inventors or Connections report types from the Manage Report Schedules interface--we can only specify a named report that we've saved, and the Connections and Inventors "types" of download are special types of report that surface data that isn't visible in a named report but which is sourced from the records in that report.

If the Manage Report Schedules interface were to allow users to specify the "type" of report (I think only Matters, Inventions, Billing, and IDS modules have more than one "type" of report) that is to be scheduled, then I think this would allow us to access the data in the manner we need.

If that's already possible, please let me know how to go about setting it up!

Best,
Christian

Some of us use AppColl data outside of AppColl, and it would be extremely helpful if fields in Matter records that draw from Contacts were to have counterparts that listed the ContactID for the record(s) that they point to. For example, ClientContact could have a ClientContactContactID, Inventors could have an InventorsContactID (which would be either a single ID or a comma-separated list of IDs).

Right now, we have to match on name since that's the only identifier in the Matter record that can be used to match to a record in Contacts--but names can have duplicates, making it not always possible to find the correct Contact record.

Would it be possible to add those fields to Matters?

Cheers,
Christian

@BrandonK6644 You could very easily set up such task types--just use the existing ones as templates, update/rename them as needed, and start using them going forward instead of the vanilla Filed RCE. You'd have to manually select the appropriate one, of course.

Doing the same for OAs would be a little more challenging since they autodocket, but I think it could be done. You'd have to make some fancy database query triggers that would check to see if a prerequisite task (e.g., 1st OA) had docketed before triggering a 2nd OA task, and checking to make sure that no existing 2nd OA task was present. I think this can all be done in the current task framework--see example below.

First NFOA - Create "Respond to 1st Non-Final Office Action" task
When a specific task is created: "Receive non-final office action"
AND
While a task database query doesn't return any records: Matter = "{Task.Matter}" and TaskType.Contains("Respond to") and TaskType.Contains("Non-Final Office Action")

Second NFOA - Create "Respond to 2nd Non-Final Office Action" task
When a specific task is created: "Receive non-final office action"
AND
While a task database query returns one or more records: Matter = "{Task.Matter}" and TaskType = "Respond to 1st Non-Final Office Action"
AND
While a task database query doesn't return any records: Matter = "{Task.Matter}" and TaskType = "Respond to 2nd Non-Final Office Action"

And so forth for 3rd, 4th, etc. NFOAs (assuming you want that level of granularity).

NOTE: In order for this to work, the most recent previous NFOA task has to be correctly assigned since each subsequent task creation event looks for the "previous" task that should have been created according to the trigger rules. So you'd have to analyze your docket and at least update the most recent Respond to NFOA tasks to reflect their proper "number" before implementing the above rules.

As far as I know, there isn't a "While a task database query returns exactly X records" where you can specify X. If that existed, you could avoid having to back-update your tasks to the new format.

Cheers,
Christian

It would be nice if AppColl could provide a read-only field that was, in effect, a list of previous contacts that had a particular role with respect to a patent application, such as "Attorney" or "Paralegal." Sometimes, it becomes necessary to reassign matters to different individuals, e.g., due to someone leaving the firm or taking an extended leave (e.g., parental leave, sabbatical, etc.).

It would be nice to be able to filter matters based not just on who those matters presently list as attorney, paralegal, etc., but also who they previously listed in such roles. This could help with reversing those assignments at a later date if the previously assigned person returns to work at the firm.

For example, an "AttorneyHistory" field could store all attorneys that have been assigned to a matter, while ParalegalHistory could do the same for all paralegals that have been assigned to the matter. You could have ContributorHistory, PartnerHistory, and ClientContactHistory as well, but those likely aren't quite as immediately useful.

Otherwise, one has to either think ahead and export the previous assignments before updating them (so you can do a bulk reverse update if you want to restore the original assigned practitioner/paralegal) or parse through the Transaction History to identify all cases where the original assigned practitioner/paralegal was changed, and then craft a filter that identifies all of those matters by docket number (which could easily require multiple queries due to the filter string length limitations).