Posts made by SadiqA2304

The current {RespondBy} date does not take into account weekends and holidays. Under USPTO rules, if a due date for a response falls on a weekend or federal holiday, the due date is adjusted to the next non-holiday weekday. This is helpful when notifying clients of when things are due, so that we aren't telling our clients the (technically) wrong due date on things, and eliminates the need for us to manually go through and adjust these communications ourselves.

Example of the proposed behavior
Example Task 1
Respondby: Saturday, Feb, 28, 2026
AdjustedRespondBy: Monday, March 2, 2026

Example Task 2
Respondby: Tuesday, March 3, 2026
AdjustedRespondBy: Tuesday, March 3, 2026

@gregg_appcoll OK so to clarify, if I create a custom field "Test," configure the field for a contacts query, and set that field for a given Matter to a particular Contact, then {Matter.Test.email} will return that Contact's email address? How can I restrict the contact fields to match the current client? This is the logic I'm looking for but the syntax isn't quite right:

@gregg_appcoll I think this can work as a partial workaround, but it is orders of magnitude more complexity than simply allowing Contact objects to be matter fields. I'm also not sure what the ContactsQuery actually returns for the text box. Is it the name, email address, or what? I want to be able to separately use this contact's email address and first name, for example.

Currently we can add custom strings and dates to matters:

It would be helpful to be able to add custom contact objects to matters as well, which can be used as billing contacts, docketing contacts, etc.

The notifications for minor tasks such as saving a matter are not necessary and amount to spam:

I'd like to suggest that these types of events no longer trigger an attention-grabbing notification.

@ChristianS9906 said in Automated Customer Number Listing for eOffice Action processing:

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.

We are doing something similar (using excel instead of Word), but it's an extra step that feels a bit clunky.

Can we get this UI element updated in some way? Can Appcoll accept csv/excel import for this? A flat text box does not seem to be the optimal way to make sure we keep this up to date

Bumping this suggestion. Fixing this seems like low-hanging fruit and will help with the overall archaic look and feel of the UI.

Some clients want us to use their own internal references on all documents, such as RCEs, ADSs, transmittal letters, etc. Currently there is no option available for Appcoll to generate USPTO forms using ClientRef instead of AttorneyRef.

This also causes the "AttorneyRef" to get flagged every time there is a Patent Center update:

Being able to specify whether ClientRef or AttorneyRef gets used in automatically generated forms would save a lot of time and manual effort.

@BrandonK6644 Whoops, looks like I had the same idea, but a few weeks later https://forum.appcoll.com/topic/343/set-task-background-color-based-on-taskstatus?_=1748361445416

Currently we are able to set a task background color based on deadline type and due date:

It would be be helpful to be able to set the task background color based on other attributes such as TaskType or TaskStatus.

@support_appcoll Any movement on this?

@joe_appcoll Nice, thanks

Any movement on this suggestion? This would remove a recurring source of frustration if implemented.

@BrandonK6644 What is the difference in your suggestion vs. having client-specific transient tasks that themselves trigger billing items?

@ChristianS9906 I agree. For example, just got this today:

"review e-office action" and "review uspto communication" for the same item. No need for this.

@RichardS3059 Do you have form letters attached to automatically generated tasks that are triggered when an eOfficeAction is received?

@gregg_appcoll All first actions/notices of allowances on my account have this issue.

Automatically generated forms, which are triggered by USPTO eOffice Actions, may use out-of-date information in certain circumstances, such as first Office Actions.

In the initial stages after an application's initial filing, the USPTO has placeholder information is in the USPTO system such as "Docket Central" as the examiner and "OPAP" as the art unit. This information gets updated by the USPTO prior to the first Office Action being sent out.

As one (basic) example, I have an Office Action Response template that is generated when an Office Action is received. This template populates basic bibliographic information, such as title, inventor, examiner, art unit, etc. In the current implementation, Appcoll does not update the information in the Appcoll system before automatically generating documents; it uses whatever was in the system before. Appcoll updates its internal information after generating documents based on an eOfficeAction. On second and subsequent actions (with no examiner or AU change), this works fine. However, on first actions, it results in situations like Appcoll-generated form fields getting populated with the placeholder information such as "Docket Central" and "OPAP."

@GeorgeJ4336 For what it's worth, I have only ever used Appcoll email intake as a CC, and I would imagine this is the intended use

@scott_appcoll Is there any concern with ambiguity here? If I have a first matter with MATTER ID 1234 and I have a second matter with MATTER ID 4321 and ATTORNEYREF m1234, wouldn't they both get resolved by [AccountIntakeID]m1234@intake.appcoll.com?

@scott_appcoll Nice, I think this works. Can we get an option to choose the new format in appcoll-generated notification emails as well?

@scott_appcoll Thanks for adding this so quickly. As @GeorgeJ4336 said, can you provide an example of the new format? It may be helpful to provide (1) an email address following the old format and (2) an email address, for the same matter, following the new format

@BrandonK6644 I have made this request before as well. This is better than having Appcoll's internal matter codes (sequential matter number for your account) as a client-facing email address. The simplest way to implement it would probably be to add a mapping between what they already have, and the email address we desire. This could be done on a per-matter basis, and would need a code/differentiator between different accounts. Example implementation:

Friendly intake email address prefix for BrandonK's account: BK
Friendly intake email address prefix for SadiqA's account: SA
*Each account administrator may specify their own prefix via admin dashboard, so long as it is unique from all other account prefixes.

BrandonK's matter:
Attorney Ref: FOO123
Appcoll Matter ID: BrandonK001
Appcoll default intake email address (current implementation): BrandonK001@intake.appcoll.com
Friendly intake email address (default): BKFOO123@intake.appcoll.com
Friendly intake email address (customizable via Matters module UI; prefix is not changeable): BKpatent123@intake.appcoll.com

SadiqA's matter:
Attorney Ref: FOO123
Appcoll Matter ID: SadiqA001
Appcoll default intake email address: SadiqA001@intake.appcoll.com
Friendly intake email address (default): SAFOO123@intake.appcoll.com
Friendly intake email address (example customized address): SAmatter456@intake.appcoll.com

Emails to BKFOO123@intake.appcoll.com and BrandonK001@intake.appcoll.com are routed to BrandonK's "FOO123" matter

Emails to SAFOO123@intake.appcoll.com and SadiqA001@intake.appcoll.com are routed to SadiqA's "FOO123" matter

^ The client doesn't need to see the arbitrary Appcoll matter ID in the email fields; firm/account code is used to route emails to the correct account and matter, even if attorney docket number itself is ambiguous

@gregg_appcoll Thanks, looks like it's working. For Examiner names, I'm doing

{Matter.Examiner(ToTitleCase, AddPeriodToSingleCharacter)}

@gregg_appcoll Has this been added?

@gregg_appcoll These fields do not work correctly with two inventors. They populate as:

Inventor1, and Inventor2

There shouldn't be a comma here.

I've used "duplicate matter" and "multi-country duplicate" for adding a Continuation of a matter, and found that "multi-country duplicate" works a little better. Ideally, this would require fewer clicks than it already does in order to add a Continuation. One suggestion I had is, when "Utility: Continuation" (or similar) is selected, the same country as the parent should be auto-selected. Unless I'm missing something, "Continuation" of a parent application in the US for example would necessarily refer to a child application in the US.