[CESG] Implementation of new CCSDS Patent Policy - ISSUES

Shames, Peter M (313B) peter.m.shames at jpl.nasa.gov
Thu Mar 17 19:14:07 EST 2011


Mike,

I think that the purpose of the ISO patent database is to document patents that have been included in ISO standards.  That is a good thing and all relevant patents that have been identified should be in there.  However, that is not sufficient for this purpose since there are new patents all the time and not all existing relevant patents will have been registered.  If someone really cares they will need to do a patent search of at least the US Patent database, where both US and foreign entities (including ESA) have register their claims.  This is true for standards developers and it is true for equipment manufacturers.

I would expect that if any patent is in the ISO registry then any new standard can just point to it and would only need to augment it if it were either a substantial modification of the patent or a substantial modification of its use or the clauses in the patent. I believe that the ISO policy does already have words to that effect.

While it may be true that a prototype might be able to be done without exercising the license, it surely is the intent of the ISO policy that licensing terms are clearly identified and documented.  CCSDS has had this language about exercising the license as part of the prototype for some time, ISO has not such language.    I think we should retain the language, but acknowledge that a prototype might not need a license, but that the license procedures and constraints must be clearly documented.  And note that the ISO legalese essentially inserts a "can't blame us" clause in regards all of this and it seems that the CMC intention is that we adopt it.

As for this last topic, please see my reply to Adrian.  I think that these two cases are not mutually incompatible, but that other statements in the policy are, such as the one that says ...

(4)   Beyond the ISO process, WG chairs should be required to *attempt* to secure the license terms from patent-holders.  However that would not be required in order to develop or approve a standard.

And I agree completely that we need to have a signed Declaration Form in place before the CMC will permit a document to be submitted for agency review.  I am just questioning if we always will require  a completed, signed Declaration Form to be in place prior to even starting a WG. Wouldn't it be satisfactory to have a filled out, but not yet formally signed, form in place at WG start-up to establish any patent dependencies and permit further analysis?  If we do this then anyone can go look up the patent, look up the "Patent Holder", and make some determination or investigation if there are likely to be problems.

I think that the latter might be satisfactory, but it would not surprise me if others have different opinions.

Regards, Peter


From: Mike Kearney <Mike.Kearney at nasa.gov<mailto:Mike.Kearney at nasa.gov>>
Date: Thu, 17 Mar 2011 08:18:21 -0700
To: Adrian Hooke <Adrian.J.Hooke at jpl.nasa.gov<mailto:Adrian.J.Hooke at jpl.nasa.gov>>, Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: RE: [CESG] Implementation of new CCSDS Patent Policy - ISSUES

I believe the purpose of the ISO database is so that once a patent is registered in it, then other standards don’t need to repeat the ISO declaration form process.  The action to the CESG asked the CESG to familiarize the WG chairs with the ISO patent database.  If they find the patent already in the database, no need to do it again.

There were indeed some statements made by at least one CMC member that expressed a belief that therequirement to exercise the license process during prototyping was not needed, or was only needed to the degree required to implement the prototype (if license terms are free for prototyping but some non-zero amount for saleable implementations, then the prototype can take the free option).   However, that was not pursued further than an expressed opinion in the CMC telecon.  I think it’s an area where the CESG can interpret the nuances on exact prototyping procedures.   If there are problems interpreting, the CESG can ask the CMC for clarification.

The resolution stated that no document would be approved without the ISO Declaration form.  The procedure says that a WG charter will not be approved without the ISO declaration form.  Those two statements are not in conflict.  It’s simply required for both.  In cases where a WG didn’t spot the patent issue when they formed,  and should a document magically appear on a CMC poll from a WG that didn’t follow charter procedure, the document will not be approved.

   -=- Mike

Mike Kearney
NASA MSFC EO-01
256-544-2029


From: Hooke, Adrian J (9000) [mailto:adrian.j.hooke at jpl.nasa.gov]
Sent: Thursday, March 17, 2011 10:04 AM
To: Shames, Peter M
Cc: CCSDS Engineering Steering Group - CESG Exec; Kearney, Mike W. (MSFC-EO01)
Subject: RE: [CESG] Implementation of new CCSDS Patent Policy - ISSUES

1) Once a patent issue has been identified, resolved according to the policy, and documented in a Blue Book, there is no need to repeat that same process for any other document that just references that Blue Book.
This discussion came up in the context of the LDPC standard,which is now being finalized in the second review of the Pink Sheets (CCSDS 131.0-P-1.2.  TM Synchronization and Channel Coding. Pink Book.)  The LDPC will need to have the patent issues clarified and an Annex added in alignment with the new policy on patents.  However, if this standard is now adopted within another Blue Book, such as the Prox-1 coding update that is now in discussion, there is no need to do this patent documentation process a second time.  It should be sufficient to do it and document it once, and then just reference the Blue Book where it is documented.

As Greenberg would say, yes and no. In the general case, true – providing that the mission application is the same. The problem with applying to Prox-1 is that it’s a symmetric protocol and that means that an implementer must provide an encoder and a decoder. The current LDPC spec only standardizes the encoder and it completely mute on the subject of decoder patents; that exposes a decoder implementer to potential patent infringement if he/she implements a decoder for the specified code and then gets hit with an undisclosed patent. As long as the current LDPC spec fully discloses all known decoder patents associated with the specified codes then it would work as you say. If not, then the Prox-1 application would have to disclose decoder patents and go through it own documentation process. In either case, the important thing is to tell usersthat there is a patent associated with a decoder design for the specified code, and that they need to either get a license (telling them how) or be very careful that their own design does not infringe on the patent.

We need to get this clarified.  Presumably both clauses are still relevant and there is still a requirement to not only "attempt to secure the license terms", and also to "separately exercise the licensing process during the prototyping and validation process to finalize a Red Book."

There is general agreement that we need to make an attempt to nail down the actual licensingterms but at the end of the day a patent holder can always say one thing and then do another. Which is why the “quality control” text must be added to the Introduction. I personally believe that we need to keep the “separate exercise of the patent” requirement but I think that there was some CMC discord about that. Mike?

3) There are conflicts in the new policy statements vis-a-vis whether resolution of license issues is required before finalizing the standard vs requiring this to be documented before a new doc project can even start.

I frankly can’t follow all of your screen-fulls of convoluted cut-and-splicing and I don’t think that there are any conflicts. (Generally, I do wish that you would try to be more to the point; the value of an e-mail isn’t increased by its length.) The bottom line is that you can’t start a WG without complying with the new process. Since the policy is retroactive, itneeds to be folded into whatever stage the current WG are at. In the specific current case of the three channel codes, none of them can advance to Blue until they comply.

(4)   Beyond the ISO process, WG chairs should be required to *attempt* to secure the license terms from patent-holders.  However that would not be required in order to develop or approve a standard.
I propose that we clarify the CCSDS adopted policy such that it is required that disclosure of patent issues isdone at the earliest possible moment and
that the Declaration Form be used  to document them, but that the requirement to have a final, signed, Declaration Form on file be used as a gate for
the CMC approving release of a draft standard for agency review.  This will permit work to get started, and to proceed, in a WG, but it will ensure
that the expenditure of aggregated agency resources is constrained until any patent issues are identified, resolved and properly documented.

Is this an agreeable clarification of the policy?


Personally, I think that it already allows that. IMHO, there will be cases where we want to be strict and other cases where we understand some special circumstances and allow work to proceed pending resolution of patent issues. What will not be tolerated is someone who has knowledge of an existing or in-work patent and who holds back from disclosing that information until such time that a lot of agency resources have been expended. That would be regarded as a serious breach of professional  fiduciary responsibility to the standardization process. But in the general case we should not allow a WG to start until we completely understand the full patent picture.

///adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110317/0f40652c/attachment-0001.html


More information about the CESG mailing list