Posts made by ChristianS9906

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

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