Stephan Wenger wrote:
Dear Hector,
I'm not quite sure that your understanding of the US patent law and MPEP
rules is inline with most patent practitioners, or that your post
otherwise make all that much sense.
First, the thing you are talking about are known as "Markush Claim". From
MPEP, 803.02: "A Markush-type claim recites alternatives in a format such
as "selected from the group consisting of A, B and C." It deals with the
examiners reaction to situations where there are too many group members
(typically much more than three, A, B, C; those group members are not
sufficiently closely related to deal with them as a group, and where the
examiner would face a burden to examine the the claim because A, B, and C,
each in combination with the rest of the claim, would require a very
different Prior Art search for each A, B, and C.
My experience come from three folds:
1) As a chemical engineer at Mobil R&D and recalling all the patent
conflicts (and case history) with Exxon strictly based on the "left
hand, right hand," twisting and mirroring of chemical and molecular
structures;
2) Westinghouse training when I was part of a think tank (Advanced
Ventures Division) where the charter was to "Bring back the light bulb
business!" We had a "Card Blanc" to look at everything, to see what
patents will stick, regardless of how simplistic and frivolous. In
order to not waste people time, especially the lawyers, I specifically
recall the chief counsel presentations on Markush with a specific
summarize outline on the two points:
a) You can not patent an combination of prior arts. One new
unique part
must exist.
b) Very importantly, dealing with existing companies that already
used the
prior art and in natural evolution could use a new part. In
other words,
you can not deny a company to grow.
3) Moving in my own business and having Reed-Smith as my legal counsel and
dealing with our technologies. Main point here, much of our system is
already integration of prior art, and what is not, we decided to use
trade secrets instead. I was not allowed to patent ideas of the system
that today I could using the new Patent TimeLine where prior art means
less.
Second, based on my very quick scanning over the patent application in
question here, your whole discussion does not appear to apply as the
application contains not a single Markush claim.
And thats by design because the trick is to claim Plausible
Deniability because once upon a time, it was a criminal fine to
intentional ignore prior art and if it were before a judge, he will
quick toss the patent and will not accept ignorance. That has
changed under today's patent laws where now the applicant is allowed
to update the patent and add the prior art claim.
Third, the developments in patent law (more precisely here: US examination
rules, MPEP, re Markush claims) are US local. Surely, you don't want to
tie the operating procedures of an international organization like the
IETF to a mere rule change in one legislation.
+1, and the fact its global, makes it more difficult. But the problem
is universal.
Fourth, your analysis below of what was/is patentable does not seem
correct. AFAIK, nothing earth-shattering has changed with respect to
patentability of novel combinations of known subject matter. Markush
claims are about a certain way to express selections, but there are many
other ways. For example, I believe in bioscience it is now common
practice to avoid Markush claims and rather spell out all combinations in
dependent claims, and just absorb the excess claim fees. (I have seen
biotech patents with more than 500 claims).
See above. The approach today is not to claim specifics and encompass
the basic integration to avoid the problems in the past. Its goes
along with the idea that beneficiary was generally not the inventor
but rather the 2nd copy cat who was privy now to learn from the
invention and business/market failures of the inventor.
Fifth, and finally, your "idea of a sanction" would result in a major
policy change, essentially disallowing any IETF work moving forward that
is not "100% PUBLIC/FREE/OPEN". This may or may not be a good idea, but
it's not the discussion we have here.
I generally try to get away from specific issues and generally more
interested in solving the overall problem that will serve all. This
case is more than likely typical of things to come and the IETF needs
to be ready for it.
For one thing, the "Note Well" statement means nothing. Its not
binding whatsoever and its most likely skipped by people. Its #1
problem is that it does nothing to address the lurkers. Of course not.
So simply reading a work group is just a good material to get ideas
to patent and guess what? I don't have to write a single note to the
group or even write an I-D or anything like that. So one question may be:
Does becoming a list member to a working group qualifies you as
part of the
Note Well "awareness" regardless of your silent participation?
Second, my only point as a possible consideration is to look at how
Markush is used as a model for the IETF. In other words, all the
parts in the case:
SMTP
IMAP
SIEVE
SIP
are already IETF sanctioned material and anyone can implement these
technologies without any IPR related issue.
The problem is not the patent itself, that is already questionable,
the problem is that the IETF needs to mold the industry mindset so
that the basic idea of adding SIP to your current system using SIEVE
is not IPR restricted. I have no problem with the "Extra Part" that
makes the integration patentable. But combing the two MUST not be
restricted simply because individually there are already unrestricted
IETF technologies.
Finally, whether or not I am out of the loop of what you deem
appropriate for the discussion, my only point and I won't waste any
more time on this, is how I see the issue. Its more a general problem
and really not specific to this SIP+SIEVE issue and if the IETF
doesn't deal with that, this is going to be a very common problem.
Just consider, maybe I am not the norm, like to do I am, but today I
will avoid any IETF I-D that even walks, talks and smells like there
will be any IPR restrictions.
One last point is that my advisers has long recommended that I
completely stay away from the IETF and especially the working groups
and list forums, exactly for many of the reasons we see. I am very
careful of any I-D I did submit and avoided submitting I-D for ideas I
felt had possibilities to be patentable material, especially under the
new patent relaxations for "Business Methods" and less emphasis on
Markush. So in one view, maybe that is the outcome we want - for
people to be more aware of what they are doing. Don't submit
something that you know can be problematic,
Anyway, thanks for your comments.
--
HLS
On 1.26.2012 16:07 , "Hector" <sant9442@xxxxxxxxx> wrote:
Pete Resnick wrote:
Just a heads-up:
Adrian Farrel and I started work on a draft to focus discussion on
sanctions that could be applied to violators of the IETF's IPR policy.
Because of incidents like the present one, we've each been asked by WG
chairs and others what can be done in response to such violations.
We've
centered our draft around sanctions that are available under current
IETF procedures, not introducing new ones. The draft should be
available in the I-D repository soon. We think this could usefully
become an RFC and we would welcome discussion.
Thanks,
pr
Personally, this may be addressing the wrong problem.
However, I do think that a document or change in existing documents
has merit to strongly focus on the fundamental idea that the
integration of IETF RFC published technology is not subject to any
kind of IPR restriction now or in the future.
Thats really the key problem here and its 100% related to the changes
to the patent laws and how that has negatively affected the IETF IPR
model which is old dated.
To the layman, experts call it the new timeline. The problem is the
simplistic ideas that integrating existing known parts where never
patentability prior to 1996. This was relaxed in 1996 with whats
called "Software Methods" or "Business Methods." But what really
changed is the the due diligence was no longer the patent examiner to
perform the full Markus Analysis. He looked for the obvious but much
of the responsibility was expected to be done by the applicant.
This is important because it hits home with all the long time systems,
especially the all the systems out there that use some and/or these
IETF parts and there is no reason to not expect they could use other
IETF parts in the future (i.e. SIP).
From the patent standpoint:
pre-1996 : SIP+SIEVE patent WOULD be denied. The PATENT is on
the new METHOD
unique in the SIP+SIEVE integration, not the
integration itself.
And a PHYSICAL DEMO must exist. The IDEA itself is
not enough.
1996-~2009: SIP+SIEVE patent MAY be denied. The patent MAY
includes the
integration and encompasses all METHODS of integration.
~2009+ : Further relaxation, SIP+SIEVE patent WILL NOT be denied
Any prior art disputes must be added to patent. The
RIGHT
to challenge is not denied but its 100% the burden of
others.
IOW, now this the patent was filed for SIP+SIEVE, the impact is ALL
existing systems, based on the 2009+ laws, CAN NOT add SIP to their
SMTP/IMAP system using SIEVE.
Thats the problem Pete. In short, I can no longer even consider the
idea of using SIP with SIEVE any more even if my integrated method is
unique.
The IETF needs to begin to address this serious problem of people
using IETF technology parts in some integrated method and makes a
"Business Method" patent claim.
I guess, if there is any "sanctions" it would be a simple idea that
once a discovery of a claim is made purely based in the integration of
IETF parts with nothing novel in the claim, then the I-D and/or RPC
would be PULLED and no longer be a IETF document for consideration
without a 100% PUBLIC/FREE/OPEN usage declaration.
Its a tough issue, but I think it becomes simply to deal with once the
strong idea that mere integration of IETF parts is not patentable
material.
--
HLS
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf