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

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

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

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

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

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.

From time to time I need to edit a report to change something. Now, I have retype the report name and select the overwrite existing report just to save a change in a report. Can you provide a way simply to save changes in an existing report without going through the "save as" process?

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

Gregg, yes it does. But I start from the Reports module, generate a report, then change it, I have to enter the report name in full, since the drop-down wasn't used.

From time to time I need to edit a report to change something. Now, I have retype the report name and select the overwrite existing report just to save a change in a report. Can you provide a way simply to save changes in an existing report without going through the "save as" process?

@GeorgeJ4336 My suggestion is that Matter.Examiner and other name fields should be treated similarly to a Contact so that the .First, .Middle, .Last, etc. subfields that we can specify for Contacts could be used for non-Contact name fields.

Can you share with us anything about your plans for future development? Is there a roadmap that you can share?

@TarC6989 You can also see the client name if you click on the field name "Client" in the Matter Details screen.

@gregg_appcoll

On further review, I'm a bit confused by both the original posting and your response. There is no Matter.ClientCode field nor a Matter.ClientFull field. There is a Contact.Client field and a Contact.ClientFull field, but at the moment those fields appear unused in Client contact entries and I can't see a way to provide them with any value. There is a Contact.ShortName field, which is what is filled in from the field labeled "Client Code" in a Client contact entry, and a Contact.Name field, which is what is filled in from the field labeled Company in a Client contact entry. There is also a Client.Company field, which appears to be a duplicate of the Contact.Name field.

However, in a Client/Solo Inventor type contact, oddly enough, the Contact.Client field is filled in with the "Client Code" value from the screen and is a duplicate of the Client.ShortName field. And, again only in a Client/Solo Inventor type contact, the Contact.ClientFull field is a duplicate of the Contact.Name field, i.e., the full name of the person, with the Contact.Company field being the Contact.Client field concatenated with the Contact.Name field in parentheses, e.g.,

1999 (John Doe)

This inconsistency between Client and Client/Solo Inventor type contacts is a bad idea, I think, although by now that would be somewhat disruptive to fix.

NB: There is a formatting problem with the Client Code field on the Client-type contact data entry screen. Instead of being aligned with the Client Code: label, the entry field and the small entity checkbox are vertically offset from the field label, unlike any other field on the screen.

The formatting error in the Client type contact doesn't appear in the Client/Solo Inventor type contact:

@gregg_appcoll As far as I can determine, there is no field named {Matter.ClientFull}. It's not listed in the help topic listing all form fields and there is no field by that name that appears in a dropdown for configuring columns to show in a report.

I think what you meant to say is {Matter.Client.Name}. For example, my form letters all start with:

{Matter.ClientContact.PersonalName}
{Matter.Client.Name}
{Matter.ClientContact.Address}

Re: [variable stuff depending on the form letter]
Our file: {Matter.AttorneyRef}

Dear {Matter.ClientContact.NicknameorFirst}:

My {Matter.Client} value (which I presume is what TarC6989 refers to as Client Code) is always a 3- or 4-digit number. My AttorneyRef values are always in the form of

[clientcode]-[matternumber][countrycode][optional extension]

e.g., 1295-0002US.

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