Posts made by ChristianS9906

AppColl determines the priority claim type for each priority connection in an application based on what the application Type is of that application. For multi-tier priority claims, each priority claim type is determined based on what the application Type was that first made that priority claim.

This works well for many applications and is generally painless for users. However, it is completely unable to handle complex priority claims in which an application might simultaneously make two or more different types of priority claim to different parent applications. For example, mixed direct CIP and CON priority claims are simply not able to be recognized/specified in AppColl. If you call the application a continuation, then AppColl assumes both priority claims are continuation priority claims. If you call it a CIP, then AppColl assumes both priority claims are CIPs. In reality, it has one CON priority claim and one CIP priority claim.

This is potentially dangerous since AppColl populates the ADS based on what it thinks the priority claim is. If the user generates the ADS and then fails to modify it to correct the incorrect priority claims that AppColl provided, they will submit a priority claim that may be specified incorrectly, thereby jeopardizing it.

Users should have the ability to specify, for each priority claim, what the priority claim type is--it should not be tied to the Type of the application that is making the priority claim. The user-specified priority claim type is what should govern in ADS creation and in other parts of AppColl that show priority claim data.

It would be a very nice feature if there were an "AdjustedExpirationDate" field that was simply the ExpirationDate field + PTA. This would not be user editable; it would be calculated based on whatever was entered into the ExpirationDate and PTA fields.

Right now, AppColl automatically changes the "Status" of "Issued" patents to "Expired" when the expiration date is reached. However, patents with PTA do not expire on their expiration date, they expire later. This can be very problematic, as if a report having the application status is generated from AppColl and provided to, for example, CPI or some other annuity service, it will incorrectly tell the annuity service that an application is expired when it is actually not. This may cause the annuity service to assume that maintenance fees no longer need to be paid, and the service will no longer request payment instructions for it.

This is problematic when trying to generate a report, for example, of all patents that may have maintenance fees that need to be paid. You'd want to include all patents with "Issued" status, but also all patents with "Expired" status that still had PTA left. Unfortunately, there is no easy way to do this right now. If the AdjustedExpirationDate field existed, we could simply filter on all patents with Issued status OR Expired status with AdjustedExpirationDate > today.

The only other option is to manually edit the ExpirationDate field to include the PTA, but that would be non-preferred since it introduces a constant risk of user error and is difficult to easily verify as being correct.

In a perfect world, the AdjustedExpirationDate would also reflect the effects of any terminal disclaimers that might have been filed--although this would be much more complicated to determine. It might be best to have another calculated field for "TDExpirationDate" that reflects this modified expiration date.

It would also be nice if the auto-change from "Issued" to "Expired" were to be based on the AdjustedExpirationDate instead of the ExpirationDate. That would be much more accurate and much less likely to lead a user to inadvertently miss a patent that was still active due to PTA. This should be the default behavior, or at least a setting that admins can select.

Can this be done?

Hi Melissa,

Interesting question/suggestion--I doubt that the current framework can support this since the "Excel" export is just a CSV format. Maybe after we get "real" XLSX support. : )

I did find one way to do what you are asking, however. It is a little kludgy but seems to work.

a) Make a report with the Images column + other columns you want.
b) Export that report to PDF. It should show the images in table format.
c) Using Adobe Acrobat (other PDF software might work as well), convert the PDF report into an Excel spreadsheet.
d) Open the converted document in Excel. Select all cells in the table and un-merge them (on Home, Alignment ribbon tab). This is important; you won't be able to sort the table at all unless you do it. And if you copy/paste into Word, you'll never be able to find the merged cells in the Word table.
e) Select one of the images in your Excel table; then hit CTRL-A to select all of them.
f) Right-click one of the images you've selected and select "Size and Properties..."
g) In the sidebar that appears, expand "Properies" and select "Move and size with cells" or "Move but don't size with cells." You'll want to experiment to see which you prefer.
h) Select the entire range of data and then go to Home...Sort & Filter and select "Filter" to turn it into a sortable table.

Word is actually a better choice for this, I think, since a Word table will let you sort it but will also retain the row heights for the sorted rows, thereby preserving the appearance of each row in the sorted table.

Cheers,
Christian

The ability to make reports from the Transactions log is helpful. However, unlike nearly every other AppColl report, it does not allow for users to modify which columns are included in the report.

We would like to use a transaction report to alert clients to revisions made to fields that they do not want to have subjected to automatic Syncing. However, we want the report to only list the Matter and the Description fields, not the ID, Created, Who, or Why fields.

It would also be nice to be able to add other Matter fields, such as ClientRef to this report.

Can this be done?

Best,
Christian

Right now, if you Sync Connections from one account to the other, the existing Connections are overwritten in the recipient account. Clients are usually the ones requesting and receiving syncs from their OC; this causes issues since clients are usually also using Invention Manager, which creates IDF records that are then "connected" to the eventual application(s) that they spawn. OC, however, don't usually have Invention Manager and don't have records of their clients' IDFs. As a result, OC's connection data doesn't have the IDF linkages.

This presents a problem when OC syncs connection data to a client, as the current sync causes a wholesale replacement of the client's connection data (for all connections) to be overwritten with the OC connection data. Thus, connections that the client has between IDFs and applications will get overwritten and lost.

It would be a nice if AppColl could be set up so that users that receive syncs could specify what level of syncing should be performed on connections, e.g.:

• Sync priority connections (y/n)?
• Sync subject matter connections (y/n)?
• Sync IDF connections (y/n)?

AppColl would then only sync connections that match the connection types selected. For example, if an account owner specified "y" for priority connections only, then AppColl would, when syncing, only remove and replace connections that are "priority" connections. It would leave any "subject matter" or IDF connections alone.

Since we are not Invention Manager users, I don't know if IDFs have a separate connection type--if they are also "subject matter" connections, it might be nice to allow users to treat them differently from other non-IDF subject matter connections, so I broke them out as a separate category above.

Is this something that could be implemented?

Without it, it makes the Sync feature for connections data pretty much unusable.

Best,
Christian

This relates to some recent suggestions regarding an InventorEmails field (https://forum.appcoll.com/topic/134/new-field-request-inventoremails?_=1663947413348); it might be a more flexible way to get to the same result that could be extended to other fields.

Some contact fields for a matter are actually lists. These include the inventors, applicant(s), and licensee(s). In each case, the contact record(s) that are listed have their own fields. It is sometimes the case that users want to be able to make a list of the contact(s) for those fields, but break out the data for specific fields for each contact within the list. For example, we have a document that we provide to our foreign associates that lists, for each inventor:

<LAST NAME>, <First name> <Middle name>, Citizenship: <Citizenship>
<StreetAddress>,
<City>, <State> <ZIP>
<Country>
<ForeignNickname>

All of this info is provided (if available) for a given inventor before the next inventor is listed. Right now, our template for this is 7800 characters long since we have to essentially create 20 separate field blocks, one for each InventorX (where X is a number from 1 to 20). The format of these blocks is identical, except that "Matter.Inventor1" in every field within the first block gets changed to "Matter.Inventor2" in the second block, and so forth.

What would be great is if there were a Form letter/email syntax that would let a user define a block of text with fields and then bracket it within some sort of syntax block that causes AppColl to replicate the field data in that block that derives from an item in a list for each item in that list.

For example:

{Matter.Inventors.List({MATTER.INVENTORX.LAST}{+032MATTER.INVENTORX.SUFFIX}{+044+032Matter.InventorX.First}{+032Matter.InventorX.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.InventorX.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.InventorX.ForeignNickname}{+013+010Matter.InventorX.Address})}

This would cause AppColl to, for each inventor listed for a matter, generate a text block per the above string.

This syntax could be really useful, I think. You could use it to insert emails for all inventors into an email, e.g.:

{Matter.Inventors.List({Matter.InventorX.EmailAddress}+059**)}**

There could even be a variant of this that adds an additional feature of making a punctuated list, e.g., with commas inserted between blocks (if more than two items in the list) and an " and " inserted before the last item (if more than one item in the list). The syntax for this could be like:

Dear {Matter.Inventors.PunctuatedList({Matter.InventorX.Prefix+032}{Matter.InventorX.Last})}

Which might generate a list like:

Dear Mr. Smith, Mrs. Doe, and Dr. Strange,

This would really enhance form letters/emails.

@MikeO5888 Awesome, so looking forward to it!

The new chat-style Discussion feature is great! We are looking forward to using it. A few suggestions for improving it:

a) Make the chat-style Discussions be accessible via fields in Reports and Email/Form Letters. When this is done, please make it so that there are not double or triple carriage returns between each line, as that will make the data take up much more space. (This is done; thanks!)

b) Make the chat-style Comments for Tasks be visible in the table Task View of Matter Details as a column. (This is also done; thanks again!)

c) Create a feature that allows for bulk and/or automated deletion of Comments. For example, it would be nice to give Admins the ability to run a Matter report and then have a button that allows the Admin to delete all Comments for all of the Matters (and, optionally, Tasks in those Matters) listed in the report without needing to go into each matter/task and individually delete every comment, which seems to be the only way to get rid of them now.... (NOTE: The ability to exclude the chat-style Comments from the transaction log is noted and welcome).

Cheers,
Christian

It would be nice if there was a single form letter field that could be used to add all inventors to an email's TO line. Right now, if you want to add all inventors to an email generated within AppColl, you have to use this:

{Matter.Inventor1.Email};{Matter.Inventor2.Email};{Matter.Inventor3.Email};{Matter.Inventor4.Email};{Matter.Inventor5.Email};{Matter.Inventor6.Email};{Matter.Inventor7.Email};{Matter.Inventor8.Email};{Matter.Inventor9.Email};{Matter.Inventor10.Email};{Matter.Inventor11.Email};{Matter.Inventor12.Email};{Matter.Inventor13.Email};{Matter.Inventor14.Email};{Matter.Inventor15.Email};{Matter.Inventor16.Email};{Matter.Inventor17.Email};{Matter.Inventor18.Email};{Matter.Inventor19.Email};{Matter.Inventor20.Email}

And if you have more than 20 inventors (god forbid!), you're out of luck.

It would be really nice if AppColl just had a field like:

{Matter.Inventors.Email}

...that would add emails for all the inventors to the form letter/email template (separated by semicolons).

This somewhat aligns with another suggestion made on May 13, 2022, for a field like {InventorFirstNames}, which would concatenate a string of inventor first names together (and add commas and "and" where appropriate).

Cheers,
Christian

The Review USPTO Differences task/yellow triangular warning is very useful, but it is also very cumbersome--I would like to ask if it can be made "smarter." In particular, I would like to suggest that it be modified so that if a flagged difference is reviewed and the user selects "Ignore" (or maybe make a new button that is "Ignore Forever"), then any future instance for that matter in which that same discrepancy is found will also be ignored.

We are faced with the situation where almost every time we PAIR scrape a matter, we get USPTO differences--and we spend an inordinate amount of time revisiting the same issues over and over and over.

For example, our docket numbers almost never actually align with what the USPTO has because we use our docket number + our client's docket number in PAIR (clients want us to do this, particularly on shared customer numbers--I'm sure we are not alone in this).

Another example is with PCT priority connections--we store the full PCT serial number in AppColl, e.g., PCT/US2015/012345, while the USPTO (for reasons I cannot fathom) stores the same serial number in the abbreviated form as PCT/US15/12345. These are identical serial numbers, but get repeatedly flagged as being "discrepancies"--every time AppColl flags these, we have to go through the process of reviewing and re-ignoring this discrepancy.

A third example is with Examiner names--the USPTO uses first name, middle initial with no period, LAST IN ALL CAPS. We use first, middle initial with period, last in normal caps. These seem to get flagged every time as well.

If the USPTO discrepancies feature/task weren't so useful, we'd likely turn off the task since it generates a massive amount of tedious work that we have to repeatedly do every time there's a PAIR scrape for a matter. If AppColl could be modified to make some sort of "whitelist" table (akin to the Contact "aliases" field) for each matter that stored each "ignored" value and then did not flag that value again if it showed up in a subsequent scrape for that matter, it would make this feature SOOOOOOO much better/more useful.

Can this be done?

@joe-appcoll-com
Yes--add:

a) the ability to allow the admin for account receiving the sync to review what fields are in the sync report and, for each such field, designate which field in the receiving account's database the sync report field will be imported into (including giving the admin the ability to direct that the synced field NOT be imported into any field in the database of the receiving account). This will vastly improve the Sync feature since it will allow users to map imports between different fields, e.g., law firm uses "AttorneyRef" to store their docket number and ClientRef to store client's docket number, while client uses "ClientRef" to store law firm's docket number and "AttorneyRef" to store their own docket number. It should be possible for either party to set up a Sync of either field and have the receiving party direct that Sync to the field that stores that same data--even if they are different field names in each account.

b) disable any new or modified sync into an account until (a) has been done--this avoids potential catastrophe that may occur if a sync is set up and the underlying report for it is then modified and ends up overwriting data in the recipient's account that was not supposed to be synced.

I suggested this to AppColl directly earlier and know this is being worked on, but figured I'd float here to get feedback from others.

Cheers,
Christian

@jonah-soundhound-com You're correct--I'd forgotten that. Since we just have a generic annuity task instead of country-specific ones, we always docket off the annuity deadline provided by our foreign associates.

There's probably a way to do what you're after, but it would involve a recursive transient event that would retrigger itself in one year intervals from the filing date until just after it passes the issue date, at which point you'd have another task that would trigger off of the recursive one--that one would be your annuity task.

I don't know how to make the recursive transient task stop after it passes the issue date, however, so that's kind of a dealbreaker for now. If you explore this, make the test tasks be internal deadlines so they don't auto-complete and trigger into infinity.

You should be able to do this--we do something similar, but generically for foreign annuities (as opposed to CN-specific ones):

1. Set up the <CN Annuity Due> task to have a RespondBy date that uses the later of 12 months from issue date OR 12 months from triggering task RespondBy date.

2. Set up the triggering for it to have two alternative triggers:

a) When a CN application gets an issue date (or the issue date changes, if you want to be more conservative) OR

b) When a <CN Annuity Due> task completes while the status field in the matter does not include "Expired." If you want, you can tweak this to be "when a <CN Annuity Due> task completes with a "Completed" or "Missed" state--that way you can close the task out with "Abandoned" if you are letting it go and it won't generate the next deadline. <CN Annuity Due> would be whatever you decide to call this task (you're actually recursively triggering it based on itself). NOTE: You may get an extra <CN Annuity Due> task at the end of the patent term that dockets before expiration but for date after it is expired. There's probably a way to deal with this, but I haven't devoted brain power to figuring it out at this time.

I also recommend setting up a <CN Annuity Due - Grace Period> task that triggers whenever the <CN Annuity Due> task completes with a "Missed" status. It would be set to have a RespondBy of 18 months from the TriggeringTask Reference Date. If you set up the <CN Annuity Due> task to auto-close with "Missed," then AppColl should, if you miss an annuity payment, auto-docket both the next annuity deadline AND the final deadline for the current annuity deadline.

Disclaimer: While I think that the above will work as desired, you should, if you attempt the above, test it thoroughly to make sure that it behaves as expected. I make no warranties about whether the above information is correct and assume no responsibility for any damages or liabilities that you may incur if you act on the above information/advice.

Depending on the situation, you could modify the TaskType definition to change the task in question to a "Transient Event"--this causes the task to be auto-generated, thereby allowing it to trigger follow-on tasks and/or send out notifications. But the Transient task will then self-destruct immediately after that and will not appear on your docket. For example, we have our AppColl setup such that all "USPTO e-Office Action: ...." tasks are transient events--they trigger any deadlines they need to trigger and then they vanish.

You can also just turn off or modify auto-docketing for tasks that you find are not useful at all. For example, we turned off the "Review USPTO Communication" triggering completely (actually, we deleted whatever triggers it had). We manually docket it when there is something peculiar needing review, but it otherwise doesn't bother anyone.

It would be nice if the reports feature allowed for more flexible display options for contact-related data. For example, it would be useful to be able to list contacts for a matter in a number of ways, e.g., by full name (as is, I believe, currently the only way you can do so), by initials, by first name last initial, by first name only, by last name only, by first initial last name, by nickname, etc.

It is often the case that contact names take up a significant amount of column space in reports since contacts are typically listed by first/middle/last name. If you have a report that includes attorney, paralegal, contributor, and partner columns, you're likely looking at about a page-width of report space that is occupied by detailed name data. Most of the time, however, providing abbreviated name information would be sufficient--for example, displaying the same information using initials would convey the same information using only 12 characters, thereby consuming much less report real estate.

There could be several ways of implementing this--one would be to simply include the alternate forms of contact name display as separate columns that could be added to a report, e.g., AttorneyFullName, AttorneyInitials, AttorneyNickname, AttorneyFirstInitLastName, etc.

Another option would be to provide a format option for contact columns that are to be included in a report. Each contact column, e.g., Attorney, ClientContact, etc., would, when selected in the column chooser, cause a listbox to be shown that would allow the user to choose between a variety of formats for how that data will be shown. This could also be extended to non-Contact data, e.g., date formats, text data (e.g., All Caps, Sentence Caps, As-entered, etc.).

A third option would be to allow the user to specify a global format setting for the report in question (which could also affect how data is displayed in the Matters/Tasks/etc. modules). For example, the user could specify that Contacts are to be shown using their middle initials as opposed to their full names. This would be applied to all such data in the module in question, so you wouldn't be able to mix-and-match, e.g., have one column with Contacts listed by initials and another column with Contacts listed by full name.

A somewhat related enhancement would be to allow the user to change how the Inventors are listed for a matter. Right now, I think the Inventors field lists inventors by their non-alias ("true") names, even if an alias was used in filing an application. It would be nice to allow users to choose to list inventors for an application using their "true" names and their "as-filed" names. It would also be nice to be able to list such data in a way that indicates when there is a discrepancy between the true inventor name and the as-filed inventor name. For example, in the Matter Details interface, when a listed inventor was listed using an alias when an application was filed, the Inventors list shows both the true name for the inventor and, in parentheses, the alias for that inventor that was used in the filing. It would be great if that could also be an option in the Reports module.

It would be great if users could be given the ability to specify "aliases" to use for column names in a report. These could be displayed in addition to the "normal" column names (or not at all) when viewing the report in AppColl, but if the report is emailed to someone, exported to CSV/PDF, etc., the aliases would be used for the column names instead of the AppColl field names.

Thus, for example, if one sets up a Task report that is intended to be sent to client DeltaCorp on a recurring basis, the "Matter.ClientRef" column could be set up to be labeled "Delta Ref." instead, and the "RefDate" column labeled as "Mail Date," and the Matter.CountryCode column labeled as "Ctry.," and so forth. In that last example, it would allow the report to be much more compact since the column header of "Matter.CountryCode" is much wider than the 2-letter country codes that would be listed under it.

Such a feature would significantly improve the Reports function and eliminate repetitive reformatting/relabeling of the report columns prior to sending such reports to clients.

These aliases, of course, would be cosmetic and would not be usable as filter conditions--it might be nice to display them in AppColl's on-screen displays of reports that use them, but I could also see implementing the feature so that the aliases only appear in the report once it "leaves" AppColl.