Posts made by ChristianS9906

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!

@BenjaminK4148 See earlier post on new field "EBD"....

https://forum.appcoll.com/topic/323/new-calculated-field-suggestion-ebd?_=1735673697072

@gregg_appcoll Hi Gregg, just wanted to check on this--is there an ETA on when this feature will be implemented? Ideally, it would be available this week or early next so that we have a little time before the new rules kick in in which to file CONs that might fall under the new fee schedule before it comes into effect.

@support_appcoll Any ETA on this feature/fix?

Every time I define columns for a new report, I end up spending more time re-ordering columns than selecting them, and it's pretty much all due to new columns being inserted above (in front of) the currently selected column instead of below it.

Seems like it would be a really easy fix--completely in the UI and not involving any schema updates or other back-end work.

@gregg_appcoll Thanks for responding, Gregg--the idea would be to ignore a) non-US priority apps and b) US provisionals for the purpose of calculating the EBD.

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

I have an IN provisional application where my docketing department inadvertently entered 1/10/2024 as a filing date; it has no Connections to any other application. The priority date changed to 1/10/2024 once the filing date was entered.

They then realized that they'd entered the wrong filing date and changed it to 1/11/2024 and saved the record. But the priority date didn't update to match.

If a priority connection is specified, then the priority date changes to match the earliest priority date of the "Connections" and is hard-coded; you can't change it.

The priority date not updating to match the filing date for applications that don't have priority connections seems like a bug. Although maybe there's some reason I'm not seeing for this behavior. The only one I can think of is if you maybe have to import a bunch of legacy matters into AppColl and want to have key date information but don't care about specifying the priority chain. But even if that were the case, it seems like maybe the default approach should be to update the priority date field to match the filing date when the filing date is edited....

Curious to hear if this is on purpose or a bug....

@MichaelVJ9199 What about the slash in patent app numbers? Remove that as well? When using Global Dossier, the application number field is badly designed--it only accepts up to 8 characters, so you have to manually delete commas and slashes from an app number when pasting in (and then add the last two digits). Having a "formatting-free" app number would be nice....

@GeorgeJ4336 If it ends up impacting you, I'm not wedded to my suggestion and wouldn't be crushed if AppColl changed it back.

We ended up hard-coding the client's intake address using the ClientRef we had for them, so our templates now automatically include it and we shouldn't need to copy-paste it any more (or at least, with much less frequency)....

@GeorgeJ4336 Thanks for the insight--for us, we actually don't use the email intake address for our own account--we prefer to save email in a different system. When we do use the intake address, it's always because a client uses AppColl and has asked us to use their intake address--so we never had to worry about them not knowing what it was/thinking it was funny, and I guess had no appreciation for how a more lengthy name might make it clearer to a client that it's a "legit" email address.

Although it seems like if you modify your email template to use: "X{Matter.AttorneyRef}@intake.appcoll.com" (where X is the prefix for your account), that would generally get you to a very similar place (an email address that has your docket number in it, which the client would hopefully see was the same as the docket number that I'm guessing is also in your subject line). You could also put a small note at the top of the template body of "Please CC X{Matter.AttorneyRef}@intake.appcoll.com to ensure communications are saved in our docketing system in association with this application."

@joe_appcoll Great, thanks!

How does AppColl handle it when it receives an email sent to the intake.appcoll.com domain that does not match any matter? I just deliberately sent a message to an incorrect intake address to see if it would bounce back, and so far, nothing's happening.

We are considering using the new intake address format for emails to clients that use AppColl, but the risk is that sometimes clients change their AttorneyRefs without telling us, resulting in our ClientRef not matching their AttorneyRef until the discrepancy is noticed and corrected. If we then generate and send an email to the client-side email intake address based on our firm-side (ClientRef) version of their AttorneyRef, it will not have a valid intake email address.

If an email sent to the intake address turns out to not be able to be matched to any AppColl matter for the specified customer account, it would be great if AppColl could send an email back to the sender alerting them to the issue--that would a) let them know that the email didn't get saved and b) prompt them to investigate and correct the issue that caused the problem....

Can this be done?

The new "secondary" email intake address opens some interesting possibilities for those of us who have clients who also use AppColl. For example, we can now relatively easily create a client-side intake email address based on information that we already store in our law firm-side AppColl dataset.

In our case, we have a custom field in our law firm-side AppColl that we use to store our clients' client-side intake email address. We have to manually add that address (or do occasional bulk imports) for those of our clients that are not willing to use the sync feature in order to populate this data. With the secondary email intake address, we could, in theory, construct the secondary email intake address on-the-fly, e.g.: "acctname{ClientRef}@intake.appcoll.com," based on data we already have (ClientRef).

There are two potential issues with this:

a) I don't know what happens if the client AttorneyRef (our ClientRef) is later changed--does the secondary email intake address change to match? I assume it must since you might otherwise have email go to the wrong matter (if a different matter is later opened with the retired AttorneyRef), but it would be nice to have confirmation of this.

b) Ideally, there'd be a field in the Client contact record that could be used to store the "acctname" data so that the address could be constructed completely dynamically. We could use an existing Contact field for that, but it would be nice if there was a dedicated field for this purpose.

Interesting possibilities.....

The left sidebar in the Matter Details view was recently revised to show both the "old" email intake address and the "new" email intake address. However, it now seems to truncate the email addresses and terminate them with an ellipsis. If you try and select the email address text and copy it, it is incomplete. You can right-click on the link and copy the complete email address from there, but it doesn't just copy the address--it copies the address plus the name/alias for the address (which is pretty useless and makes the address twice as long--see below). You can also just click the email address link to make a new email addressed to the address, but the email address also includes the alias and you then have to copy and paste it into the email you are drafting (if already in progress).

acctname1234567US@intake.appcoll.com
v.
AppColl_Matter_1234567USacctname1234567US@intake.appcoll.com

Could this be changed so that the mailto link that underpins these addresses does not include the alias and is just the bare email address?

Thanks,
Christian

Just checking on whether there's been any movement on this suggestion--it was made nearly a year ago, and the interface is unchanged. This seems like a relatively easy fix to make, and would be a nice quality-of-life enhancement....

Best,
Christian

When filtering Matters, it is not possible to select the PatentTermAdjustment as a filter condition. Can this be added?

I wasn't able to attend the webcast on the new module--my apologies if these features were addressed in the discussion (I did review the help files and didn't see mention of them, however).

Two features that would be good to have for this:

a) The ability to "force" use of non-stylized signatures when using DocuSign, i.e., do not allow "typed" signatures and require that a signature either be input directly using stylus or from a scan. Some jurisdictions allow for DocuSign-like signatures but require that the actual signature that is used for DocuSign be input by hand.

b) The ability to see what the current signature for a signatory will look like prior to sending out documents for signature. This would help identify signatures that may be undesirable so that the signatory can be contacted and asked to make corrections prior to sending out the document for signature. This would allow a document preparer to avoid scenarios like:

i) scanned signature is from a scan with a dark background (resulting in a dark rectangular block with a darker signature in it).

ii) scanned signature is upside down or rotated 90 degrees.

iii) scanned signature is too low quality (poor resolution or too faint).

iv) scanned signature is microscopic/very small when reproduced, making it illegible.

The above feature would be best combined with a system that lets potential signatories that aren't signed up with DocuSign be enrolled into DocuSign before they need to sign documents so that their signatures can be vetted ahead of time.

Just my two cents....

It would be nice to have an "archive" feature in AppColl--essentially, an archive AppColl account for each customer that stores record data separately from the customer's main account so that searches/reports done while in a customer's main account don't show the records in the archive account (and vice versa). Records could be moved back and forth between the two accounts by account holders.

This would, for example, allow records for disengaged clients or transferred-out files to be removed from the record pool of the main account, which would keep them from needing to be processed when generating reports. For example, right now nearly 20% of our matters and tasks have a transferred out status (a total of 70,000+ records); we would only need to look at them if their new stewards had a historical question about such an application. We could just delete these records, but prefer to keep them on-hand just in case.

Records in the archive account would not have auto-triggering--it would just be a static repository of records for archival purposes.

Seems like a potentially useful feature....