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.

Best posts made by RichardS3059
-
Just a AIA-82A form
-
RE: Foreign law support
@joe-appcoll-com In my mind, this is by far the greatest weakness of AppColl. Doing it right is a huge undertaking, however.
-
RE: Foreign law support
@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.
-
RE: New field request: Contact.FirstOrNickname
@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.
-
RE: Open search field under module tabs
@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.
-
RE: Automatically calculate expiration date
@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.
-
RE: Switching the order of "from" and "to" in descriptions of changes
@jonah-soundhound-com I agree, although what I'd really prefer is for the truncation to be eliminated.
-
Docketing for Hague International Design registrations
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.
-
RE: New field request: Contact.FirstOrNickname
@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.
-
Multifactor authentication
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.
Latest posts made by RichardS3059
-
RE: Has anyone configured for task to be assigned to more than one owner?
@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. -
RE: Feature Request: PTO Fee Schedules
@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.
-
RE: Open search field under module tabs
@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.
-
Generate email to a group of contacts
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.
-
Docketing for TM oppositions
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.
-
RE: Parse email subject line for Docket Number/Client Reference
@jonah-soundhound-com And based on my experience, I can guarantee that foreign associates will do that.
-
RE: New field request: Contact.FirstOrNickname
@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.
-
RE: New field request: {Contact.USPTORegNumComma}
@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.
-
RE: New field request: Contact.FirstOrNickname
@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.
-
RE: New field request: {Contact.USPTORegNumComma}
@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.