That would not solve the problem, because the risk is about undisclosed existing patents held by participating members. If such an essential patent has already been granted, it would block the proposed patent. In fact, any essential patents related to the standard's field of use, even those by cooperating companies that agree to license on RAND terms, would block approval of the proposed patent.
In addition, attempting to patent the standard would involve prohibitive expense and years of delay, and then you still have a potential anti-trust problem should those shared IP owners not license on RAND terms. It is much better to deal with it up front.
Wouldn’t it be better if the standards committee just patented the standard. This would cut off any members coming in later and trying to patent a piece of the standard. The members that came up with the standard could then share in the IP however they saw fit.
We work with Samsung at both the technical level and as an elected member of Si2's Board. Our experience has been positive, with no patent issues and willingness to commit to Si2's IP Policy in multiple projects.
Based on the discounting of Samsung's already FRANDed 3G patents in the Apple vs. Samsung decision, it appears that IP frameworks like yours offer some benefit when things get to the litigation stage. Yet, it appears that rogue companies like Samsung appear willing to violate their previous FRAND agreements with standards bodies and sue over essential patents, even after being stung by previous decisions
Does your organization have dealings with Samsung ? If so, are they sharing information their essential patents and committing to RAND, or are they hiding ?
Yes, a slide summary of Si2's IP Policy is publicly available at: http://www.si2.org/?page=1584
Also, Si2 does maintain all RAND License and Exclusion Certificates received. Rather than having to search through a database, Si2 affixes these certificates to the specification document itself so any IP positions are obvious when someone downloads a specific standard. We also have detailed tracking pages on applicable licenses in the downloads section of our website. Feel free to contact Si2 for more specific questions, we're happy to help.
Generally, it is reasonable to assume that if Intel had a valid license, then Apple could freely use the component purchased from Intel. After all, why else would Intel make a product customers could not use?
Nonetheless, the full legal answer is in fact dependent upon the specific terms of the actual license. There could conceivably be any number of special restrictions or conditions - technically, the rights are subject to whatever the two parties agreed to at the time.
I would have thought that if the 3G license was paid by Intel, and Apple use the Intel chip, then that should be enough, no? The fee has been paid.
Perhaps it's not always so. I too have been stuck with this sort of problem, but happily let our legal types work it out.
Although the Si2 IP Policy's track record has been ideal these last 7 years, we would agree that the broad topic of patents are never truly zero risk. At the end of the day, it is the perceived odds / value of winning vs. the risks incurred that will drive behavior.
That being said, having an up-front signed legal agreement among all parties is pretty strong evidence in any court; the odds of winning against such evidence are virtually non-existent. So this seems to pass the smell test for substantial risk mitigation for "submarine patents" in standards.
Yet even putting that first point aside, hopefully you would agree that the latter two points nonetheless provide vast improvements to full awareness and efficiency throughout the standardization process and would benefit all.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.