Posts made by ChristianS9906

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!

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