Creating really powerful templates requires an ability to embed calculations, "if-then" logic, and database queries in fields.

1. For example, when reporting paying an issue fee, it is nice to provide at least an estimated expiration date. If all maintenance fees are timely paid, the patent is scheduled to expire on {Matter.ExpiredDate(MMMM d, yyyy)} or {Matter.FilingDate(+20y MMMM d, yyyy)} + {Matter.PatentTermAdjustment(0)} days, assuming no terminal disclaimer is involved. It would be very nice to be able to perform that arithmetic automatically, along the lines of:

{Matter.ExpiredDate(+{Matter.PatentTermAdjustment}d MMMM d, yyyy)}

2. The only current logic capability I am aware of is to specify alternative text to be inserted when a field is empty:

{!No Client Ref Specified!Matter.ClientRef}

It would be great to expand this logic capability.

For example, the due date to file an Article 19 Amendment is the later of {Task.RespondBy(-1m MMMM d, yyyy)} or {Matter.PriorityDate(+16m MMMM d, yyyy)}. It would be better if a template could include something like:

The due date to file an Article 19 Amendment is {LaterOf {Task.RespondBy(-1m MMMM d, yyyy)}, {Matter.PriorityDate(+16m MMMM d, yyyy)} }.

Although the prior example refers to dates, numerical comparisons might be useful, too.

3. To report when the next European (3rd to nth) annuity payment will be due requires concatenating: (a) the application filing month, (b) the last day of that month, and (c) the current year (if the month has not yet occurred this year) or the next year (if the month has already occurred this year). But, I know of no way to do anything close to this with the present template document field syntax. I suggest adding support for syntax along the lines of:

{Matter.FilingDate(MMMM dlast)}, {if {Matter.FilingDate(MonthDayOf)} < {General.Now(MonthDayOf)} then {General.Now(yyyy)} else {General.Now(+1y yyyy)} }

or

{Matter.FilingDate(MMMM LastDayOf)}, ...

I realize this is asking for a significant addition to the capability of the syntax parser, essentially turning it into an interpreter. But, we would be able to write really useful templates.

Thanks,
George

@MarkW5689 I can't remember where I found them, but here are some invoice fields:

Invoice Balance
Invoice BillTo
ex. {Invoice.BillTo.First} {Invoice.BillTo.Last} {Invoice.BillTo.Company} {Invoice.BillTo.EmailCC} {Invoice.BillTo.EmailNoCC}
These values are determined by the “Bill To” field in an invoice. This field accepts a Contact, so the subfields are determined from the Contact record.
Invoice Client
ex. {Invoice.Client.Name} {Invoice.Client.IntakeEmailAddress}
(See notes re BillTo.)
Invoice Comments
Invoice CutoffDate
Invoice Description
Invoice DueDate
Invoice Expenses
Invoice Fees
Invoice InvoiceAmount
Invoice InvoiceDate
Invoice InvoiceNos
Invoice LEDESFile
Invoice Locked
Invoice Modified
Invoice PaidOnDate
Invoice Payment
Invoice PaymentTerms
Invoice PDFFile
Invoice RemitTo
ex. {Invoice.RemitTo.Name} {Invoice.RemitTo.EmailNoCc
(See notes re BillTo.)
Invoice SendToQuickBooks
Invoice StartDate
Invoice Status
Invoice WriteOffs

@jonah-soundhound-com
Agreed! I have a task to "Pay foreign associate," although it could be more generally "Pay vendor," such as draftsman. I'd like to be able to store the vendor's invoice number and invoice amount in the Task, then use those fields in generating e-mail messages. It would be even more useful if Tasks were augmented to be able to Create Form Letters (for example, as Matter Detail pages can do). Then, I could print the vendor's check from the Task, and print a payment cover letter from the Task, and send the vendor a payment advice via e-mail, all from the Task. Some of this would require expanding the number of fields that return values in Tasks. For example, currently {Matter.ForeignAssociate} returns a value, but {Matter.ForeignAssociate.Company} and {Matter.ForeignAssociate.Street} do not return values within a Task.

This situation is a reason to support multi-level fields, such as {Task.Matter.ForeignAssociate} or {Task.Matter.ForeignAssociate.Company} or {Task.Matter.ForeignAssociate.Street}.

Another useful user field would be check number, to record the check with which I paid the vendor. All these fields could, of course, be user-defined, as Jonah suggests. But, the number of fields that return values in Tasks needs to be expanded, and Tasks need to be able to Create Form Letters. (I will post these as separate suggestions.)

I don't like to retype or copy/paste when I don't have to. Recording assignments requires LOTS of error-prone and mind numbing typing and/or copying and pasting. However, most of the information required by ePAS is already in a Matter Detail record. So, why not have AppColl generate an XML file that ePAS (USPTO Electronic Patent Assignment System) will ingest? Since AppColl now supports TXT files, and an XML file is just a TXT file with a different filename extension, it can be done.

The attached file (actually, a PDF of a TXT file, because the forum does not allow uploading TXT files) does almost everything that I need. Store the TXT file as a Form Letter in AppColl, then generate a document in the Matter Details page, and almost all of the information needed to record the assignments goes into the generated TXT file. Lightly edit the TXT file with a text editor (if you use a word processor, be careful to output a TXT file), and you can then upload the TXT file into ePAS. (ePAS accepts TXT and XML files.) See instructions in the comments section at the beginning of the attached document about what you have to edit in the TXT file. I have lobbied AppColl to add some capabilities, such as per-inventor assignment execution dates, but until these are implemented, you will have to enter the execution dates manually. You have to be fastidious, because ePAS is notoriously finicky, and in some places inconsistent. So, pay attention to the instructions.

The attached document is built to handle up to 20 assignors and one assignee, but you can extend that, if you want.

I provide this file FYI, without support or warranty.

ePAS Assignment Recordation Upload.pdf

Each contact has a "role," such as inventor, employee, client, or company. For contacts that have relationships to entities, for example, inventors, employees, or paralegals, who are associated with clients or foreign associates, it would be nice to have the option to specify the contact's preferred contact information (mailing address, phone number, etc.) is the same as for the corresponding entity, maybe via check boxes next to these fields. Otherwise, when an entity moves, I have to change the addresses of all the people associated with that entity. I realize I could use the address, etc. fields for people to store only their personal contact information, but that defeats automatic generation of reporting letters, such as those that must be sent via paper (ex. original Letters Patent). It would also make it easier to be consistent in the way correspondence gets addressed. For example, it would avoid sending one contact's correspondence to "The Charles Stark Draper Laboratory, Inc." and sending another contact's correspondence to "Draper Laboratory."
Thanks.
George

The Manage Invoices module generates a Balance (current amount due plus past due invoices). However, this does not seem to be a field I can access, which is unfortunate. It would be nice to be able to include this in a cover e-mail message when I send an invoice.
Would anyone else find such a field useful?

@TarC6989 I generally use Role=Employee in these situations. "Employee" seems to be generic enough to cover anything that isn't one of the specific roles, such as Paralegal, Docketing Manager, Attorney, or Corporate Counsel. Sometimes, I use Role=Other. I have not used Role=Manager. I figured I would use that to keep track of managers of inventors, if that ever becomes useful. So far, it has not.

As you noted, a Role=Client contact has a field called "Primary Contact." That is how I link my clients to their respective primary contacts. In some cases, the primary contact is a Role=Paralegal. In other cases, the primary contact is an Inventor or (in case of a CEO) an Employee. This has worked well for me, for example in generating reporting messages using a "To" address of:

{Matter.Client.PrimaryContact.First} {Matter.Client.PrimaryContact.Last} <{Matter.Client.PrimaryContact.EmailNoCC}>

and a salutation of:

Dear {Matter.Client.PrimaryContact.First}:

What about your arrangement has not worked well for you?

-George

I like to address my reporting and instruction letters using nicknames, if the recipients have nicknames. The contacts module conveniently has a Nickname field, so my letter template could include something like:

Dear {Matter.Client.PrimaryContact.Nickname}:

However, many contacts do not have nicknames, so their Nickname fields are empty. It would be very nice if I could put something like:

{!{Matter.Client.PrimaryContact.First}!Matter.Client.PrimaryContact.Nickname}

in my letter template to use the Nickname field if it is not blank, but use the First field if the Nickname field is blank. I suspect this syntax would also be very handy in relation to other fields.

I realize I could go through all my contacts and, for those who don't have nicknames, copy their first names into their respective Nickname fields, but being a former software developer, I'm lazy.

Is there another way to accomplish my goal?

Thanks,
George

When replying to an e-mail message within the Conversations tab, I can use an e-mail template, which is nice. However, only the message body from the template is used. The subject line specification in the template is ignored. Instead, the subject line of the message being replied to is used.
Please let me use the template to customize the subject line in the reply message.
It is sometimes desirable to keep the original subject line. So, for complete generality, please add a template field along the lines of {email.subject} to enable the template to refer to the original subject line of the message being replied to. Along those lines, it would be really nice to have template fields like {email.from}, {email.to}, {email.cc}, and {email.date}, too.
Thanks,
George

Most grid-based displays, such as the email folder of each matter, allow a user to select which fields to display and the columns in which to display them, which is nice. However, the email folder always displays the "Name" and "Revision" fields in columns 1 and 2. Furthermore, the Name field is often messy, because it contains lots of information, such as date & time, subject line (our and our foreign associate's docket numbers, application number, etc.) Thus, the Name field is often not helpful to quickly understand the contents of the email message. Fortunately, the "Notes" field is available to store an abstract of the message, for example, "Instructions to F/A to pay issue fee."

I would like the Notes field to be displayed in the first column, but that is not currently possible.

Please enable us to fully select which fields (including the Name and Revision fields) are, and are not, displayed in the email page, and the order in which these fields are displayed.

Thanks.
George

Thanks! That is great.

Thanks. This is a great addition.

A competing product (Clio, see clio.com) has a web-based UI and has solved this problem. When you click on a document stored by Clio, a native application program launches on your computer to open the document. When you close the document in the application program, the revised document is stored back in Clio. I don't know how they manage this, but I tested the product when I was looking for docketing software. Unfortunately, their docketing software is not designed for patent practitioners, so it wasn't suitable.

Clio's web site describes two facilities: Clio Drive (apparently a virtual drive - "Create, access, and share your matter-related files right from your desktop and securely sync them to Clio using our virtual drive experience. No need to download or reupload. Open files from the web for easy document editing.") and Clio Launcher ("... to easily open files from your web app into programs like Microsoft Word, Adobe Reader, and more. Any updates you make will be saved on your desktop and in the cloud.")

Another competing product (maybe DocketTrack or maybe another package I tested, but I can't remember which one) also solved the problem. This package requires running a (I'll call it a "helper") program that seems to communicate with the server, so that when you click on a document, you select "download" or something like that, and the server sends the document to the helper program, which then launches a local native application program to edit the document. Once the application program closes the document, the helper program sends the modified document back to the server for storage in the cloud. I found AppColl superior to the competing product in many ways, except for this ability to handle documents.

I have suggested (including screenshots) to AppColl that they investigate operation of these competing products and consider building similar functionality.

-George

Attaching documents to an e-mail message, when generating and sending an e-mail message for a matter, is straightforward, as long as the documents are in folders associated to the matter, i.e., in AsFiled, Email, OfficialCorrespondence, etc. However, to attach a prior art document, such as when reporting an Office Action, one must look in the References folder, which contains all prior art documents stored by AppColl, not just prior art references for this matter. That can be a long list, and finding exactly the desired document can be tricky, given the file names, which typically contain many digits.

I suggest augmenting the "Attach Document or Form Letter" document chooser so it also lists prior art documents associated to the matter. AppColl already knows which prior art documents are associated to the matter. (AppColl displays them in the Matter Prior Art > [select a matter] screen.) I suggest a UI something like the following:

-George

Enable a client contact record to point to several other (people or organization) contact records, for roles such as general counsel, paralegal, docketing clerk, billing contact, etc.

Conveniently, a client contact record can point to another contact record as a "Primary Contact." This is handy for generating reporting messages. I use this all the time. A client contact record can also have a pointer to a "Default Attorney" and "Other Contacts Emails."

But, there are more types of automatically generated messages sent from AppColl that are not accommodated by these fields. For example: (a) a billing contact to whom invoices are sent (by the way, this could be a company hired by the client to handle invoices), (b) general counsel to whom yearly engagement renewal letters are sent, and (c) docketing clerks and paralegals who are not the primary contact, but who should receive certain types of correspondence. (By the way, the docketing clerk could be a company where the client has outsourced its docketing.) It would be very handy for a client contact record to have the ability to point to other types of people or organizations who each have their own contact record.

A client contact record has name fields ({Contact.First}, {Contact.Last}, {Contact.Email}, etc. But, what to put in these fields for a client? No one person fits all the needs. Besides, putting a person's information here is redundant with that person's own contact record.

A specific example: The Manage Invoices module has a required field ("Bill To"), which accepts a contact. The module uses this contact's information for various things, such as when generating an invoice e-mail message, for example to populate fields such as {Invoice.BillTo.EmailNoCC} and {Invoice.BillTo.Company}. However, I can't figure out what to put into this field to meet both of two needs: (1) generate e-mail messages to deliver invoices to clients and (2) export invoices from AppColl to QuickBooks. I can set up the Bill To field to work well for either (1) or (2), but I can't figure out what to put in the field to meet both needs.

If I populate the Bill To field with a client, the client name gets sent to QuickBooks, which is good. However, the billing e-mail messages get populated from the client contact fields, such as {Contact.First}, {Contact.Last}, {Contact.Email}, etc. For some clients, I send the invoices to a billing contact, not the primary contact or general counsel. I have a separate contact record for the person at the client who should receive invoices, but I can't make the client record point to that person's contact record for directing invoices there.

I don't want to put the billing contact's information in the client's {Contact.First}, {Contact.Last}, {Contact.Email}, etc. fields, because that duplicates the information in the database. That violates a principal rule of database design, because it can lead to inconsistent information in the database about a single person.

On the other hand, if I populate the Bill To field with the billing contact's contact record, AppColl tells QuickBooks that the invoices are sent to a person, rather than an entity, and QuickBooks expects payment from that person, not from the entity. When payment from the entity arrives, QuickBooks gets confused. Besides, if the billing contact changes, QuickBooks will be even more confused, because it will think I have a new client.

So, maybe this is a two-part request:

(a) Enable a client contact record to point to other contact records for defined purposes. Enable the Manage Invoices module to select one of these (indirectly pointed) contacts as a Bill To.

(b) Enable the Manage Invoices module to send invoices to a selected contact (ex. a billing contact person, or maybe a company), but let me specify a different contact (i.e., the client) to the Manage Invoices module for passing on to QuickBooks.

-George

@jonah-soundhound-com I use Patent Center. I haven't used EFS-Web for months. The missing fonts issue I mentioned above relates to Patent Center. I did not try uploading the IDS via EFS-Web. I agree, it does not make sense to spend engineering effort to help with problems in a system that is planned for deprecation. However, Patent Center is not planned for deprecation.

@TarC6989 I generally use Role=Employee in these situations. "Employee" seems to be generic enough to cover anything that isn't one of the specific roles, such as Paralegal, Docketing Manager, Attorney, or Corporate Counsel. Sometimes, I use Role=Other. I have not used Role=Manager. I figured I would use that to keep track of managers of inventors, if that ever becomes useful. So far, it has not.

As you noted, a Role=Client contact has a field called "Primary Contact." That is how I link my clients to their respective primary contacts. In some cases, the primary contact is a Role=Paralegal. In other cases, the primary contact is an Inventor or (in case of a CEO) an Employee. This has worked well for me, for example in generating reporting messages using a "To" address of:

{Matter.Client.PrimaryContact.First} {Matter.Client.PrimaryContact.Last} <{Matter.Client.PrimaryContact.EmailNoCC}>

and a salutation of:

Dear {Matter.Client.PrimaryContact.First}:

What about your arrangement has not worked well for you?

-George

I really like the Prior Art module in AppColl, because it stores prior art, cross-correlates between matters, and generates IDSs. I have a suggested enhancement.

This weekend, I ran into a problem trying to upload several references with an IDS I generated from the Prior Art module. Patent Center would not accept two of the documents, for lack of embedded fonts. I was able to recover, but it took a while. If I had been working against a midnight deadline, I might not have made it. (I eventually learned to fix the problem using the Preview application on my Mac. The print dialog box offers a "Save as PDF..." option, which flattens the file, embeds fonts, or performs some other magic, but that is another story.)

I suggest adding a test of PDF documents uploaded into the Prior Art module to see if all the fonts are embedded, and maybe perform other tests that Patent Center performs, and warn the user if the document is unlikely to be acceptable to Patent Center. Don't reject the file, just warn the user that he/she will probably not be able to upload the PDF to the USPTO, without first flattening the file or embedding the fonts or fixing something else.

I don't know exactly what tests the USPTO performs on uploaded PDF files or what tool they use to perform the tests, but that information should be available from the USPTO. Their "PDF Creation for EFS-Web" document outlines basic PDF requirements, so that should provide at least a framework.

The USPTO being what it is, just because a PDF document passes a test AppColl performs when ingesting the document does not guarantee the PTO won't later reject the document. But, being warned of possible problems ahead of time could save a practitioner from a last minute panic.

Thanks,
George

Creating really powerful templates requires an ability to embed calculations, "if-then" logic, and database queries in fields.

1. For example, when reporting paying an issue fee, it is nice to provide at least an estimated expiration date. If all maintenance fees are timely paid, the patent is scheduled to expire on {Matter.ExpiredDate(MMMM d, yyyy)} or {Matter.FilingDate(+20y MMMM d, yyyy)} + {Matter.PatentTermAdjustment(0)} days, assuming no terminal disclaimer is involved. It would be very nice to be able to perform that arithmetic automatically, along the lines of:

{Matter.ExpiredDate(+{Matter.PatentTermAdjustment}d MMMM d, yyyy)}

2. The only current logic capability I am aware of is to specify alternative text to be inserted when a field is empty:

{!No Client Ref Specified!Matter.ClientRef}

It would be great to expand this logic capability.

For example, the due date to file an Article 19 Amendment is the later of {Task.RespondBy(-1m MMMM d, yyyy)} or {Matter.PriorityDate(+16m MMMM d, yyyy)}. It would be better if a template could include something like:

The due date to file an Article 19 Amendment is {LaterOf {Task.RespondBy(-1m MMMM d, yyyy)}, {Matter.PriorityDate(+16m MMMM d, yyyy)} }.

Although the prior example refers to dates, numerical comparisons might be useful, too.

3. To report when the next European (3rd to nth) annuity payment will be due requires concatenating: (a) the application filing month, (b) the last day of that month, and (c) the current year (if the month has not yet occurred this year) or the next year (if the month has already occurred this year). But, I know of no way to do anything close to this with the present template document field syntax. I suggest adding support for syntax along the lines of:

{Matter.FilingDate(MMMM dlast)}, {if {Matter.FilingDate(MonthDayOf)} < {General.Now(MonthDayOf)} then {General.Now(yyyy)} else {General.Now(+1y yyyy)} }

or

{Matter.FilingDate(MMMM LastDayOf)}, ...

I realize this is asking for a significant addition to the capability of the syntax parser, essentially turning it into an interpreter. But, we would be able to write really useful templates.

Thanks,
George

@SadiqA2304 That's right. I thought it sounded familiar!