Best posts made by ChristianS9906

The Review USPTO Differences task/yellow triangular warning is very useful, but it is also very cumbersome--I would like to ask if it can be made "smarter." In particular, I would like to suggest that it be modified so that if a flagged difference is reviewed and the user selects "Ignore" (or maybe make a new button that is "Ignore Forever"), then any future instance for that matter in which that same discrepancy is found will also be ignored.

We are faced with the situation where almost every time we PAIR scrape a matter, we get USPTO differences--and we spend an inordinate amount of time revisiting the same issues over and over and over.

For example, our docket numbers almost never actually align with what the USPTO has because we use our docket number + our client's docket number in PAIR (clients want us to do this, particularly on shared customer numbers--I'm sure we are not alone in this).

Another example is with PCT priority connections--we store the full PCT serial number in AppColl, e.g., PCT/US2015/012345, while the USPTO (for reasons I cannot fathom) stores the same serial number in the abbreviated form as PCT/US15/12345. These are identical serial numbers, but get repeatedly flagged as being "discrepancies"--every time AppColl flags these, we have to go through the process of reviewing and re-ignoring this discrepancy.

A third example is with Examiner names--the USPTO uses first name, middle initial with no period, LAST IN ALL CAPS. We use first, middle initial with period, last in normal caps. These seem to get flagged every time as well.

If the USPTO discrepancies feature/task weren't so useful, we'd likely turn off the task since it generates a massive amount of tedious work that we have to repeatedly do every time there's a PAIR scrape for a matter. If AppColl could be modified to make some sort of "whitelist" table (akin to the Contact "aliases" field) for each matter that stored each "ignored" value and then did not flag that value again if it showed up in a subsequent scrape for that matter, it would make this feature SOOOOOOO much better/more useful.

Can this be done?

AppColl has a "Trash" that deleted items get sent to; items in the Trash can be selectively undeleted if desired. The trash can also be emptied to permanently delete items.

However, there are some aspects of trash that could be vastly improved:

a) For the love of God, make deleting trash items a background task. Right now, if you delete items, you can expect to wait ~3+ minutes/1000 items, and the poor schmuck doing it can't really do anything else in AppColl while the deleting is occurring.

b) The trash should be able to be filtered. For example, I'd like to be able to delete all items in the trash that are more than a month old, but the only way to do that is to go through every page of trash items more than a month old, select all items, and then delete them. At 120 pages of trash items, I'm looking at a minimum of six hours spent doing this, with me having to interact with the system every 3 minutes.

c) Add a setting that lets admins specify a default "permanently delete" age where AppColl automatically permanently deletes items in the trash that are over X days old.

And a minor quibble:

d) There are two buttons: "Permanently Delete" and "Empty Trash." They do the same thing, except that the former only deletes the items that are selected and the latter deletes ALL items in the trash. Maybe they should be relabeled "Permanently Delete Selected Items" and "Permanently Delete ALL Items."

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

It would be great if users could be given the ability to specify "aliases" to use for column names in a report. These could be displayed in addition to the "normal" column names (or not at all) when viewing the report in AppColl, but if the report is emailed to someone, exported to CSV/PDF, etc., the aliases would be used for the column names instead of the AppColl field names.

Thus, for example, if one sets up a Task report that is intended to be sent to client DeltaCorp on a recurring basis, the "Matter.ClientRef" column could be set up to be labeled "Delta Ref." instead, and the "RefDate" column labeled as "Mail Date," and the Matter.CountryCode column labeled as "Ctry.," and so forth. In that last example, it would allow the report to be much more compact since the column header of "Matter.CountryCode" is much wider than the 2-letter country codes that would be listed under it.

Such a feature would significantly improve the Reports function and eliminate repetitive reformatting/relabeling of the report columns prior to sending such reports to clients.

These aliases, of course, would be cosmetic and would not be usable as filter conditions--it might be nice to display them in AppColl's on-screen displays of reports that use them, but I could also see implementing the feature so that the aliases only appear in the report once it "leaves" AppColl.

@joe-appcoll-com
Yes--add:

a) the ability to allow the admin for account receiving the sync to review what fields are in the sync report and, for each such field, designate which field in the receiving account's database the sync report field will be imported into (including giving the admin the ability to direct that the synced field NOT be imported into any field in the database of the receiving account). This will vastly improve the Sync feature since it will allow users to map imports between different fields, e.g., law firm uses "AttorneyRef" to store their docket number and ClientRef to store client's docket number, while client uses "ClientRef" to store law firm's docket number and "AttorneyRef" to store their own docket number. It should be possible for either party to set up a Sync of either field and have the receiving party direct that Sync to the field that stores that same data--even if they are different field names in each account.

b) disable any new or modified sync into an account until (a) has been done--this avoids potential catastrophe that may occur if a sync is set up and the underlying report for it is then modified and ends up overwriting data in the recipient's account that was not supposed to be synced.

I suggested this to AppColl directly earlier and know this is being worked on, but figured I'd float here to get feedback from others.

Cheers,
Christian

It would be nice if there was a single form letter field that could be used to add all inventors to an email's TO line. Right now, if you want to add all inventors to an email generated within AppColl, you have to use this:

{Matter.Inventor1.Email};{Matter.Inventor2.Email};{Matter.Inventor3.Email};{Matter.Inventor4.Email};{Matter.Inventor5.Email};{Matter.Inventor6.Email};{Matter.Inventor7.Email};{Matter.Inventor8.Email};{Matter.Inventor9.Email};{Matter.Inventor10.Email};{Matter.Inventor11.Email};{Matter.Inventor12.Email};{Matter.Inventor13.Email};{Matter.Inventor14.Email};{Matter.Inventor15.Email};{Matter.Inventor16.Email};{Matter.Inventor17.Email};{Matter.Inventor18.Email};{Matter.Inventor19.Email};{Matter.Inventor20.Email}

And if you have more than 20 inventors (god forbid!), you're out of luck.

It would be really nice if AppColl just had a field like:

{Matter.Inventors.Email}

...that would add emails for all the inventors to the form letter/email template (separated by semicolons).

This somewhat aligns with another suggestion made on May 13, 2022, for a field like {InventorFirstNames}, which would concatenate a string of inventor first names together (and add commas and "and" where appropriate).

Cheers,
Christian

The new chat-style Discussion feature is great! We are looking forward to using it. A few suggestions for improving it:

a) Make the chat-style Discussions be accessible via fields in Reports and Email/Form Letters. When this is done, please make it so that there are not double or triple carriage returns between each line, as that will make the data take up much more space. (This is done; thanks!)

b) Make the chat-style Comments for Tasks be visible in the table Task View of Matter Details as a column. (This is also done; thanks again!)

c) Create a feature that allows for bulk and/or automated deletion of Comments. For example, it would be nice to give Admins the ability to run a Matter report and then have a button that allows the Admin to delete all Comments for all of the Matters (and, optionally, Tasks in those Matters) listed in the report without needing to go into each matter/task and individually delete every comment, which seems to be the only way to get rid of them now.... (NOTE: The ability to exclude the chat-style Comments from the transaction log is noted and welcome).

Cheers,
Christian

It would be a very nice feature if there were an "AdjustedExpirationDate" field that was simply the ExpirationDate field + PTA. This would not be user editable; it would be calculated based on whatever was entered into the ExpirationDate and PTA fields.

Right now, AppColl automatically changes the "Status" of "Issued" patents to "Expired" when the expiration date is reached. However, patents with PTA do not expire on their expiration date, they expire later. This can be very problematic, as if a report having the application status is generated from AppColl and provided to, for example, CPI or some other annuity service, it will incorrectly tell the annuity service that an application is expired when it is actually not. This may cause the annuity service to assume that maintenance fees no longer need to be paid, and the service will no longer request payment instructions for it.

This is problematic when trying to generate a report, for example, of all patents that may have maintenance fees that need to be paid. You'd want to include all patents with "Issued" status, but also all patents with "Expired" status that still had PTA left. Unfortunately, there is no easy way to do this right now. If the AdjustedExpirationDate field existed, we could simply filter on all patents with Issued status OR Expired status with AdjustedExpirationDate > today.

The only other option is to manually edit the ExpirationDate field to include the PTA, but that would be non-preferred since it introduces a constant risk of user error and is difficult to easily verify as being correct.

In a perfect world, the AdjustedExpirationDate would also reflect the effects of any terminal disclaimers that might have been filed--although this would be much more complicated to determine. It might be best to have another calculated field for "TDExpirationDate" that reflects this modified expiration date.

It would also be nice if the auto-change from "Issued" to "Expired" were to be based on the AdjustedExpirationDate instead of the ExpirationDate. That would be much more accurate and much less likely to lead a user to inadvertently miss a patent that was still active due to PTA. This should be the default behavior, or at least a setting that admins can select.

Can this be done?

AppColl allows admins to define custom fields (would be nice to have a few more of those!). Those fields are shown above the Notes field and below the Connections and Inventors field. Custom date fields are shown in a column to the right, and all other custom fields in a column to the left. There is the ability to re-order the fields within each column.

What would be really nice (and admittedly pretty challenging to pull off, I bet) is to give admins the ability to change where custom fields are located in the Matter details interface. For example, let's say that I create a "TD_Date" field that is intended to record the expiration date of a patent subject to terminal disclaimer--I'd probably want that info to be up near the "expiration date" field. Similarly, if I have a custom field of "ClientAdmin" to that is intended to record which client paralegal/secretary is assigned to a given matter, I'd probably want that to be just below "ClientContact" in the GUI.

It would be really neat if AppColl offered this flexibility.....

Cheers,
Christian

The PatentTermAdjustment field is (I think) only shown for applications that have the United States as Country. However, China is implementing a PTA-like system and PTA will thus be a datapoint that needs to be entered for Chinese patent applications.

It appears that other countries offer PTA as well, including, for example:

South Korea
Singapore
Nicaragua
Honduras
Guatemala
El Salvador
Dominican Republic
Costa Rica
Colombia
Chile

The PTA field should, I think, just be made available globally.

Cheers,
Christian

AppColl currently allows for a decent number of "custom fields" to be specified for Matters. It would be nice if AppColl also allowed users to specify some custom fields for tasks as well.

For example, users might want to have fields for:

Deadline for recommendation
Number of extensions available
Countries in which to validate in
Etc.

I think it could be a relatively small number of such fields--hard to imagine needing as many as for Matters.

Christian

@JasonP2345 I also agree, but with a caveat--once a task is closed out, then the owner should not change dynamically. Or there should be a way to choose whether or not the owner should be updated dynamically for closed-out tasks.

Closed-out tasks are historical records, indicating how a task was closed out, who was responsible for it when it was closed out, etc. Having that data change when a matter is reassigned to a new attorney or other contact could lead to misunderstandings as to who did what later.

Open tasks, however, are the responsibility of whoever they are assigned to, and it makes sense to update those to reflect whoever is assigned to a particular role for a matter when matter contacts are updated.

Otherwise, I agree that this would be a very useful feature. Right now, we have to manually bulk update all tasks to have new owners when we reassign matters. It is a drag.

Christian

It would be helpful if AppColl could provide statistics on report usage, e.g., a way to see how many times a given report was run by users within a given timeframe (or several time frames, e.g., within last month, within last 3 months, within last 6 months, within last 12 months, lifetime).

Ideally, these statistics would reflect only incidents where reports were generated manually by a user (as opposed to auto-scheduled emailed reports). However, it might be nice to have both types of report usage tracked and available for review by users/admins.

This would allow admins/users to periodically review their reports and make more informed decisions as to whether to retire reports that are infrequently used. As the system currently stands, we're finding there are lots and lots of reports that have been generated over the years and we have little idea which actually get used on a regular basis. Having that info on hand would make it easier to figure out which ones spark joy and which can be tidied up.

It would be really great if task notification emails could be set up to be triggerable based on task metadata. For example, it would be great if a notification for a task could be set up to only be sent out if the Matter.Client was a particular client or if Matter.CountryCode = "CN"--you get the idea. This would allow a single task to have multiple potential notifications that could be sent out in the alternative based on matter-specific data.

The only way to do this now is to either:

a) Have multiple separate tasks, each with its own set of notifications that are tailored to a particular metadata condition. However, this results in having different tasks for different clients/countries/etc., which is confusing on the docket and makes it very cumbersome to manage how tasks trigger (for example, if you have 10 different flavors of what is the same task (except for the notifications), you'd have to revise 10 separate tasks if there was any revision needed, e.g., to task triggering.

b) Have (b), but make them each a transient task that triggers off a common task type. Each transient task would only trigger off that common task type if certain other conditions were met, e.g., if the common task was in a particular client's docket or in a matter in a particular jurisdiction. The transient tasks would have the customized notifications. However, this still results in potentially a large number of different task types--we already have 600+ task types, and we'd like to avoid having hundreds more that are just there to provide different notifications....

Cheers,
Christian

Windows has a somewhat arbitrary (and aggravatingly pointless--NTFS can support filenames of thousands of characters!) limit on path and file name length that causes all sorts of issues with files downloaded from AppColl's Files module. This is particularly problematic due to the way that AppColl names email files, which are automatically assigned a name starting with a 23-character timestamp, followed by the email address of the sender, followed by the entire subject line of the email.

This can easily result in emails that have filenames of 200+ characters, 25% of which are consumed by the timestamp and sender email address. This wrecks havoc with Windows' default filename length (260 characters?). For example, I tried to access a ZIP file of files downloaded from a matter today and found that the only way I could extract the ZIP file was to put it in a folder named "1" in my root directory and then rename the ZIP file to 2.zip before extracting it. This resulted in filenames/paths that were short enough to allow all of the files to successfully extract, but it is cumbersome--for example, one would then need to go through and rename all of the too-long files to shorten them if they are to be copied to some more useful location.

It would be great if AppColl gave users the option to specify a max path/filename length for files to have when downloading documents/files from AppColl. For example, provide a pop-up when a user clicks the Download ZIP File button that allows a user to specify a character limit (it can be set to only allow numbers within a certain range to be specified). If a number is entered, then all files being added to the ZIP file would have their path+filenames+zipfile name truncated to be no longer than the specified length as they are added to the ZIP file (the filenames in AppColl would stay the same). If no number is specified, then no truncation would occur. Truncated names that would result in duplicate names could have [XXX] added to the end, with zero-padded sequential numbers replacing the XXX.

This would allow users to specify a max length that was compatible with wherever that ZIP file is going to be placed, allowing it to be successfully extracted once in the destination location.

An alternative/supplemental feature to this would be to have a text input box instead of (or in addition to) the length input control; the user could copy and paste the destination path in that text input box, and AppColl could simply count the character length of it and then automatically adjust the filename length to meet the requirements of Windows.

Cheers,
Christian

@GreggH8509 I think Tar's original idea would provide usefulness beyond what the transient task approach would. For example, it might be that a particular matter has certain sensitivities, e.g., requires special handling (perhaps due to a licensee's requirements, litigation considerations, etc.), and having it so that there was a pop-up that came up if you ever brought that matter's matter details up could put it front-and-center to the user that there is something important about the case....

To that end, it might also be useful to have a "private notes" field for both tasks and matters (like exists for Contact records) that could be used to store such info. "Notes" could be used to store more verbose info, e.g., text from client emails, etc., whereas "Private Notes" could be used to store more concise info, e.g., "MATTER SUBJECT TO LITIGATION HOLD" or "CLIENT MUST PREPAY" that could be popped up in the pop-up that Tar mentions.

AppColl allows you to create form-filled USPTO forms for a matter; you can also create form-filled copies of such forms for multiple matters relatively easily from the Matters module. It would, however, be great if one could (for at least certain forms), give the user the option to specify how fields in that form that are NOT fillable from AppColl data are to be filled in.

For example, the AIA/122, AIA/123, AIA/83, and SB/123 forms (and there may be others) all relate to changing the address for a patent or application. Take the AIA/123 form, which is used to switch the correspondence/maintenance fee notice address--you need to provide either (a) a customer number that has the new address or (b) separately specify the name/address/telephone/email of the new addressee. It would be really great if AppColl gave you the chance to enter data for the fields in (b) prior to generating the PDFs, and then populated those fields in the generated PDF with that data.

For example, we recently had to transfer files back to a client (with no successor counsel arranged) and file change of correspondence address forms for 30 different patents. All of them had the information in (b) specified to be the same, and we had to copy-paste that info (which involved copying the data for 8 fields into all 30 forms--240 copy-pastes!) to finish the forms. It would have been a huge time-saver if we could have supplied that info up-front and had AppColl populate it when it populated the matter-specific data.

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

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

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

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

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

@gregg_appcoll Hi Gregg, just had the opportunity to use it--works great, and man is it a nice update. Thank you again!

Christian

Depending on the situation, you could modify the TaskType definition to change the task in question to a "Transient Event"--this causes the task to be auto-generated, thereby allowing it to trigger follow-on tasks and/or send out notifications. But the Transient task will then self-destruct immediately after that and will not appear on your docket. For example, we have our AppColl setup such that all "USPTO e-Office Action: ...." tasks are transient events--they trigger any deadlines they need to trigger and then they vanish.

You can also just turn off or modify auto-docketing for tasks that you find are not useful at all. For example, we turned off the "Review USPTO Communication" triggering completely (actually, we deleted whatever triggers it had). We manually docket it when there is something peculiar needing review, but it otherwise doesn't bother anyone.

This relates to some recent suggestions regarding an InventorEmails field (https://forum.appcoll.com/topic/134/new-field-request-inventoremails?_=1663947413348); it might be a more flexible way to get to the same result that could be extended to other fields.

Some contact fields for a matter are actually lists. These include the inventors, applicant(s), and licensee(s). In each case, the contact record(s) that are listed have their own fields. It is sometimes the case that users want to be able to make a list of the contact(s) for those fields, but break out the data for specific fields for each contact within the list. For example, we have a document that we provide to our foreign associates that lists, for each inventor:

<LAST NAME>, <First name> <Middle name>, Citizenship: <Citizenship>
<StreetAddress>,
<City>, <State> <ZIP>
<Country>
<ForeignNickname>

All of this info is provided (if available) for a given inventor before the next inventor is listed. Right now, our template for this is 7800 characters long since we have to essentially create 20 separate field blocks, one for each InventorX (where X is a number from 1 to 20). The format of these blocks is identical, except that "Matter.Inventor1" in every field within the first block gets changed to "Matter.Inventor2" in the second block, and so forth.

What would be great is if there were a Form letter/email syntax that would let a user define a block of text with fields and then bracket it within some sort of syntax block that causes AppColl to replicate the field data in that block that derives from an item in a list for each item in that list.

For example:

{Matter.Inventors.List({MATTER.INVENTORX.LAST}{+032MATTER.INVENTORX.SUFFIX}{+044+032Matter.InventorX.First}{+032Matter.InventorX.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.InventorX.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.InventorX.ForeignNickname}{+013+010Matter.InventorX.Address})}

This would cause AppColl to, for each inventor listed for a matter, generate a text block per the above string.

This syntax could be really useful, I think. You could use it to insert emails for all inventors into an email, e.g.:

{Matter.Inventors.List({Matter.InventorX.EmailAddress}+059**)}**

There could even be a variant of this that adds an additional feature of making a punctuated list, e.g., with commas inserted between blocks (if more than two items in the list) and an " and " inserted before the last item (if more than one item in the list). The syntax for this could be like:

Dear {Matter.Inventors.PunctuatedList({Matter.InventorX.Prefix+032}{Matter.InventorX.Last})}

Which might generate a list like:

Dear Mr. Smith, Mrs. Doe, and Dr. Strange,

This would really enhance form letters/emails.

AppColl determines the priority claim type for each priority connection in an application based on what the application Type is of that application. For multi-tier priority claims, each priority claim type is determined based on what the application Type was that first made that priority claim.

This works well for many applications and is generally painless for users. However, it is completely unable to handle complex priority claims in which an application might simultaneously make two or more different types of priority claim to different parent applications. For example, mixed direct CIP and CON priority claims are simply not able to be recognized/specified in AppColl. If you call the application a continuation, then AppColl assumes both priority claims are continuation priority claims. If you call it a CIP, then AppColl assumes both priority claims are CIPs. In reality, it has one CON priority claim and one CIP priority claim.

This is potentially dangerous since AppColl populates the ADS based on what it thinks the priority claim is. If the user generates the ADS and then fails to modify it to correct the incorrect priority claims that AppColl provided, they will submit a priority claim that may be specified incorrectly, thereby jeopardizing it.

Users should have the ability to specify, for each priority claim, what the priority claim type is--it should not be tied to the Type of the application that is making the priority claim. The user-specified priority claim type is what should govern in ADS creation and in other parts of AppColl that show priority claim data.

Hi Melissa,

Interesting question/suggestion--I doubt that the current framework can support this since the "Excel" export is just a CSV format. Maybe after we get "real" XLSX support. : )

I did find one way to do what you are asking, however. It is a little kludgy but seems to work.

a) Make a report with the Images column + other columns you want.
b) Export that report to PDF. It should show the images in table format.
c) Using Adobe Acrobat (other PDF software might work as well), convert the PDF report into an Excel spreadsheet.
d) Open the converted document in Excel. Select all cells in the table and un-merge them (on Home, Alignment ribbon tab). This is important; you won't be able to sort the table at all unless you do it. And if you copy/paste into Word, you'll never be able to find the merged cells in the Word table.
e) Select one of the images in your Excel table; then hit CTRL-A to select all of them.
f) Right-click one of the images you've selected and select "Size and Properties..."
g) In the sidebar that appears, expand "Properies" and select "Move and size with cells" or "Move but don't size with cells." You'll want to experiment to see which you prefer.
h) Select the entire range of data and then go to Home...Sort & Filter and select "Filter" to turn it into a sortable table.

Word is actually a better choice for this, I think, since a Word table will let you sort it but will also retain the row heights for the sorted rows, thereby preserving the appearance of each row in the sorted table.

Cheers,
Christian

When you generate an email template, the Send Email pop-up that allows you to choose which email template to create has two radio buttons for "Use local email client" and "Use AppColl." By default, "Use local email client" is selected. However, if the selected email template is greater than 2K in size, "Use AppColl" is selected by default.

It would be nice if the decision as to which option to select by default was sensitive to the browser being used. For example, Chrome and Edge both have low limits (I think in the 2K range) for mailto links, so if the user selects a template that will result in >2K message length, it makes sense in those browsers to flip the default selection for editor to "AppColl."

However, Firefox seems to allow for much longer mailto lengths, e.g., messages up to 24K characters in length. It would be nice if the threshold for switching to "use AppColl" was made different for Firefox than Chrome or Edge so that you don't need to switch back to "use local email client" each time you want to create an email using a greater-than-2K email template in Firefox.

Cheers,
Christian

@AnnM9156 You'd have to make special TaskTypes for that, e.g., "Respond to Non-Final Office Action (Track One)" that was a non-extendable deadline that triggers in place of the normal extendable one.

Or, and this is likely simpler, just have a "Track One Deadline" task that auto-dockets based on the triggering task respondby date and have it trigger whenever a Track One application dockets an initial Respond to Missing Parts/Restriction/Office Action deadline. That should about cover it. You'll have that on your docket to remind you that the normal response is subject to special timing considerations.

You can also include the Matter.FastTrack field included on docket reports; it will list if the matter is Track One.

Minor UI suggestion....

In many interfaces in AppColl where you can review/edit the details of a particular records, e.g., Matter Details, Task Details, Task Type Definitions, Contact Details, etc., there are blue forward/back triangle buttons that bracket the record name at the top of the interface, just underneath the modules tab selector. These let you advance to the next record or previous record without having to navigate back to the list of records and select the next or previous record from the list.

These are nice buttons to have, but they are, unfortunately, dynamically positioned based on the length of the text in between them (which can be variable length, e.g., docket numbers, task type names, contact names, etc.). As a result, it is often the case that these buttons reposition themselves after every click, forcing the user to constantly have to reposition their mouse when clicking on them repeatedly.

It would be nice if they could be assigned a static position in the UI so that their location remains fixed.