Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[PP-DIALOG] MSBlock Comments -- First draft of updated IEEE-SA Patent Policy FAQs



Below  are comments for the IEEE Patent Policy FAQs.   I will insert into the unwieldy table shortly. The line headings refer to FAQ numbers. Red highlights direct to more key items. These comments are intended to improve the FAQs and do not suggest abandonment of my concerns with the Policy itself.

******

16/31. The EPC definition here could be improved to be "what the rep believes to be essential or would be essential if the spec is finally approved" -- as in other SDOs.  The "potential" ["may become"] and other uncertain characterizations could  lead to an obligation to disclose non-EPCs.  Some people are asking how to reduce overdisclosure -- this definition promotes overdisclosure.  The concept of a "potential claim"  is also potentially confusing, especially in that patent application claims  may be amended to "become" essential.  

The text should change 'potential claims" and "may become" to  "claims believed by the participant to be  essential if the specification was approved in its current draft form".  While legacy, the change is timely.  

29/31. Once a party, including a third party, submits an LOA for one EPC, IT IS COMMITTED TO FILING FURTHER LOAS FOR OTHER EPCS.  This follows the Policy and is a sleeper likely to surprise third parties and members alike. Put differently, if a party does not submit an LOA, it is fine. But once it submits one LOA, it is obliged to file an LOA on any future potential EPC or is in breach of the Policy. Interesting counterincentive. While this is not a new FAQ, it is counterproductive. I appreciate the desire to address a problem from a previous case, but this text isn't the answer.

After "Additionally, a Submitted of a LOA..." change "is required" to "is encouraged."


43. This FAQ is hard to follow with its reference to two alternatives and "incremental value" which has meaning to economists way beyond what seems to be suggested in the FAQ.  In any event, what does the non-selected alternative have to do with the value and royalty of  the selected alternative? The last sentence of the FAQ is confusing that "Any incremental value imputed to the selected option because of its inclusion in the standard is excluded."  I suggest deleting the last four  sentences and insert what I think was intended:

" A value benchmark  of a selected patented invention is the value it would have if there were no standardization effects. That is, reasonable royalty does not include value arising from the cost or inability of implementers, who have sizable sunk in costs, to change away from the selected patented invention."  

Otherwise, explain how the royalty is affected by the second alternative.  

44.  "smallest saleable compliant implementation" should be informed by recent cases, such as CSIRO v Cisco and VirnetX v Cisco et al.  

46. There seems to be some inconsistency here.  This factor asserts that EPC value should be measured in the context of the EPC relative to the entire standard. That is, "do not value the EPC in isolation of other EPCs in the standard."  But another Policy  factor states that EPC value is confined to the SSCI and should NOT look at the overall value of the product or standard. So we look at the chip that embodies the EPC to determine SSCI and Reasonable Rate, BUT  then confine the Reasonable Rate  based on all the EPCs in the 802.11 standard--  which can include patents on the waterfront.

There is also no mention here of elasticity of price, other than that royalties can be more than price could withstand. There is also no discussion of what implementers are actually licensing/paying and that royalties are not sought for most EPCs.   In the example, there may be just one or a few  EPC holders seeking royalties. Under the FAQ, the EPC holder may be entitled to 2% royalty for value of its EPC, but is relegated to 1% of that because of 100 disclosed patents which may or may not be essential. Court case law has refused to follow the notion that all EPCs (e.g. the 100 disclosed)  are valid and essential and will evoke a royalty. The fraction approach also fails to recognize that different patents may have different value.  

47.  The FAQ does not clarify the  uncertain  "implicit threat of Protective Order" included in the Policy. This condition  could attach to  and possibly exclude many helpful licensing negotiations, to the detriment of EPC holders, implementers, and courts.  Consider the recent CSIRO v Cisco decision in which the implementer presented evidence of a license agreement offered "prior to the inclusion of the 069 patent in any 802.11 standard." The alleged infringer [implementer] argued that "the [agreement] is an actual, real-world license, negotiated at arms-length, not clouded by litigation, and occurring prior to the hypothetical negotiation...[T]hese factors isolate the value of the patented technology."  The limitations in the IEEE Policy "comparables" factor,  left vague and unlimited by the FAQ, would exclude this agreement [in that there was certainly a threat of injunction in CSIRO] and do effectively emasciate the most valuable information for determining reasonableness.  [It is noted that the agreement was not relied on by the CSIRO court, however for reasons unrelated to the timing or potential injunction aspect.] Expressing, in the FAQ, one trivial "example" of  "implicit threat" is of no value. If the FAQs are ashamed of the facts, then perhaps the Policy needs reconsideration.  IEEE should consider the anticompetitive effects of this factor, and the problems it raises with the negotiating parties.

48. Contrary to prior explanations by the Policy drafting team of the term "should" as permissive, this FAQ makes the factors sound like "must" requirements. Moreover the syntax raises questions about the permissive nature of the factors.

A sentence should be added that "The Policy factors are permissive, not required."

56. This FAQ states that  an EPC holder can never seek Prohibitive Order. This is contrary to the Policy itself that states when an Order can be sought.

57. Where does the Policy discuss "burdens of proof" ? Why not state that IEEE  Policy does not change any laws of jurisdictions?  Why leave rules unchanged and not include laws? This is not a FAQ but a Policy issue that needs vetting.
61.  The question is whether an implementer is immunized from injunction for any conduct it engages in. The FAQ provides no useful information in answer to the question.

83.  As for the statement "If any Accepted LOAs on a standard have selected Reciprocal Licensing, then an Applicant can invoke the terms of Reciprocal Licensing", that sentence is flawed and should be deleted. Frankly, I did not interpret the Policy to requirethe EPC licensor to take a license back from the licensee under Reciprocal Licensing. As I interpreted it, the implementer has the option of requesting a license and being offered RAND terms.  That is, to prevent the EPC licensor  itself from being blocked, the licensor can request a license back under RAND terms. Is it intended by the FAQ that, by the EPC holder  checking the "reciprocity" box, the licensee can invoke or force Reciprocal Licensing on the EPC holder?  Suppose the EPC holder has already paid for a license under licensee's EPCs or merely does not wish to take a license under the licensee's EPCs (if there are any) -- after all the licensee has the right to refuse to request or take a license from the EPC holder.  Is the purpose of reciprocity  to place the EPC holder and implementer on equal footing, or is it to turn the crank on the EPC holder? Is this provision suggesting that an EPC holder (implementer) can force another to take a license under its EPCs? This is, of course, a wide departure from existing standards bodies, such as ETSI in which "The above undertaking may be made subject to the condition that those who seek licences agree to reciprocate." The word "may" in ETSI text  allows the EPC holder to seek reciprocity but does not force him/her to accept it or have it imposed by the licensee. Please correct me if my interpretation is wrong, especially if my proposed change reflects the FAQ meaning.    

Replace the sentence: "If an EPC holder has checked the reciprocity box, such licensor may request a license back from the Applicant in accordance with the definition of Reciprocal Licensing."

To the extent that the Policy may be interpreted as stated in  the unrevised FAQ text, the Policy  should be revised.

84. This FAQ cannot be deciphered without the DaVinci Code. It is appreciated that blanket licensing must conform to the patent transfer provision, but the reciprocity, RAND v RF, BUYER v SELLER LOA, etc deserve more open discussion than this FAQ provides. Any such provision should be considered for the Policy, with a FAQ that explains it. This is not some informal guidance but a substantive issue that may impact standards participants. It is appreciated  that the FAQ is largely legacy, but it is still hard to follow.

Marc Sandy Block,
Counsel, Intellectual Property Law
1B117 /  North Castle Drive /  Armonk, NY  10504
msb@xxxxxxxxxx
TL 251-4295  (outside 914-765-4295); fax 251-4290