Posts made by ChristianS9906

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

The new Earliest Benefit Date (EBD) for some matters is incorrect. This is currently a calculated field and is correct in many cases. However, we have discovered that it is not being properly determined for cases that claim only partial priority to a prior case lineage. For example, application A has an EBD that is 6+ years ago. Application B is a CIP of application A and was filed 4 years ago but inherits application A's 6+ year old EBD. The applicant then decides to file application C, which claims priority to application B but avoids claiming priority to application A. The EBD for application C should be the filing date of application B. But AppColl calculates the EBD for application C to be the same as application A. Application A is not listed as a Connection for application C.

This should be fixed. At a minimum, the field should be made user-editable so that users can fix it if necessary.

I'm not sure what the upper end is on filename length in AppColl, but it would solve a lot of headaches if it could be limited to something reasonable. When files from AppColl are downloaded, there are often files that can't be extracted because the resulting path length exceeds the file system limitations of Windows.

For example, I just had to deal with a ZIP file download from AppColl in which an email had a filename that was 216 characters long. When coupled with the root folder and email path, the entire path length was 260 characters in length--when I tried to unzip in a temp folder, that threw it over the limit. I could unzip it into root drive, but I'd still have to then go find any file with a filename longer than the difference between 260 characters and the folder I ultimately intend to copy it to and then rename those files to something below that limit. It makes it very time-consuming to deal with moving files into our local file system, e.g., with transfers of matters.

Or maybe provide a way of letting users specify a max filename length for ZIP file creation and then renaming the files in the ZIP file so as to not exceed that specified filename length. That would probably be the lowest-impact way of addressing this. The source files in AppColl would have filenames that remain unchanged in this approach.

Sometimes users pick query conditions that result in extraordinarily long execution times. For example, there are some fields that are apparently very computationally expensive to determine, and if you happen to include one in a report query/filter/column selection, it can result in AppColl spinning its wheels for ridiculous amounts of time (I just did this and it's been processing/sitting there for 10+ minutes with no end in sight). While this is happening, the user is effectively locked out of AppColl in that browser.

Would it be possible to add a control/button/something to the various report modules that lets the user cancel execution of a submitted query and have AppColl either clear the filters completely, revert to the previous query run, or revert to some default query that is not computationally intensive? Such a feature would be really great to have.

@support_appcoll Great, thank you for the quick action on this--can you provide further details on how it works? For example:

a) What triggers it? From testing, it seems that if I create a Client contact record with a "new" customer number (one that is not in the Admin eOffice Action settings list) or change an existing customer number for an existing Client contact record to a "new" customer number, AppColl generates an email that says "AppColl Warning - e-Office Not Enabled for USPTO Customer Number" in the subject line.
- Will it trigger if a client contact record lists a customer number that is in the admin customer number list but is then removed from that list? It doesn't seem like it does based on a test I just did--but that would be good to have as well.

b) How often is it sent out? Just once when the triggering Client contact record is saved? Or will the warning email continue to be sent out periodically, e.g., first of the month?

Thanks!
Christian

@SadiqA2304 100% agreed. It really should be a table view where a customer number can be added/removed without potentially modifying any other customer numbers already added. The table view could also list the client contact record(s) listing that customer number so that it's easier to understand what numbers are listed. The table view could be sortable by customer number / client.

We have 52 customer numbers for our account, so the current textbox control format really doesn't work well for interacting with/editing the list--we have to copy its contents into Word, edit it there, and then copy back the entire list into AppColl.

AppColl automatically determines the expiration dates for provisionals and US design apps, but not for any other types of application. PCTs are relatively straightforward--would be nice if AppColl could automatically determine them as well.

I'm envisioning a user/admin setting that has a drop-down menu that allows selection between: manual, 30 months, 31 months, 32 months, and 34 months. Manual would be the default and would make AppColl perform as it does now, i.e., no automated PCT expiration date determination.

The others would cause the expiration dates for PCTs without expiration dates to be determined based on the indicated month offset from their priority dates. Or maybe they don't touch existing PCT apps, but when a PCT app gets a priority date going forward (or has one that changes), the selected month offset is used to automatically determine the expiration date. If a user wants to back-fill expiration dates for existing PCTs, maybe they do that with a bulk update.

Cheers,
Christian

@gregg_appcoll I would suggest the following:

a) Account admin(s) (this should be the minimum!)
b) The partner(s) listed for matters that have the client with the customer number.
c) The paralegal(s) listed for matters that have the client with the customer number.

However, (b) and (c) would be contingent on how this is implemented. For example, the client contact record (with CN) would usually be created before any matters are created for that client, so there might not be any partners/paralegals for (b) and (c) when the CN comes into existence, and thus nobody to send to for (b) and (c).

But if the warning emails are sent out on initial contact creation/CN addition to a contact and then re-sent on a recurring periodic basis, e.g., once a month, then (b) and (c) would probably work.

It might also be good to have a way to enter a customer number into an AppColl contact record in a way that does not trigger the warning email. I haven't quite figured out the scenario where this would be needed*, but it seems potentially worth it to include as a feature. For example, if a customer number is preceded by an underscore, e.g., _12345, in the Contact record, assume that's definitely not a customer number that needs to potentially have the warning email sent out.

*Potential Scenarios
Client leaves firm and takes us off customer number; we could a) still leave the customer number in our eOffice Action settings to avoid triggering the warning email or b) delete the customer number from the eOffice Action settings and the client contact record. Option (a) might cause an issue if our continued listing of the customer number in the settings prevents another firm from being able to add the customer number without AppColl support involvement. Option (b) would mean we'd have to delete the customer number from our Contact record, but we might want to retain it.

@gregg_appcoll That would be a great start--please don't wait too long to add the ability to list specific recipients, however. It would also be useful to allow the admins to specify the subject line for such emails to increase the chances that it will be noticed/acted on.

Thanks!
Christian

@gregg_appcoll Understood about the privacy issues--if the addendum feature could be added, that would be great and honestly seems like it would address most of the issues.

Ideally it would be implemented in a way that allowed for admins to specify one or more individuals that should receive the email warning, and to specify when it was sent (it would be great it if it could be a) when a contact record with an unlisted customer number is saved and b) on a regular scheduled basis, e.g., on the 1st of each month).

Although, it seems like the automated approach could be implemented, but with a check to make it so that if there are two accounts listing the same customer number, then permission is sought from the first before authorizing the second. I mean, if I enter another customer's customer number into the settings page and save it, it's still there, right? You just don't enable it until permission is granted?

@SadiqA2304 Good idea--to add onto this, it would be nice to be able to, on a per-client basis, specify the field(s) to use for "Attorney Docket Number" in USPTO forms.

For example, as you originally suggested, some clients might want their own docket number used.

However, our firm often uses both, e.g., "{Matter.AttorneyRef}/{Matter.ClientRef}"

It would be nice to be able to specify a client-specific field string to use when inserting Attorney Docket Number into USPTO forms. Ideally, it would not be limited to just the AttorneyRef and ClientRef fields, and would allow additional plaintext characters to be included (like "/") as separators.

Ideally, there would be two such fields available for each client--the primary one and a backup one that is used if the primary one would result in a text string that exceeds 25 characters in length (the longest docket number permitted by the USPTO). We've had instances where including both our own and our client's docket numbers have exceeded 25 characters, so having a shorter backup version would be useful.

If no client-specific field codes are provided, then it would simply default to AttorneyRef.

USPTO Differences would be changed to check to see if the USPTO Attorney Docket Number matches the text that would be generated from the client-specific field code(s) that are specified; if not, then flag it as needing review.

Right now, you have to enter each customer number for which you wish to have eOffice Action processing performed in a special field in AppColl settings/matters (for some reason, this field is only a small text box that shows only the first four numbers, although it seems to store many more).

When doing client intake, it's an easy thing to forget adding the new client's customer number to this setting, which means that even though AppColl might be receiving eOffice Actions for the new client's matters via eofficeaction@appcoll.com, they won't get processed by AppColl. In fact, I don't think AppColl even warns you when this happens (unlike when it has issues processing an eOffice Action for a customer number that it is set up to monitor--in which case it sends an "AppColl e-Office Action Processing Failed" email). If it's not noticed, it could be a disaster if correspondence is missed and rights are lost.

My suggestion is to make AppColl automatically process eOffice Actions for any customer number that is listed in a record in the Contacts module having a "Client" role. This could be fine-tuned to only use customer numbers listed in the Contacts module for Clients that have at least one non-transferred/non-closed matter.

This could either be made the default way that AppColl performs eOffice Action processing or could be a setting that an Admin could enable, e.g., "Perform eOffice Action processing for eOffice Actions received from any customer number for any client in the Contacts module."

Customer numbers are almost always added to client records so that they will populate into USPTO forms, like the ADS, so this would be an almost foolproof way of avoiding the issue noted above.....

ADDENDUM: At the very least, if the above is not possible, there should be the ability to email designated users (admins or specific people) any time a contact record is created that has a customer number listed that is not in the eOffice Action customer number admin setting and to have the ability to have that email re-sent on a periodic basis, e.g., first of the month. This would at least give warning to administrators that a customer number might need to be added.

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?

@BruceY9495 I'm curious as well--it was supposed to have been instituted end of last week.

For the official filing date field, have you been manually updating it with the EBD all these years? I can't recall if it auto-populates, but if it does, it's only doing it for national stage applications.

If you have, good foresight!

@LawrenceL6000 If you have the EBD field available, I think users can define whatever task/timing they want based on that field to flag when you might want to consider filing a CON/DIV to avoid the fees. The EBD is the only thing that we, as users, cannot handle on our own--needs a backend calculation.

@gregg_appcoll Hi Gregg, just had the opportunity to use it--works great, and man is it a nice update. Thank you again!

Christian

@gregg_appcoll Thanks, Gregg--looking forward to it!