Posts made by ChristianS9906

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

If AppColl is set up to process e-Office Actions, it will automatically create a "USPTO e-Office Action: XXXX" Event task type for each different e-Office Action document code XXXX that it processes. It will also create a corresponding Hard External Deadline "Review USPTO e-Office Action XXXX" task type for that newly created Event task type.

It would be nice if there was a way to let the account admin have more control over how this system works. In particular, it would be nice if a) the admin could make it so that newly generated "USPTO e-Office Action: XXXX" Event tasks are instead created as Transient Events by default and b) the admin could instruct AppColl to not make "Review USPTO e-Office Action XXXX" task types at all.

At present, 25% of our 760 different task types are e-Office Action-related task types (split evenly between the Event task types and the Review USPTO e-Office Action task types). We never use the Review USPTO e-Office Action tasks, and immediately disable auto-generation as soon as we detect a new version of such a task. It would be great if we could simply tell AppColl not to bother making such task types going forward.

For the USPTO e-Office Action Event tasks, we want them to trigger since they may be needed to trigger follow-on tasks, but we don't want them hanging around since they are just extra clutter--the event date, if important, is always reflected in the RefDate of a task triggered by such an event, so there is zero benefit to keeping the USPTO e-Office Action Event tasks around. In view of that, we always change them to Transient Event types. But when a new one gets created by AppColl, we have to go track it down and change it. It would be nice if we could have AppColl default to defining these as Transient Events instead of as Events.

We don't currently use the Billing module, but I am listening to the webinar on it right now. The ability to specify, on a client-by-client basis, what UTBMS billing codes are available for use, and to specify custom descriptions (with field code capability) that are used by default each time such a UTBMS code is selected, would be very useful.

We have multiple, large clients that use UTBMS codes in different ways (e.g., some use 430 for all office actions, while others use it only for non-final OAs and then use 435 for final OAs). We also have clients that expect specific language in the billing entry description for particular task codes, e.g., "{Matter.CountryCode} Request Examination Recommendation." They do not want us to deviate from this language. Our current billing system auto-fills it for us based on the UTBMS code selected.

It would also be ideal to have multiple entries for a given UTBMS code for a client--for example, the client might have different budgeting frameworks for the same UTBMS task code depending on complexity of the task. Ideally, each of these task codes could have an alias that the customer can specify to allow them to easily differentiate between each of several options for a given UTBMS code for a client.

There is the ability to export an AppColl Inventors (CSV) file for matters. The output file includes Matter, Inventor, AsFiled, and Rank as the fields.

I would like to request that it also include ContactID for the inventors listed. "Inventor" is not a unique record identifier, as different inventors can have the same names.

@gregg_appcoll Ah, thanks for clarifying. Might be worth including some parenthetical text below the "Empty Trash" button to indicate that it has this capability.

Looking forward to using it!

Best,
Christian

@ChristianS9906 How do you get to this interface? Our Trash doesn't have it--although I did just delete a bunch of records and it was noticeably faster--on the order of seconds instead of minutes.

If we can access the age-based drop-down that you show, that would pretty much do the trick for us, I think.

@support_appcoll Has there been any progress on this front? Trash has been piling up for another year, and it does not look like the Trash interface has changed at all--still no ability to filter trash items so that you can easily delete only items that were put in the trash prior to a specified date....

It would be helpful to have the inventor status listed or indicated in some way on the Matter Details interface. For example, when sending a draft application to inventors, it would be helpful to be able to see which inventors are active/inactive so that we can easily decide which inventors to include on distribution.

Right now, you can only see the inventor status information if you click on each individual inventor to inspect their additional details.

It would be great if users could have the ability to specify alternate column headings to be displayed in reports, i.e., aliases that, if present, would be displayed as the column header for a given field.

For example, clients often request that we send them reports of their docket data, but with column headers labeled in a certain way (for example, they want to see "XYZ Docket Number" instead of "ClientRef" or "OC Reference Number" instead of "AttorneyRef" or "Responsible Manager" instead of "ClientContact").

Ideally, we'd just create a report for this information and then set up an autoschedule to send it to the client on a specified timeframe...except that we can't because we need to first send it to someone in our firm who manually replaces the column headers with the desired column headers.

If this was implemented, I think it would be fine if those aliases are only shown in "Print" view, when the report is inserted into an email/form letter, and when the report is exported to PDF or CSV/Excel format. I don't see a strong need to see the aliases in the interactive GUI itself (although it might be nice).

Can this be implemented? It would really make reports much more useful for communicating information to clients.

Best,
Christian

I'd like to suggest a new deadline type: "Workflow." Workflow deadlines would be similar to "internal," but would have the ability to be caused to not be displayed in the Matter Details interface if completed (while still displaying other completed deadline types). Tasks with Workflow DeadlineTypes could also be turned on/off wholesale in the Matter Details interface, similar to "Internal" and "USPTO" tasks.

Tasks with Workflow DeadlineType would also be able to be edited by anyone regardless of their permission level.

The idea would be that users could use tasks with this DeadlineType to track various workflow stages, e.g., reported out to client, recommendation sent, response drafted, etc., and then close them out, thereby allowing workflow to be tracked internally. However, external deadlines and events would not be able to be edited except by users with Tasks edit permissions. This allows customers to tightly control access to mission-critical data, e.g., docket and bibliographic data, to their docketing departments while also allowing them to track workflow progress without needing to involve/burden their docketing departments.

Having the ability to screen out completed workflow tasks would allow fairly granular workflows without cluttering the Matter Details task interface with lots of completed workflow tasks....

Adding columns to a report is relatively easy--you get an interface with two listboxes--the left one lists all the fields that are not in the report, and the right one lists all the fields that are (in the order that those fields will appear from left to right). There are buttons to move a field from the left listbox to the right, and vice-versa.

HOWEVER, when you add a field to the listbox that lists the fields that are in the report, the newly added field is inserted ABOVE the currently selected field, and then the newly added field becomes the currently selected field. It should be inserted BELOW the currently selected field and then become the currently selected field.

In the current system, if you are going through a list of columns that you need to add to a report (and doing so in the order you want them to be in in the report), you need to, after adding each column, go back to the righthand listbox and click on the listbox entry one row down from the currently selected entry, and then go back to the lefthand listbox and select the next field to add. Or just add them all and then click a bunch more times to reorder the fields in the order you want them in.

The interface should be configured so that users can simply select the fields they want to add from the left side and add them in sequence, without needing to click in the righthand listbox at all.

@support_appcoll Has there been any movement on implementing this idea? It would be hugely useful to have the ability to define some custom fields for tasks.

For example, a field for "In IDS Database" to record whether an Office Action and its cited references have been added to the IDS database. Or "recommendation sent" to indicate that the client has been provided with a recommendation.

Christian

The Email button in the Matter Details screen is great. However, the way in which emails are created could use a little improvement. This would all be fairly straightforward to implement and would be a timesaver for users:

a) There are often situations where the email being generated lists the email address of the person who is generating the email. While having that email address in the email address fields is harmless, it is also completely unnecessary and needlessly consumes space in the mailto link that could be used for other purposes. This would be very simple to strip out.

b) There are also often situations where an email address may get double-included. For example, a client may have standing instructions to always CC a particular attorney in addition to the ClientContact on correspondence for all their matters (thus leading to that particular attorney's email address being hard-coded into a client-specific email template for that client), but that particular attorney is also the ClientContact for some matters. In the matters where that particular attorney is the ClientContact, their email address will appear twice. At the very least, it would be nice if AppColl could cleanse each of the TO and CC fields for dupes and remove them. If an email address appears in both the TO and CC fields, they could be either a) left in both fields or b) removed from one field, e.g., the CC field.

Christian

AppColl offers the ability for users who have Report creation permissions to make a report "Private", which is great. It would be really nice, however, if the Permissions manager in AppColl could have a setting that could give add/delete/modify Report privileges to a user but only for private reports. In other words, that user could add/delete/modify reports that they make, but not modify/delete reports that others have made. Moreover, any report made by such a user would automatically be a "private" report so that others cannot see it. Ideally, those permissions would extend through to the Manage Report Schedules as well, e.g., those users could manage schedules for their private reports, but NOT add/delete/modify schedules for other reports.

For example, we want our practitioners and secretaries to be able to make their own reports and schedule them to be sent to themselves (if desired), but we do not want them to be able to modify other reports, e.g., ones that sys admins have set up for general use by anyone in the firm. Right now, there isn't a happy middle ground that will let us do that. We have to give full report permissions to our users and just trust that they will not accidentally modify a report that they have no ownership of.

It would also be great if the "Reports" combo box in each module could have a toggle that lets the user flip between listing all reports, only private reports, and (possibly) public reports.

Cheers,
Christian

It would be nice if there was a way to easily pull or display more detailed info on all matter inventors from the Matter Details interface. For example, right now, it just shows you the name of each inventor. However, it would be really great if the interface could be updated to show (or optionally show) further info for each inventor, e.g., City/State/Country of residence, citizenship, assignee, and possibly other data (for example, a field that might show if they are ex-employees or active employees).

Most/all of the above info is actually very useful info to have on-hand when looking at a matter. For example, if any inventor is a resident of India, you would want to be able to easily figure that out so you can make sure to docket requesting an Indian foreign filing license. Similarly, if any inventor is a Greek citizen, you'd want to be able to easily detect that as well so you can make sure you file the first application in Greece. And if there are inventors that work for different entities/would assign to different entities, you'd want to know that up-front as well so that the proper assignments get generated.

Right now, the only ways to get all this info for the inventors in a matter are to:

a) Drill down inventor-by-inventor from the Matter Details screen. You have to click on each inventor's "View Contact" button, review the pop-up, and then close it. This technique does not let you see all of this info at once for all of the inventors. It also does not show all info for each inventor (although, to be fair, it does show most/all of the info I flagged above).

b) Create a form letter or email that has fields to show all this data, and then generate it. This is clunky/cumbersome.

c) Create a database query in Contacts module? I'm not even sure if you can do this. But even if you can, it would require leaving the Matter Details module for the Contacts module and then crafting a query. It should not require such steps to get easy access to this info.

I would propose that the Matter Details interface be updated to include a button below the "Add" button called "Summary" that, when clicked, would bring up a pop-up window that listed, in table form, all of the inventors, their as-filed names (if applicable), their citizenship, assignee/employer, city of residence, etc. Ideally, the listed data can be copied in table form and pasted in table form into other documents, e.g., Excel, Word, or Outlook. It would, in effect, act somewhat like the "View Contact" link, but for all inventors at once and showing the data in a table format.

And if you really wanted to gold-plate it, you could add the ability for any individual user to add/remove any column from the Contacts module to the table view and to change the column order as they see fit, similar to how users can modify the columns in the Contacts module itself. That would let users potentially add other fields to the display that might be relevant to them, e.g., a field like "Tags" that they maybe use to store indications of whether or not the inventor is an ex-employee or not, or perhaps "Private Notes" or "Nicknames" to provide more info on how to communicate with that inventor.

@ChristianS9906 After posting this, I noticed that task types now include a "deleted" task status that can be selected for the auto-close behavior. I initially thought that maybe AppColl would cause tasks with such status to automatically delete themselves when they auto-close (which would pretty much reach a similar end result to the above). But then I tested it, and it seems like all it does is close the task out as "deleted." The task sticks around, however.

AppColl includes a "Transient Event" DeadlineType that was created responsive to input I provided several years ago. A transient event is just like a normal event except that it comes into existence and then immediately deletes itself--however, it triggers any follow-on tasks that might be needed and sends out notifications associated with it prior to disappearing.

It would be very nice if the Tasks framework were to be updated so that any TaskType could be made to be "transient," i.e., made to self-delete once no longer "Open." For example, every TaskType definition could have a "Transient" (or "Delete Once Closed" if a more descriptive name is desired) setting, e.g., a checkbox, that can be checked for a TaskType if that TaskType is to self-destruct once closed out.

This would be a little different than how the existing Transient Event DeadlineType works in that non-Event TaskTypes with this setting enabled would not immediately self-delete, but would stay visible on the docket until closed out. However, the existing Transient Event DeadlineType should be implementable under this new framework as well, e.g., as a normal Event DeadlineType that has the "Transient" setting enabled--since Events are tasks that instantly complete themselves, the "transient"-enabled Event should work like the current Transient Event DeadlineType.

The benefit to having this setting is that it would allow for intermediate deadlines, e.g., reminder deadlines, to be auto-closed and then disappear from the docket, as opposed to cluttering it up in a "completed" state. We like to have our docket be relatively streamlined, e.g., free of low-value entries. An advance reminder of an upcoming foreign deadline, for example, is useful to have on the docket, but once that reminder is in the past, it really isn't something we need to keep seeing.... Being able to have it automatically clean itself off the docket would be a nice capability to have (and would save our docketing department time and effort).