This moggy noticed this morning this article in Chemical & Engineering News (the magazine of the American Chemical Society) concerning an error that has been found in the structure of a compound known as TIC10 or ONC201.  The compound, which is the subject of various patents including US 8673923 and the pending EP 2701708 (in the name of Penn State Research Foundation, but apparently licensed to a compnay called Oncoceutics), is currently in clinical trials as an anticancer therapy.

Incorrect structure (top) Correct structure (bottom)

But researchers at Scripps have found that the structure is wrong, and have applied for a patent on the correct structure.  This raises a whole host of questions - Is the first patent invalid and/or will it not cover the actual compound of interest?  Can the second patent be valid?

This Kat is put in mind of cases where the originally determined sequence of proteins has been found to be incorrect.  In the cases he is thinking of, the correct sequence has already been identified in the priority year, and so the downside has been loss of priority, not loss of the whole patent (or effective scope of patent protection). This happened for example in decision T 0080/05 where the European patent for the BRCA1 breast cancer gene EP 0 699 754 was maintained in amended form after the priority claim was held invalid because of a sequence error in the original US application.  The consequence of incorrect sequences is not always the same.  If by luck the difference is a "silent mutation", where different nucleotide sequences would in fact encode for the same amino acid sequence because of the degeneracy of the code, then there may be no problem. If there is an issue with the amino acid sequence itself, however, then the applicant is likely to encounter difficulties under EPO practice.

Some practitioners have felt that this is too strict, and that the law should accept the reality of sequencing errors, and should not punish the applicant who was able to correct the error during the priority year.  Such an approach however has not yet found favour at the EPO. Each situation will turn on its own facts, and depending on the technical consequence of the error, the legal consequence will likely be different.  Thus it is not possible to say in general terms what the consequence is.

Errors in small molecule structure are rarer, and this moggy cannot bring another one to mind.  Again, the precise consequence will depend on the facts of exactly how the first patent is framed; whether the claims are directed towards a structure or a compound defined in another way; and what other information there may be in the specification to enable the skilled person to determine the correct structure.  This Kat cannot say what applies in the present case, not least because he has not seen the second patent application.  It is logically possible however for neither patent to be valid.  If the first patent has claims directed towards the wrong structure, it may well not be infringed by the correct compound, and it is conceivable that this may not be correctable.  There may be issues of enablement as well if the actually claimed compound is inactive.  On the other hand, the patent may disclose enough for a subsequent application to the correct structure to lack novelty (based on the inevitable result of applying the prior art) or at least be obvious.  It will be jolly interesting to see what actually happens.

The article notes surprise from chemists that this compound progressed so far into clinical trials before this error was spotted.  It may be a while before we get another case like the present one, so Merpel advises to make the most of it.

Thanks to Dr Ross Forgan for alerting this Kat to the article.

The CEIC Conference is going on as I write this, and Suzanne Widup's author panel went on yesterday.  I'm not at the conference, so like many others, I live vicariously through what gets Tweeted about the conference, as well as about specific portions of the conference, such as the panel.

I saw a question posted to Twitter, in which the tweeter asked, "for the panel, why not self-publish like RTFM?"

My initial thought was, you need to consider the members of the panel and the books they've written or co-authored; those titles really don't lend themselves too well to a format similar to RTFM, which, in some cases, is described as a collection of notes and tips bound into a book.  For example, I don't think I could see Hacking Exposed Computer Forensics in a format similar to RTFM.  As such, the question is essentially an apples-to-oranges comparison.  While self-publishing definitely has it's place, but may not always the best option for the material, nor for the author.  But that doesn't mean that there aren't publishing possibilities out there that would be very well suited to a format similar to RTFM.

I've addressed this topic before, but it is a good question, and certainly bears addressing.  Essentially, the choice of whether to go with a publisher or to self-publish comes down to how much time and effort you do want to invest in getting the book published...at least, that's my perspective.  Other perspectives might be about what the author gets out of it, or how much someone has to pay for the book.  Writing a book is tough enough as it is...having someone there to do some of those things that need to be done (i.e., formatting, illustrations, copy editing, printing, etc.) in order for the book to be available to others means that the author can focus time and effort on writing the book, and not have to stop and figure out how get something done, or find a resource.

A friend of mine told me that her husband publishes CDs for his band on his own, rather than going through a production firm.  That means that he does everything himself; in some cases this makes perfect sense.  In others, such as writing a DFIR book, maybe not so much.  Most of us don't like to write as it is; if you self-publish, would you have someone review your materials for grammar, consistency, and technical accuracy?  If so, would it be someone you pay for that service?  Where's that money going to come from?  How will you handle illustrations or figures?

As such, consider this... if self-publishing were the sole route available, we'd likely have far fewer books available in the DFIR field.  Or, maybe another way to put it is that if self-publishing really were that easy, we'd have more books.  In the years that I've been involved in writing books, I've seen a fairly good number of folks start down the road and not make it very far, for a variety of reasons.  In some cases, it's due to the realization that there's much more to writing a book than simply having an idea.  When the publisher comes back and gives you a bunch of forms to fill out, and requests a market analysis and a detailed outline, with a swag on a word count, the reality of the situation becomes readily apparent.  I've seen people stop there.  I've also seen one instance where the author got past the point of signing a contract, and the publisher came back later and modified the contract, almost doubling the word count for the final manuscript, but made no other changes to contract, including the delivery date. The author simply walked away.

I've read a number of the reviews for RTFM, and to be honest, the book sounds like a fantastic idea; it was apparently originally intended to be an accumulation of someone's notes to be passed on to their team.  In the right hands, something like that can be extremely useful, and I can relate; when I was in grad school in '95-ish, I taught myself Java programming and relied heavily on O'Reilly's "...in a Nutshell" books for tips and guidance.  I found it very useful, because I wasn't looking for the basics of programming, and the basics of Java programming to be explained to me...I just wanted the bare bones stuff, with no fluff.  Material that might be better suited to an RTFM-like format might be something like what's found here.

Self-publishing simply isn't for everyone...the audience for a book like this is pretty limited.  I can see books like this for using other tools, but I think that one of the strengths of RTFM is that there's the base assumption that anyone purchasing the book is familiar with both operating at the command line, and with Linux.  While there are certain segments of the DFIR community that would strongly suggest that that's exactly how it should be, the fact is that this is far from reality.

Resources
Self-publishing a book: 25 things you need to know - I strongly suggest that you read them all
Lulu.com - self-publishing company
How to self-publish - a guide, with pictures