Before you create a new standard....

Standards create problems. There are way too many of them, and closely-related standards are a source confusion. Often, IP (intellectual property) encumbers standards. Standards often disappear, greatly inconviencing adopters. "Big" standards tend to be dominated by powerful and wealthy corporations and often impose requirements that cannot reasonably be met by small companies or by individuals.

Before embarking on a new standard, committees should try to answer all of these questions:

1. Is there a pre-existing standard that covers the same technology?

2. If there is a pre-existing standard, can it be enhanced or modified to provide a desired functionality?

3. How much will it cost to develop the standard?

4. How long will the standards development process take?

5. Will the intended beneficiaries of the standard pay for the standards development process?

6. Who will develop the standard? Are the selected developers competent to produce an adequate standard?

7. Are any of the developers conflicted? Do they stand to profit if the standard is developed in a specific way?

8. Do any of the developers have proprietary software or data that they may wish to include in the standard?

9. Are the expected developers committed to work through the duration of the standards development process, and are they committed to providing all of the time and energy needed to develop the standard?

10. Will there be a mechanism whereby drafts of the standard are reviewed openly by the public? Will the minutes of the working committee be made public? Will public comments be used to modify successive drafts of the standard?

11. Will the standard have dependencies on other standards? If so, are there intellectual property issues that must be resolved before development begins? Will these issues require licenses or royalty agreements from the standards developers or the standards users?

12. Once created, is the standard likely to be adopted? Is the anticipated standard easily implemented?

13. Who will be the adopters of the standard? Are the expected standard adopters included in the development process for the standard?

14. Will the standard benefit a range of users beyond the standards developers?

15. What are the hazards that the standard may produce, and who might be hurt by the standard? In particular, will any entities be disadvantaged if they cannot readily adopt the standard?

16. Is it necessary to have the standard approved by an external organization?

17. If so, who will pay for the extra costs of obtaining approval from an external standards organization?

18. Will the standard need to be continuously updated and modified? Is there a planned process for producing multiple versions of the standard?

19. Is it really important to have the standard? Is it worth the effort?

Issues related to the development of new standards are discussed at length in my book, Biomedical Informatics.

-Jules Berman

---

My book, Principles of Big Data: Preparing, Sharing, and Analyzing Complex Information was published in 2013 by Morgan Kaufmann.

I urge you to explore my book. Google books has prepared a generous preview of the book contents.

tags: big data, metadata, data preparation, data analytics, data repurposing, datamining, data mining, medical standards

Specifications versus Standards

In a prior blog I suggested 16 ways that SDOs (Standards Development Organizations) can protect their standards from embedded patents. Suggestion 12 was "Make specifications, not standards."

This suggestion, I'm sure, is cryptic to most people. A major theme of this blog site is that specifications are different from standards and have a number of features that make them more suitable than standards for describing and exchanging many types of biomedical information.

Though informaticians often use the terms "specification" and "standard" interchangeably, a specification is just a formal way (usually employing RDF) of describing any data object. A data standard is a set of requirements, created by an SDO, that comprise a pre-determined content and format for a set of data related to a very specific kind of data object.

Features of a "specified" object:

1. Anyone can understand the composition and construction of the object

2. If the object is unique, anyone can distinguish the object from all other objects.

3. If the object falls into a known class of objects, anyone can determine, from the specification, the class of the object.


A specification serves most of the purposes of a standard, and much more (data description, data exchange, data merging, data interoperability, semantic logic). Data specifications spare us most of the heavy baggage that comes with a standard (limited flexibility to include changing data objects, locked-in data descriptors, licensing and other intellectual property issues, competing standards for the same domain resulting in limited interoperability, bureaucratic overhead, etc.).

Readers of this blog might want to read an introduction to RDF data specifications written by myself and Dr. G. William Moore. I believe that standards are important, but that specifications are even more important. There are instances in the field of biomedical informatics where specifications could serve better than standards. This was a developed theme in my book, Biomedical Informatics.I hope to provide many examples of specifications (how they are created and used) in future blogs here.

-Jules Berman

---

Science is not a collection of facts. Science is what facts teach us; what we can learn about our universe, and ourselves, by deductive thinking. From observations of the night sky, made without the aid of telescopes, we can deduce that the universe is expanding, that the universe is not infinitely old, and why black holes exist. Without resorting to experimentation or mathematical analysis, we can deduce that gravity is a curvature in space-time, that the particles that compose light have no mass, that there is a theoretical limit to the number of different elements in the universe, and that the earth is billions of years old. Likewise, simple observations on animals tell us much about the migration of continents, the evolutionary relationships among classes of animals, why the nuclei of cells contain our genetic material, why certain animals are long-lived, why the gestation period of humans is 9 months, and why some diseases are rare and other diseases are common. In “Armchair Science”, the reader is confronted with 129 scientific mysteries, in cosmology, particle physics, chemistry, biology, and medicine. Beginning with simple observations, step-by-step analyses guide the reader toward solutions that are sometimes startling, and always entertaining. “Armchair Science” is written for general readers who are curious about science, and who want to sharpen their deductive skills.

Don't ask the government to write your standard

In an earlier post, I wrote that it was a bad idea for user communities to ask the U.S. government to create their standards.

The government is seldom inclined to create new standards. The government expects user communities to form SDOs (Standards Development Organizations) to create their standards. NIST (National Institue for Standards and Technology) is interested in helping SDOs create standards and is not really interested in taking primary responsibility for new standards.

This government's hands-off approach towards standards is specified by law in the National Technology Transfer and Advancement Act of 1995 (NTTAA), Public Law 104-113, and is explained at some length in a NIST white paper:

Johnsen K, Pugh N. NISTIR 6778 Guidelines for NIST Staff Participating in Voluntary Standards Developing Organizations' Activities. US Department of Commerce, June 2002.

This Act directs Federal agencies to use standards developed by private standards sevelopment organizations, (not government agencies), whenever feasible.

Furthermore, it may be possible for individuals to sue the government for violations of NTTAA. In an opinion published by the Center for Regulatory effectiveness:

"Unless there is `clear and convincing' evidence that Congress intended to preclude judicial review under a statute, persons adversely affected or aggrieved are entitled to seek redress for federal agency violations of that statute under the APA (Administrative Procedure Act)."

There are some very practical reasons why the U.S. government is disinclined to write standards. This general area is discussed at some length in my book, Biomedical Informatics , and I'll be expanding on the issue in future blogs here.

- Jules Berman

---

My book, Principles of Big Data: Preparing, Sharing, and Analyzing Complex Information was published in 2013 by Morgan Kaufmann.

I urge you to explore my book. Google books has prepared a generous preview of the book contents. If you like the book, please request your librarian to purchase a copy of this book for your library or reading room.

Jules J. Berman, Ph.D., M.D.
tags: big data, metadata, data preparation, data analytics, data repurposing, datamining, data mining, biomedical informatics, federal government, medical standards, NIST, NTAA, sdo, specifications, technology transfer

Protecting standards from embedded patents

In a prior blog, I discussed patent farming within standards. I promised another blog with suggestions for SDOs (Standard Development Organizations) that would reduce the risk that their standards were victimized by patent farming.

Here is the list:

1. Work closely with the USPTO (US Patent and Trade Office) or the EPO (European Patent Office) to block trivial or non-original patents applied to your standard. Take advantage of the USPTO peer to peer project.

2. Collect and publish a list of prior art for all the methods included in your standard

3. Where no prior art exists, develop and publish your own "prior" art as open source projects

4. Do your own careful patent search to ensure that your standard does not include any previously patented methods

5. Require your members to search their company's patents to ensure that they have no patents within the standard.

6. The patent searches conducted by companies that are members of the standards committee should include all patents transferred to patent holding
companies

7. Require members of the standards committee to sign agreements (co-signed by authorized representtives of their companies) that no company patents (held or transferred) or claims will apply to the standard.

8. Whenever possible, use open, or public domain, or old (> 20 years) methods within your standards.

9. Whenever possible, use "escape" methods in the standard so that users are not locked into a single method that implements the standard

10. Make optional standards, not required standards, so that the user community is not locked into one implementation

11. Make interoperable standards (that can port to-and-from related standards)

12. Make specifications, not standards (to be explained in a later blog - JB)

13. Have open [to the public] committee meetings and publish the minutes of your meetings

14. Include a "user advocate" in the standards committee

15. Publish the efforts you have made to comply with some or all of the suggestions in items 1 through 14.

16. As a user, whenever possible, use standards that were developed with most of the suggestions from this list. Remember, it is the user (not the SDO) that will pay for patents embedded within standards.

Nothing can reduce your risk to zero, but following these items can help. I will be writing future blogs that explain specific items from the list.

- Jules Berman

tags: embedded patents, european patent office, hidden patents, medical standards, patent farming, prior art, sdo, specifications, standards development organizations, trivial patents, uspto

---

Science is not a collection of facts. Science is what facts teach us; what we can learn about our universe, and ourselves, by deductive thinking. From observations of the night sky, made without the aid of telescopes, we can deduce that the universe is expanding, that the universe is not infinitely old, and why black holes exist. Without resorting to experimentation or mathematical analysis, we can deduce that gravity is a curvature in space-time, that the particles that compose light have no mass, that there is a theoretical limit to the number of different elements in the universe, and that the earth is billions of years old. Likewise, simple observations on animals tell us much about the migration of continents, the evolutionary relationships among classes of animals, why the nuclei of cells contain our genetic material, why certain animals are long-lived, why the gestation period of humans is 9 months, and why some diseases are rare and other diseases are common. In “Armchair Science”, the reader is confronted with 129 scientific mysteries, in cosmology, particle physics, chemistry, biology, and medicine. Beginning with simple observations, step-by-step analyses guide the reader toward solutions that are sometimes startling, and always entertaining. “Armchair Science” is written for general readers who are curious about science, and who want to sharpen their deductive skills.

Patent farming in medical standards

In a prior blog, I listed some of the IP issues involving medical standards. One of the biggest problems is the inclusion of patented methods within standards. Hidden patents within standards can be asserted against anyone who implements the standard.

Bruce Perens, an open source Guru, has written extensively on this problem. He uses the term "patent farming" to describe the act of planting the seed, a patented method, into the standard while the standard is being developed. Once the standard is approved and implemented by the user community, the patent farmer reaps his crop by asserting the hidden patent. Perens provides several specific examples where patent farming has benefited standards committee members to the detriment of the users of the standard.

You might think that it would be a simple matter to require the participants in a standards effort to disclose any of their owned patents that might be included in the standard. In the Rambus case described by Perens, such a disclosure agreement was in evidence, but the patent disclosure policy of the standards organization proved unenforceable in court.

Even if an SDO (Standards Development Organization) had an enforceable disclosure agreement with its members, it would seem that a committee member could sell strategic patents to a patent holding company, striking a deal with the holding company that would yield IP earnings on an asserted patent positioned within a standard. By working with a holding company, the original patent holder divests the patent and would not need to disclose the existence of the patent to the standards committee.

Patent holding companies (called patent trolls by their detractors) buy portfolios of patents to assert IP rights in strategically chosen business sectors. Recently, hospital-based technologies (including radiology imaging) have been the target of at least one major patent holding company.

In the next blog, I will discuss measures that SDOs may take to reduce their vulnerability to patent farmers. I will also discuss some defensive strategies that are often suggested but which really do not work.

This blog will also appear on Bruce Friedman's Labsoft
site

- Jules Berman

---

My book, Principles of Big Data: Preparing, Sharing, and Analyzing Complex Information was published in 2013 by Morgan Kaufmann.

I urge you to explore my book. Google books has prepared a generous preview of the book contents.

tags: big data, metadata, data preparation, data analytics, data repurposing, datamining, data mining, hidden patent, intellectual property, ip, medical standards, patent holding company, patent troll, specification, viral patent