I would really like to be able to create an AIA/82A by itself, without the AIA/82B form. You list an "AIA/82 Transmittal For Power of Attorney ..." form in the list of PTO forms that can be created and filled in with data from a matter. The form created is both an AIA/82A and an AIA/82B. For my clients, I have them sign an 82B once, then create an 82A for each application, which is how the forms are designed to work. But now I have to edit the AIA/82 created by AppColl to delete the pages for the 82B every time I create an 82A.

@joe-appcoll-com In my mind, this is by far the greatest weakness of AppColl. Doing it right is a huge undertaking, however.

@joe-appcoll-com Eventually, maybe. But I've not seen anything like a roadmap saying when. As a solo with clients who only work in a small number of countries, I can create my own rules fairly easily. But AppColl would have to spend a lot of resources to cover the world and all of the possible updates that have to be made from time to time. I managed a docketing group for a large firm for a while that used IP Manager (ugh), and the number of updates the vendor made--90% of which probably were of no interest to our clients--was huge.

@SadiqA2304 I'd rather not add yet another field. First Name and Nickname aren't the only fields that could use something like this. For example Filing Date and Official Filing Date. What I'd really prefer is some kind of syntax that allows generally indicating "use field X if it's not null, but use field Y if field X is null." Perhaps something like:

            {{Matter.ClientContact.Nickname},{Matter.ClientContact.FirstName}}

I'm not pushing that syntax. It was just the first thing that came to mind. Even more powerful would be a more generalized IF syntax.

What I end up doing now is filling in Nickname with the first name all the time, and just using Nickname all the time.

@MelissaT3398 Like other firms I've been at, my current firm includes the country code in the matter number. E.g., the AU designation in a Madrid case would be 1234.0002AU. So including an extra copy of the country code in the search results would be counterproductive for us, since it would take up more of the limited space.

@BerndN5890 You'd have to remember that the calculated date could be incorrect if a terminal disclaimer was in place. Or if PTE was granted under Hatch Waxman. And, of course, non-payment of maintenance fees. And that's just for US patents. For foreign patents, it's even more complicated.

@jonah-soundhound-com I agree, although what I'd really prefer is for the truncation to be eliminated.

Does anyone have any suggestions for the best way to docket international design registrations under the Hague convention? If you've already done that and would be willing to share what tasks you created, I would appreciate the help and not having to customize everything from scratch.

@SadiqA2304 I'm used to programming, so the idea of adding syntax for more control of the templates feels better to me than adding fields that have logic embedded into them. I agree that putting the first name into the nickname field if no nickname exists isn't a great solution, but it does work until they provide something better. You only have to embed the nickname field into your template to get the desired result. It's a little extra setup work to remember to fill in the nickname field when it's not really a nickname, but that's a one-time effort when you create the contact.

I'll always prefer a programmatic way to accomplish the result over fields that have field-specific logic embedded into them, because they allow a more generalized result. For example, none of the several priority fields produces exactly how I often
want priority information specified. As it is, the list of fields doesn't remind me how each version is formatted, so I have to do tests to figure out which one has the closest to what I need, then manually edit the result of the template every time it's used.

If we had a generalized formatting syntax, we wouldn't have to wait for AppColl to create yet another special-purpose field, but would immediately have the ability to get what we want.

AppColl should support (and encourage) multifactor authentication. Preferably, you would allow the user to select multiple methods from a list of methods, such as email, SMS message, push notification, TOTP, and digital certificate. That way, if for some reason one method isn't working at login, an alternate method could be used.

@JonahP1621 I've certainly worked with more than one docketing systems that allowed matters and docket entries to be assigned to multiple attorneys. That way, things would show up on each person's docket. Usually, the docketing system simply designated them as Attorney 1, Attorney 2, etc. and the firm could choose by policy the roles assigned to each of the Attorney n fields. At one big firm where I was a partner, at least one partner insisted that docket reports produced for him only show docket items for those few cases where he was the working attorney. The system we had there was so bad that I found to my horror that
one docketing clerk spent their entire day just producing daily docket reports for each attorney by running a giant docket for everyone, then manually extracting the docket for each attorney into a spreadsheet for just that person. I was able to cut that down to no more than an hour by writing some code to split the giant docket into individual files. It wasn't a great solution but was the best we could do with the limited capability of the system.

@TarC6989 While that might be a nice idea, given how little support is currently builtin to AppColl for non-U.S. prosecution, I'd rather they spend time developing that support.

@MelissaT3398 Like other firms I've been at, my current firm includes the country code in the matter number. E.g., the AU designation in a Madrid case would be 1234.0002AU. So including an extra copy of the country code in the search results would be counterproductive for us, since it would take up more of the limited space.

From time to time, I need to send an informative email to a group or all of my active clients. I would really like to generate that email by selecting the relevant client contacts, then have AppColl generate the email, either as separate emails with them as To:, or as a group email, with each of them in the Bcc: line.

I'm looking for suggestions on the best way to docket dates for a client to file an opposition or an EOT request against a third-party trademark application. AppColl has a fairly well-developed series of tasks for opposition due dates once an opposition has been instituted, but nothing before then. Surely someone must have done this already.

Do you use a regular trademark matter or an opposition matter? You have to ask AppColl to add the opposition matter type, and it's pretty limited in the available fields, so there's nothing like a publication date field that you could trigger an opposition deadline task against. Before I go through a lot of effort to build a structure of tasks for this, I thought I'd see if anyone else had useful advice.

@jonah-soundhound-com And based on my experience, I can guarantee that foreign associates will do that.

@SadiqA2304 I'm used to programming, so the idea of adding syntax for more control of the templates feels better to me than adding fields that have logic embedded into them. I agree that putting the first name into the nickname field if no nickname exists isn't a great solution, but it does work until they provide something better. You only have to embed the nickname field into your template to get the desired result. It's a little extra setup work to remember to fill in the nickname field when it's not really a nickname, but that's a one-time effort when you create the contact.

I'll always prefer a programmatic way to accomplish the result over fields that have field-specific logic embedded into them, because they allow a more generalized result. For example, none of the several priority fields produces exactly how I often
want priority information specified. As it is, the list of fields doesn't remind me how each version is formatted, so I have to do tests to figure out which one has the closest to what I need, then manually edit the result of the template every time it's used.

If we had a generalized formatting syntax, we wouldn't have to wait for AppColl to create yet another special-purpose field, but would immediately have the ability to get what we want.

@SadiqA2304 The format I proposed is very similar to the way you can format cells in Excel and the way date fields can already be formatted, But the real advantage would be that you wouldn't be limited to specific fields, but could format any field you want however you like it.

@SadiqA2304 I'd rather not add yet another field. First Name and Nickname aren't the only fields that could use something like this. For example Filing Date and Official Filing Date. What I'd really prefer is some kind of syntax that allows generally indicating "use field X if it's not null, but use field Y if field X is null." Perhaps something like:

            {{Matter.ClientContact.Nickname},{Matter.ClientContact.FirstName}}

I'm not pushing that syntax. It was just the first thing that came to mind. Even more powerful would be a more generalized IF syntax.

What I end up doing now is filling in Nickname with the first name all the time, and just using Nickname all the time.

@SadiqA2304 Instead of a new field, I'd rather have AppColl allow formatting characteristics in non-date fields like it does with dates. Something like:

{Contact.USPTORegNum(#dd,ddd)}

That way I don't have to remember yet another field name.