Solo Practitioners

@gregg_appcoll Do you have an ETA for syntax for an alternate field, when a first field is blank? The examples I gave in an earlier post in this thread are still valid use cases, at least for me. Thanks.
-George

After one uploads an assignment to Assignment Center, the USPTO sends an e-mail message with a subject “Assignment confirmation: Assignment ID – xxxxxxx.” Attached to this e-mail message is a document, i.e., a printable version of a “Confirmation Receipt,” a/k/a “Cover Sheet.” The filename of this document is “Cover sheet_xxxxxxx.pdf.” Outlook recognizes the document as a PDF, as indicated by an icon Outlook displays.

Clicking “Preview” or “Open” in Outlook, in relation to this document, correctly displays the document, including its filename ending in “.pdf.”

However, clicking “Download” in Outlook, in relation to this document, opens a File Explorer/Chooser (depending on operating system – Windows or Mac) window with a proposed filename to be used to create a file. Outlook on Windows correctly proposes a filename that ends in “.pdf.” However, Legacy Outlook for Mac proposes a filename that does not end in “.pdf,” and such a file causes problems, because the operating system doesn’t know what application to launch when the file is later opened. Furthermore, AppColl doesn’t know what kind of file it is, so it gets stored in AppColl as a generic file. Double-clicking on the generic file in AppColl opens a Chooser window, instead of launching an appropriate application. After I receive an e-mail message with a Cover Sheet, I rename the file in AppColl by appending “.pdf” to the filename, but that takes time and messes up the “Modified” date/time in the Files module.

The root of this problem lies in the MIME type of the Cover Sheet attachment. Each attachment to an e-mail message has a Multipurpose Internet Mail Extensions (MIME) type that indicates its data format. The fine support people at AppColl figured out that the e-mail messages from Assignment Center use the wrong MIME type for the Cover Sheet attachments, which confuses Outlook, at least on a Mac. Looking at the source of an example e-mail message from Assignment Center with a Cover Sheet:

[beginning of snippet]

--B_3842273732_2993734876
Content-type: application/octet-stream; name="Cover sheet_1323165.pdf";
x-mac-creator="4F50494D";
x-mac-type="50444620"
Content-ID: 34FA466A49568F4F8A8BEAF16BC59F88@namprd10.prod.outlook. com
Content-disposition: attachment;
filename="Cover sheet_1323165.pdf"
Content-transfer-encoding: base64
JVBERi0xLjUKJeLjz9MKNSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMz
NDY+PnN0cmVhbQp4nJVbW3fbNhJ+16/A4+45KUOC9+xLbUdN7caya8nJSffsgyIzFmuJciU5
l3+/AIEBZwakpJw+VBPzu8yFIAjL/4zOZ6NQFEkUFIWYPYzGs9Gfo39GYRDGeSq+jaS4Uj// ...

[end of snippet]

one can see that the MIME type is specified as “application/octet-stream,” which means the file contains generic, unknown binary data, often used as a default when a server doesn't recognize a file's true type or lacks specific file extension information. This is ridiculous, because Assignment Center knows it is sending the Cover Sheet as a PDF. Thus, the correct MIME type is “application/pdf,” and Assignment Center should send the e-mail messages with this MIME type.

Indeed, when Assignment Center sends a Notice of Recordation, it uses the correct MIME type:

[beginning of snippet]

--B_3842386854_2014183294
Content-type: application/pdf; name="Notice.pdf";
x-mac-creator="4F50494D";
x-mac-type="50444620"
Content-ID: 036DFAD60460D14DAFB6E21724429C0E@namprd10.prod.outlook. com
Content-disposition: attachment;
filename="Notice.pdf"
Content-transfer-encoding: base64

JVBERi0xLjMKJaqrrK0KNCAwIG9iago8PCAvVHlwZSAvSW5mbwovUHJvZHVjZXIgKG51bGwp
ID4+CmVuZG9iago1IDAgb2JqCjw8IC9MZW5ndGggNTAzMjAgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgCiA+PgpzdHJlYW0KeJzsvVuzJLeRJvievyIfp9dGpcA1IuaNokoSuymWhix1T9vOPqXZ ...

[end of snippet]

Thus, the Assignment Center developers know how to correctly formulate an e-mail message with a PDF attachment. They simply failed to do so for Cover Sheet messages, which is inexcusable.

I understand that the fine people at AppColl are working to modify their system to automatically recognize PDF attachments, even if the MIME type is wrong. This would be great, because I suspect it would take quite a bit of effort to get the USPTO to correct its system.

In the meantime, I will continue to rename the Cover Sheet files by appending ".pdf" to their filenames.

@ChristianS9906 Whereas AppColl already implemented the change you requested, I'm reluctant to request they change it back. I don't know to what extent others have strong or weak feelings about e-mail addresses with or without aliases (display names). You and I have stated our preference and reasons. It would be interesting to see if anyone else expresses an opinion.

@ChristianS9906 Thanks. My e-mail templates essentially already include your suggestion. The "To" field is populated by:

{Matter.ClientContact.First+032}{Matter.ClientContact.Last+032}{+060Matter.ClientContact.EmailNoCC+062+044+032}{Matter.Client.PrimaryContact.First} {Matter.Client.PrimaryContact.Last} <{Matter.Client.PrimaryContact.EmailNoCC}>

and the "CC" field is populated by:

{Matter.Client.PrimaryContact.EmailCC+059+032}Auto-docket mailbox for matter {Matter.AttorneyRef} <{Matter.EmailIntakeAddress}>

This works well for e-mail messages generated within AppColl.

However, I often copy the matter auto-intake e-mail address from a matter detail page and paste that address into a new (or reply) e-mail message in Outlook (my mail agent), i.e., a message not generated by AppColl. This is where the alias comes in handy, because although I send that message from Outlook, a copy gets stored in AppColl, and if the client responds to "all," a copy of the response gets stored in AppColl.

@ChristianS2558 I actually like the alias that prepends the auto-intake e-mail address. Often, I send e-mail messages from Outlook, because I have large attachments that AppColl can't handle, or I'm responding to a message that was sent only to my Outlook address, not to an AppColl matter. I like to CC the auto-intake mailbox for the corresponding matter. I like the alias appearing in the message, because it indicates to the recipient (typically a client) what the "funny" address is and, hopefully, encourages the recipient to "respond to all," so a copy of the response ends up being stored in the "email" folder of the corresponding matter.
I suppose mine may be a minority view.
-George

@gregg_appcoll Yes, the issue I pointed out occurs on the "Payments Summary" page, which is the first page of my invoice and includes the client's mailing address, so it is the first page the client sees when he opens the invoice. Adding some text to clarify that the "Items through..." date covers payments and retainers (but not billing items) would be helpful. Thanks.
In addition, it would be nice to have the invoice (perhaps optionally) show the period covered, i.e. the cut-off date.
George

When adding a new invoice in the Manage Invoices module, AppColl requires a "Cut-off Date."

No Billing Items after this date are included in the bill, which makes sense.
The generated bill shows the date it was generated (see green outline), which also makes sense. However, the generated bill says "Items through <date>" (see red outline), where <date> is the generated-on date, NOT the Cut-off Date.

This is misleading to the client. In the example shown here, the bill was generated on October 3, 2024, but it includes items only through the end of September. Yet, the bill appears on its face to cover through October 3. If my next bill to this client includes billing items dated 10/1 - 10/3, the client will think I am billing him twice.
Please change the way the Manage Invoices module inserts the "Items through" date to put the "Cut-off Date," not the generated-on date. Thanks.
-George

Request: A task or event can be triggered "when any email is received" and, of course, the task trigger can include additional requirements, such as "while the sender email address or subject of the email contains contains <a specific text string>". This is a very powerful facility. It would be more powerful if the task could be defined to automatically attach or link the triggering e-mail message to the triggered event or task, and that message or link could be passed on to subsequently-triggered tasks. Currently, one can only manually attach a document, such as an e-mail message, to a task.
Currently, one can include e-mail fields, such as {Email.Body}, in the task, such as in the task's Default Comment. However, text formatting, such as underlining, is lost. Furthermore, including the entire body can add many lines to the task Comment, making the task very large when displayed in a matter detail page or on the All Open Tasks list. Attaching or linking the entire e-mail message to the task would overcome these shortcomings.
Reason for the request: I send an e-mail message to a matter's intake mailbox after an examiner calls me with a telephonic restriction requirement, to document the call. In the body of the message, I summarize the restriction requirement, and sometimes I include comments or notes about possible responses. Often, I use underlining to highlight differences between claim groups.
I defined an event ("Receive Telephonic Restriction Requirement”) that is triggered when a matter receives such an e-mail message, i.e., a message from me with "telephonic restriction requirement" in the subject.

This event triggers another task I defined (“Respond to Telephonic Restriction Requirement”). I modeled my new tasks after similarly-named pre-defined AppColl tasks, although the "Respond to..." task has a internal deadline of five days.
It would be very handy to see the text formatting when I work on the restriction requirement.
Suggested implementation: Augment the "Files:" "Add" button dialog, as follows. Change "Select form to be added when tasks of this type are created" to "Select form or triggering e-mail message to be added when tasks of this type are created." Add a radio button for "Triggering e-mail message." The triggering e-mail message is already in the Email folder for the matter.

Optionally or alternatively: Add a checkboxes to New/Update Task Type details page. Under the "Trigger Event:" "Add" button, add a check box for "Attach triggering e-mail message" and a checkbox for "Link triggering e-mail message." Obviously, the checkboxes would be effective only if the task is triggered by receipt of an e-mail message.

Optionally or alternatively, if the Default Comment contains "{Email}," attach the triggering e-mail message to the task or include a clickable link to the e-mail message in the Comment.
In any case, ensure that another task that is triggered by the present task could "inherit" the attached or linked e-mail message, perhaps via {TriggeringTask.Comments}.
Broader applicability: Fulfilling this request might facilitate other uses, such as automatically triggering events upon receipt of e-mail correspondence from a foreign associate or a foreign patent office.
Thanks!
-George

A Tandem account seems like a nice way to let a client have controlled and limited access to my AppColl data. Currently, AppColl does not give Tandem users visibility into all the data that I have for that client's matters. For example, as viewed in a Tandem synch'ed account, no matter details page displays any tasks. I can understand why some (maybe many) attorneys wouldn't want their clients to see all tasks for that client's matters, especially if the attorney is behind on his/her docket.

However, I would like to make my tasks visible to a particular client, and I wonder if other AppColl users would also like to be able to do the same. If so, I suggest adding a switch (or maybe several switches) to turn on visibility to Tandem users (on a per-client basis) to various currently-hidden data caches, such as Tasks and the Notes fields in e-mail messages.

Thanks,
George

I often know a foreign cost, such as a foreign filing fee, in a local currency, but not an equivalent US dollar (USD) amount. For example, my foreign associates often quote or estimate costs in their local currency. I can store the local-currency cost in a custom matter field or a task field (maybe {Task.BudgetExpense}), but I would like to report it to my client in USD equivalent.

When generating a reporting letter or a letter requesting instructions (such as for requesting examination), it would be handy if AppColl provided a mechanism to call an API to convert a foreign currency to USD. Several such APIs exist, and some provide several hundred free conversions per month. (See, for example, Currency Beacon, Currency API, and Exchange Rates API.)

Please consider adding a field that calls an external API, for example something along the lines of:

{CallAPI.https://api.currencybeacon.com/v1/convert?api_key=abcdefghijklmnopqrst&from={Matter.CurrencySymbol}&to=USD&amount={Task.BudgetExpense}("value",0.00)}

This syntax includes the URL of the API and four parameters to pass to the API (each parameter begins with a question mark): an API key (assigned to a user when the user signs up for an account), a "from" currency symbol (in this example, extracted from a custom matter field), a "to" currency symbol, and an amount (extracted from a task field).

Most of these APIs return values in JSON. The parenthetical in my suggested syntax provides information on what part of the returned JSON values AppColl should return for its field. In this example, the API returns a bunch of things, including the converted USD as "value" followed by a floating point number (ex, "value 62.156").
"0.00" in the parenthetical is the standard AppColl number formatting specification (return a floating point number, with two decimal places).

If AppColl could pull this off, it might have wider applicability, because there may be other useful APIs that could be called, such as EPO OPS (the European Patent Office's Open Patent Services API). The key is for the syntax to allow the AppColl user to: (1) call a URL, including passing parameters, some of which may be extracted from fields, and (2) give the AppColl field evaluator a hint about what to return from the JSON values.

I know this is a big ask, but if we don't dream big, we won't be able to succeed spectacularly.

Edit 1: Alternatively, AppColl could do the foreign currency exchange rate conversion and return the equivalent USD in response to a "ToUSD" text formatting command (somewhat like the "ToUpper" text formatting command). I suggest syntax something like:

{Task.BudgetExpense(ToUSD, {Matter.CurrencySymbol}, 0.00)}

Of course, AppColl would have to subscribe to a foreign exchange API, but the cost would be minimal.

Edit 3: AppColl could assume the "from" currency symbol based on the country code of the matter, although this might not be a safe assumption. For example, my Malaysian cases are handled through an Australian associate, so I pay in AUD, not MYR.

Edit 2: In case anyone wants to try any of the free foreign exchange rate APIs listed above or others, here is a hint: Many of them limit HTTPS requests to paying customers, and they require free accounts to call the APIs with plain HTTP requests. So, ensure your request is in HTTP, not HTTPS.

But, some browsers may be set to "HTTPS-only." In this case, the browser will change all HTTP requests into HTTPS requests behind your back. Thus, the browser will change an HTTP API call into an HTTPS request, which will fail with an "unauthorized" or similar error.

If this happens, add an exception URL to the browser's list (forcing the browser not to change HTTP to HTTPS request for the excepted URL). For example, Firefox > Settings... or Preferences (depending on OS) > Privacy & Security > (scroll to HTTPS-Only Mode) > Manage Exceptions ... > (enter URL of the API in "Address of website" and click "Turn off") > Save Changes.

Thanks,
George